From kilobit at gmail.com Sat Nov 1 05:20:15 2008 From: kilobit at gmail.com (bas) Date: Sat, 1 Nov 2008 11:20:15 +0100 Subject: Sending vs requesting. Was: Re: Sprint / Cogent Message-ID: On Fri, Oct 31, 2008 at 7:03 PM, Patrick W. Gilmore wrote: > If Sprint is upset that Cogent is sending Sprint much more traffic than > Sprint is sending Cogent, how does Sprint sending Cogent even less traffic > (and making the ratio even worse) help Sprint? Why would Cogent care? Why does everyone keep referring to traffic flows as sendng? In this case it's not as if Cogent just randomly sends data to Sprint. Sprint customers are requesting content from Cogent customers right? So Sprint depeers Cogent because Sprint customers are requesting to much content from Cogents customers? I've heard eyeball networks refer to traffic flows as sending too.. "You content hosters are sending us too much traffic, we want money to upgrade ports and transport all that traffic" Complete reverse logic imho. It is always eyeball network customers that request data. (except for a small portion of iphone/blackberry push email, but that can't account for much.) Bastiaan From jeremy at manor.org Sat Nov 1 08:22:44 2008 From: jeremy at manor.org (Jeremy Hartman) Date: Sat, 1 Nov 2008 09:22:44 -0400 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: References: Message-ID: <3dae084d0811010622u11467405q4ce0a37d8255d141@mail.gmail.com> On Sat, Nov 1, 2008 at 6:20 AM, bas wrote: > On Fri, Oct 31, 2008 at 7:03 PM, Patrick W. Gilmore > wrote: > > If Sprint is upset that Cogent is sending Sprint much more traffic than > > Sprint is sending Cogent, how does Sprint sending Cogent even less > traffic > > (and making the ratio even worse) help Sprint? Why would Cogent care? > > Why does everyone keep referring to traffic flows as sendng? > In this case it's not as if Cogent just randomly sends data to Sprint. > > Sprint customers are requesting content from Cogent customers right? > So Sprint depeers Cogent because Sprint customers are requesting to > much content from Cogents customers? > > I've heard eyeball networks refer to traffic flows as sending too.. > "You content hosters are sending us too much traffic, we want money to > upgrade ports and transport all that traffic" Complete reverse logic > imho. It is always eyeball network customers that request data. > (except for a small portion of iphone/blackberry push email, but that > can't account for much.) > > Bastiaan > > it makes little to no difference how you skin that cat... the traditional model still plagues so called "content rich" networks and has been used, shamelessly, by the eyeball networks with no end in sight. i am by no means defending cogent, nor do i claim to know that ratios are the only item on the list of violated peering agreement clauses. my particular complaint is that with the upswing of broadband in this country it is continually less and less to do with "how many direct eyeballs do i have" and more to do with "to which cable/dsl providers do i provide transit." the former was used as a cost-model basis for the eyeball networks requiring ratios as it was far more expensive to establish a broad presence to provide eyeball connectivity... the latter does not match that logic and has yet to filter it's way into fair settlement-free peering agreements. /jer From patrick at ianai.net Sat Nov 1 10:47:11 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 1 Nov 2008 11:47:11 -0400 Subject: Why do some companies get depeered and some don't? In-Reply-To: <1354846503.117451225431145641.JavaMail.root@mbv2.indiatimes.com> References: <1354846503.117451225431145641.JavaMail.root@mbv2.indiatimes.com> Message-ID: <978AF989-64D5-4A00-93F1-0BF79BBA05DA@ianai.net> On Oct 31, 2008, at 1:32 AM, Nelson Lai wrote: > Why do some companies like Cogent get depeered relatively often and > companies like Teleglobe don't even get talked about and operate in > silence free from depeering? That's funny. One of the first networks to de-peer Cogent was Teleglobe. They re-peered after a bit. The next obvious question is: When Sprint, Telia & L3 de-peering Cogent, it causes a lot of news in the press & noise on NANOG, so why didn't you know Teleglobe depeered Cogent? Is this because Teleglobe runs a better network than Sprint? Well, that's hard to say, but please note that when Teleglobe depeered Cogent, they were disconnected just as Sprint & Cogent are disconnected now. Doesn't matter how 'good' a network you run, if packets won't go there, you can't get there. I'll leave it as an exercise to the reader to figure out the rest. -- TTFN, patrick From dts at senie.com Sat Nov 1 10:37:30 2008 From: dts at senie.com (Daniel Senie) Date: Sat, 01 Nov 2008 11:37:30 -0400 Subject: Sprint / Cogent In-Reply-To: References: <200810311323.m9VDNCcI081807@aurora.sol.net> <490B2215.6000601@inex.ie> Message-ID: <200811011549.mA1FnBwC029551@parsley.amaranth.net> At 01:20 PM 10/31/2008, Randy Epstein wrote: >If you haven't already seen it, the great Todd Underwood of Renesys >published an article today on his blog regarding this subject: > >http://www.renesys.com/blog/2008/10/wrestling-with-the-zombie-spri.shtml Just read through Todd's blog posting. Since I'm travelling at the moment with a Sprint EVDO card as my connectivity, I now understand why some sites have not been working. I assume my Sprint phone SMS service is also impacted, insofar as any text-to/from-email will not work to sites on the affected networks either. The micro-browser in my phone will have been affected too, though it's too useless to really use anyway. If I can find a way to fax the corporate offices of Sprint on Monday, I'll ask them for a refund on my service charges for the month, since they're now selling me access to only part of the Internet from my mobile devices. Funny, I'd just checked a few days ago to see if my mobile devices are beyond any term commitment. Since they are, I will now look at changing to another wireless carrier at the next reasonable opportunity. Did Sprint think about the fact that their decision would actually impact their wireless customers? I'm sure my business's wireless devices won't make or break Sprint's profits, but wonder if larger businesses using EVDO might also raise concern? Is Sprint now lying about selling "Unlimited Internet Access from anywhere" when peddling their data cards? Is Sony, as well, by inclusion of EVDO cards within their notebook computers? I presume their actuarial staff ran the numbers and decided the risk was worth it, and that's what they'll tell their stock holders. From tme at multicasttech.com Sat Nov 1 11:02:48 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 1 Nov 2008 12:02:48 -0400 Subject: Sprint / Cogent In-Reply-To: <200811011549.mA1FnBwC029551@parsley.amaranth.net> References: <200810311323.m9VDNCcI081807@aurora.sol.net> <490B2215.6000601@inex.ie> <200811011549.mA1FnBwC029551@parsley.amaranth.net> Message-ID: <9D32FE50-C928-46C6-A709-3CEF9550D29D@multicasttech.com> On Nov 1, 2008, at 11:37 AM, Daniel Senie wrote: > At 01:20 PM 10/31/2008, Randy Epstein wrote: >> If you haven't already seen it, the great Todd Underwood of Renesys >> published an article today on his blog regarding this subject: >> >> http://www.renesys.com/blog/2008/10/wrestling-with-the-zombie-spri.shtml > > Just read through Todd's blog posting. Since I'm travelling at the > moment with a Sprint EVDO card as my connectivity, I now understand > why some sites have not been working. I assume my Sprint phone SMS > service is also impacted, insofar as any text-to/from-email will not > work to sites on the affected networks either. The micro-browser in > my phone will have been affected too, though it's too useless to > really use anyway. > > If I can find a way to fax the corporate offices of Sprint on > Monday, I'll ask them for a refund on my service charges for the > month, since they're now selling me access to only part of the > Internet from my mobile devices. I have had occasion to dispute a Sprint charge. To do that, send a physical letter to Sprint Correspondence Customer Disputes PO 15955 Shawnee Mission, Kansas 66285 (This is for "residential" not business accounts.) Regards Marshall > Funny, I'd just checked a few days ago to see if my mobile devices > are beyond any term commitment. Since they are, I will now look at > changing to another wireless carrier at the next reasonable > opportunity. > > Did Sprint think about the fact that their decision would actually > impact their wireless customers? I'm sure my business's wireless > devices won't make or break Sprint's profits, but wonder if larger > businesses using EVDO might also raise concern? Is Sprint now lying > about selling "Unlimited Internet Access from anywhere" when > peddling their data cards? Is Sony, as well, by inclusion of EVDO > cards within their notebook computers? I presume their actuarial > staff ran the numbers and decided the risk was worth it, and that's > what they'll tell their stock holders. > > > From cmadams at hiwaay.net Sat Nov 1 11:05:26 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 1 Nov 2008 11:05:26 -0500 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: References: Message-ID: <20081101160526.GB921665@hiwaay.net> Once upon a time, bas said: > I've heard eyeball networks refer to traffic flows as sending too.. > "You content hosters are sending us too much traffic, we want money to > upgrade ports and transport all that traffic" Complete reverse logic > imho. It is always eyeball network customers that request data. > (except for a small portion of iphone/blackberry push email, but that > can't account for much.) Traffic sources tend to be concentrated in large data centers (easier to service), while traffic sinks (DSL, cable, wireless) are widespread and costly to upgrade. The sink customers don't want to pay more (and there's at least some competition), so the sink providers look to see where else they get income to pay for their needed network upgrades. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From patrick at ianai.net Sat Nov 1 11:45:31 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 1 Nov 2008 12:45:31 -0400 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: <20081101160526.GB921665@hiwaay.net> References: <20081101160526.GB921665@hiwaay.net> Message-ID: On Nov 1, 2008, at 12:05 PM, Chris Adams wrote: > Once upon a time, bas said: >> I've heard eyeball networks refer to traffic flows as sending too.. >> "You content hosters are sending us too much traffic, we want money >> to >> upgrade ports and transport all that traffic" Complete reverse logic >> imho. It is always eyeball network customers that request data. >> (except for a small portion of iphone/blackberry push email, but that >> can't account for much.) > > Traffic sources tend to be concentrated in large data centers > (easier to > service), while traffic sinks (DSL, cable, wireless) are widespread > and > costly to upgrade. The sink customers don't want to pay more (and > there's at least some competition), so the sink providers look to see > where else they get income to pay for their needed network upgrades. Combined with hot-potato routing, the first part of that paragraph is a fancy way of saying "I have to carry the large packet a long way, you have to carry the small packet a long way". It is not "fair". This is almost a good reason, but not quite. (It can also be offset by moving the source next to the sink, through cold-potato routing / MEDs, anycast, CDNs, etc.) The second part is a good business reason. Profitable revenue is good, costs are bad. There are good business reasons not to pay the sink as well. But neither decision is obvious or the same for everyone. Peering is complicated, people should stop trying to generalize it. Peering is a business tool. For years & years many people have claimed that to "peer" you must be equal. Bullshit. If I can make more or spend less by peering, I should do it. If not, I should not. Full stop. Notice the complete lack of regard for how big you are, how much capacity your backbone has, how many ASes are downstream of you, etc.? When I go to buy routers or hire employees or any other business transaction, I don't say "that router vendor is making more money than I am, so I won't buy from him". If people applied "peering" logic to anything else, they'd be laughed out of a job. Don't know about you, but I am in business to make money, not measure my anatomy. How big the next guy is doesn't enter into my equation - other than how it affects my bottom line. To be clear, it is entirely possible that peering does not save you money. Vijay is right, most people can't measure their COGS to save their life. And if the network in question cannot, there's no way in hell the prospective peer can. If you are a huge point source of traffic and want to peer, I may save money by saying no and paying a transit provider to deliver the packet to me where I want it (especially at today's prices). Fiber, routers, colo, NOC employees, engineers, etc., are all not free ya know. You can claim my customers asked for the data and therefore I have a requirement to peer, but you would be deluded. What my customer and I have agreed has _nothing_ to do with you or your needs. You don't tell me how to run my network, and I won't tell you how to run yours. Deal? On the flip side, saying "you are not on 3 continents so I will not peer" is stupid of not peering costs you millions a year. Stupid decisions abound in the peering ecosystem. There are tons of other _business_ reasons to peer, or not to peer. But "we're equal" or "your customer asked for it" are not reasons, stop using them. -- TTFN, patrick From blyon at blyon.com Sat Nov 1 12:30:25 2008 From: blyon at blyon.com (Barrett Lyon) Date: Sat, 1 Nov 2008 10:30:25 -0700 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: References: <20081101160526.GB921665@hiwaay.net> Message-ID: <71128E40-3FEE-4442-859D-C03E8ACA52D6@blyon.com> Patrick, To further your point about the dynamics of peering: Not to sound overly altruistic, but nowhere in there did I see, "it's good for the Internet". If peering was less of a raw business decision, the Internet would be a better place. In this case, if they left it status quo and congested, at least users could send smoke signals across the two networks and could at least communicate. The implications of this depeering could be pretty severe. If you dive into business ethics, there's some pretty serious moral dilemmas involved with cutting communications between two major networks. This could be taken to an extreme if it causes VoIP calls to fail and ultimately disrupts someone's 911 calling. In less reaching situations, someone can't SMS with their wife to know what to bring home from the grocery store. Regardless of how stupid relying on the Internet is (I know it's sad we can't) I do feel networks have a moral responsibility to provide continuity. As you know, beyond business, peering can decrease latency, increase throughput, and provide better network engineering, thus increasing the scale of the overall Internet. As a technologist and entrepreneur I try to do what's best for the Internet in my peering decisions rather than what Bill Lumbergh would say, "umm yeah, do what's best for the company". In this case, it's very clear that customers are impacted and the Internet as a whole suffers, which is really unfortunate. The end result of a business decision has been to sacrifice the customer's needs, trust, and ability to communicate. It's a bad maxim to subscribe to! I really hope that other networks do apply more thinking into peering than just what's best for business -- it sure shows off an ugly underbelly. -Barrett On Nov 1, 2008, at 9:45 AM, Patrick W. Gilmore wrote: > On Nov 1, 2008, at 12:05 PM, Chris Adams wrote: >> Once upon a time, bas said: >>> I've heard eyeball networks refer to traffic flows as sending too.. >>> "You content hosters are sending us too much traffic, we want >>> money to >>> upgrade ports and transport all that traffic" Complete reverse >>> logic >>> imho. It is always eyeball network customers that request data. >>> (except for a small portion of iphone/blackberry push email, but >>> that >>> can't account for much.) >> >> Traffic sources tend to be concentrated in large data centers >> (easier to >> service), while traffic sinks (DSL, cable, wireless) are widespread >> and >> costly to upgrade. The sink customers don't want to pay more (and >> there's at least some competition), so the sink providers look to see >> where else they get income to pay for their needed network upgrades. > > Combined with hot-potato routing, the first part of that paragraph > is a fancy way of saying "I have to carry the large packet a long > way, you have to carry the small packet a long way". It is not > "fair". This is almost a good reason, but not quite. (It can also > be offset by moving the source next to the sink, through cold-potato > routing / MEDs, anycast, CDNs, etc.) > > The second part is a good business reason. Profitable revenue is > good, costs are bad. > > There are good business reasons not to pay the sink as well. But > neither decision is obvious or the same for everyone. > > Peering is complicated, people should stop trying to generalize it. > > > Peering is a business tool. For years & years many people have > claimed that to "peer" you must be equal. Bullshit. If I can make > more or spend less by peering, I should do it. If not, I should > not. Full stop. Notice the complete lack of regard for how big you > are, how much capacity your backbone has, how many ASes are > downstream of you, etc.? When I go to buy routers or hire employees > or any other business transaction, I don't say "that router vendor > is making more money than I am, so I won't buy from him". If people > applied "peering" logic to anything else, they'd be laughed out of a > job. > > Don't know about you, but I am in business to make money, not > measure my anatomy. How big the next guy is doesn't enter into my > equation - other than how it affects my bottom line. > > To be clear, it is entirely possible that peering does not save you > money. Vijay is right, most people can't measure their COGS to save > their life. And if the network in question cannot, there's no way > in hell the prospective peer can. If you are a huge point source of > traffic and want to peer, I may save money by saying no and paying a > transit provider to deliver the packet to me where I want it > (especially at today's prices). Fiber, routers, colo, NOC > employees, engineers, etc., are all not free ya know. > > You can claim my customers asked for the data and therefore I have a > requirement to peer, but you would be deluded. What my customer and > I have agreed has _nothing_ to do with you or your needs. You don't > tell me how to run my network, and I won't tell you how to run > yours. Deal? > > On the flip side, saying "you are not on 3 continents so I will not > peer" is stupid of not peering costs you millions a year. Stupid > decisions abound in the peering ecosystem. > > There are tons of other _business_ reasons to peer, or not to peer. > But "we're equal" or "your customer asked for it" are not reasons, > stop using them. > > -- > TTFN, > patrick > > From dfblaine at gmail.com Sat Nov 1 18:59:31 2008 From: dfblaine at gmail.com (Dave Blaine) Date: Sat, 1 Nov 2008 16:59:31 -0700 Subject: routing around Sprint's depeering damage Message-ID: There are at least three ways to address this Sprint / Cogent partition: 1. Send Vint Cerf back up to Capitol Hill with a doomsday scenario of what would happen to the economy if anyone else gets as stupid as Sprint has been, begging for laws that any tier-1 or tier-2 who wants to de-peer needs to provide all their customers and peers with 90 day notice or face stiff fines. Send John Schnizlein along with him to get the House Communications Director an Akamai hosting account. Repeat the "eyeballs-or-data, which is more valuable" mantra whether or not there are still forty Republicans in the Senate. 2. Pick up some more fiber, dust off the router manuals, and allow and recommend that tier-1s transit any third party tier-1-to-tier-1 traffic. 3. Both. Which is the best way? From mpetach at netflight.com Sat Nov 1 19:00:46 2008 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 1 Nov 2008 17:00:46 -0700 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: <71128E40-3FEE-4442-859D-C03E8ACA52D6@blyon.com> References: <20081101160526.GB921665@hiwaay.net> <71128E40-3FEE-4442-859D-C03E8ACA52D6@blyon.com> Message-ID: <63ac96a50811011700h441a411et5785986f6ae5f9fa@mail.gmail.com> On 11/1/08, Barrett Lyon wrote: ... > In this case, it's very clear that customers are impacted and the Internet > as a whole suffers, which is really unfortunate. The end result of a > business decision has been to sacrifice the customer's needs, trust, and > ability to communicate. It's a bad maxim to subscribe to! I really hope > that other networks do apply more thinking into peering than just what's > best for business -- it sure shows off an ugly underbelly. > > -Barrett Unfortunately, as I'm sure you're all too aware, for public companies, it's very hard to get away with saying "I was doing what was right for the Internet, not what would make my business the most money" at a shareholder meeting, or during an earning's call with Wall Street analysts; they tend to be very unforgiving of actions that aren't in line with the short-term profit-making goal, to the point where CEOs have been ousted and class-action lawsuits threatened when it seems the actions being taken weren't geared to optimize profits for the shareholders. Converging two threads together, I think the same pressure affects IPv6 deployment and will affect IPv6 peering; while it would be *best* for the Internet if everyone put the time and resources forward to get dual-stacked now, bring up widespread peering, and get IPv6 to a point where it's a viable transport mechanism, the real fact of the matter is that there's no profit motive in moving to IPv6 at the moment, so people just aren't going to do it, no matter how much it may be "best for the Internet". Fix the market drivers for public companies, and then we can fix the Internet; otherwise, we'll always be steering towards that which makes sense for the business, regardless of which customers of other networks it hurts, or which resource exhaustion cliff it hurtles us towards. Putting on a devil's advocate hat for a moment...if various international regulatory bodies and government agencies mandated universal connectivity via both IPv4 and IPv6, depeering would cease to be an issue; regardless of what the business side said, companies would not be allowed to partition the Internet, and widespread adoption of IPv6 would be forced, rather than being a "maybe someday" case. Downside is that prices would go up, and expansion into new regions would slow down, as the costs associated with developing new areas would bring a much higher price tag. It would be better for the Internet as a whole, but worse for most of the individual users of it, from a cost perspective. Would you still say things were better for the overall Internet at that point, if it meant everyone had to pay more in order to ensure that universal connectivity? I'm cheap, so I'm leaning towards the side of letting the market work these issues out; but I'm always willing to listen to other thoughts on the matter. :) Matt From LarrySheldon at cox.net Sat Nov 1 19:04:08 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 01 Nov 2008 19:04:08 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: References: Message-ID: <490CEE78.5030506@cox.net> Dave Blaine wrote: > Which is the best way? More regs and more laws is certainly not in the running. How about: If there is a need, somebody will provide at a suitable price? If no body steps up, we don't need it. From blyon at blyon.com Sat Nov 1 19:37:54 2008 From: blyon at blyon.com (Barrett Lyon) Date: Sat, 1 Nov 2008 17:37:54 -0700 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: <63ac96a50811011700h441a411et5785986f6ae5f9fa@mail.gmail.com> References: <20081101160526.GB921665@hiwaay.net> <71128E40-3FEE-4442-859D-C03E8ACA52D6@blyon.com> <63ac96a50811011700h441a411et5785986f6ae5f9fa@mail.gmail.com> Message-ID: <12B0C816-5E91-4758-AC48-66DF7E89D8C6@blyon.com> True... however this depeering may have created more of a mess for Sprint's marketing and their customers than they predicted, which has a negative impact on business and would not be fun to explain at a board meeting. I guess it's hard for sweater vests to understand that until it smacks them in the face. -Barrett On Nov 1, 2008, at 5:00 PM, Matthew Petach wrote: > On 11/1/08, Barrett Lyon wrote: > ... >> In this case, it's very clear that customers are impacted and the >> Internet >> as a whole suffers, which is really unfortunate. The end result of a >> business decision has been to sacrifice the customer's needs, >> trust, and >> ability to communicate. It's a bad maxim to subscribe to! I >> really hope >> that other networks do apply more thinking into peering than just >> what's >> best for business -- it sure shows off an ugly underbelly. >> >> -Barrett > > Unfortunately, as I'm sure you're all too aware, for public > companies, it's > very hard to get away with saying "I was doing what was right for the > Internet, not what would make my business the most money" at a > shareholder meeting, or during an earning's call with Wall Street > analysts; they tend to be very unforgiving of actions that aren't in > line with the short-term profit-making goal, to the point where CEOs > have been ousted and class-action lawsuits threatened when it > seems the actions being taken weren't geared to optimize profits > for the shareholders. > > Converging two threads together, I think the same pressure affects > IPv6 deployment and will affect IPv6 peering; while it would be *best* > for the Internet if everyone put the time and resources forward to get > dual-stacked now, bring up widespread peering, and get IPv6 to a > point where it's a viable transport mechanism, the real fact of the > matter is that there's no profit motive in moving to IPv6 at the > moment, so people just aren't going to do it, no matter how much > it may be "best for the Internet". > > Fix the market drivers for public companies, and then we can > fix the Internet; otherwise, we'll always be steering towards > that which makes sense for the business, regardless of which > customers of other networks it hurts, or which resource exhaustion > cliff it hurtles us towards. > > Putting on a devil's advocate hat for a moment...if various > international > regulatory bodies and government agencies mandated universal > connectivity via both IPv4 and IPv6, depeering would cease to be > an issue; regardless of what the business side said, companies > would not be allowed to partition the Internet, and widespread > adoption > of IPv6 would be forced, rather than being a "maybe someday" case. > Downside is that prices would go up, and expansion into new regions > would slow down, as the costs associated with developing new areas > would bring a much higher price tag. It would be better for the > Internet > as a whole, but worse for most of the individual users of it, from a > cost > perspective. Would you still say things were better for the overall > Internet at that point, if it meant everyone had to pay more in order > to ensure that universal connectivity? > > I'm cheap, so I'm leaning towards the side of letting the market > work these issues out; but I'm always willing to listen to other > thoughts on the matter. :) > > Matt From mmc at internode.com.au Sat Nov 1 19:43:25 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 02 Nov 2008 11:13:25 +1030 Subject: routing around Sprint's depeering damage In-Reply-To: References: Message-ID: <490CF7AD.50800@internode.com.au> Dave Blaine wrote: > There are at least three ways to address this Sprint / Cogent partition I'd be fairly reluctant to allow the government to get involved in peering relationships too deeply. Australia has some very wierd consquences of our government doing so almost ten years on. One of those is which is that the "Gang of Four" have effectively set a floor price on domestic transit that is much higher than it should be - meaning that much content is delivered to us from overseas because the cost of delivering in Australia to those networks is too high to do so economically. Even a lot of Australian content is hosted overseas for this reason. Consider that this is in a land where the broadband providers don't have to deliver unlimited for a fixed price. (Would things have been different without this government directive? Hmm. Dunno. Feel free to discuss). -- Matthew Moyle-Croft - Internode/Agile - Networks From mmc at internode.com.au Sat Nov 1 21:07:05 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 02 Nov 2008 12:37:05 +1030 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: References: Message-ID: <490D0B49.6050304@internode.com.au> bas wrote: > Why does everyone keep referring to traffic flows as sendng? > In this case it's not as if Cogent just randomly sends data to Sprint. > I think it's a really odd reinterpretation of telephony concepts. In telephony interconnects are typically settlement based, sender pays receiver, in the settlement based world it seems to have gotten confused. I'm still trying to come to terms with what Sprint is trying to achieve here. I can only assume it's (and I'm stealing from Vijay here) to raise Cogent's cost of doing business by forcing them to do settlement based or paid peering and thus trying to force the cost of their transit to rise. Maybe it's to damage Cogent's reputation as well? The cost of doing this seems to be high (ie. upsetting high paying (single homed) transit and mobile customers) and getting negative media coverage. Is this really going to make a substantial kind of difference? MMC -- Matthew Moyle-Croft - Internode/Agile - Networks From mmc at internode.com.au Sat Nov 1 21:16:59 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 02 Nov 2008 12:46:59 +1030 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: <490D0B49.6050304@internode.com.au> References: <490D0B49.6050304@internode.com.au> Message-ID: <490D0D9B.4010306@internode.com.au> Matthew Moyle-Croft wrote: > >> > I think it's a really odd reinterpretation of telephony concepts. In > telephony interconnects are typically settlement based, sender pays > receiver, in the settlement based world it seems to have gotten confused. "in the settlement FREE world it seems to have gotten confused." MMC -- Matthew Moyle-Croft - Internode/Agile - Networks From scott.berkman at reignmaker.net Sat Nov 1 22:00:56 2008 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Sat, 1 Nov 2008 23:00:56 -0400 (EDT) Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: <490D0B49.6050304@internode.com.au> References: <490D0B49.6050304@internode.com.au> Message-ID: <03ee01c93c97$9ddd63f0$d9982bd0$@berkman@reignmaker.net> I really doubt Sprint's purpose here is to "hurt the Internet" or to harm Cogent either in terms of costs or reputation. Here are my views on the topic: Every time Cogent gets de-peered (at least 5 times now since 2003), this discussion comes up again and it seems that some people forget (or don't know) how many times it's happened to them before. There must be a reason it keeps happening, right? Are there any other large ISPs that have had this type of problem 5 times? As someone was saying earlier, in the PSTN world carriers generally pay for every call terminated to another carrier's network and pay each other back and forth. In IP peering, these types of costs are "eliminated" by settlement-free peering relationships where carriers feel there is a benefit to do so. These are relationships or contracts between the two carriers, and most of us have no idea how these are written or what clauses are included about how and when one carrier can end that contract. Regardless of the exact terms, there will certainly be actions or other situations that would be viewed as a breach of contract, resulting in ending or changing the relationship. In the case of Cogent, they seem to want to be a Tier 1 carrier (usually loosely defined as an carrier that does not pay for transit or access from/to any other carrier), but they are not usually considered one by many in the industry. Technically at this point they are not since they are believed to pay Level 3 and Sprint. Now I really can't speak to exactly why each carrier that has de-peered Cogent in the past has done so, but based on conversations I've had with higher-ups at one of these ISPs, their major issue with Cogent was a huge discrepancy in the volume of inbound vs. outbound traffic. To that carrier, based on the traffic patterns, they believed that Cogent should be paying for their connections and was not keeping to the spirit of their relationship or breaking the contract if there was one. They supposedly attempted for some time to resolve the issue amicably, but when that failed they chose to take action as a last chance to resolve the dispute to their liking. Now as to the "harmful" effect to Cogent's customers, that effect would be easily mitigated if Cogent would choose to buy transit from any other ISP. Instead, they try to avoid that by offering affected customers free circuits for some period of time, which hopefully turn into paying customers at a later date. Also, anyone running any important site or network knows never to be single-homed, and therefore should not be effected in the long run. Anyone single homed accepts the risks associated with that by not having redundant connections, especially if that single home is Cogent based on their history of peering arguments. So based on that the only "difference" I'd expect this to make is in the relationship between Sprint and Cogent in the future. I doubt this will change Sprint's, Cogent's, or any other ISP's corporate views/policies on peering in the long term. Just my 2 cents, -Scott -----Original Message----- From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] Sent: Saturday, November 01, 2008 10:07 PM To: bas Cc: nanog at nanog.org Subject: Re: Sending vs requesting. Was: Re: Sprint / Cogent bas wrote: > Why does everyone keep referring to traffic flows as sendng? > In this case it's not as if Cogent just randomly sends data to Sprint. > I think it's a really odd reinterpretation of telephony concepts. In telephony interconnects are typically settlement based, sender pays receiver, in the settlement based world it seems to have gotten confused. I'm still trying to come to terms with what Sprint is trying to achieve here. I can only assume it's (and I'm stealing from Vijay here) to raise Cogent's cost of doing business by forcing them to do settlement based or paid peering and thus trying to force the cost of their transit to rise. Maybe it's to damage Cogent's reputation as well? The cost of doing this seems to be high (ie. upsetting high paying (single homed) transit and mobile customers) and getting negative media coverage. Is this really going to make a substantial kind of difference? MMC -- Matthew Moyle-Croft - Internode/Agile - Networks From tomb at byrneit.net Sat Nov 1 23:28:04 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sat, 1 Nov 2008 20:28:04 -0800 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: References: <20081101160526.GB921665@hiwaay.net> Message-ID: <70D072392E56884193E3D2DE09C097A9F883@pascal.zaphodb.org> Well put. The etymology of the whole mindset around peering is a legacy from the academic/socialist roots of the Internet. There are still a great number of people who think this is some kind of social engineering experiment, as opposed to a communications infrastructure run by, and for the benefit of, businesses. If that craws anyone's hide, then go build community networks and peer with each other, no-one's going to stop you. By the same token, you don't have the right to force anyone else to pay for what you want. >-----Original Message----- >From: Patrick W. Gilmore [mailto:patrick at ianai.net] >Sent: Saturday, November 01, 2008 9:46 AM >To: NANOG list >Subject: Re: Sending vs requesting. Was: Re: Sprint / Cogent > >On Nov 1, 2008, at 12:05 PM, Chris Adams wrote: >> Once upon a time, bas said: >>> I've heard eyeball networks refer to traffic flows as sending too.. >>> "You content hosters are sending us too much traffic, we want money >>> to >>> upgrade ports and transport all that traffic" Complete reverse logic >>> imho. It is always eyeball network customers that request data. >>> (except for a small portion of iphone/blackberry push email, but that >>> can't account for much.) >> >> Traffic sources tend to be concentrated in large data centers >> (easier to >> service), while traffic sinks (DSL, cable, wireless) are widespread >> and >> costly to upgrade. The sink customers don't want to pay more (and >> there's at least some competition), so the sink providers look to see >> where else they get income to pay for their needed network upgrades. > >Combined with hot-potato routing, the first part of that paragraph is >a fancy way of saying "I have to carry the large packet a long way, >you have to carry the small packet a long way". It is not "fair". >This is almost a good reason, but not quite. (It can also be offset >by moving the source next to the sink, through cold-potato routing / >MEDs, anycast, CDNs, etc.) > >The second part is a good business reason. Profitable revenue is >good, costs are bad. > >There are good business reasons not to pay the sink as well. But >neither decision is obvious or the same for everyone. > >Peering is complicated, people should stop trying to generalize it. > > >Peering is a business tool. For years & years many people have >claimed that to "peer" you must be equal. Bullshit. If I can make >more or spend less by peering, I should do it. If not, I should not. >Full stop. Notice the complete lack of regard for how big you are, >how much capacity your backbone has, how many ASes are downstream of >you, etc.? When I go to buy routers or hire employees or any other >business transaction, I don't say "that router vendor is making more >money than I am, so I won't buy from him". If people applied >"peering" logic to anything else, they'd be laughed out of a job. > >Don't know about you, but I am in business to make money, not measure >my anatomy. How big the next guy is doesn't enter into my equation - >other than how it affects my bottom line. > >To be clear, it is entirely possible that peering does not save you >money. Vijay is right, most people can't measure their COGS to save >their life. And if the network in question cannot, there's no way in >hell the prospective peer can. If you are a huge point source of >traffic and want to peer, I may save money by saying no and paying a >transit provider to deliver the packet to me where I want it >(especially at today's prices). Fiber, routers, colo, NOC employees, >engineers, etc., are all not free ya know. > >You can claim my customers asked for the data and therefore I have a >requirement to peer, but you would be deluded. What my customer and I >have agreed has _nothing_ to do with you or your needs. You don't >tell me how to run my network, and I won't tell you how to run yours. >Deal? > >On the flip side, saying "you are not on 3 continents so I will not >peer" is stupid of not peering costs you millions a year. Stupid >decisions abound in the peering ecosystem. > >There are tons of other _business_ reasons to peer, or not to peer. >But "we're equal" or "your customer asked for it" are not reasons, >stop using them. > >-- >TTFN, >patrick > From sethm at rollernet.us Sun Nov 2 02:28:51 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 02 Nov 2008 01:28:51 -0700 Subject: routing around Sprint's depeering damage In-Reply-To: References: Message-ID: <490D64C3.9040207@rollernet.us> Dave Blaine wrote: > There are at least three ways to address this Sprint / Cogent partition: > > 1. Send Vint Cerf back up to Capitol Hill with a doomsday > scenario of what would happen to the economy if anyone else > gets as stupid as Sprint has been, begging for laws that any > tier-1 or tier-2 who wants to de-peer needs to provide all their > customers and peers with 90 day notice or face stiff fines. > Send John Schnizlein along with him to get the House > Communications Director an Akamai hosting account. > Repeat the "eyeballs-or-data, which is more valuable" mantra > whether or not there are still forty Republicans in the Senate. > > 2. Pick up some more fiber, dust off the router manuals, and > allow and recommend that tier-1s transit any third party > tier-1-to-tier-1 traffic. > > 3. Both. > > Which is the best way? > 4. Multihome. ~Seth From mvgfr1 at gmail.com Sun Nov 2 03:56:24 2008 From: mvgfr1 at gmail.com (Marc Farnum Rendino) Date: Sun, 2 Nov 2008 04:56:24 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: <490CEE78.5030506@cox.net> References: <490CEE78.5030506@cox.net> Message-ID: <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> On Sat, Nov 1, 2008 at 7:04 PM, Larry Sheldon wrote: > More regs and more laws is certainly not in the running. Why? > How about: If there is a need, somebody will provide at a suitable price? > If no body steps up, we don't need it. There seems to be ample evidence, in many arenas, that naked capitalism can have disastrous results. From mvgfr1 at gmail.com Sun Nov 2 06:52:00 2008 From: mvgfr1 at gmail.com (Marc Farnum Rendino) Date: Sun, 2 Nov 2008 07:52:00 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: <490CEE78.5030506@cox.net> References: <490CEE78.5030506@cox.net> Message-ID: <4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> Folks - At some point, a society decides that X is important enough to the society as a whole, that something official is in the overall interest. Roads, immigration, whatever. That it's necessary to require that some things be done (or not be done). Peering may very well not be in that category, however I think it's worth discussion. - Marc From LarrySheldon at cox.net Sun Nov 2 07:38:55 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 02 Nov 2008 07:38:55 -0600 Subject: routing around Sprint's depeering damage In-Reply-To: <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> References: <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> Message-ID: <490DAD6F.2000307@cox.net> Marc Farnum Rendino wrote: > On Sat, Nov 1, 2008 at 7:04 PM, Larry Sheldon wrote: >> More regs and more laws is certainly not in the running. > > Why? That is the way government works, too much, too late, in the wrong place. >> How about: If there is a need, somebody will provide at a suitable price? >> If no body steps up, we don't need it. > > There seems to be ample evidence, in many arenas, that naked > capitalism can have disastrous results. There is no evidence whatever that "naked" capitalism has ever been allowed to operate. From patrick at zill.net Sun Nov 2 07:58:45 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Sun, 02 Nov 2008 08:58:45 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: <4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> References: <490CEE78.5030506@cox.net> <4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> Message-ID: <490DB215.8070408@zill.net> Marc Farnum Rendino wrote: > Folks - > > At some point, a society decides that X is important enough to the > society as a whole, that something official is in the overall > interest. Roads, immigration, whatever. That it's necessary to require > that some things be done (or not be done). > > Peering may very well not be in that category, however I think it's > worth discussion. > > - Marc My response would be to point out the behavior of the incumbents in the telcom industry vs. the upstarts; which are the ones responsible for most of the innovation that actually got delivered to the market? Regulations raise barriers to entry; which favors the incumbent over the upstart. Roads are a bad analogy and will only serve to obscure the discussion. --Patrick From Rod.Beck at hiberniaatlantic.com Sun Nov 2 08:24:02 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Sun, 2 Nov 2008 14:24:02 -0000 Subject: routing around Sprint's depeering damage References: <490CEE78.5030506@cox.net><4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> <490DB215.8070408@zill.net> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> I'll make one comment before 'Alex the Hammer' closes this discussion for straying into politics. Clearly regulating the incumbents to unbundle local loops has worked very well in some European countries (France and possibly others). Clearly US financial deregulation has cost the world dearly. So regulation is the appropriate response in some cases (I hope that is clear given the world financial system almost went under a few weeks ago). However, it is not clear what a well crafted peering regulation would do that is different than what the market has achieved already. Sensible and hence pragmatic government mandated peering would require companies having equal bilateral traffic flows to peer or buy transit from each other. That would not necessarily preclude the current peering dispute. Forcing companies to peer when it is not in their interest is unlikely to be supported by the courts in any country, even the French and German courts. Sooner or later these two companies in conflict will either return to peering or one of them will buy transit to reach the other. It is a short term issue that probably doesn't merit government intervention Regards, Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From james at towardex.com Sun Nov 2 08:32:35 2008 From: james at towardex.com (James Jun) Date: Sun, 2 Nov 2008 09:32:35 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> References: <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> Message-ID: <00d101c93cf7$d9a46c70$8ced4550$@com> > > How about: If there is a need, somebody will provide at a suitable > price? > > If no body steps up, we don't need it. > > There seems to be ample evidence, in many arenas, that naked > capitalism can have disastrous results. And there are lot of examples and ample evidence in history, in many areas, that complete regulation, complete socialism can have disastrous results as well. If you want to have a good idea on how the internet will look like in the US after regulation, simply look at Australia. The government imposed regulation early on in internet infrastructure market caused nothing but raising the entry barrier for small ISPs, only creating government-approved monopoly for major telcos/carriers. Only such regulation creates a situation where it is cheaper and affordable for a smaller ISP to route traffic from .AU to .US, then back to .AU than interconnect directly with incumbent carrier in their own country. So yes, more regulations definitely help the internet indeed (by adding extra 300ms into the process). Instead of calling for socialist/communist policies to regulate the transit industry, the single-homed networks can simply multihome. Because of Cogent, the cost of transit has come down to single-digit per megabit that even after adding transport costs, it's now affordable to add a 2nd internet connection for practically most organizations out there, especially in the continental US (the same capitalism that you call 'disatrous results' is the same capitalism that brought cheap dollars/meg pricing, allowing smaller companies to multihome now when they couldn't afford to do so in the past). As much as we blame Cogent and Sprint for breaking the internet, I also have no sympathy for individual single-homed downstream customers on either networks. If you are complaining about Sprint<->Cogent depeering and have customers demanding for your mission-critical services, then you are just as negligent to not have multihomed before all of this happened. If you need that 100% uptime guarantee, you shouldn't rely on single carrier, nor should you rely on government for more regulation. No one can help you but yourself in ensuring your uptime-- so perhaps look at your own setup and decide that you need that 2nd connection to back you up when first one fails. This is a simple business logic. James From swmike at swm.pp.se Sun Nov 2 08:33:15 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 2 Nov 2008 15:33:15 +0100 (CET) Subject: routing around Sprint's depeering damage In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> References: <490CEE78.5030506@cox.net><4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> <490DB215.8070408@zill.net> <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> Message-ID: On Sun, 2 Nov 2008, Rod Beck wrote: > It is a short term issue that probably doesn't merit government > intervention The only government intervention I can imagine as being productive would be to mandate what the "Internet" is, and if someone is selling access to it, mandate that customers can demand a refund in case the "Internet Access" doesn't provide access to enough a big part of it in a well enough working manner. If two parties were both to lose enough money over cutting off peering, then perhaps they'd make sure there was a backup path that at least worked well enough to enable them to refuse to refund their respective customers. I see lots of problems with definitions in this model, but it's worked (for some definition of "worked") in other areas and it might work here as well. -- Mikael Abrahamsson email: swmike at swm.pp.se From LarrySheldon at cox.net Sun Nov 2 08:45:39 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 02 Nov 2008 08:45:39 -0600 Subject: routing around Sprint's depeering damage In-Reply-To: References: <490CEE78.5030506@cox.net><4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> <490DB215.8070408@zill.net> <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> Message-ID: <490DBD13.2040804@cox.net> Mikael Abrahamsson wrote: > The only government intervention I can imagine as being productive would > be to mandate what the "Internet" is, and if someone is selling access > to it, mandate that customers can demand a refund in case the "Internet > Access" doesn't provide access to enough a big part of it in a well > enough working manner. In some parts of the US, we already have that. We call it "Contract Law" where I live. You "make a deal" with somebody, with notes on paper about what each of you think is to be delivered in each direction, then when everybody agrees the notes accurately reflect the agreement, everybody signs it. If somebody reneges, the lawyers get rich and maybe a repair is worked out, maybe not. But if that doesn't work, probably nothing else was going to either. From dts at senie.com Sun Nov 2 09:01:39 2008 From: dts at senie.com (Daniel Senie) Date: Sun, 02 Nov 2008 10:01:39 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: References: <490CEE78.5030506@cox.net> <4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> <490DB215.8070408@zill.net> <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> Message-ID: <200811021506.mA2F6loA015653@parsley.amaranth.net> At 09:33 AM 11/2/2008, Mikael Abrahamsson wrote: >On Sun, 2 Nov 2008, Rod Beck wrote: > >>It is a short term issue that probably doesn't merit government intervention > >The only government intervention I can imagine as being productive >would be to mandate what the "Internet" is, and if someone is >selling access to it, mandate that customers can demand a refund in >case the "Internet Access" doesn't provide access to enough a big >part of it in a well enough working manner. Precisely the issue I am concerned about. End consumers cannot go off and multihome easily. Comcast got in trouble for altering traffic flows to its residential customers. Sprint has broken access to its EVDO customers. Does it make sense for end customers to be protected from companies providing access to only parts of the Internet? Sprint could, in response to this partitioning, buy some transit to provide complete connectivity to its EVDO users. But unless they're willing to allow termination of contracts for cell phones and data cards without penalty, consumers are NOT free to switch carriers, and they are not getting unfettered access to the Internet as was sold to them. The other carriers in the space aren't much better. Verizon got in trouble for selling "unlimited" access via data cards, then cutting people off who used it heavily. Is it worthwhile for the government and/or the courts to set rules for such? As a consumer, I would prefer the government protect me from large businesses selling me one thing, then delivering another. Consumer protection is a valid and useful function of government, IMO. From matthew at eeph.com Sun Nov 2 09:14:14 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Sun, 02 Nov 2008 07:14:14 -0800 Subject: routing around Sprint's depeering damage In-Reply-To: <00d101c93cf7$d9a46c70$8ced4550$@com> References: <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> Message-ID: <490DC3C6.7090402@eeph.com> James Jun wrote: > As much as we blame Cogent and Sprint for breaking the internet, I also have > no sympathy for individual single-homed downstream customers on either > networks. If you are complaining about Sprint<->Cogent depeering and have > customers demanding for your mission-critical services, then you are just as > negligent to not have multihomed before all of this happened. ... Ah yes, I suspect we can get all the network operators here to agree that any customer of another ISP should buy a second connection "just in case". Maybe this breakage will turn out to be the best way for everyone to double their customer base overnight. But seriously, it shouldn't be necessary to have two connections at work, two connections at home, two connections for each mobile device, just to ensure that when large providers stop working together you can still reach what you need to reach. Matthew Kaufman matthew at eeph.com http://www.matthew.at From hescominsoon at emmanuelcomputerconsulting.com Sun Nov 2 09:20:44 2008 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Sun, 02 Nov 2008 10:20:44 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: <00d101c93cf7$d9a46c70$8ced4550$@com> References: <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> Message-ID: <490DC54C.1010707@emmanuelcomputerconsulting.com> James Jun wrote: >>> How about: If there is a need, somebody will provide at a suitable >>> >> price? >> >>> If no body steps up, we don't need it. >>> >> There seems to be ample evidence, in many arenas, that naked >> capitalism can have disastrous results. >> > > And there are lot of examples and ample evidence in history, in many areas, > that complete regulation, complete socialism can have disastrous results as > well. > > If you want to have a good idea on how the internet will look like in the US > after regulation, simply look at Australia. The government imposed > regulation early on in internet infrastructure market caused nothing but > raising the entry barrier for small ISPs, only creating government-approved > monopoly for major telcos/carriers. Only such regulation creates a > situation where it is cheaper and affordable for a smaller ISP to route > traffic from .AU to .US, then back to .AU than interconnect directly with > incumbent carrier in their own country. So yes, more regulations definitely > help the internet indeed (by adding extra 300ms into the process). > > Instead of calling for socialist/communist policies to regulate the transit > industry, the single-homed networks can simply multihome. Because of > Cogent, the cost of transit has come down to single-digit per megabit that > even after adding transport costs, it's now affordable to add a 2nd internet > connection for practically most organizations out there, especially in the > continental US (the same capitalism that you call 'disatrous results' is the > same capitalism that brought cheap dollars/meg pricing, allowing smaller > companies to multihome now when they couldn't afford to do so in the past). > > As much as we blame Cogent and Sprint for breaking the internet, I also have > no sympathy for individual single-homed downstream customers on either > networks. If you are complaining about Sprint<->Cogent depeering and have > customers demanding for your mission-critical services, then you are just as > negligent to not have multihomed before all of this happened. If you need > that 100% uptime guarantee, you shouldn't rely on single carrier, nor should > you rely on government for more regulation. No one can help you but > yourself in ensuring your uptime-- so perhaps look at your own setup and > decide that you need that 2nd connection to back you up when first one > fails. This is a simple business logic. > > James > > > > > If things were truly operating as designed the internet would be able to automatically route around this depeering..the problem is not only do these two depeer but they also totally block any other traffic coming in from the other side. This is not how things should be done..disconnect the peering but let the traffic get automatically route around the disruption as it should. From jgreco at ns.sol.net Sun Nov 2 09:28:31 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 2 Nov 2008 09:28:31 -0600 (CST) Subject: routing around Sprint's depeering damage In-Reply-To: <00d101c93cf7$d9a46c70$8ced4550$@com> from "James Jun" at Nov 02, 2008 09:32:35 AM Message-ID: <200811021528.mA2FSVIY085139@aurora.sol.net> > As much as we blame Cogent and Sprint for breaking the internet, I also have > no sympathy for individual single-homed downstream customers on either > networks. If you are complaining about Sprint<->Cogent depeering and have > customers demanding for your mission-critical services, then you are just as > negligent to not have multihomed before all of this happened. If you need > that 100% uptime guarantee, you shouldn't rely on single carrier, nor should > you rely on government for more regulation. No one can help you but > yourself in ensuring your uptime-- so perhaps look at your own setup and > decide that you need that 2nd connection to back you up when first one > fails. This is a simple business logic. Is it just me, or is this awful logic? Really, we DO NOT WANT every site that considers itself to have "mission critical needs" to be multihomed. This would lead to an explosion in the size of the routing table. When two "Tier 1 Wannabes" get into a peering dispute and start deliberately breaking reachability, this is an artifically-generated crisis. It certainly strikes me that someone here isn't making "best-effort" attempts to supply Internet access. One would wish that the customers of that guilty party have contracts which require "best-effort" attempts to provide Internet access, which would mean that a peering spat that results in visible traffic failures ought to open the door for customers to migrate ... elsewhere. Of course, while that might be fair, it isn't compatible with the real world. However, requiring everyone to get a second Internet connection is not realistic. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From list-only at dnz.se Sun Nov 2 09:29:52 2008 From: list-only at dnz.se (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=) Date: Sun, 2 Nov 2008 16:29:52 +0100 Subject: routing around Sprint's depeering damage In-Reply-To: <200811021506.mA2F6loA015653@parsley.amaranth.net> References: <490CEE78.5030506@cox.net> <4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> <490DB215.8070408@zill.net> <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> <200811021506.mA2F6loA015653@parsley.amaranth.net> Message-ID: Well, selling you an "unlimited" account and them terminating that contract if you use "to much" is one thing, that is a stated lack of a limit in your contract. There is no delivery guarantee of your IP packets in your contract, adding one would be a rather bad idea since there is no delivery guarantee in IP that your service is based on and that would open a carrier to liabilities if someone was using a firewall for instance since that is effectivly limiting your delivery to that machine. What you are buying is access to Sprints network, and transit effectivly on Sprints view of the Internet, and that is what they deliver really.. ------------------------------ Anders Lindb?ck anders.lindback at dnz.se On 2 nov 2008, at 16.01, Daniel Senie wrote: > At 09:33 AM 11/2/2008, Mikael Abrahamsson wrote: >> On Sun, 2 Nov 2008, Rod Beck wrote: >> >>> It is a short term issue that probably doesn't merit government >>> intervention >> >> The only government intervention I can imagine as being productive >> would be to mandate what the "Internet" is, and if someone is >> selling access to it, mandate that customers can demand a refund >> in case the "Internet Access" doesn't provide access to enough a >> big part of it in a well enough working manner. > > Precisely the issue I am concerned about. End consumers cannot go > off and multihome easily. Comcast got in trouble for altering > traffic flows to its residential customers. Sprint has broken > access to its EVDO customers. Does it make sense for end customers > to be protected from companies providing access to only parts of > the Internet? > > Sprint could, in response to this partitioning, buy some transit to > provide complete connectivity to its EVDO users. But unless > they're willing to allow termination of contracts for cell phones > and data cards without penalty, consumers are NOT free to switch > carriers, and they are not getting unfettered access to the > Internet as was sold to them. The other carriers in the space > aren't much better. Verizon got in trouble for selling "unlimited" > access via data cards, then cutting people off who used it heavily. > > Is it worthwhile for the government and/or the courts to set rules > for such? As a consumer, I would prefer the government protect me > from large businesses selling me one thing, then delivering > another. Consumer protection is a valid and useful function of > government, IMO. > > > From james at towardex.com Sun Nov 2 09:32:34 2008 From: james at towardex.com (James Jun) Date: Sun, 2 Nov 2008 10:32:34 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: <490DC3C6.7090402@eeph.com> References: <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> Message-ID: <00d601c93d00$3a96b760$afc42620$@com> > > But seriously, it shouldn't be necessary to have two connections at > work, two connections at home, two connections for each mobile device, > just to ensure that when large providers stop working together you can > still reach what you need to reach. I think you're misinterpreting what I'm trying to say. The consumers/end-users don't necessarily have to multihome. The problem is the content providers/web hosters sitting single-homed on either networks, when most of them are physically sitting in better environment to multihome (i.e. a datacenter) than consumers. A consumer can be single homed to Sprint or Cogent, but when the other side (the content) is multihomed, you'll simply take new route to get to that content. My point is, any business providing services over internet (this excludes mobile devices, end-user/consumers) should be multihoming themselves if they are serious about uptime. James From mike at mtcc.com Sun Nov 2 09:34:46 2008 From: mike at mtcc.com (Michael Thomas) Date: Sun, 02 Nov 2008 07:34:46 -0800 Subject: routing around Sprint's depeering damage In-Reply-To: <490DC3C6.7090402@eeph.com> References: <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> Message-ID: <490DC896.5090902@mtcc.com> Matthew Kaufman wrote: > James Jun wrote: >> As much as we blame Cogent and Sprint for breaking the internet, I >> also have >> no sympathy for individual single-homed downstream customers on either >> networks. If you are complaining about Sprint<->Cogent depeering and have >> customers demanding for your mission-critical services, then you are >> just as >> negligent to not have multihomed before all of this happened. ... > > Ah yes, I suspect we can get all the network operators here to agree > that any customer of another ISP should buy a second connection "just in > case". Maybe this breakage will turn out to be the best way for everyone > to double their customer base overnight. I have a probably dumb question. Even if a company were of large enough wallet to have, say, a single redundant connection, how could it evaluate the partition problem in order to choose the "best" connection (where "best" is a function of overall connectivity, say) ? It seems to me that that's a really, really hard problem. And surely isn't a static one-off kind of calculation, right? Mike From jgreco at ns.sol.net Sun Nov 2 09:39:15 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 2 Nov 2008 09:39:15 -0600 (CST) Subject: routing around Sprint's depeering damage In-Reply-To: from "=?ISO-8859-1?Q?Anders_Lindb=E4ck?=" at Nov 02, 2008 04:29:52 PM Message-ID: <200811021539.mA2FdFxu085495@aurora.sol.net> > Well, selling you an "unlimited" account and them terminating that > contract if you use "to much" is one thing, that is a stated lack of > a limit in your contract. > > There is no delivery guarantee of your IP packets in your contract, > adding one would be a rather bad idea since there is no delivery > guarantee in IP that your service is based on and that would open a > carrier to liabilities if someone was using a firewall for instance > since that is effectivly limiting your delivery to that machine. > > What you are buying is access to Sprints network, and transit > effectivly on Sprints view of the Internet, and that is what they > deliver really.. Based on that logic, it sounds like a fine time for me to get into the wireless market. I can save a ton of money by getting a 56k dialup line to $9.95/mo-company as an upstream connection, and just saying that I don't guarantee delivery of packets, and if my upstream service gets terminated for some reason, hey, my view of the Internet is pretty small. Come on. Really, an ISP has to make a reasonable effort to be able to reach other arbitrary destinations on the Internet. That they might not be able to promise access to obscure networks in the farthest portions of China on the end of two tin cans and a string is obvious. But when they can't get traffic across the street because they're actively buggering routes from an AS, well, that's different. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From fw at deneb.enyo.de Sun Nov 2 09:40:00 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 02 Nov 2008 16:40:00 +0100 Subject: routing around Sprint's depeering damage In-Reply-To: <490D64C3.9040207@rollernet.us> (Seth Mattinen's message of "Sun, 02 Nov 2008 01:28:51 -0700") References: <490D64C3.9040207@rollernet.us> Message-ID: <87od0yxhkf.fsf@mid.deneb.enyo.de> * Seth Mattinen: > 4. Multihome. Or get upstream from someone who does, and who is small enough to be able to get additional upstream upon short notice. I know that this solution isn't always cost-effective. 8-/ (Multihoming alone isn't a solution because it's hard to figure out how independent your peering partners are.) From jgreco at ns.sol.net Sun Nov 2 09:49:42 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 2 Nov 2008 09:49:42 -0600 (CST) Subject: routing around Sprint's depeering damage In-Reply-To: <00d601c93d00$3a96b760$afc42620$@com> from "James Jun" at Nov 02, 2008 10:32:34 AM Message-ID: <200811021549.mA2Fnghg085801@aurora.sol.net> > > But seriously, it shouldn't be necessary to have two connections at > > work, two connections at home, two connections for each mobile device, > > just to ensure that when large providers stop working together you can > > still reach what you need to reach. > > I think you're misinterpreting what I'm trying to say. > > The consumers/end-users don't necessarily have to multihome. The problem is > the content providers/web hosters sitting single-homed on either networks, > when most of them are physically sitting in better environment to multihome > (i.e. a datacenter) than consumers. > > A consumer can be single homed to Sprint or Cogent, but when the other side > (the content) is multihomed, you'll simply take new route to get to that > content. My point is, any business providing services over internet (this > excludes mobile devices, end-user/consumers) should be multihoming > themselves if they are serious about uptime. So my Sprint EVDO (hypothetical, not real) can't get to the DSL line I've got through $cheap-Cogent-bandwidth-DSL-provider (also hypothetical, not something I have, but I know of such a provider. Given they're not at fault in this dispute, I will not name them.) So what you're saying is that I'm expected ... to go get myself some space in a data center so that I can buy some more Internet connectivity in the data center so that I can bounce my VPN connection from my laptop to my home office via the data center? That's insane. Let's try to remember that the Internet isn't the sort of "content provider" and "end-user" thing you're pretending it is. This model is loosely true for some large percentage of traffic, but it is by no means the only usage model. Further, why should content networks be taxed extra in the manner you suggest? Are you willing to mandate that customers in Sprint and Cogent colocation centers must be offered reasonable pricing on connections to alternate providers? You really don't want all your content providers multihoming in any case, there are far too many of them, and encouraging each one to solve its own connectivity problem will result in an explosion of the routing table. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From LarrySheldon at cox.net Sun Nov 2 09:50:37 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 02 Nov 2008 09:50:37 -0600 Subject: routing around Sprint's depeering damage In-Reply-To: <490DC54C.1010707@emmanuelcomputerconsulting.com> References: <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC54C.1010707@emmanuelcomputerconsulting.com> Message-ID: <490DCC4D.2050203@cox.net> William Warren wrote: > If things were truly operating as designed the internet would be able to > automatically route around this depeering..the problem is not only do > these two depeer but they also totally block any other traffic coming in > from the other side. This is not how things should be done..disconnect > the peering but let the traffic get automatically route around the > disruption as it should. Some of us gun-clingers think involuntary servitude is a seriously bad idea. From list-only at dnz.se Sun Nov 2 09:52:33 2008 From: list-only at dnz.se (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=) Date: Sun, 2 Nov 2008 16:52:33 +0100 Subject: routing around Sprint's depeering damage In-Reply-To: <200811021539.mA2FdFxu085495@aurora.sol.net> References: <200811021539.mA2FdFxu085495@aurora.sol.net> Message-ID: Nice interpretation of my statement.. A reasonable effort and a contractual guarantee are two different things, a reasonable effort could be defined as economicly feasable for instance. My point was that in Cogents case this is really a force majeure situation and in Sprints case unless you have a contract that defines an SLA with delivery to "the entire Internet" or something similar you do not really have case to break your contract or sue due to the de-peering as a breach of contract from Sprints side.. ------------------------------ Anders Lindb?ck anders.lindback at dnz.se On 2 nov 2008, at 16.39, Joe Greco wrote: >> Well, selling you an "unlimited" account and them terminating that >> contract if you use "to much" is one thing, that is a stated lack of >> a limit in your contract. >> >> There is no delivery guarantee of your IP packets in your contract, >> adding one would be a rather bad idea since there is no delivery >> guarantee in IP that your service is based on and that would open a >> carrier to liabilities if someone was using a firewall for instance >> since that is effectivly limiting your delivery to that machine. >> >> What you are buying is access to Sprints network, and transit >> effectivly on Sprints view of the Internet, and that is what they >> deliver really.. > > Based on that logic, it sounds like a fine time for me to get into the > wireless market. I can save a ton of money by getting a 56k dialup > line > to $9.95/mo-company as an upstream connection, and just saying that I > don't guarantee delivery of packets, and if my upstream service gets > terminated for some reason, hey, my view of the Internet is pretty > small. > > Come on. Really, an ISP has to make a reasonable effort to be able to > reach other arbitrary destinations on the Internet. That they > might not > be able to promise access to obscure networks in the farthest portions > of China on the end of two tin cans and a string is obvious. But when > they can't get traffic across the street because they're actively > buggering routes from an AS, well, that's different. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http:// > www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance > [and] then I > won't contact you again." - Direct Marketing Ass'n position on e- > mail spam(CNN) > With 24 million small businesses in the US alone, that's way too > many apples. From jgreco at ns.sol.net Sun Nov 2 10:10:03 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 2 Nov 2008 10:10:03 -0600 (CST) Subject: routing around Sprint's depeering damage In-Reply-To: from "=?ISO-8859-1?Q?Anders_Lindb=E4ck?=" at Nov 02, 2008 04:52:33 PM Message-ID: <200811021610.mA2GA3hG086391@aurora.sol.net> > Nice interpretation of my statement.. > > A reasonable effort and a contractual guarantee are two different > things, a reasonable effort could be defined as economicly feasable > for instance. "Economically feasible?" If it isn't economically feasible, then repair your pricing model so that it becomes economically feasible. In some locales, it is actually illegal to sell for below cost. > My point was that in Cogents case this is really a force majeure > situation and in Sprints case unless you have a contract that defines > an SLA with delivery to "the entire Internet" or something similar > you do not really have case to break your contract or sue due to the > de-peering as a breach of contract from Sprints side.. So each and every customer has to negotiate with the Internet Service Provider to guarantee access to "the entire Internet"? You can't just approach an "Internet Service Provider" and expect that they provide you with the capability to connect to the Internet? When was the last time you went to a car dealership, bought a car, and they didn't include the gas tank, or tires, or seatbelts? "Oh, yeah, we've determined that it's economically more feasible to provide your car without a steering wheel. You can buy a different brand of car across the street if you happened to need a steering wheel." Do you begin to understand how retarded this sort of thing sounds to the average consumer? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From tme at multicasttech.com Sun Nov 2 10:27:15 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Sun, 2 Nov 2008 11:27:15 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: References: <490CEE78.5030506@cox.net> <4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> <490DB215.8070408@zill.net> <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> <200811021506.mA2F6loA015653@parsley.amaranth.net> Message-ID: On Nov 2, 2008, at 10:29 AM, Anders Lindb?ck wrote: > Well, selling you an "unlimited" account and them terminating that > contract if you use "to much" is one thing, that is a stated lack of > a limit in your contract. > > There is no delivery guarantee of your IP packets in your contract, > adding one would be a rather bad idea since there is no delivery > guarantee in IP that your service is based on and that would open a > carrier to liabilities if someone was using a firewall for instance > since that is effectivly limiting your delivery to that machine. > > What you are buying is access to Sprints network, and transit > effectivly on Sprints view of the Internet, and that is what they > deliver really.. Sure. Note the "what I am buying" part of this. If I, as a Sprint customer, cannot get to the web sites, email servers, etc., that I need to with EVD0, I will blame Sprint if Sprint is dropping the packets. As a customer, I do not really care why this is occurring. Yes, I might cut them some slack if the site was hosted somewhere like the summit of Mt. Everest, but that does not apply here. For enforcing an SLA, it matters what the contract says, what the EULA says, etc. For keeping customers happy, it does not. Or, to put it another way, if Sprint's view of the Internet is not mine, my view of the Internet will rapidly no longer include being a customer of Sprint. Regards Marshall > > > ------------------------------ > Anders Lindb?ck > anders.lindback at dnz.se > > > On 2 nov 2008, at 16.01, Daniel Senie wrote: > >> At 09:33 AM 11/2/2008, Mikael Abrahamsson wrote: >>> On Sun, 2 Nov 2008, Rod Beck wrote: >>> >>>> It is a short term issue that probably doesn't merit government >>>> intervention >>> >>> The only government intervention I can imagine as being productive >>> would be to mandate what the "Internet" is, and if someone is >>> selling access to it, mandate that customers can demand a refund >>> in case the "Internet Access" doesn't provide access to enough a >>> big part of it in a well enough working manner. >> >> Precisely the issue I am concerned about. End consumers cannot go >> off and multihome easily. Comcast got in trouble for altering >> traffic flows to its residential customers. Sprint has broken >> access to its EVDO customers. Does it make sense for end customers >> to be protected from companies providing access to only parts of >> the Internet? >> >> Sprint could, in response to this partitioning, buy some transit to >> provide complete connectivity to its EVDO users. But unless >> they're willing to allow termination of contracts for cell phones >> and data cards without penalty, consumers are NOT free to switch >> carriers, and they are not getting unfettered access to the >> Internet as was sold to them. The other carriers in the space >> aren't much better. Verizon got in trouble for selling "unlimited" >> access via data cards, then cutting people off who used it heavily. >> >> Is it worthwhile for the government and/or the courts to set rules >> for such? As a consumer, I would prefer the government protect me >> from large businesses selling me one thing, then delivering >> another. Consumer protection is a valid and useful function of >> government, IMO. >> >> >> > > From lorell at hathcock.org Sun Nov 2 11:28:17 2008 From: lorell at hathcock.org (Lorell Hathcock) Date: Sun, 2 Nov 2008 11:28:17 -0600 Subject: Sprint Depeering Timeframe Message-ID: <000d01c93d10$66171690$324543b0$@org> All: I am trying to help a small ISP/cable operator in south Texas with VOIP customers. They are having VOIP problems and have been for about three to four weeks. A traceroute from the end users location reveals that their ATAs traverse Sprint's network on their way to the hosted VOIP provider. Working with providers at both ends provides reveals a willingness to point fingers at the IXC providers (Sprint and Level 3) Sprint and Level 3 have examined traceroutes and they have are satisfied that their networks aren't to blame. I'm looking for a smoking gun and the Sprint depeering could fit the crime if the timeline works out. When did Sprint depeer? If this is at the root cause of the problem and I think it could be if the time lines match when the VOIP problems started, then it would fall under the category of why a routine roll out of hosted PBX / VOIP is a bad idea. It would help me point the customer towards a more secure solution of a SIP Trunk with transit specifically purchased from the VOIP provider to the cable head end where the CMTS resides. Thanks! Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | lorell at OfficeConnect.net ocbannerjoomla -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 7350 bytes Desc: not available URL: From tme at multicasttech.com Sun Nov 2 11:40:01 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Sun, 2 Nov 2008 12:40:01 -0500 Subject: Sprint Depeering Timeframe In-Reply-To: <000d01c93d10$66171690$324543b0$@org> References: <000d01c93d10$66171690$324543b0$@org> Message-ID: <371624CB-E077-4E5C-839C-423FF1BE9B4E@multicasttech.com> Between 13:07:00 and 18:08 EDT on Oct 30 2008. (Note the EDT, not EST.) That does not sound like it is consistent with your problem. Marshall On Nov 2, 2008, at 12:28 PM, Lorell Hathcock wrote: > All: > > > > I am trying to help a small ISP/cable operator in south Texas with > VOIP > customers. They are having VOIP problems and have been for about > three to > four weeks. > > > > A traceroute from the end users location reveals that their ATAs > traverse > Sprint's network on their way to the hosted VOIP provider. Working > with > providers at both ends provides reveals a willingness to point > fingers at > the IXC providers (Sprint and Level 3) Sprint and Level 3 have > examined > traceroutes and they have are satisfied that their networks aren't > to blame. > > > > I'm looking for a smoking gun and the Sprint depeering could fit the > crime > if the timeline works out. When did Sprint depeer? > > > > If this is at the root cause of the problem and I think it could be > if the > time lines match when the VOIP problems started, then it would fall > under > the category of why a routine roll out of hosted PBX / VOIP is a bad > idea. > It would help me point the customer towards a more secure solution > of a SIP > Trunk with transit specifically purchased from the VOIP provider to > the > cable head end where the CMTS resides. > > > > Thanks! > > > > Sincerely, > > > > Lorell Hathcock > > > > OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | > lorell at OfficeConnect.net > > > > ocbannerjoomla > > > > > > > > > From list-only at dnz.se Sun Nov 2 13:09:18 2008 From: list-only at dnz.se (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=) Date: Sun, 2 Nov 2008 20:09:18 +0100 Subject: routing around Sprint's depeering damage In-Reply-To: <200811021610.mA2GA3hG086391@aurora.sol.net> References: <200811021610.mA2GA3hG086391@aurora.sol.net> Message-ID: <96CB4467-1B73-491C-9669-21A9D17FBE96@dnz.se> I am well aware how retarded this sounds to an average end-user, and for that I am glad I am not in a buisness where I need to explain it to them. But experience gained working for a party involved in a previus Cogent spat I am well aware of what the SLAs and service sold is. You can change provider, ask for compensation due to degraded service and what not, your service is still not defined as delivery to all of the Internet and nothing changes that fact.. But this discussion is going nowhere, and I dont really care about it either since a difference between what you buy and what you tought you bought is not really my problem.. :) ------------------------------ Anders Lindb?ck anders.lindback at dnz.se On 2 nov 2008, at 17.10, Joe Greco wrote: >> Nice interpretation of my statement.. >> >> A reasonable effort and a contractual guarantee are two different >> things, a reasonable effort could be defined as economicly feasable >> for instance. > > "Economically feasible?" > > If it isn't economically feasible, then repair your pricing model > so that > it becomes economically feasible. > > In some locales, it is actually illegal to sell for below cost. > >> My point was that in Cogents case this is really a force majeure >> situation and in Sprints case unless you have a contract that defines >> an SLA with delivery to "the entire Internet" or something similar >> you do not really have case to break your contract or sue due to the >> de-peering as a breach of contract from Sprints side.. > > So each and every customer has to negotiate with the Internet Service > Provider to guarantee access to "the entire Internet"? You can't just > approach an "Internet Service Provider" and expect that they provide > you with the capability to connect to the Internet? > > When was the last time you went to a car dealership, bought a car, and > they didn't include the gas tank, or tires, or seatbelts? "Oh, yeah, > we've determined that it's economically more feasible to provide your > car without a steering wheel. You can buy a different brand of car > across > the street if you happened to need a steering wheel." > > Do you begin to understand how retarded this sort of thing sounds > to the > average consumer? > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http:// > www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance > [and] then I > won't contact you again." - Direct Marketing Ass'n position on e- > mail spam(CNN) > With 24 million small businesses in the US alone, that's way too > many apples. From asr+nanog at latency.net Sun Nov 2 13:09:43 2008 From: asr+nanog at latency.net (Adam Rothschild) Date: Sun, 2 Nov 2008 14:09:43 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: <490DC3C6.7090402@eeph.com> References: <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> Message-ID: <20081102190943.GA30474@latency.net> On 2008-11-02-10:14:14, Matthew Kaufman wrote: > But seriously, it shouldn't be necessary to have two connections at > work [...] This is less than clear, and largely dependent on a specific organization's [in]ability to function if their internets go down. End-site multihoming in some form or fashion is a growing requirement, and folk thinking otherwise need to get their heads out of sand. If anything, these recent de-peerings underscore the lack of wisdom in end users connecting to (or purchasing CDN services from) members of the tier 1 club directly. -a From mpetach at netflight.com Sun Nov 2 13:30:15 2008 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 2 Nov 2008 11:30:15 -0800 Subject: routing around Sprint's depeering damage In-Reply-To: <20081102190943.GA30474@latency.net> References: <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <20081102190943.GA30474@latency.net> Message-ID: <63ac96a50811021130s635ae9bdy3305c50687f0fe62@mail.gmail.com> On 11/2/08, Adam Rothschild wrote: > On 2008-11-02-10:14:14, Matthew Kaufman wrote: > > But seriously, it shouldn't be necessary to have two connections at > > > work [...] > > This is less than clear, and largely dependent on a specific > organization's [in]ability to function if their internets go down. > End-site multihoming in some form or fashion is a growing requirement, > and folk thinking otherwise need to get their heads out of sand. > > If anything, these recent de-peerings underscore the lack of wisdom in > end users connecting to (or purchasing CDN services from) members > of the tier 1 club directly. Thank goodness IPv6 cleanly supports end-site multihoming so we won't ever face messy issues like this in the Internet of tomorrow! Oh, wait--could this end up being a damper on IPv6 deployment? "I'd like to move to IPv6, but I can't multihome in IPv6, and I've seen what happens when you don't multihome--so I'll stick with v4, where I at least have the option to multihome to try to avoid being screwed when the net is partitioned like this." Hopefully people recognize that we're rapidly being caught between the twin perils of Scylla and Charybdis here; on the one hand, we don't want to mandate universal connectivity throughout the Internet, we want to allow networks to engage in squabbles like this, and we tell companies "hey, this is the reality of the internet--you want your customers to have more reliable connectivity, you need to multihome" But at the same time, we're telling them "IPv4 is running out, you need to look at moving to IPv6; oh, by the way, in IPv6, you don't get to multihome, you get your addresses from your upstream, and you're stuck with them; you can buy from multiple upstreams, but you'll have to use some type of kludge to switch addresses to make use of the additional paths." With network partitioning becoming more and more an accepted fact of the Internet, if multihoming in IPv6 is not made at least as easy as it is in IPv4, companies who cannot get PI space will not move to IPv6 for any serious production traffic; they have heard us chant the "you must multihome in order to reach the entire Internet, partitions happen on a regular basis, and we refuse to let anyone put regulations in place to prevent them" mantra enough times to realize that the only viable business model for the forseeable future is to use IPv4 addresses in an end-site multihomed fashion. This is the bed we have created for ourselves; why do we spend so much time here wailing and wishing it were otherwise? Matt From ejensen at jensenresearch.com Sun Nov 2 13:30:16 2008 From: ejensen at jensenresearch.com (Eric Jensen) Date: Sun, 02 Nov 2008 14:30:16 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: Message-ID: <5.0.2.1.2.20081102141945.025cce10@authpop.jensenresearch.com> >Date: Sun, 2 Nov 2008 14:09:43 -0500 >From: Adam Rothschild > >On 2008-11-02-10:14:14, Matthew Kaufman wrote: > > But seriously, it shouldn't be necessary to have two connections at > > work [...] >... >If anything, these recent de-peerings underscore the lack of wisdom in >end users connecting to (or purchasing CDN services from) members >of the tier 1 club directly. This is the take-away message for me. Buying transit from Tier 1 (and especially almost-Tier 1) providers is a risky idea for single-homed customers. Tier 1 connectivity could be cheaper, and could be better-performing, but has this potential for severe connectivity issues. Single-homed end users would be well-advised to buy transit from a multi-homed tier 2/3 ISP. Single-homed SPs (such as Sprint Wireless, for example) should become multi-homed or buy transit from such a multi-homed tier 2/3 ISP as well. - Eric From mpetach at netflight.com Sun Nov 2 14:14:20 2008 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 2 Nov 2008 12:14:20 -0800 Subject: routing around Sprint's depeering damage In-Reply-To: <63ac96a50811021130s635ae9bdy3305c50687f0fe62@mail.gmail.com> References: <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <20081102190943.GA30474@latency.net> <63ac96a50811021130s635ae9bdy3305c50687f0fe62@mail.gmail.com> Message-ID: <63ac96a50811021214k60f84fs8aaaa6954282b8d7@mail.gmail.com> On 11/2/08, Matthew Petach wrote: > On 11/2/08, Adam Rothschild wrote: > > On 2008-11-02-10:14:14, Matthew Kaufman wrote: > > > But seriously, it shouldn't be necessary to have two connections at > > > > This is less than clear, and largely dependent on a specific > > organization's [in]ability to function if their internets go down. > > End-site multihoming in some form or fashion is a growing requirement, > > and folk thinking otherwise need to get their heads out of sand. > > > > If anything, these recent de-peerings underscore the lack of wisdom in > > end users connecting to (or purchasing CDN services from) members > > of the tier 1 club directly. > > > Thank goodness IPv6 cleanly supports end-site multihoming so we > won't ever face messy issues like this in the Internet of tomorrow! > > Oh, wait--could this end up being a damper on IPv6 deployment? > > "I'd like to move to IPv6, but I can't multihome in IPv6, and I've seen > what happens when you don't multihome--so I'll stick with v4, where > I at least have the option to multihome to try to avoid being screwed > when the net is partitioned like this." > > Hopefully people recognize that we're rapidly being caught between > the twin perils of Scylla and Charybdis here; on the one hand, we > don't want to mandate universal connectivity throughout the Internet, > we want to allow networks to engage in squabbles like this, and we > tell companies "hey, this is the reality of the internet--you want your > customers to have more reliable connectivity, you need to multihome" > > But at the same time, we're telling them "IPv4 is running out, you need > to look at moving to IPv6; oh, by the way, in IPv6, you don't get to > multihome, you get your addresses from your upstream, and you're > stuck with them; you can buy from multiple upstreams, but you'll > have to use some type of kludge to switch addresses to make use > of the additional paths." > > With network partitioning becoming more and more an accepted > fact of the Internet, if multihoming in IPv6 is not made at least as > easy as it is in IPv4, companies who cannot get PI space will not > move to IPv6 for any serious production traffic; they have heard us > chant the "you must multihome in order to reach the entire Internet, > partitions happen on a regular basis, and we refuse to let anyone > put regulations in place to prevent them" mantra enough times to > realize that the only viable business model for the forseeable > future is to use IPv4 addresses in an end-site multihomed fashion. > > This is the bed we have created for ourselves; why do we spend > so much time here wailing and wishing it were otherwise? > > Matt And, just to converge one more set of threads together, including the recent talk at the NANOG in LA; for those of you complaining about routing table explosion, who are having to take steps to filter out routes so that your table still fits in the 256K memory slots your current kit affords, and for those who are panic-stricken over the thought of having to upgrade all your routers in case we allow multihoming in IPv6--it is events like this that drive the message home that multihoming is a requirement even for smaller businesses in order to stay well connected in the Internet of today; and it is a result of this drive for ever-smaller entities to be multihomed that will drive up routing table size, and force networks to upgrade their routers. So--don't want to be forced to upgrade your routers? Perhaps mandated interconnection arrangements might not seem so terrible to your management, if it means you can save millions on capex for router upgrades. I think it's only a matter of time before we're forced to choose between shutting up and doing forced technology refreshes across wide swaths of the internet to support the swelling routing tables that are the direct result of additional multihoming due to events like this (which I'm sure will make the router vendors quite happy), or accepting mandated interconnection and universal connectivity requirements which will keep the routing table size down, as people won't have the same pressures forcing them to multihome, and will let them contemplate moving to IPv6 without fear of being partitioned (which I'm sure will make the smaller businesses happier, as well as the network engineers who will no longer have quite the gun pointed at their head forcing memory upgrades of all their router kit). Personally, I'm betting on the latter outcome, as much as I don't like it. Governments seem to be unable to resist getting involved whenever it seems that some fundamental linchpin of their society is at risk of faltering or failing without intervention. And unfortunately, I've not seen anyone offer a solution yet that solves all the issues: 1) Prevent or address partitioning of the internet due to depeerings 2) Provide reasonable assurances to end sites of near-universal internet access, barring reasonable outages, maintenance periods, etc. without the need for all end-sites to multihome to multiple upstream providers 3) Provide a reasonable migration path to IPv6, either by re-drafting the IPv6 addressing guidelines to allow widespread end-site multihoming, or by providing assurances that single-homing will not lead to long-term widespread network partitionings due to depeerings or other disputes 4) Limit the potential explosion of routing table entries and forced technology refreshes due to the lack of universal connectivity and the resulting demand for multihoming. I'm sure I'm just nearsighted; but I don't see any other way to solve the situation other than through regulation. Can someone else help enlighten me as to how else we can deal with these converging, conflating issues forcing us towards a cliff, before we hit the IPv4 exhaustion point, and realize that we've backed ourselves into a corner and have no choice but to accept regulation--because we can't upgrade all our networks fast enough to allow everyone to multihome in IPv6, and we're not willing to self-regulate ourselves in the IPv6 world to forbid intentional creation of widespread network partitions? Thanks! Matt (hoping it's just the lack of breakfast making him paranoid this morning) From tvest at eyeconomics.com Sun Nov 2 15:09:04 2008 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Sun, 2 Nov 2008 22:09:04 +0100 Subject: routing around Sprint's depeering damage In-Reply-To: <5.0.2.1.2.20081102141945.025cce10@authpop.jensenresearch.com> References: <5.0.2.1.2.20081102141945.025cce10@authpop.jensenresearch.com> Message-ID: <3547D4D0-A8A0-4A55-A7FB-5821299A57D4@eyeconomics.com> Repent repent, for the end is near. People like to say that the Internet interprets (censorship, monopolies, clue deficits, et al.) as congestion, and routes around -- but they got the causality exactly backwards. The Internet is an epiphenomenon of the possibility of bypass, which enables "cost discovery," which enables cost-effective routing -- at least wherever bypass is possible. But bypass is only possible where someone has invested in alternate paths, and those kind of investments (no matter how large or small) have been almost always been entirely contingent on positive regulation of the pro-competitive kind... That is to say, the kind that the US pioneered but subsequently abandoned, the kind that Japan and Korea et al. subsequently adopted (and which still holds), the kind that many countries in Western Europe et al. have adopted even more recently... and which still holds.* Those who are currently willfully violating the conventional routing services distinctions would be wise to be patient a little longer; the only thing you'll buy now is cartelization, regulation of which may not ultimately favor your interests. Those who are currently actively attempting to kill bypass altogether would be wise to be desist; no one is going to think that the idea/expectation/requirement of multiple, fully redundant fiber entrance to every residence is anything other than absurd, so the rhetoric of "facilities based competition" is about find to its proper place in the ashcan of history. Work it out, or else someone else will do it for you. And they won't be entirely clueless if it comes to that. TV *re: the latest NANOG iteration of the AU debate: nothing that the ACCC could have done would have made any major difference, because Antipodeans speak English, and ever since 1999 the continent has been captive to whatever CIT could/did (i.e., couldn't/didn't) do. Bu that may be changing too... From jmaimon at ttec.com Sun Nov 2 15:05:52 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 02 Nov 2008 16:05:52 -0500 Subject: Why do some companies get depeered and some don't? In-Reply-To: <978AF989-64D5-4A00-93F1-0BF79BBA05DA@ianai.net> References: <1354846503.117451225431145641.JavaMail.root@mbv2.indiatimes.com> <978AF989-64D5-4A00-93F1-0BF79BBA05DA@ianai.net> Message-ID: <490E1630.2080707@ttec.com> Patrick W. Gilmore wrote: > On Oct 31, 2008, at 1:32 AM, Nelson Lai wrote: > >> Why do some companies like Cogent get depeered relatively often and >> companies like Teleglobe don't even get talked about and operate in >> silence free from depeering? > > That's funny. One of the first networks to de-peer Cogent was > Teleglobe. They re-peered after a bit. > > The next obvious question is: When Sprint, Telia & L3 de-peering Cogent, > it causes a lot of news in the press & noise on NANOG, so why didn't you > know Teleglobe depeered Cogent? Imagine the news had they all depeered cogent at the same time. From brandon.galbraith at gmail.com Sun Nov 2 15:33:28 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sun, 2 Nov 2008 15:33:28 -0600 Subject: Why do some companies get depeered and some don't? In-Reply-To: <490E1630.2080707@ttec.com> References: <1354846503.117451225431145641.JavaMail.root@mbv2.indiatimes.com> <978AF989-64D5-4A00-93F1-0BF79BBA05DA@ianai.net> <490E1630.2080707@ttec.com> Message-ID: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> On 11/2/08, Joe Maimon wrote: > > > > Patrick W. Gilmore wrote: > >> On Oct 31, 2008, at 1:32 AM, Nelson Lai wrote: >> >> Why do some companies like Cogent get depeered relatively often and >>> companies like Teleglobe don't even get talked about and operate in silence >>> free from depeering? >>> >> >> That's funny. One of the first networks to de-peer Cogent was Teleglobe. >> They re-peered after a bit. >> >> The next obvious question is: When Sprint, Telia & L3 de-peering Cogent, >> it causes a lot of news in the press & noise on NANOG, so why didn't you >> know Teleglobe depeered Cogent? >> > > Imagine the news had they all depeered cogent at the same time. Imagine the lawsuits and government regulation had that occurred. -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From repstein at chello.at Sun Nov 2 15:40:20 2008 From: repstein at chello.at (Randy Epstein) Date: Sun, 2 Nov 2008 16:40:20 -0500 Subject: Sprint / Cogent dispute over? In-Reply-To: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> References: <1354846503.117451225431145641.JavaMail.root@mbv2.indiatimes.com><978AF989-64D5-4A00-93F1-0BF79BBA05DA@ianai.net><490E1630.2080707@ttec.com> <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> Message-ID: <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> Real time look at the situation: *>i4.23.112.0/24 66.216.0.20 0 100 0 1239 174 21889 i * i 66.216.0.1 0 100 0 1239 174 21889 i * i 66.186.193.16 0 100 0 1239 174 21889 i * i 66.186.193.17 0 100 0 1239 174 21889 i *>i4.23.113.0/24 66.216.0.20 0 100 0 1239 174 21889 i * i 66.216.0.1 0 100 0 1239 174 21889 i * i 66.186.193.16 0 100 0 1239 174 21889 i * i 66.186.193.17 0 100 0 1239 174 21889 i Etc. Problem resolved? Randy From joe.johnson at inwk.com Sun Nov 2 15:45:11 2008 From: joe.johnson at inwk.com (Johnson, Joe) Date: Sun, 2 Nov 2008 15:45:11 -0600 Subject: Sprint / Cogent dispute over? In-Reply-To: <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> References: <1354846503.117451225431145641.JavaMail.root@mbv2.indiatimes.com><978AF989-64D5-4A00-93F1-0BF79BBA05DA@ianai.net><490E1630.2080707@ttec.com> <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> Message-ID: <2FFDEA6ABE8B8F469E7FCB759D4C407D133F9960@exbe01.IWPrint.net> Randy Epstein wrote: > Problem resolved? >From a single-homed Cogent site, I can get to sprint.net and fcc.gov, both of which were unavailable after the de-peering. Joe Johnson Senior Systems Engineer InnerWorkings, Inc. Managed Print & Promotional Solutions 600 West Chicago Avenue, Suite 850 Chicago, IL 60654 Phone: 312.676.6873 Fax: 312.604.5487 joe.johnson at inwk.com www.inwk.com NASDAQ: INWK -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2931 bytes Desc: not available URL: From mohacsi at niif.hu Sun Nov 2 15:50:05 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Sun, 2 Nov 2008 22:50:05 +0100 (CET) Subject: Another driver for v6? In-Reply-To: References: <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <20081030154738.GA5482@isc.org> <20081031163248.GF16800@isc.org> <490B351D.2030503@rockynet.com> <20081031164940.GH16800@isc.org> <490B3BD4.6060900@spaghetti.zurich.ibm.com> Message-ID: On Fri, 31 Oct 2008, HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote: > ever heard of the concept "open market" > > ipv4 address space delegations will just move from the rirs to places like > ebay, problem solved. Are you willing to pay premium to get global IPv4 address? Are you willing to pay non-dynamic global IPv4 addresses for your servers? > > most of it is unused anyway (milnet, amateur radio ranges, etc) Did you consider operational consequences? No prefix allocation database? No routing database? Address collisions? Fighting for announcing more specifics to use your allocated addresses? Regards, Janos Mohacsi From adriankok2000 at yahoo.com.hk Sun Nov 2 16:36:21 2008 From: adriankok2000 at yahoo.com.hk (adrian kok) Date: Mon, 3 Nov 2008 06:36:21 +0800 (CST) Subject: L2tp for DSL Message-ID: <869993.2701.qm@web33305.mail.mud.yahoo.com> Hi Do you know any free open source L2tp for NAS? I know this software was developed so many years before but stopped any information Thank you Send instant messages to your online friends http://uk.messenger.yahoo.com From dr at cluenet.de Sun Nov 2 17:54:22 2008 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 3 Nov 2008 00:54:22 +0100 Subject: Sprint / Cogent dispute over? In-Reply-To: <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> Message-ID: <20081102235422.GA15591@srv03.cluenet.de> On Sun, Nov 02, 2008 at 04:40:20PM -0500, Randy Epstein wrote: > Problem resolved? https://www.sprint.net/cogent.php Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ml at t-b-o-h.net Sun Nov 2 18:04:48 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Sun, 2 Nov 2008 19:04:48 -0500 (EST) Subject: Sprint / Cogent dispute over? In-Reply-To: <20081102235422.GA15591@srv03.cluenet.de> Message-ID: <200811030004.mA304mXe078114@himinbjorg.tucs-beachin-obx-house.com> > > On Sun, Nov 02, 2008 at 04:40:20PM -0500, Randy Epstein wrote: > > Problem resolved? > > https://www.sprint.net/cogent.php > Check out the of the document. Me thinks it was a rush job to post up the page and a bit of cut/paste was done. ;) Tuc From randy at psg.com Sun Nov 2 18:05:39 2008 From: randy at psg.com (Randy Bush) Date: Mon, 03 Nov 2008 09:05:39 +0900 Subject: Sprint / Cogent dispute over? In-Reply-To: <20081102235422.GA15591@srv03.cluenet.de> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> Message-ID: <490E4053.5010709@psg.com> > https://www.sprint.net/cogent.php no nda, eh? randy From brandon.galbraith at gmail.com Sun Nov 2 18:05:52 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sun, 2 Nov 2008 18:05:52 -0600 Subject: Sprint / Cogent dispute over? In-Reply-To: <20081102235422.GA15591@srv03.cluenet.de> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> Message-ID: <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> On 11/2/08, Daniel Roesen <dr at cluenet.de> wrote: > > On Sun, Nov 02, 2008 at 04:40:20PM -0500, Randy Epstein wrote: > > Problem resolved? > > https://www.sprint.net/cogent.php > > > Best regards, > Daniel > > Seeing as Cogent is going to try tooth and nail to keep their new found Tier 1 status (and not pay anyone for transit), I would think this would bode worse for Sprint, since most of their transit customers could migrate to Cogent (saving $$$ and not having to face future depeerings). Just my $0.02. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From adrian at creative.net.au Sun Nov 2 18:06:33 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 3 Nov 2008 09:06:33 +0900 Subject: L2tp for DSL In-Reply-To: <869993.2701.qm@web33305.mail.mud.yahoo.com> References: <869993.2701.qm@web33305.mail.mud.yahoo.com> Message-ID: <20081103000633.GB18948@skywalker.creative.net.au> Try openl2tp or l2tpns. They can both be LNSes. Adrian On Mon, Nov 03, 2008, adrian kok wrote: > Hi > > Do you know any free open source L2tp for NAS? > > I know this software was developed so many years > before but stopped > > any information > > Thank you From repstein at chello.at Sun Nov 2 18:06:49 2008 From: repstein at chello.at (Randy Epstein) Date: Sun, 2 Nov 2008 19:06:49 -0500 Subject: Sprint / Cogent dispute over? In-Reply-To: <20081102235422.GA15591@srv03.cluenet.de> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com><409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> Message-ID: <401928DB10D446AA8373ADD1677A90F1@D88CFA77634F40F> > https://www.sprint.net/cogent.php Yes, I've read it. They need to fix their <TITLE>. So while Cogent was depeered by Sprint, we contacted the CEO of Cogent on Friday to try and arrange at least a temporary peering arrangement so that bits flowed between our networks while they battled this situation out with Sprint. Cogent's response? Buy transit from them. I presume one of Sprint's dissatisfactions during the trial with Cogent were ratios. My network happens to have a very high ratio of eyeballs (inbound traffic) vs outbound traffic. One would believe that Cogent would like to offload their outbound traffic to networks other than their Tier-1 peers, to at least give them an upper hand when negotiating peering arrangements with these networks. It's funny how Cogent depeers networks whenever they want, but the second another network depeers them, they cry foul. Randy From simon at slimey.org Sun Nov 2 18:11:28 2008 From: simon at slimey.org (Simon Lockhart) Date: Mon, 3 Nov 2008 00:11:28 +0000 Subject: Sprint / Cogent dispute over? In-Reply-To: <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> Message-ID: <20081103001128.GA18579@virtual.bogons.net> On Sun Nov 02, 2008 at 06:05:52PM -0600, Brandon Galbraith wrote: > Seeing as Cogent is going to try tooth and nail to keep their new found Tier > 1 status (and not pay anyone for transit), I would think this would bode > worse for Sprint, since most of their transit customers could migrate to > Cogent (saving $$$ and not having to face future depeerings). Just my $0.02. Unless they need to reach other networks single homed from Sprint... Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From pauldotwall at gmail.com Sun Nov 2 19:02:53 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Sun, 2 Nov 2008 19:02:53 -0600 Subject: Sprint / Cogent dispute over? In-Reply-To: <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> Message-ID: <620fd17c0811021702i2cb7f9a0i82c02ad2c2e95f1e@mail.gmail.com> On Sun, Nov 2, 2008 at 6:05 PM, Brandon Galbraith <brandon.galbraith at gmail.com> wrote: > Seeing as Cogent is going to try tooth and nail to keep their new found Tier > 1 status (and not pay anyone for transit), I would think this would bode > worse for Sprint, since most of their transit customers could migrate to > Cogent (saving $$$ and not having to face future depeerings). Just my $0.02. Cogent has never been a Tier 1, they have only been "transit free". Being transit free is not a difficult accomplishment, it just means that you don't announce or receive routes via a relationship which is intended to be heard by the entire Internet. You could easily go out and buy transit from each of the existing transit free networks, tag your routes with communities to only announce to customers, and become a "transit free" network with global reachability overnight. Of course, this carries with it the risk of breaking global Internet connectivity in the event of a depeering. It is well known that Cogent pays for out-of-ratio traffic with Level3 and Telia, and clearly Sprint says that they have no actual peering agreement. This doesn't have the making of a real tier 1 network. As far as fighting "tooth and nail", that much seems abundantly clear considering that they are actually stealing service from Sprint (and have been for over a year) in order to maintain their status. They used a "trial" peering session to weasel their way into a direct connection with Sprint, and once they got it they intentionally changed their announcements so that if Sprint disconnected them it would cause unreachability. It seems abundantly clear that this situation was created entirely by Cogent, and that they are intentionally harming their customers and the customers of Sprint in an effort to extort a settlement free relationship. This is despicable behavior, if not outright criminal activity considering the theft of service they are committing, and it is amazing that Sprint cared enough about Internet connectivity to allow it to continue for so long, and to restore connectivity temporarily. If any of us stopped paying for our Internet service, and set up routing so that as soon as our provider turned us off we would be reachable to them and their customers complained, then demanded that they give us free service in order to restore connectivity, we would be laughed at. That is what Cogent has done here, and just because they've done it on a large scale doesn't make it right. This specific issue will be solved in a real court and not the court of public opinion, but we should all do our parts to recognize the blatant lies Cogent has told, and to make it clear that we will not accept that kind of behavior. The last thing the Internet needs is more misguided regulation because someone actually believed Cogent's lies. From sethm at rollernet.us Sun Nov 2 20:10:06 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 02 Nov 2008 18:10:06 -0800 Subject: Sprint / Cogent dispute over? In-Reply-To: <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> Message-ID: <490E5D7E.4030505@rollernet.us> Brandon Galbraith wrote: > On 11/2/08, Daniel Roesen <dr at cluenet.de> wrote: >> On Sun, Nov 02, 2008 at 04:40:20PM -0500, Randy Epstein wrote: >>> Problem resolved? >> https://www.sprint.net/cogent.php >> >> >> Best regards, >> Daniel >> >> > Seeing as Cogent is going to try tooth and nail to keep their new found Tier > 1 status (and not pay anyone for transit), I would think this would bode > worse for Sprint, since most of their transit customers could migrate to > Cogent (saving $$$ and not having to face future depeerings). Just my $0.02. > I guess, if you like being affected by Cogent's peering spats on a recurring basis. Are you forgetting this is not the first time? ~Seth From hannigan at gmail.com Sun Nov 2 20:29:06 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Sun, 2 Nov 2008 21:29:06 -0500 Subject: Sprint / Cogent dispute over? In-Reply-To: <490E5D7E.4030505@rollernet.us> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> <490E5D7E.4030505@rollernet.us> Message-ID: <2d106eb50811021829s3dc048d1i987ed8c16d4944a1@mail.gmail.com> On Sun, Nov 2, 2008 at 9:10 PM, Seth Mattinen <sethm at rollernet.us> wrote: > Brandon Galbraith wrote: >> [ snip ] > > > I guess, if you like being affected by Cogent's peering spats on a recurring > basis. Are you forgetting this is not the first time? > But according to Sprint, this isn't a peering spat. This is a customer who didn't pay their bill. Probably useful to keep that in perspective. -M< From vixie at isc.org Sun Nov 2 20:49:20 2008 From: vixie at isc.org (Paul Vixie) Date: Mon, 03 Nov 2008 02:49:20 +0000 Subject: Another driver for v6? In-Reply-To: <Pine.LNX.4.58.0810311926280.6192@scott.cb3rob.net> (HRH Sven Olaf Prinz von CyberBunker-Kamphuis's message of "Fri\, 31 Oct 2008 19\:27\:21 +0000 \(GMT\)") References: <alpine.DEB.1.10.0810290750480.4948@uplift.swm.pp.se> <49088217.3030501@ttec.com> <389B24BA-1AC9-461D-ADE1-F6D99ECC8A5D@ndsu.edu> <4908E47F.2080109@kingrst.com> <20081029232940.GC5212@isc.org> <alpine.DEB.1.10.0810300802410.4948@uplift.swm.pp.se> <20081030154738.GA5482@isc.org> <AB14D5D3-4F78-4D44-8404-7CB7165E0274@nosignal.org> <20081031163248.GF16800@isc.org> <490B351D.2030503@rockynet.com> <20081031164940.GH16800@isc.org> <490B3BD4.6060900@spaghetti.zurich.ibm.com> <Pine.LNX.4.58.0810311926280.6192@scott.cb3rob.net> Message-ID: <g34p2pr0b3.fsf@nsa.vix.com> i'm slightly worried about feeding trolls here but it's sunday here. HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP <sven at cyberbunker.com> writes: > ever heard of the concept "open market" > > ipv4 address space delegations will just move from the rirs to places like > ebay, problem solved. > > most of it is unused anyway (milnet, amateur radio ranges, etc) the human, as a species in the animal kingdom, is known to be the kind of animal who fouls its own nest and overruns its habitat. the idea of a tipping point, whether it be for CO2 in the atmosphere or polar ice shelves or explosively deaggregated IPv4 routing tables, does not occur in the minds of individual decision makers. instead it's left to us "chicken little" types, and the only way the individual decision makers ever make their decisions on the basis of tipping points is if some kind of "governance" makes them do so. -- Paul Vixie From sethm at rollernet.us Sun Nov 2 21:00:53 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 02 Nov 2008 19:00:53 -0800 Subject: Sprint / Cogent dispute over? In-Reply-To: <2d106eb50811021829s3dc048d1i987ed8c16d4944a1@mail.gmail.com> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> <490E5D7E.4030505@rollernet.us> <2d106eb50811021829s3dc048d1i987ed8c16d4944a1@mail.gmail.com> Message-ID: <490E6965.3080008@rollernet.us> Martin Hannigan wrote: > On Sun, Nov 2, 2008 at 9:10 PM, Seth Mattinen <sethm at rollernet.us> wrote: >> Brandon Galbraith wrote: > > [ snip ] > >> >> I guess, if you like being affected by Cogent's peering spats on a recurring >> basis. Are you forgetting this is not the first time? >> > > > But according to Sprint, this isn't a peering spat. This is a customer > who didn't pay their bill. > > Probably useful to keep that in perspective. > Yeah, I know, but it was a trial arrangement which it turns out Cogent didn't meet requirements for, then didn't want to pony up the cash and pretended it was still settlement free peering. And I am inclined to believe Sprint's side of the story because Cogent likes to do this every so often. It just amazes me how some people seem to think this is the first time Cogent has done this. It's like they want the horrid operational impact it will have, cry that big bad provider X disconnected them, and people will come to their defense. ~Seth From justin.ream at tierzero.com Sun Nov 2 21:03:25 2008 From: justin.ream at tierzero.com (Justin Ream) Date: Sun, 02 Nov 2008 19:03:25 -0800 Subject: Sprint / Cogent dispute over? In-Reply-To: <490E6965.3080008@rollernet.us> Message-ID: <C533A9FD.E872%justin.ream@tierzero.com> > It just amazes me how some people seem to think this is the first time > Cogent has done this. It's like they want the horrid operational impact > it will have, cry that big bad provider X disconnected them, and people > will come to their defense. > Everyone loves an underdog story. -Justin From patrick at ianai.net Sun Nov 2 22:41:02 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 2 Nov 2008 23:41:02 -0500 Subject: Why do some companies get depeered and some don't? In-Reply-To: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> References: <1354846503.117451225431145641.JavaMail.root@mbv2.indiatimes.com> <978AF989-64D5-4A00-93F1-0BF79BBA05DA@ianai.net> <490E1630.2080707@ttec.com> <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> Message-ID: <ED95FC9C-CEF9-4F99-BF96-0435825F6770@ianai.net> On Nov 2, 2008, at 4:33 PM, Brandon Galbraith wrote: >> On 11/2/08, Joe Maimon <jmaimon at ttec.com> wrote: >>> Patrick W. Gilmore wrote: >>>> On Oct 31, 2008, at 1:32 AM, Nelson Lai wrote: >>>> >>>> Why do some companies like Cogent get depeered relatively often >>>> and companies like Teleglobe don't even get talked about and >>>> operate in silence free from depeering? >>> >>> That's funny. One of the first networks to de-peer Cogent was >>> Teleglobe. They re-peered after a bit. >>> >>> The next obvious question is: When Sprint, Telia & L3 de-peering >>> Cogent, it causes a lot of news in the press & noise on NANOG, so >>> why didn't you know Teleglobe depeered Cogent? >> >> Imagine the news had they all depeered cogent at the same time. > > Imagine the lawsuits and government regulation had that occurred. That would be none. -- TTFN, patrick From frnkblk at iname.com Sun Nov 2 22:43:16 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 2 Nov 2008 22:43:16 -0600 Subject: routing around Sprint's depeering damage In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net><4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> <490DB215.8070408@zill.net> <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAlIQlYdB6FRbvhGEoXuVRmAQAAAAA=@iname.com> It would be better to regulate some type of communication to customers *before* depeering occurs, much in the same way that the SEC requires publicly traded companies to communicate certain things a certain times to its shareholders. It's an indirect form of market intervention that can be pretty effective, because sometimes the unwillingness to communicate a bad thing to ones customers is enough incentive for the parties involved to "figure it out". Frank -----Original Message----- From: Rod Beck [mailto:Rod.Beck at hiberniaatlantic.com] Sent: Sunday, November 02, 2008 8:24 AM To: Patrick Giagnocavo; nanog at nanog.org Subject: RE: routing around Sprint's depeering damage I'll make one comment before 'Alex the Hammer' closes this discussion for straying into politics. Clearly regulating the incumbents to unbundle local loops has worked very well in some European countries (France and possibly others). Clearly US financial deregulation has cost the world dearly. So regulation is the appropriate response in some cases (I hope that is clear given the world financial system almost went under a few weeks ago). However, it is not clear what a well crafted peering regulation would do that is different than what the market has achieved already. Sensible and hence pragmatic government mandated peering would require companies having equal bilateral traffic flows to peer or buy transit from each other. That would not necessarily preclude the current peering dispute. Forcing companies to peer when it is not in their interest is unlikely to be supported by the courts in any country, even the French and German courts. Sooner or later these two companies in conflict will either return to peering or one of them will buy transit to reach the other. It is a short term issue that probably doesn't merit government intervention Regards, Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From patrick at ianai.net Sun Nov 2 22:46:08 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 2 Nov 2008 23:46:08 -0500 Subject: Sprint / Cogent dispute over? In-Reply-To: <401928DB10D446AA8373ADD1677A90F1@D88CFA77634F40F> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com><409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <401928DB10D446AA8373ADD1677A90F1@D88CFA77634F40F> Message-ID: <3767694C-D86B-43AD-886B-43F6C8E0D606@ianai.net> On Nov 2, 2008, at 7:06 PM, Randy Epstein wrote: >> https://www.sprint.net/cogent.php > > Yes, I've read it. They need to fix their <TITLE>. > > So while Cogent was depeered by Sprint, we contacted the CEO of > Cogent on > Friday to try and arrange at least a temporary peering arrangement > so that > bits flowed between our networks while they battled this situation > out with > Sprint. Cogent's response? Buy transit from them. > > I presume one of Sprint's dissatisfactions during the trial with > Cogent were > ratios. My network happens to have a very high ratio of eyeballs > (inbound > traffic) vs outbound traffic. One would believe that Cogent would > like to > offload their outbound traffic to networks other than their Tier-1 > peers, to > at least give them an upper hand when negotiating peering > arrangements with > these networks. > > It's funny how Cogent depeers networks whenever they want, but the > second > another network depeers them, they cry foul. Aren't you in one of the "1300 on-net locations" with Cogent? Doesn't that give you a free FE? :-) -- TTFN, patrick From repstein at chello.at Sun Nov 2 22:50:07 2008 From: repstein at chello.at (Randy Epstein) Date: Sun, 2 Nov 2008 23:50:07 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAlIQlYdB6FRbvhGEoXuVRmAQAAAAA=@iname.com> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net><4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> <490DB215.8070408@zill.net><1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAlIQlYdB6FRbvhGEoXuVRmAQAAAAA=@iname.com> Message-ID: <5F635DFEC095463D8E312A542918E90C@D88CFA77634F40F> >It would be better to regulate some type of communication to customers >*before* depeering occurs, much in the same way that the SEC requires >publicly traded companies to communicate certain things a certain times to >its shareholders. Wait. Cogent's known about this risk factor for some time. Have they not included this in their 10-Q/K filings? Randy From repstein at chello.at Sun Nov 2 22:51:52 2008 From: repstein at chello.at (Randy Epstein) Date: Sun, 2 Nov 2008 23:51:52 -0500 Subject: Sprint / Cogent dispute over? In-Reply-To: <3767694C-D86B-43AD-886B-43F6C8E0D606@ianai.net> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com><409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F><20081102235422.GA15591@srv03.cluenet.de><401928DB10D446AA8373ADD1677A90F1@D88CFA77634F40F> <3767694C-D86B-43AD-886B-43F6C8E0D606@ianai.net> Message-ID: <049E0679F1BB43209E78F5F411A005F8@D88CFA77634F40F> Patrick, >Aren't you in one of the "1300 on-net locations" with Cogent? Doesn't >that give you a free FE? > :-) Clearly you are joking here, but no, wasn't even offered the free FastE! :) Randy From frnkblk at iname.com Sun Nov 2 23:03:31 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 2 Nov 2008 23:03:31 -0600 Subject: routing around Sprint's depeering damage In-Reply-To: <5F635DFEC095463D8E312A542918E90C@D88CFA77634F40F> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net><4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> <490DB215.8070408@zill.net><1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAlIQlYdB6FRbvhGEoXuVRmAQAAAAA=@iname.com> <5F635DFEC095463D8E312A542918E90C@D88CFA77634F40F> Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACinqik1nnaTajnJyV+Bx3qAQAAAAA=@iname.com> Top of page 12: http://www.cogentco.com/Reports/10k_Report.pdf Doesn't refer to Sprint or anything. But this wasn't the regulation I was talking about -- I'm suggesting a public communication sent by the peered provider to its customers x days before the partitioning event occurs. This would at least give their customers some time to make alternative arrangements. Sprint's web page points out that even while it was turning down each of the peering sites one by one, several days apart, Cogent did not communicate anything to its customers about the impending last snip. Of course, it appears that Sprint didn't communicate anything to its customers, either. Frank -----Original Message----- From: Randy Epstein [mailto:repstein at chello.at] Sent: Sunday, November 02, 2008 10:50 PM To: 'Frank Bulk'; 'Rod Beck'; 'Patrick Giagnocavo'; nanog at nanog.org Subject: RE: routing around Sprint's depeering damage >It would be better to regulate some type of communication to customers >*before* depeering occurs, much in the same way that the SEC requires >publicly traded companies to communicate certain things a certain times to >its shareholders. Wait. Cogent's known about this risk factor for some time. Have they not included this in their 10-Q/K filings? Randy From mysidia at gmail.com Sun Nov 2 23:10:45 2008 From: mysidia at gmail.com (James Hess) Date: Sun, 2 Nov 2008 23:10:45 -0600 Subject: Sprint / Cogent dispute over? In-Reply-To: <2d106eb50811021829s3dc048d1i987ed8c16d4944a1@mail.gmail.com> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> <490E5D7E.4030505@rollernet.us> <2d106eb50811021829s3dc048d1i987ed8c16d4944a1@mail.gmail.com> Message-ID: <6eb799ab0811022110v68b7768fh12095301477d1eec@mail.gmail.com> On Sun, Nov 2, 2008 at 8:29 PM, Martin Hannigan <hannigan at gmail.com> wrote: > But according to Sprint, this isn't a peering spat. This is a customer > who didn't pay their bill. > > Probably useful to keep that in perspective. > -M< I would say it's a "peering spat", because Cogent's press releases stated Sprint failed to meet Sprint's "contractual obligation" to peer with them on a settlement-free basis. That's a political issue that (I expect) remains to be mediated by the courts. The disconnection should have been eminently forseeable by Cogent, if the entire peering was indicated by Sprint as being on a "trial basis". To maintain connectivity, Cogent should have had a contingency in place and taken it, when Sprint rejected their request for settlement-free peering. There is something a bit worst for a single-homed customer than a Tier 1 provider that gets in peering spats; that IS: being single-homed to a provider who wants to say they're "Tier 1" when in fact: they may _really_ be a Tier 2 in disguise. And who as a result of wanting to market themselves "Tier 1" refuses to pay their paid peering fees. Because it means your provider _could_ have taken actions to preserve connectivity, but something else was so much more important to them than providing the product you their customer expect, that they intentionally allow it to get in the way. In other words, if you want to be single-homed, a Tier 2 or 3 upstream that admits they're a Tier 2 or 3, and provides you redundancy and excellent connectivity, seems like the thing to find.. Because a Tier 2 posing and marketing as a Tier 1 might prioritize their continued marketing themselves as a Tier 1 over actually providing Tier 1 connectivity. - Government regulation of peering relationships would be a disaster... I fear regulatory organizations are too easily influenced by the largest players. One can imagine per-megabit "peering taxes" imposed by the feds on interconnections between different networks that only large providers would have carved out rules to exempt themselves from. And artificial government interfering with small networks wanting to peer. Requiring reams of paperwork, registrations, design documents, waiting periods, etc.... -- -J From patrick at ianai.net Mon Nov 3 00:26:14 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Nov 2008 01:26:14 -0500 Subject: Sprint v. Cogent, some clarity & facts Message-ID: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> Having skimmed the Sprint / Cogent threads, I saw multiple errors and lots of really bad guesses. Instead of replying individually, I thought I would sum up a few facts so everyone was on the same page. This way when we run off into another 100 post thread, we can at least -start- from reality (although I would bet serious cash on long odds we will diverge from it soon enough). 1. Neither Sprint nor Cogent have transit Both Sprint & Cogent are transit-free networks. (Notice how I carefully avoided saying "tier one"?) Whether one or both _should_ have transit is not a fact, and therefore outside the scope of this e- mail, but that neither have transit today is a fact. (And please don't tell me how Network X has 100 Mbps of transit in Sri Lanka because they are too lazy to lease undersea cable. If you don't understand what I am saying here, stop reading now.) 2. The Internet cannot "route around" de-peering I know everyone believes "the Internet routes around failures". While occasionally true, it does not hold in this case. To "route around" the "failure" would require transit. See item #1. 3. Standard transit contracts do not guarantee full connectivity If you are a Cogent customer, it is very unlikely your contract will allow you SLA or other credits for not being able to reach Sprint unless you negotiated something special. I doubt Sprint's standard contract is much different. Transit contract SLAs end at AS boundaries. This is because Network A has no control over Network B and therefore will not give credit if Network B fails. Of course, you can still sue, threaten to terminate, etc., but the letter of the contract almost certainly says nothing about packets going beyond your transit provider's ASN. 4. There is a reason behind ratios which has nothing to do with telco "sender-pays" Hot potato routing + very poor ratios puts much more of the cost on the receiving network. This is a valid, logical, and costly concern for receiving networks. The concern can be alleviated by cold-potato routing through accepting MEDs, anycast, CDN, and other technologies; to which the receiving network may say they cannot send proper MEDs, etc. Whether the problem can or should be worked through is not a fact, though. That this issue has nothing to do with telco "sender- pays" mentality is. (Of course, the telcos might still have that mentality, but that doesn't change the facts.) 5. Cogent has been disconnected several times Cogent has been de-peered (e.g. Teleglobe, L3, Sprint) and/or performed de-peering themselves (e.g. Telia) multiple times. Cogent has been disconnected from another network more times & for longer (in each instance?) than every other transit free network combined for the last decade. (In fact, if memory serves, for the history of the Internet - but I'm not quite sure enough to guarantee it as fact.) Cogent has also de-peered many non-transit-free networks, at least sometimes without even notifying the peer prior to disconnection. Whether that makes Cogent the bully-er or the bully-ee is not fact, so I will not comment on that here. There are probably other errors I missed while skimming the longer posts. But this should get us started on a good, clean, factual footing for future flights of fancy. -- TTFN, patrick From karnaugh at karnaugh.za.net Mon Nov 3 01:33:43 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 03 Nov 2008 09:33:43 +0200 Subject: routing around Sprint's depeering damage In-Reply-To: <490CF7AD.50800@internode.com.au> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CF7AD.50800@internode.com.au> Message-ID: <490EA957.8010708@karnaugh.za.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Moyle-Croft wrote: > Dave Blaine wrote: >> There are at least three ways to address this Sprint / Cogent partition > I'd be fairly reluctant to allow the government to get involved in > peering relationships too deeply. Australia has some very wierd > consquences of our government doing so almost ten years on. One of > those is which is that the "Gang of Four" have effectively set a floor > price on domestic transit that is much higher than it should be - > meaning that much content is delivered to us from overseas because the > cost of delivering in Australia to those networks is too high to do so > economically. Even a lot of Australian content is hosted overseas for > this reason. Snap, same problem in ZA. Except it's a gang of two. You don't want your government involved, you want them to go away... Unfortunately our government misinterpreted "go away" as "get more involved, here lies money", so watch out for that too! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJDqlX0FZZWLfHKjURArQIAJ9yljqGppZorgD4Q99JOtCIMIB9igCfSg9D 9erfOYsDSM2IuQxylgcdVgE= =SGyH -----END PGP SIGNATURE----- From pauldotwall at gmail.com Mon Nov 3 01:35:42 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 3 Nov 2008 02:35:42 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> Message-ID: <620fd17c0811022335l27f64ae2r42f68b161145d7ac@mail.gmail.com> On Mon, Nov 3, 2008 at 1:26 AM, Patrick W. Gilmore <patrick at ianai.net> wrote: > 1. Neither Sprint nor Cogent have transit > Both Sprint & Cogent are transit-free networks. (Notice how I carefully > avoided saying "tier one"?) How do you explain Cogent's arrangement with NTT (AS 2914)? If it's not transit, what is it? Does Akamai have peering arrangements with Cogent directly? Paul From karnaugh at karnaugh.za.net Mon Nov 3 01:47:47 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 03 Nov 2008 09:47:47 +0200 Subject: routing around Sprint's depeering damage In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net><4c7b1780811020452r55f86e98w778fa65428fa04cb@mail.gmail.com> <490DB215.8070408@zill.net> <1E8B940C5E21014AB8BE70B975D40EDB483B87@bert.HiberniaAtlantic.local> Message-ID: <490EACA3.6090803@karnaugh.za.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rod Beck wrote: > I'll make one comment before 'Alex the Hammer' closes this discussion > for straying into politics. > > Clearly regulating the incumbents to unbundle local loops has worked > very well in some European countries (France and possibly others). > Clearly US financial deregulation has cost the world dearly. > > So regulation is the appropriate response in some cases (I hope that > is clear given the world financial system almost went under a few > weeks ago). I think you're making a faulty logical leap. Regulation to unbundle local loops works (sometimes) because it is a simple regulation that undoes what a previous regulation screwed up in the first place. That said, flattening the regulations to allow others to properly build their own loops would likely be more effective, except from a cost perspective it has a very high barrier to entry - however people could form smaller operations and simply service their community then grow that mesh outwards. That is an option I'd take over LLU far more readily. The issue for me comes from looking at the incumbents position. Many of these were government owned entities that were privatised, and then later in some cases gone to public market ownership. It sets a nasty precedent when you hand a company their privatisation, and then later on start bullying them around at a very high legal level. Those are still laws that apply across all other companies too - and in the worst of cases they are applied across a group of 'license holders' which simply further entrenches their position. Much of this also tends to alert governments to the fact that they are financially incentivised to hold their big money churning incumbents as the tax rewards are greater, and if they are an African government; hell, just force your incumbents to give you shares. So no, regulation is not an appropriate response in some cases, you've only confused it with deregulation, and it's one I'm not convinced about either... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJDqyj0FZZWLfHKjURAo4zAJ4od5mGi+OG644nmen+uEr+G6M/vQCfasQZ 7Ivu9l8zT5aMDliGTDZbk24= =jViN -----END PGP SIGNATURE----- From fw at deneb.enyo.de Mon Nov 3 03:26:59 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 03 Nov 2008 10:26:59 +0100 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> (Patrick W. Gilmore's message of "Mon, 3 Nov 2008 01:26:14 -0500") References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> Message-ID: <87k5blkvmk.fsf@mid.deneb.enyo.de> * Patrick W. Gilmore: > 1. Neither Sprint nor Cogent have transit > Both Sprint & Cogent are transit-free networks. (Notice how I > carefully avoided saying "tier one"?) Whether one or both _should_ > have transit is not a fact, and therefore outside the scope of this e- > mail, but that neither have transit today is a fact. (And please > don't tell me how Network X has 100 Mbps of transit in Sri Lanka > because they are too lazy to lease undersea cable. If you don't > understand what I am saying here, stop reading now.) > > 2. The Internet cannot "route around" de-peering > I know everyone believes "the Internet routes around failures". While > occasionally true, it does not hold in this case. To "route around" > the "failure" would require transit. See item #1. Out of curiosity, what would happen if one of the parties got transit from a business POV? Not just in this particular case, but in general. Doesn't this work because they are so large that any such arrangement would immediately threaten traffic ratios at the (transit-free) transit provider? > 3. Standard transit contracts do not guarantee full connectivity If this were true, why would end users (or, more generally, not significantly multi-homed networks) buy transit from such networks? From Valdis.Kletnieks at vt.edu Mon Nov 3 03:51:06 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 03 Nov 2008 04:51:06 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: Your message of "Mon, 03 Nov 2008 10:26:59 +0100." <87k5blkvmk.fsf@mid.deneb.enyo.de> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> <87k5blkvmk.fsf@mid.deneb.enyo.de> Message-ID: <60673.1225705866@turing-police.cc.vt.edu> On Mon, 03 Nov 2008 10:26:59 +0100, Florian Weimer said: > * Patrick W. Gilmore: > > 3. Standard transit contracts do not guarantee full connectivity > > If this were true, why would end users (or, more generally, not > significantly multi-homed networks) buy transit from such networks? Quite frankly, if any potential transit provider tried to make noises about being able to *guarantee* full connectivity, I'd show him the door. Consider the average length of an AS path. Now consider that your AS is at one end, your transit provider is the next hop - and there's often 5 or 6 or more AS hops past that. And that potential transit provider has absolutely *no* control over what some backhoe just did to connectivity 4 AS down the path... For example, look at the traceroute from my desktop to where your mail originated: traceroute to 212.9.189.177 (212.9.189.177), 30 hops max, 60 byte packets 1 isb-6509-1.vl103.cns.vt.edu (128.173.12.1) 0.394 ms 0.712 ms 0.791 ms 2 isb-6509-2.po51.cns.vt.edu (128.173.0.5) 0.597 ms 0.681 ms 0.756 ms 3 isb-7606-2.ge1-1.cns.vt.edu (192.70.187.218) 0.740 ms 0.709 ms 0.687 ms 4 192.70.187.10 (192.70.187.10) 7.590 ms 7.610 ms 7.647 ms 5 te2-1--580.tr01-asbnva01.transitrail.net (137.164.131.177) 89.583 ms 89.618 ms 89.797 ms 6 llnw-peer.asbnva01.transitrail.net (137.164.130.30) 11.956 ms 9.450 ms 9.473 ms 7 ve5.fr3.iad.llnw.net (69.28.171.213) 17.243 ms 9.689 ms 17.443 ms 8 * * * 9 FRA-3-eth0-403.de.lambdanet.net (81.209.156.9) 99.266 ms 99.180 ms 99.163 ms 10 FRA-1-eth000.de.lambdanet.net (217.71.96.69) 98.342 ms 98.436 ms 98.283 ms 11 STU-3-pos330.de.lambdanet.net (217.71.96.82) 111.748 ms 111.764 ms 107.438 ms 12 bond0.border2.LF.net (212.9.160.73) 104.380 ms 104.404 ms 104.262 ms 13 em1.core.LF.net (212.9.160.65) 104.622 ms 104.761 ms 104.504 ms 14 dsl-gw.ispeg.de (212.9.161.26) 106.013 ms 105.999 ms 105.973 ms 15 dsl.enyo.de (213.178.172.64) 135.094 ms 136.729 ms 136.007 ms Are you saying that you'd accept a contract where ispeg.de or LF.net are making claims they can guarantee connectivity to AS1312 no matter what transitrail is doing? (I admit being surprised - I was *expecting* the traceroute to go through Level3 or Sprint, actually. When did lambdanet land in DE? ;) (And the real kicker - if transitrail burps, is ispeg or LF able to find us via our Level3 or Sprint connections? Maybe, maybe not...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081103/98c2239e/attachment.bin> From cgucker at onesc.net Mon Nov 3 06:58:46 2008 From: cgucker at onesc.net (Charles Gucker) Date: Mon, 3 Nov 2008 08:58:46 -0400 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <620fd17c0811022335l27f64ae2r42f68b161145d7ac@mail.gmail.com> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> <620fd17c0811022335l27f64ae2r42f68b161145d7ac@mail.gmail.com> Message-ID: <c85424b0811030458x5fffb1dar3e254495d73a8308@mail.gmail.com> On Mon, Nov 3, 2008 at 3:35 AM, Paul Wall <pauldotwall at gmail.com> wrote: > On Mon, Nov 3, 2008 at 1:26 AM, Patrick W. Gilmore <patrick at ianai.net> wrote: >> 1. Neither Sprint nor Cogent have transit >> Both Sprint & Cogent are transit-free networks. (Notice how I carefully >> avoided saying "tier one"?) > > How do you explain Cogent's arrangement with NTT (AS 2914)? If it's > not transit, what is it? So you are asking to have what was Cogent's arrangement with NTT? That's like asking what was AOL's relationship with Level(3) when they had their peering spat with Sprint. Just because a relationship existed in the past does not mean the same relationship exists today. Accept the fact that both providers are transit free and move forward. > Does Akamai have peering arrangements with Cogent directly? Akamai are self declared peering sluts. So, yes, they have direct peering arrangements with Cogent. charles From cgucker at onesc.net Mon Nov 3 07:08:33 2008 From: cgucker at onesc.net (Charles Gucker) Date: Mon, 3 Nov 2008 09:08:33 -0400 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <c85424b0811030458x5fffb1dar3e254495d73a8308@mail.gmail.com> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> <620fd17c0811022335l27f64ae2r42f68b161145d7ac@mail.gmail.com> <c85424b0811030458x5fffb1dar3e254495d73a8308@mail.gmail.com> Message-ID: <c85424b0811030508h5556c75clcb2e01041ba85a13@mail.gmail.com> >> Does Akamai have peering arrangements with Cogent directly? > > Akamai are self declared peering sluts. So, yes, they have direct > peering arrangements with Cogent. Hrm, so after I posted this, I looked a bit deeper into it and found: 3 vl3493.mpd03.jfk02.atlas.cogentco.com (154.54.5.226) 0.665 ms 0.670 ms 0.667 ms 4 te9-4.mpd01.jfk05.atlas.cogentco.com (154.54.26.62) 0.697 ms 0.686 ms 0.653 ms 5 gblx.jfk05.atlas.cogentco.com (154.54.11.138) 0.721 ms 0.717 ms 0.802 ms 6 te3-2-10g.ar4.nyc1.gblx.net (67.16.131.105) 0.986 ms 0.934 ms 1.181 ms 7 bandwidth-consulting.tengigabitethernet8-3.ar4.nyc1.gblx.net (64.210.29.14) 0.696 ms 2.665 ms 0.700 ms 8 te-8-3.bbr1.ash1.bandcon.com (216.151.179.225) 7.187 ms 7.177 ms 7.073 ms 9 209.234.254.198 (209.234.254.198) 7.322 ms 7.141 ms 7.217 ms 10 84.53.144.71 (84.53.144.71) 7.053 ms 7.071 ms 7.016 ms So, for at least for traceroute www.akamai.com, Coget is using their peer (Global Crossing) to reach Akamai transit provider. Guess I got caught up in the past myself, thinking "Cogent would never depeer a slut like Akamai". charles From patrick at ianai.net Mon Nov 3 07:09:28 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Nov 2008 08:09:28 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <620fd17c0811022335l27f64ae2r42f68b161145d7ac@mail.gmail.com> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> <620fd17c0811022335l27f64ae2r42f68b161145d7ac@mail.gmail.com> Message-ID: <8A979F72-95E6-4A74-8012-AF98292DCBE6@ianai.net> On Nov 3, 2008, at 2:35 AM, Paul Wall wrote: > On Mon, Nov 3, 2008 at 1:26 AM, Patrick W. Gilmore > <patrick at ianai.net> wrote: >> 1. Neither Sprint nor Cogent have transit >> Both Sprint & Cogent are transit-free networks. (Notice how I >> carefully >> avoided saying "tier one"?) > > How do you explain Cogent's arrangement with NTT (AS 2914)? If it's > not transit, what is it? I do not know, and neither do you. But I do know it is not "transit", at least not to Sprint. It is trivial to prove to yourself if Cogent has transit. Find me any AS path in the global table showing "_TF1_TF2_174_", there "TF1" and "TF2" are the ASNs of two of the other 13 transit free networks. (Modulo a few leaked prefixes, which always seem to crop up. For instance, if a network has 40K prefixes in its cone, showing O(10) paths is not proof.) This is a positive test - if you see it, you know they have transit, if you do not see it, you do not know they do not have transit. But combined with bifurcation when Sprint drops peering to Cogent, one can _know_ Cogent does not have full transit, or partial transit to Sprint. It is possible (although I personally believe unlikely) Cogent has partial transit to some other transit free network that you cannot see right now because their peering to that network is up and overriding the AS paths in the global table. But that doesn't matter to this discussion. > Does Akamai have peering arrangements with Cogent directly? That is none of your business, not to mention completely irrelevant to the topic at hand as Akamai is neither a network nor transit free. -- TTFN, patrick From patrick at ianai.net Mon Nov 3 07:17:31 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Nov 2008 08:17:31 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <87k5blkvmk.fsf@mid.deneb.enyo.de> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> <87k5blkvmk.fsf@mid.deneb.enyo.de> Message-ID: <99AE6285-0926-454F-9A84-13CF9737E4CA@ianai.net> On Nov 3, 2008, at 4:26 AM, Florian Weimer wrote: > * Patrick W. Gilmore: > >> 1. Neither Sprint nor Cogent have transit >> Both Sprint & Cogent are transit-free networks. (Notice how I >> carefully avoided saying "tier one"?) Whether one or both _should_ >> have transit is not a fact, and therefore outside the scope of this >> e- >> mail, but that neither have transit today is a fact. (And please >> don't tell me how Network X has 100 Mbps of transit in Sri Lanka >> because they are too lazy to lease undersea cable. If you don't >> understand what I am saying here, stop reading now.) >> >> 2. The Internet cannot "route around" de-peering >> I know everyone believes "the Internet routes around failures". >> While >> occasionally true, it does not hold in this case. To "route around" >> the "failure" would require transit. See item #1. > > Out of curiosity, what would happen if one of the parties got transit > from a business POV? Not just in this particular case, but in > general. From a business perspective, one of the two parties would then be paying a third party to reach the other. In fact, a year ago this is exactly what was happening - Cogent bought partial transit from Verio to reach Sprint and AOL. Neither believes this is in their best interest. I cannot tell you if that is true. > Doesn't this work because they are so large that any such arrangement > would immediately threaten traffic ratios at the (transit-free) > transit provider? Obviously not since it was happening in the past. But you make a good point. Traffic from either of these networks is probably large enough to push at least one of the other transit-free networks over their peering ratios with someone else. But probably not all. It is probable some transit free networks gets more traffic from Sprint than they send, so selling transit to Cogent would not hurt them. Not so sure any transit-free network pushes more to Cogent than they receive, but I cannot prove it. And even if selling to Cogent would put them over their ratio requirements, perhaps they could negotiate a better settlement deal, so they get more from Cogent than they pay to Sprint. Despite the fact I believe Cogent is heavy outbound to all other transit free networks, there are solutions that would allow a network to sell Sprint transit to Cogent. Etc., etc. It is a business problem, it has multiple business solutions. >> 3. Standard transit contracts do not guarantee full connectivity > > If this were true, why would end users (or, more generally, not > significantly multi-homed networks) buy transit from such networks? "If this were true"? "Why would end users [...] buy transit from such networks"? Please show me a transit contract - just one - that guarantees connectivity beyond the transit AS boundary. Put another way, since _every_ network does this, if you do not want to buy from 'such networks', you cannot buy transit. -- TTFN, patrick From michael.dillon at bt.com Mon Nov 3 07:54:30 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 3 Nov 2008 13:54:30 -0000 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <99AE6285-0926-454F-9A84-13CF9737E4CA@ianai.net> Message-ID: <C0F2465B4F386241A58321C884AC7ECC091C0926@E03MVZ2-UKDY.domain1.systemhost.net> > Put another way, since _every_ network does this, if you do > not want to buy from 'such networks', you cannot buy transit. Let's put it another 'nother way. Would an end user get better connectivity by buying from a reseller of transit? In other words, buying transit from a network which also buys transit. Presumably up near the top of the chain (Tier 1 vicinity), that transit reseller has a lot of peering in place with other folks in the same neighborhood (Tier 1 vicinity). But as long as a network is a transit reseller (i.e. they buy transit), then they are less likely to suffer from partition events caused by fractious peering negotiations. --Michael Dillon frac*tious (frakshus) adj. 1. Inclined to make trouble; unruly. 2. Having a peevish nature; cranky. Also likely to cause your network having connectivity to only a fraction of the Internet. From vixie at isc.org Mon Nov 3 08:14:29 2008 From: vixie at isc.org (Paul Vixie) Date: Mon, 03 Nov 2008 14:14:29 +0000 Subject: Sprint / Cogent dispute over? In-Reply-To: <6eb799ab0811022110v68b7768fh12095301477d1eec@mail.gmail.com> (James Hess's message of "Sun\, 2 Nov 2008 23\:10\:45 -0600") References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> <490E5D7E.4030505@rollernet.us> <2d106eb50811021829s3dc048d1i987ed8c16d4944a1@mail.gmail.com> <6eb799ab0811022110v68b7768fh12095301477d1eec@mail.gmail.com> Message-ID: <g3wsfkq4l6.fsf@nsa.vix.com> note that i have friends at both sprint and cogent and i'm not taking sides. "James Hess" <mysidia at gmail.com> writes: > I would say it's a "peering spat", because Cogent's press releases stated > Sprint failed to meet Sprint's "contractual obligation" to peer with them > on a settlement-free basis. That's a political issue that (I expect) > remains to be mediated by the courts. if cogent signed a trial peering contract which required payment if sprint determined after three months that cogent did not qualify, then the court's open questions are was the contract valid (and thus, does cogent owe sprint money) and why isn't there some kind of common carriage law for IP like in dialtone to protect the end users from these types of partition events? i guess we'll all see and discuss the filings here. perhaps cogent countersued on some grounds having to do with the interconnect itself, but with wvfiber standing ready to act as a friend of the court, that's a dangerous game. > The disconnection should have been eminently forseeable by Cogent, if the > entire peering was indicated by Sprint as being on a "trial basis". To > maintain connectivity, Cogent should have had a contingency in place and > taken it, when Sprint rejected their request for settlement-free peering. by that reasoning shouldn't sprint have also had such a contingency plan? > There is something a bit worst for a single-homed customer than a Tier 1 > provider that gets in peering spats; that IS: being single-homed to a > provider who wants to say they're "Tier 1" when in fact: they may > _really_ be a Tier 2 in disguise. > > And who as a result of wanting to market themselves "Tier 1" refuses to > pay their paid peering fees. this is similar to the logic PSI gave me when i was at MFN. of course, both companies later went through bankruptcy (but only one came out again). but i remember getting PSI's demand for payment for peering, looking at network maps, saying "but, my network is BIGGER than yours, more routers, more/fatter pipes, more peering edges, more traffic" and asking "why would i pay you?" but according to PSI they had more eyeballs and i had a ratio problem. note that MFN *did* make arrangements for our customers to reach and be reached by PSI's customers before the date PSI told us they were shutting down peering. (and, the fact that PSI was behind on their their payments to MFN for dark fiber IRU's helped my case considerably.) i re-raise this story not because i'm still pissed off about it, but because peering spats *always* involve assertions of unfairness from both sides. it's just business, and it's all part of the game. ultimately somebody will blink. > ... > > Because a Tier 2 posing and marketing as a Tier 1 might prioritize their > continued marketing themselves as a Tier 1 over actually providing Tier 1 > connectivity. > > Government regulation of peering relationships would be a disaster... I > fear regulatory organizations are too easily influenced by the largest > players. > > ... the very fact that folks speak about tiers here may be a red flag to regulators. forgetting the "t" word for the moment, peering is a business decision involving both tactical cost:benefit and strategic cost:benefit, and ultimately we can expect cogent and sprint to work it out on that basis, not on the "t" word basis. -- Paul Vixie From streiner at cluebyfour.org Mon Nov 3 08:17:03 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 3 Nov 2008 09:17:03 -0500 (EST) Subject: routing around Sprint's depeering damage In-Reply-To: <490DC3C6.7090402@eeph.com> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> Message-ID: <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> On Sun, 2 Nov 2008, Matthew Kaufman wrote: > Ah yes, I suspect we can get all the network operators here to agree that any > customer of another ISP should buy a second connection "just in case". Maybe > this breakage will turn out to be the best way for everyone to double their > customer base overnight. > > But seriously, it shouldn't be necessary to have two connections at work, two > connections at home, two connections for each mobile device, just to ensure > that when large providers stop working together you can still reach what you > need to reach. No, but the providers who provide those connections should be multihomed. If they're not, I'd consider switching providers. Simple as that. jms From sven at cyberbunker.com Mon Nov 3 08:41:33 2008 From: sven at cyberbunker.com (HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP) Date: Mon, 3 Nov 2008 14:41:33 +0000 (GMT) Subject: routing around Sprint's depeering damage In-Reply-To: <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> Message-ID: <Pine.LNX.4.58.0811031435210.3374@scott.cb3rob.net> > No, but the providers who provide those connections should be multihomed. > If they're not, I'd consider switching providers. Simple as that. > > jms multihomed to whichever parties decide to generate split ups on purpose in the intarrwebbz.. meaning: all of them.. (you can never tell which ones will get the idea to depeer next, so you have to be multihomed to all of them or this can still happen) -this- time its sprint and cogent, next time it could be level3 and sprint, etc, now, do you want to multihome on all of them, just to avoid problems when they purposely and actively break the internet, or would you rather just tell them not to do it.. what should happen here is their customers just enforcing a contract change that they contractually have to make every possible effort to peer with anyone or the customers leave... you can buy shares in both companies, so its also possible to cause a riot at their shareholders meeting if this is a major problem to your connectivity, and tell them never to do that again. > > > X-CONTACT-FILTER-MATCH: "nanog" > From davids at webmaster.com Mon Nov 3 08:46:24 2008 From: davids at webmaster.com (David Schwartz) Date: Mon, 3 Nov 2008 06:46:24 -0800 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <60673.1225705866@turing-police.cc.vt.edu> Message-ID: <MDEHLPKNGKAHNMBLJOLKGEPNANAD.davids@webmaster.com> > Quite frankly, if any potential transit provider tried to make > noises about > being able to *guarantee* full connectivity, I'd show him the door. Let's not make the perfect the enemy of the good. All that's required is that they promise to make a good faith effort to interconnect with anyone else who makes a similar good faith effort. Now we can all fight about whether Cogent and/or Sprint are making such a good faith effort. ;) DS From patrick at ianai.net Mon Nov 3 08:54:52 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Nov 2008 09:54:52 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: <Pine.LNX.4.58.0811031435210.3374@scott.cb3rob.net> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> <Pine.LNX.4.58.0811031435210.3374@scott.cb3rob.net> Message-ID: <41CC83CE-2BEF-493B-8901-60E21F948627@ianai.net> On Nov 3, 2008, at 9:41 AM, HRH Sven Olaf Prinz von CyberBunker- Kamphuis MP wrote: >> No, but the providers who provide those connections should be >> multihomed. >> If they're not, I'd consider switching providers. Simple as that. > multihomed to whichever parties decide to generate split ups on > purpose > in the intarrwebbz.. meaning: all of them.. (you can never tell > which ones > will get the idea to depeer next, so you have to be multihomed to > all of > them or this can still happen) I am afraid you are confused. No, you do not have to attach to every network unless you think every network is going to disconnect from every other network simultaneously. (Would there even be an Internet then?) If you are attached to two transit-free networks, you are guaranteed connectivity to the entire Internet unless there is more than one bifurcation simultaneously. And not just any two bifurcations. Specifically, both of your upstreams would have to depeer the same transit free network at the same time. Attach to three, and it would require all 3 to depeer someone simultaneously to affect you. Etc., etc. > what should happen here is their customers just enforcing a contract > change that they contractually have to make every possible effort to > peer with > anyone or the customers leave... Good luck with that. -- TTFN, patrick From dts at senie.com Mon Nov 3 09:01:48 2008 From: dts at senie.com (Daniel Senie) Date: Mon, 03 Nov 2008 10:01:48 -0500 Subject: Sprint / Cogent dispute over? In-Reply-To: <20081102235422.GA15591@srv03.cluenet.de> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> Message-ID: <200811031501.mA3F1omo031556@parsley.amaranth.net> At 06:54 PM 11/2/2008, Daniel Roesen wrote: >On Sun, Nov 02, 2008 at 04:40:20PM -0500, Randy Epstein wrote: > > Problem resolved? > >https://www.sprint.net/cogent.php Reading this accounting of Sprint's side of the story reveals something that's not too surprising about Sprint. They've got serious accounting problems. The trial of peering they talk about was for three months in 2007, ending in September 2007. They claim to have billed Cogent at the end of it, though knowing Sprint's billing (having had them fail to send me bills, then hit me with late fees) they probably can't prove that. But this is a YEAR later. They let an account linger for a year without collecting or terminating the services provided. That's their own damned fault. This indicates poor management of Accounts Receivable. That's your problem, Sprint, deal with it. Also in this document is a complaint that Cogent failed to disconnect. Excuse me? This was a trial PEERING agreement. That implies one or a series of point-to-point connections. That implies EITHER party can disconnect the circuits (in reality, the physical circuit doesn't even matter, just shut down the BGP session(s)). So Sprint failed to manage Accounts Receivable and left this "temporary" circuit in place too long. Some bean counter noticed this a year later. Way to go Sprint. As I've noted previously, Sprint hurt its own customers by the action taken. It's my guess they restored the circuit to avoid further damage to themselves that resulted from their actions. It's interesting to see a biased, "blame Cogent first" mentality in so many postings on NANOG. Maybe they deserve it, maybe not. But after reading the traffic here, after living through the consequences of the Cogent/L3 depeering, and after reading what Sprint said on their page, my read on this is that Sprint's accounting department might need some house cleaning. From eric at atlantech.net Mon Nov 3 09:02:17 2008 From: eric at atlantech.net (Eric Van Tol) Date: Mon, 3 Nov 2008 10:02:17 -0500 Subject: "Tier 1" vs. all. Was: Sprint v. Cogent, some clarity & facts In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC091C0926@E03MVZ2-UKDY.domain1.systemhost.net> References: <99AE6285-0926-454F-9A84-13CF9737E4CA@ianai.net> <C0F2465B4F386241A58321C884AC7ECC091C0926@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350C3DA6D5@exchange.aoihq.local> > -----Original Message----- > From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] > Sent: Monday, November 03, 2008 8:55 AM > > Let's put it another 'nother way. > Would an end user get better connectivity by buying from a > reseller of transit? In other words, buying transit from > a network which also buys transit. Presumably up near the > top of the chain (Tier 1 vicinity), that transit reseller > has a lot of peering in place with other folks in the same > neighborhood (Tier 1 vicinity). But as long as a network > is a transit reseller (i.e. they buy transit), then they > are less likely to suffer from partition events caused > by fractious peering negotiations. > > --Michael Dillon Can anyone explain to me why end users find it so important to label carriers as "Tier 1" or "Tier 2"? The prevailing theory in the heads of prospective customers is that a "Tier 1" is somehow inherently better than a "Tier 2" (or lower), even though they don't quite understand the concepts behind why the "Tier" designation even exist(s/ed). These labels, at least to me, are no longer very relevant in today's internet world. In fact, would anyone agree that being a "Tier 1", as Cogent believes themselves to be, leaves that network in a very painful position when things like their frequent peering disputes happen? For an NSP, it's obviously a "good thing" to be SFI-only, as in theory, it _should_ lower your costs. YMMV, as mentioned in a previous thread. However, what does it really matter to an end-user, especially if they are biased towards using "Tier 1" networks only? Why does a network who purchases transit give the impression to end users that that network's internet genitalia is somehow smaller than, say, Verizon or AT&T? I can see merit in touting the size and coverage of the actual network, but it's always been my understanding that this is not the true definition of the tiered system. -evt From davids at webmaster.com Mon Nov 3 09:03:04 2008 From: davids at webmaster.com (David Schwartz) Date: Mon, 3 Nov 2008 07:03:04 -0800 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> Message-ID: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> Patrick W. Gilmore wrote: > 4. There is a reason behind ratios which has nothing to do with telco > "sender-pays" There is an alleged reason. > Hot potato routing + very poor ratios puts much more of the cost on > the receiving network. This is a valid, logical, and costly concern > for receiving networks. So what? So the argument is: 1) Your customers want to receive from my customers. 2) Receiving is more expensive. 3) Therefore you should pay me? I want to send, and sending is cheap. Your customers want to do the expensive receiving, not mine. My customers want to do the cheap sending. The ratio argument is nonsense. If your customers want to receive mostly, and receiving is expensive, they should pay you more to cover your higher costs in receiving traffic. If my customers mostly want to send, and sending is cheap, then I should pay less, since I want to do the cheap thing and you want to do the expensive thing. If we hold a convention in Idaho, the people who live near Idaho don't pay money to the people who came from out-of-town. And if you live in Alaska, get used to the fact that you're going to be paying more than your share of transportation expenses to go to conventions. If you don't like it, don't live in Alaska. > That this issue has nothing to do with telco "sender- > pays" mentality is. (Of course, the telcos might still have that > mentality, but that doesn't change the facts.) You are probably right that it's not an old-fahsioned "sender-pays" mentality. But it is complete nonsense. Your customers pay you to receive their traffic, even if that's more expensive than other things they might want to do. Your customers pay you to carry their traffic across your network between them and the next network in the line. There is no reason anyone else should compensate you for doing this. DS From jgreco at ns.sol.net Mon Nov 3 09:07:53 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 3 Nov 2008 09:07:53 -0600 (CST) Subject: routing around Sprint's depeering damage In-Reply-To: <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> from "Justin M. Streiner" at Nov 03, 2008 09:17:03 AM Message-ID: <200811031507.mA3F7rBk069298@aurora.sol.net> > No, but the providers who provide those connections should be multihomed. > If they're not, I'd consider switching providers. Simple as that. Am I the only one to whom this sounds really strange? I really doubt that customers going to buy Sprint EVDO service are asking about "are you multihomed," or that they realize that they should ask such a question, or that the salesman would have any clue, and when the salesman tried to figure out what it meant, he'd come up with it equating to "how reliable is your service," to which he'd answer "Yes, of course, it's very reliable!" because he'd honestly never heard of a "peering dispute." This all gets back to a point that I've tried to impress on several people who are all-too-fixated on contracts and how contracts will make it all work out in the end, or how it is too bad when that doesn't happen. We can all agree that, on a technical level, a provider here in the US cannot guarantee the reachability of portions of China on the end of two tin cans and a string, and to us, this seems obvious. However, it might take a little time to explain this to a non-technical person. However, when two networks that previously had a connection to each other, and who have no technical issue that prevents them from continuing such a connection, then decide to not only eliminate said connection and actively take steps that are meant to coerce the other network into some particular activity, that's something a little different. My concern isn't about the letter of the contract between Sprint and their customers, or the letter of the contract between Cogent and their customers. My concern is that they are being sold "Internet service," and sooner or later someone is going to notice that the incomplete Internet service being delivered is due to decisions actually made by the service provider(s). At this point, there's a very real possibility that the customer will argue that they interpreted the terms of the bandwidth contract to mean "best effort Internet" in the China example sense, not "best effort Internet" where the service provider decided a business strategy made making part of the Internet deliberately unreachable so that they could use their customers as traffic hostages was a good idea. At that point, we could see a court make a determination as to what the obligations are, or worse, we could see government interference with the operation of major networks. "Switch providers" is a nice sound bite, but the reality of it all is that most customers are locked into various types of contracts, and this is an expensive proposition, one that burdens the consumer. I am sure that each side can make a legitimate business case for the actions taken. I don't care. Ultimately, events like this are likely to be a driving force between some "network neutrality" regulation that we are all going to regret on some level. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From tme at multicasttech.com Mon Nov 3 09:08:44 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 3 Nov 2008 10:08:44 -0500 Subject: "Tier 1" vs. all. Was: Sprint v. Cogent, some clarity & facts In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B86350C3DA6D5@exchange.aoihq.local> References: <99AE6285-0926-454F-9A84-13CF9737E4CA@ianai.net> <C0F2465B4F386241A58321C884AC7ECC091C0926@E03MVZ2-UKDY.domain1.systemhost.net> <2C05E949E19A9146AF7BDF9D44085B86350C3DA6D5@exchange.aoihq.local> Message-ID: <E5EF3B41-EA9B-4881-B1D4-CE2181371EA2@multicasttech.com> On Nov 3, 2008, at 10:02 AM, Eric Van Tol wrote: >> -----Original Message----- >> From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] >> Sent: Monday, November 03, 2008 8:55 AM >> >> Let's put it another 'nother way. >> Would an end user get better connectivity by buying from a >> reseller of transit? In other words, buying transit from >> a network which also buys transit. Presumably up near the >> top of the chain (Tier 1 vicinity), that transit reseller >> has a lot of peering in place with other folks in the same >> neighborhood (Tier 1 vicinity). But as long as a network >> is a transit reseller (i.e. they buy transit), then they >> are less likely to suffer from partition events caused >> by fractious peering negotiations. >> >> --Michael Dillon > > Can anyone explain to me why end users find it so important to label > carriers as "Tier 1" or "Tier 2"? In my experience, end users generally don't know and almost never care. It's the sales people who talk about tiers. Regards Marshall > The prevailing theory in the heads of prospective customers is that > a "Tier 1" is somehow inherently better than a "Tier 2" (or lower), > even though they don't quite understand the concepts behind why the > "Tier" designation even exist(s/ed). These labels, at least to me, > are no longer very relevant in today's internet world. In fact, > would anyone agree that being a "Tier 1", as Cogent believes > themselves to be, leaves that network in a very painful position > when things like their frequent peering disputes happen? > > For an NSP, it's obviously a "good thing" to be SFI-only, as in > theory, it _should_ lower your costs. YMMV, as mentioned in a > previous thread. However, what does it really matter to an end- > user, especially if they are biased towards using "Tier 1" networks > only? Why does a network who purchases transit give the impression > to end users that that network's internet genitalia is somehow > smaller than, say, Verizon or AT&T? I can see merit in touting the > size and coverage of the actual network, but it's always been my > understanding that this is not the true definition of the tiered > system. > > -evt > From patrick at ianai.net Mon Nov 3 09:11:03 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Nov 2008 10:11:03 -0500 Subject: Sprint / Cogent dispute over? In-Reply-To: <200811031501.mA3F1omo031556@parsley.amaranth.net> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <200811031501.mA3F1omo031556@parsley.amaranth.net> Message-ID: <C356D9D1-26A3-48B3-9761-A2019A5C7D8D@ianai.net> On Nov 3, 2008, at 10:01 AM, Daniel Senie wrote: > At 06:54 PM 11/2/2008, Daniel Roesen wrote: >> On Sun, Nov 02, 2008 at 04:40:20PM -0500, Randy Epstein wrote: >> > Problem resolved? >> >> https://www.sprint.net/cogent.php > > Reading this accounting of Sprint's side of the story reveals > something that's not too surprising about Sprint. They've got > serious accounting problems. > > The trial of peering they talk about was for three months in 2007, > ending in September 2007. They claim to have billed Cogent at the > end of it, though knowing Sprint's billing (having had them fail to > send me bills, then hit me with late fees) they probably can't prove > that. But this is a YEAR later. > > They let an account linger for a year without collecting or > terminating the services provided. That's their own damned fault. > This indicates poor management of Accounts Receivable. That's your > problem, Sprint, deal with it. > > Also in this document is a complaint that Cogent failed to > disconnect. Excuse me? This was a trial PEERING agreement. That > implies one or a series of point-to-point connections. That implies > EITHER party can disconnect the circuits (in reality, the physical > circuit doesn't even matter, just shut down the BGP session(s)). > > So Sprint failed to manage Accounts Receivable and left this > "temporary" circuit in place too long. Some bean counter noticed > this a year later. Way to go Sprint. > > As I've noted previously, Sprint hurt its own customers by the > action taken. It's my guess they restored the circuit to avoid > further damage to themselves that resulted from their actions. You have an interesting set of assumptions. Is there any reason you did not give Sprint the benefit of the doubt? For instance, is it not possible that Sprint knew this and was trying "for a year" to fix the problem without taking such drastic steps? Because they did not want to hurt their own customers? > It's interesting to see a biased, "blame Cogent first" mentality in > so many postings on NANOG. Maybe they deserve it, maybe not. But > after reading the traffic here, after living through the > consequences of the Cogent/L3 depeering, and after reading what > Sprint said on their page, my read on this is that Sprint's > accounting department might need some house cleaning. And I thought just the opposite. Having a clear contract with clear terms, giving Cogent plenty of notice, taking the links down slowly over time to ensure Cogent knew what was happening, etc., etc. That was very up-front, above-board, and more than polite on Sprint's part, IMHO. Compare Sprint's actions & attitude to Cogent's sub-12-hour notice when they de-peered Telia. Yeah, Cogent is definitely the more professional company.... -- TTFN, patrick From juicewvu at gmail.com Mon Nov 3 09:15:45 2008 From: juicewvu at gmail.com (Josh Smith) Date: Mon, 3 Nov 2008 10:15:45 -0500 Subject: cold.net contact Message-ID: <d3bf5a870811030715w28511f27ldcbc4c4cb52085c4@mail.gmail.com> Could someone who has insight into DNS for it.colt.net please contact me off list. I am having sporadic difficulty resolving a domain you are providing DNS for. Thanks -- Josh Smith KD8HRX email/jabber: juicewvu at gmail.com phone: 304.237.9369(c) () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From bicknell at ufp.org Mon Nov 3 09:19:05 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 3 Nov 2008 10:19:05 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> Message-ID: <20081103151905.GA90976@ussenterprise.ufp.org> In a message written on Mon, Nov 03, 2008 at 01:26:14AM -0500, Patrick W. Gilmore wrote: > Having skimmed the Sprint / Cogent threads, I saw multiple errors and > lots of really bad guesses. Instead of replying individually, I > thought I would sum up a few facts so everyone was on the same page. > This way when we run off into another 100 post thread, we can at least > -start- from reality (although I would bet serious cash on long odds > we will diverge from it soon enough). I notice a significant bit of information which has not been posted in any of the posts I have read. If I were to rank networks by the difficulty of getting settlement free peering I believe Sprint would be at the top of the list. The traffic volume they demand is pretty much higher than anyone else, the ratio they demand is tighter than anyone else, and they demand you meet them at Sprint POP's. Not friendly carrier neutral colos, they are stuck in the Telco world of we run half the circuits to you and run half the circuits to us. Never mind that only a few carriers are even in a Sprint POP to deliver a circuit. I don't necessarily fault Sprint for setting their requirements as such; if I were them I may well do the same. Basically they have decided they have enough peers and attempt to keep their requirements high enough such that they need not ever add more. However, looking at the issue from an external view, since I work for neither Cogent nor Sprint, I do believe there are two fundamental "fairness" questions: 1) Do all of Sprint's current peers meet Sprint's peering policy? 2) Due to the size and customer base of Sprint's network is it possible for anyone to meet their peering policy? While these are rarely tested by anyone who could enforce them (save the odd merger of mega players) they really are the interesting questions. Several of the "good old boys" in the settlement free club have fallen from where they once were, yet they don't get depeered. If you have peers that no longer meet your current peering policy and don't get depeered, how is that fair? Of course, the way the industry is structured those arrangements are completely hidden, so we'll never know if everyone meets the criteria or no one does. The second is also very interesting. Most networks came up with their criteria (say, 2:1 ratio) 10, 15, or even 20 years ago. The network was a very different place at that time, when a T1 was a large circuit and interconnects were DS-3's. In particular, most access was symmetrical; T1's, DS-3's, maybe ethernet (the 10M kind) in a colo; and what's more, everyone was selling the same products. There was no DSL, no cable modems, no EV-DO cards. There have been two interesting developments in the industry since that time, and the traditional criteria don't serve them well. Asymmetrical access and specialization. Take a pure end user play network, like most of the cable modem networks, and peer them with any content player and the ratio is never going to be 1.5:1 or 2:1, but they both get benefit from the arrangement. Many of the new networks have realized this and adjusted their criteria, many of the old players, like Sprint, may have morphed into one of these new buckets, but not realized it yet. This is an area where I believe our industry needs to grow up. We like to operate on the assumption that if we have to jump over a particular bar to peer with someone that policy has been applied fairly across all players and is reasonable. However, there is no way for anyone to verify that; short of the DoJ stepping in during a merger. I am fairly sure that the requirements are not enforced evenly by some players (no comment on Sprint or Cogent in this case); that they use the fact that actual traffic volumes and ratios are hidden to play poker with other networks. While I'm generally pro business and think this is a good thing; I believe it has reached a point in our industry where it is damaging the Internet. The increase in peering spats to me is an indication that the players are not looking out for stability, performance, and insuring their customers are getting the access that they pay for, but rather that they are interested in playing poker with each other. I don't even think it's about the money, but rather about the power. The interesting thing is that there is a disruptive force on the horizon. The IPv6 transition will change the peering landscape. Traffic volumes and ratios will be moving to new providers as people transition technologies. This is going to lead to quite a shake up on the peering front I'm afraid, and I fear the result is going to be great instability. The lack of transparency means that those in power will try and bluff their way forward; the question is how many people who have some visibility will call that bluff. In all, this situation just reminds me of what I already knew. When there is a depeering both networks are at fault. The fact that these two players couldn't come to some commercially acceptable terms to both of them speaks volumes about both. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081103/d5d32210/attachment.bin> From stephen at sprunk.org Mon Nov 3 09:24:27 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 03 Nov 2008 09:24:27 -0600 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> Message-ID: <490F17AB.4080109@sprunk.org> David Schwartz wrote: > Your customers pay you to carry their traffic across your network between them and the next network in the line. There is no reason anyone else should compensate you for doing this. > What it all comes down to is that the majority of eyeballs are on "residential" connections that are relatively expensive to provide but for which are sold at a relatively low price (often 1/10th as much per megabit of capacity). Those eyeball ISPs cannot or will not charge their customers the full cost of "receiving" traffic so they want money from the more profitable content ISPs "sending" the traffic to offset their losses. This is also one of the reasons eyeball ISPs want to stamp out P2P: both ends of the connections are on unprofitable lines and there is _nobody_ paying for the traffic. Just follow the money. S From will at harg.net Mon Nov 3 09:27:39 2008 From: will at harg.net (Will Hargrave) Date: Mon, 03 Nov 2008 15:27:39 +0000 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> Message-ID: <490F186B.5080709@harg.net> David Schwartz wrote: > The ratio argument is nonsense. If your customers want to receive mostly, > and receiving is expensive, they should pay you more to cover your higher > costs in receiving traffic. If my customers mostly want to send, and sending > is cheap, then I should pay less, since I want to do the cheap thing and you > want to do the expensive thing. If it costs one party to an SFI agreement more than the other (total cost, including intangibles) this makes the agreement less attractive, perhaps to the point of inequitability. Where one party profits more from the agreement than another, there is less incentive for the interconnection to be settlement-free. There is no father figure standing there saying 'Party A and Party B must SFI regardless of cost' - that decision is up to the relevant commercial minds within Party A and Party B to carry out the required analysis and negotiate as required. Will From patrick at ianai.net Mon Nov 3 09:40:46 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Nov 2008 10:40:46 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> Message-ID: <8FA88C27-C0DB-4366-80E9-668484E09ABC@ianai.net> On Nov 3, 2008, at 10:03 AM, David Schwartz wrote: > Patrick W. Gilmore wrote: > >> 4. There is a reason behind ratios which has nothing to do with telco >> "sender-pays" > > There is an alleged reason. Peering rations were first 'big news' when BBN wanted to de-peer Above.Net, Global Center, and Exodus in 1998. I spent a long time chatting with BBN's CTO about why BBN wanted to do this. I am convinced the facts are correct. Perhaps more importantly, anyone who understands how BGP, fiber, routers, etc. work can figure this out for themselves without even talking to another network. Put another way, this is not a fantasy, supposition, bluster, etc. What do you have to convince people otherwise? >> Hot potato routing + very poor ratios puts much more of the cost on >> the receiving network. This is a valid, logical, and costly concern >> for receiving networks. > > So what? So the argument is: > > 1) Your customers want to receive from my customers. > > 2) Receiving is more expensive. > > 3) Therefore you should pay me? I don't remember saying that at all. Perhaps you should re-read my post. > I want to send, and sending is cheap. Your customers want to do the > expensive receiving, not mine. My customers want to do the cheap > sending. > > The ratio argument is nonsense. If your customers want to receive > mostly, > and receiving is expensive, they should pay you more to cover your > higher > costs in receiving traffic. If my customers mostly want to send, and > sending > is cheap, then I should pay less, since I want to do the cheap thing > and you > want to do the expensive thing. The ratio argument is not nonsense. And fortunately, what you spout on NANOG has no effect on reality. > Your customers pay you to carry their traffic across your network > between > them and the next network in the line. There is no reason anyone > else should > compensate you for doing this. <eyeball-network advocate> Your customers pay you to deliver their traffic to my eyeballs. There is no reason I should compensate you for doing so. </advocate> The FACT is that a point-source sending traffic to distributed receivers combined with hot-potato routing puts more of the cost on the receiver. That fact is not in dispute, apparently even you agree. From that fact, you can argue whether that is grounds for de-peering, settlements, etc. But the fact stands. Also, please note no one is forcing you to pay anyone. Cogent decided not to pay. There is no law forcing them, Sprint is not holding a gun to Dave's head. But just like no one is forcing the sender to pay, no one is forcing the receiver to pay either. Personally I think business problems have a business solution. For the ratio problems in 1998, Above.Net (and others, probably), agreed to carry the traffic and deliver it closer to BBN's eyeballs, thereby shifting the majority of the cost to AN. Dave (Rand this time, not Schaeffer) actually preferred it that way, saying he trusted his network more than BBN's and AN's customers pay him for quality. Hrmm, sounds like just the opposite of how you treat your customer's traffic.... -- TTFN, patrick From tore at linpro.no Mon Nov 3 09:41:11 2008 From: tore at linpro.no (Tore Anderson) Date: Mon, 3 Nov 2008 16:41:11 +0100 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <490F17AB.4080109@sprunk.org> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> <490F17AB.4080109@sprunk.org> Message-ID: <200811031641.11127.tore@linpro.no> * Stephen Sprunk > What it all comes down to is that the majority of eyeballs are on > "residential" connections that are relatively expensive to provide > but for which are sold at a relatively low price (often 1/10th as > much per megabit of capacity). Those eyeball ISPs cannot or will not > charge their customers the full cost of "receiving" traffic so they > want money from the more profitable content ISPs "sending" the > traffic to offset their losses. Another point worth mentioning is that the traffic is going to flow between those two ISPs _anyway_. Therefore, in many cases the only ones to profit from them not reaching a peering agreement (settlement-free or not) is their upstream(s), who is probably delighted to be able to charge them both for the transit traffic. Regards, -- Tore Anderson From tore at linpro.no Mon Nov 3 09:41:11 2008 From: tore at linpro.no (Tore Anderson) Date: Mon, 3 Nov 2008 16:41:11 +0100 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <490F17AB.4080109@sprunk.org> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> <490F17AB.4080109@sprunk.org> Message-ID: <200811031641.11127.tore@linpro.no> * Stephen Sprunk > What it all comes down to is that the majority of eyeballs are on > "residential" connections that are relatively expensive to provide > but for which are sold at a relatively low price (often 1/10th as > much per megabit of capacity). Those eyeball ISPs cannot or will not > charge their customers the full cost of "receiving" traffic so they > want money from the more profitable content ISPs "sending" the > traffic to offset their losses. Another point worth mentioning is that the traffic is going to flow between those two ISPs _anyway_. Therefore, in many cases the only ones to profit from them not reaching a peering agreement (settlement-free or not) is their upstream(s), who is probably delighted to be able to charge them both for the transit traffic. Regards, -- Tore Anderson From patrick at ianai.net Mon Nov 3 09:49:06 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Nov 2008 10:49:06 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <200811031641.11127.tore@linpro.no> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> <490F17AB.4080109@sprunk.org> <200811031641.11127.tore@linpro.no> Message-ID: <FD11BDD0-0DD6-4C7E-B850-8C5066F36403@ianai.net> On Nov 3, 2008, at 10:41 AM, Tore Anderson wrote: > Another point worth mentioning is that the traffic is going to flow > between those two ISPs _anyway_. I believe the events of 2-3 days ago disproves your assertion. > Therefore, in many cases the only > ones to profit from them not reaching a peering agreement > (settlement-free or not) is their upstream(s), who is probably > delighted to be able to charge them both for the transit traffic. Again, supposed facts not in evidence. I mentioned in the thread earlier that it is entirely possible Eyeball Network saves money by turning down peering and paying a transit provider to deliver the packets where Eyeball Network wants. Fiber, routers, IX ports, engineers, etc. are all expensive. Transit these days is not. Doesn't mean Eyeball Network actually does save money. Just means you don't know either way. -- TTFN, patrick From bicknell at ufp.org Mon Nov 3 09:49:32 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 3 Nov 2008 10:49:32 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <8FA88C27-C0DB-4366-80E9-668484E09ABC@ianai.net> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> <8FA88C27-C0DB-4366-80E9-668484E09ABC@ianai.net> Message-ID: <20081103154932.GA95305@ussenterprise.ufp.org> In a message written on Mon, Nov 03, 2008 at 10:40:46AM -0500, Patrick W. Gilmore wrote: > The FACT is that a point-source sending traffic to distributed > receivers combined with hot-potato routing puts more of the cost on > the receiver. That fact is not in dispute, apparently even you agree. s/more of the cost/more of the network transport cost/. Having been at AboveNet when several providers tried to tell us it was unfair that we had data centers near exchanges and it cost them a lot of money to put in access to the end user I simply pointed them to our stock reports where we were spending hundreds of millions of dollars building data centers, and our customers were further buying hundreds of millions of dollars of servers to serve up the content. You are correct that hot potato routing makes more of the bits flow on the "eyeball" network. This of course can be mitigated by using alternate routing strategies; for instance AboveNet actively encouraged other providers to send us Meds and in some cases deaggregate to us such that we could carry the bits on our network. However I am skeptical when looking at the total system cost that the costs are as disproportionate as you suggest. It's great to build an eyeball network, but unless someone invests in data centers and servers it's not going to get to any content. The view that network transport cost is the only interesting figure is a historical artifact of the days of $5000/megabit transit. There was a time it was more expensive to carry bits across the country than to build a data center; if anything I think it's now the exact opposite. The data center providers are actually taking more of the costs than many end user ISP's are due to the falling price of transport and the relatively static price of real estate, generators, air conditioners, and the like. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081103/106d5660/attachment.bin> From jgreco at ns.sol.net Mon Nov 3 10:28:48 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 3 Nov 2008 10:28:48 -0600 (CST) Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <8FA88C27-C0DB-4366-80E9-668484E09ABC@ianai.net> from "Patrick W. Gilmore" at Nov 03, 2008 10:40:46 AM Message-ID: <200811031628.mA3GSmCp073041@aurora.sol.net> > The FACT is that a point-source sending traffic to distributed > receivers combined with hot-potato routing puts more of the cost on > the receiver. That fact is not in dispute, apparently even you agree. Mmm, that's really not a fact. I like the way you painted it though. When you're looking at fundamental cost, let's not get confused by labelling it as "distributed" receivers. There are several elements to the cost of getting data from point A to B. Consider some examples. Let's pretend: You are a "point-source" sender on the east coast. I am a "point-destination" receiver in the midwest. The receiving network can build out its own national network, so that a node is near you, and you (or someone that transits your packets to it) peer with it. In such a case, yes, hot-potato routing dumps most of the cost on the receiving network, which is the sort of case that commonly exists these days. However, there is no reason that receivers need to build national networks. A small receiver (think: regional ISP) could certainly bring a line down to Chicago, get relatively inexpensive transit bandwidth, and leave the sending site with the task of purchasing transit from someone who had a national network in order to get packets to the receiving network. Now, there are a variety of problems here. One problem is that there is inherently a much higher cost-per-bit to actually deliver bits on a residential broadband network than there is where bits are delivered in a data center. Despite this, residential broadband network feel a downward pressure on price. No successful residential broadband network actually has a network capable of delivering large numbers of bits to all its customers simultaneously, and reliance on incredible overcommit is very common. But there's another factor. Many ISP's "feel" that it is cheaper to internalize network costs; a regional network might still get a connection to the east and west coasts, and peer on each coast, on the theory that doing this was "cheaper" than paying transit. In doing so, however, they internalize that cost for what-used-to-be- transit, and remember that transit used to be paid for at both ends, by the sender and the receiver. Now it's all being paid for by the receiver, at least in this example. Therefore, I will take issue with the statement "puts more of the cost on the receiver." I will certainly agree that the receiver has underwritten more of the cost, but as a deliberate choice. This is, of course, only a very small component of a much more complex picture, but it can be used to help people understand why things such as paid peering exist. In the case of Cogent, I have seen numerous examples of situations where data entered the Cogent network and left it within the same building; one has to assume that this is very inexpensive for Cogent, of course based on the fact that their peering with other networks is settlement-free. At least in major POP's such as Ashburn, this is actually more the norm than not, last I was able to see live data from a customer to Cogent. $10/meg from a paying customer, spit out onto other networks settlement-free, Cogent's costs are rather minimal there. > From that fact, you can argue whether that is grounds for de-peering, > settlements, etc. But the fact stands. No, it doesn't. It's not even a fact. It's just the way things often work right now, because most have chosen to work it that way. > Personally I think business problems have a business solution. For > the ratio problems in 1998, Above.Net (and others, probably), agreed > to carry the traffic and deliver it closer to BBN's eyeballs, thereby > shifting the majority of the cost to AN. Dave (Rand this time, not > Schaeffer) actually preferred it that way, saying he trusted his > network more than BBN's and AN's customers pay him for quality. That would seem a reasonable solution. Cold-potato routing is relatively difficult to do well on a large scale, but perhaps a focus on this could reduce the "political" problem. Cogent has been depressing the price of bandwidth for years, largely because of their hot-potato routing strategy. Perhaps this isn't Cogent's fault so much as it is a failure to engineer equitable cost-management strategies that would discourage companies like Cogent from selling for $4/meg. Please note that I'm mainly trying to paint a more accurate and comprehensible picture for the audience here, Patrick. I expect that none of this is news to /you/. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From blyon at blyon.com Mon Nov 3 10:49:07 2008 From: blyon at blyon.com (Barrett Lyon) Date: Mon, 3 Nov 2008 08:49:07 -0800 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <20081103154932.GA95305@ussenterprise.ufp.org> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> <8FA88C27-C0DB-4366-80E9-668484E09ABC@ianai.net> <20081103154932.GA95305@ussenterprise.ufp.org> Message-ID: <BF5800DD-4D46-45FB-88FD-4DE2310712EE@blyon.com> Incase this has not hit the list yet: http://www.pcworld.com/businesscenter/article/153194/sprint_reconnects_cogent_but_differences_are_unresolved.html Sprint Reconnects Cogent, but Differences Are Unresolved Mikael Rickn?s, IDG News Service Monday, November 03, 2008 7:50 AM PST On Sunday Sprint Nextel reconnected its network with Cogent Communications after severing it earlier last week. The reconnection is only temporary, as the core issues in this dispute have not changed, Sprint said in a statement to its customers. As a result, it is again possible for Sprint customers and Cogent customers to directly communicate across the Internet. Data supplied by Keynote Systems confirms that the two networks are again communicating with each other. Sprint's view of what led up to its disconnecting from Cogent Communications on Oct. 30 differs substantially from what Cogent has stated. In shutting down the peering between the two, Sprint violated a contractual obligation to exchange Internet traffic with Cogent on a settlement-free peering basis, according to Cogent. But that's just fiction, according to Sprint, because at no time did the two enter into an actual contract. In 2006, Sprint and Cogent formed a trial agreement that ended in September last year. A three-month commercial trial indicated that Cogent didn't meet the minimum traffic exchange criteria agreed to by both parties, according to Sprint. As a result, settlement-free peering was not established, Sprint said. Instead, Sprint wants Cogent to pay for its ongoing connection to the Sprint network. But despite repeated collection attempts by Sprint, Cogent has not done that. Nonpayment on Cogent's part is the reason Sprint decided to disconnect from Cogent last week, a process that had started on Oct. 7, and shouldn't have come as a surprise for Cogent, Sprint said in its customer statement. What happens next remains to be seen. The two operators are involved in litigation over the matter. Sprint filed a lawsuit against Cogent on Sept. 2 in Fairfax County Circuit Court in Virginia for breach of contract. On its part, Cogent said it wants settlement-free peering with Sprint. From vixie at isc.org Mon Nov 3 10:49:18 2008 From: vixie at isc.org (Paul Vixie) Date: Mon, 03 Nov 2008 16:49:18 +0000 Subject: Sprint / Cogent dispute over? In-Reply-To: <200811031501.mA3F1omo031556@parsley.amaranth.net> (Daniel Senie's message of "Mon\, 03 Nov 2008 10\:01\:48 -0500") References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <200811031501.mA3F1omo031556@parsley.amaranth.net> Message-ID: <g3hc6opxf5.fsf@nsa.vix.com> Daniel Senie <dts at senie.com> writes: > At 06:54 PM 11/2/2008, Daniel Roesen wrote: >> https://www.sprint.net/cogent.php > > ... > > Also in this document is a complaint that Cogent failed to disconnect. > Excuse me? This was a trial PEERING agreement. That implies one or a > series of point-to-point connections. That implies EITHER party can > disconnect the circuits (in reality, the physical circuit doesn't even > matter, just shut down the BGP session(s)). > > ... Not having read the contract in question, my assumption when I read Sprint's account of their depeering of Cogent was that the trial peering contract says "Sprint will notify Cogent of its qualification status after 90 days; if in Sprint's estimation Cogent does not qualify, and Sprint notifies Cogent of that fact, then Cogent will either disconnect or start paying." Sprint's document's wording is careful even if their <TITLE> is not. If they are involved in litigation with Cogent then actual lawyers would have seen that text (if not necessarily the <TITLE>) before it went out. The heart of the lawsuit might be whether Cogent did or didn't implicitly agree to pay, as signalled by their lack of disconnection after their 90 day notice. None of us who aren't parties to the dispute can do other than wonder, ponder, guess. -- Paul Vixie From Martin.Hannigan at verneglobal.com Mon Nov 3 11:10:38 2008 From: Martin.Hannigan at verneglobal.com (Martin Hannigan) Date: Mon, 3 Nov 2008 17:10:38 -0000 Subject: Sprint / Cogent dispute over? In-Reply-To: <g3hc6opxf5.fsf@nsa.vix.com> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com><409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F><20081102235422.GA15591@srv03.cluenet.de><200811031501.mA3F1omo031556@parsley.amaranth.net> <g3hc6opxf5.fsf@nsa.vix.com> Message-ID: <BF08482709F8B24484F80A48DE20BEF38E1C1A@agusto.kerfisleiga.is> > -----Original Message----- > From: Paul Vixie [mailto:vixie at isc.org] > Sent: Monday, November 03, 2008 11:49 AM > To: Daniel Senie > Cc: nanog at merit.edu > Subject: Re: Sprint / Cogent dispute over? > > Sprint's > document's wording is careful even if their <TITLE> is not. FWIW, that's the <TITLE> on every page on the website. Best, -M< -- Martin Hannigan http://www.verneglobal.com/ Senior Director e: hannigan at verneglobal.com Verne Global Datacenters c: +16178216079 Keflavik, Iceland f: +16172347098 From tore at linpro.no Mon Nov 3 11:19:12 2008 From: tore at linpro.no (Tore Anderson) Date: Mon, 3 Nov 2008 18:19:12 +0100 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <FD11BDD0-0DD6-4C7E-B850-8C5066F36403@ianai.net> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> <200811031641.11127.tore@linpro.no> <FD11BDD0-0DD6-4C7E-B850-8C5066F36403@ianai.net> Message-ID: <200811031819.13182.tore@linpro.no> * Patrick W. Gilmore > On Nov 3, 2008, at 10:41 AM, Tore Anderson wrote: > > Another point worth mentioning is that the traffic is going to flow > > between those two ISPs _anyway_. > > I believe the events of 2-3 days ago disproves your assertion. Having partitioned transit-free networks is going to continue to be the exception and not the rule, or at least I hope so... > > Therefore, in many cases the only > > ones to profit from them not reaching a peering agreement > > (settlement-free or not) is their upstream(s), who is probably > > delighted to be able to charge them both for the transit traffic. > > Again, supposed facts not in evidence. It does happen. I've experienced it myself. > I mentioned in the thread earlier that it is entirely possible > Eyeball Network saves money by turning down peering and paying a > transit provider to deliver the packets where Eyeball Network wants. But I never said that this could never be the case either, in fact I think you're right; it is indeed entirely possible that this in many cases is the reason for one network to turn down the other's peering request. If only one of the networks is geographically large or the proposed peering agreement does not have provisions about multiple peering locations (and respecting MED), it's probably even more likely to be the case. However, it is also entirely possible that the networks simply are too stubborn to either accept paid peering, to loosen up on any requirements of balanced ingress/egress ratio, or to commit to cold potato routing, or whatever. I suspect that the likelyhood of this beeing the case is dependant on the size of the networks involved, though. Regards, -- Tore Anderson From sethm at rollernet.us Mon Nov 3 11:20:22 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 03 Nov 2008 09:20:22 -0800 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <BF5800DD-4D46-45FB-88FD-4DE2310712EE@blyon.com> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> <8FA88C27-C0DB-4366-80E9-668484E09ABC@ianai.net> <20081103154932.GA95305@ussenterprise.ufp.org> <BF5800DD-4D46-45FB-88FD-4DE2310712EE@blyon.com> Message-ID: <490F32D6.1020103@rollernet.us> Barrett Lyon wrote: > Incase this has not hit the list yet: > > http://www.pcworld.com/businesscenter/article/153194/sprint_reconnects_cogent_but_differences_are_unresolved.html > > > > > Sprint Reconnects Cogent, but Differences Are Unresolved > Mikael Rickn?s, IDG News Service > > Monday, November 03, 2008 7:50 AM PST > On Sunday Sprint Nextel reconnected its network with Cogent > Communications after severing it earlier last week. The reconnection is > only temporary, as the core issues in this dispute have not changed, > Sprint said in a statement to its customers. > > As a result, it is again possible for Sprint customers and Cogent > customers to directly communicate across the Internet. Data supplied by > Keynote Systems confirms that the two networks are again communicating > with each other. > > Sprint's view of what led up to its disconnecting from Cogent > Communications on Oct. 30 differs substantially from what Cogent has > stated. > > In shutting down the peering between the two, Sprint violated a > contractual obligation to exchange Internet traffic with Cogent on a > settlement-free peering basis, according to Cogent. But that's just > fiction, according to Sprint, because at no time did the two enter into > an actual contract. > > In 2006, Sprint and Cogent formed a trial agreement that ended in > September last year. A three-month commercial trial indicated that > Cogent didn't meet the minimum traffic exchange criteria agreed to by > both parties, according to Sprint. As a result, settlement-free peering > was not established, Sprint said. > > Instead, Sprint wants Cogent to pay for its ongoing connection to the > Sprint network. But despite repeated collection attempts by Sprint, > Cogent has not done that. Nonpayment on Cogent's part is the reason > Sprint decided to disconnect from Cogent last week, a process that had > started on Oct. 7, and shouldn't have come as a surprise for Cogent, > Sprint said in its customer statement. > > What happens next remains to be seen. The two operators are involved in > litigation over the matter. Sprint filed a lawsuit against Cogent on > Sept. 2 in Fairfax County Circuit Court in Virginia for breach of contract. > > On its part, Cogent said it wants settlement-free peering with Sprint. > So basically, it won't be resolved until Cogent gets to keep free access to Sprint. Where's my free access to Sprint? Can I cry and scream that I have to pay for my access too because I don't qualify for free peering? ~Seth From andy at nosignal.org Mon Nov 3 11:52:03 2008 From: andy at nosignal.org (Andy Davidson) Date: Mon, 3 Nov 2008 17:52:03 +0000 Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B47999@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net><21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F864@pascal.zaphodb.org> <89D27DE3375BB6428DDCC2927489826A01B47999@nexus.nexicomgroup.net> Message-ID: <610187A3-D08F-4AFE-933C-A795A036989B@nosignal.org> On 31 Oct 2008, at 16:56, Paul Stewart wrote: > Why does the controversy word keep coming up? You're the third > personnow to ask if I was trying to provide controversy and for the > third time, NO I AM NOT. Hi, I have no intention of fanning the fire, but I can explain the controversy message pretty well. Bringing a whole new methodology to how an organisation interconnects is hugely controversial for most organisations who are not already peering. In my role as a consulting engineer in this field, I most recall introducing peering to two 'enterprise' organisations. Both joined exchanges in Europe at a time when their network edge was redesigned to support 'better practice' IT. Both were e-commerce organisations who traded directly with the general public, and ran open peering policies soliciting sessions with eyeball networks. At the end of my involvement with both, each organisation was peering off a third or so of their traffic. One is still peering and probably peers off more traffic. The other withdrew from peering operations after around six months. Wearing another hat as an IX operator, I can confirm that IXPs do not want organisations to join and leave, since most of the IXP costs are front- stacked and relate to setup. So what went wrong ? The organisation which is still peering has a more rich technical culture, willing to accept the so-called intangible benefits of peering. The second asked "are we a sales and marketing firm designed to shift widgets, or are we a fancy technical firm with a big network ?" The culture of many firms is to keep-it-simple-stupid, and if your proposal for peering reached C*O levels, then it would be met with significant controversy if you are not already peering. Especially when the C*O responsible for legal hears about peering contracts... Furthermore, to get and retain the peers you need, you need to make relationships with other peering co-ordinators. Attending the peering conferences is hard work and all of your colleagues will think you're on a jolly ! If you can't get sponsorship for your idea outside the technology department, then the idea is probably dead. Are there some PNIs you can run in the local area which will have a significant impact on your resiliency and traffic profile ? Good luck. I am happy to talk to you in more detail about this subject if you would like more advice, drop me a line off-list. Best wishes Andy Davidson. From andy at nosignal.org Mon Nov 3 11:57:03 2008 From: andy at nosignal.org (Andy Davidson) Date: Mon, 3 Nov 2008 17:57:03 +0000 Subject: Peering - Benefits? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01B47999@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01B4746B@nexus.nexicomgroup.net><21ef2c1c0810301919k6e25de93n5af493f83a07be73@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F864@pascal.zaphodb.org> <89D27DE3375BB6428DDCC2927489826A01B47999@nexus.nexicomgroup.net> Message-ID: <526EDAF5-2B04-4782-B8F4-E92738C12F9D@nosignal.org> On 31 Oct 2008, at 16:56, Paul Stewart wrote: > Why does the controversy word keep coming up? You're the third > personnow to ask if I was trying to provide controversy and for the > third time, NO I AM NOT. Hi, I have no intention of fanning the fire, but I can explain the controversy message pretty well. Bringing a whole new methodology to how an organisation interconnects is hugely controversial for most organisations who are not already peering. In my role as a consulting engineer in this field, I most recall introducing peering to two 'enterprise' organisations. Both joined exchanges in Europe at a time when their network edge was redesigned to support 'better practice' IT. Both were e-commerce organisations who traded directly with the general public, and ran open peering policies soliciting sessions with eyeball networks. At the end of my involvement with both, each organisation was peering off a third or so of their traffic. One is still peering and probably peers off more traffic. The other withdrew from peering operations after around six months. Wearing another hat as an IX operator, I can confirm that IXPs do not want organisations to join and leave, since most of the IXP costs are front- stacked and relate to setup. So what went wrong ? The organisation which is still peering has a more rich technical culture, willing to accept the so-called intangible benefits of peering. The second asked "are we a sales and marketing firm designed to shift widgets, or are we a fancy technical firm with a big network ?" The culture of many firms is to keep-it-simple-stupid, and if your proposal for peering reached C*O levels, then it would be met with significant controversy if you are not already peering. Especially when the C*O responsible for legal hears about peering contracts... Furthermore, to get and retain the peers you need, you need to make relationships with other peering co-ordinators. Attending the peering conferences is hard work and all of your colleagues will think you're on a jolly ! If you can't get sponsorship for your idea outside the technology department, then the idea is probably dead. Are there some PNIs you can run in the local area which will have a significant impact on your resiliency and traffic profile ? Good luck. I am happy to talk to you in more detail about this subject if you would like more advice, drop me a line off-list. Best wishes Andy Davidson. From nantoniello at antel.net.uy Mon Nov 3 12:34:16 2008 From: nantoniello at antel.net.uy (Nicolas Antoniello) Date: Mon, 03 Nov 2008 16:34:16 -0200 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <8A979F72-95E6-4A74-8012-AF98292DCBE6@ianai.net> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> <620fd17c0811022335l27f64ae2r42f68b161145d7ac@mail.gmail.com> <8A979F72-95E6-4A74-8012-AF98292DCBE6@ianai.net> Message-ID: <490F4428.2010503@antel.net.uy> Sorry for my possible ignorance, but could you explain me what are you calling "transit-free"? I mean, the ISP I work for, has contract for several STM-4 links with Sprint (at least for 8 years now), and for sure they do have transit, at least for us (as we publish our customers ASs to them and they publish them to other carriers). ?is that what you call transit? Thanks in advance, Nicolas. Patrick W. Gilmore wrote: > On Nov 3, 2008, at 2:35 AM, Paul Wall wrote: >> On Mon, Nov 3, 2008 at 1:26 AM, Patrick W. Gilmore <patrick at ianai.net> >> wrote: >>> 1. Neither Sprint nor Cogent have transit >>> Both Sprint & Cogent are transit-free networks. (Notice how I carefully >>> avoided saying "tier one"?) >> >> How do you explain Cogent's arrangement with NTT (AS 2914)? If it's >> not transit, what is it? > > I do not know, and neither do you. But I do know it is not "transit", > at least not to Sprint. > > It is trivial to prove to yourself if Cogent has transit. Find me any > AS path in the global table showing "_TF1_TF2_174_", there "TF1" and > "TF2" are the ASNs of two of the other 13 transit free networks. > (Modulo a few leaked prefixes, which always seem to crop up. For > instance, if a network has 40K prefixes in its cone, showing O(10) paths > is not proof.) > > This is a positive test - if you see it, you know they have transit, if > you do not see it, you do not know they do not have transit. But > combined with bifurcation when Sprint drops peering to Cogent, one can > _know_ Cogent does not have full transit, or partial transit to Sprint. > It is possible (although I personally believe unlikely) Cogent has > partial transit to some other transit free network that you cannot see > right now because their peering to that network is up and overriding the > AS paths in the global table. But that doesn't matter to this discussion. > > >> Does Akamai have peering arrangements with Cogent directly? > > That is none of your business, not to mention completely irrelevant to > the topic at hand as Akamai is neither a network nor transit free. > From fw at deneb.enyo.de Mon Nov 3 13:01:05 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 03 Nov 2008 20:01:05 +0100 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <60673.1225705866@turing-police.cc.vt.edu> (Valdis Kletnieks's message of "Mon, 03 Nov 2008 04:51:06 -0500") References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> <87k5blkvmk.fsf@mid.deneb.enyo.de> <60673.1225705866@turing-police.cc.vt.edu> Message-ID: <87abcgvdla.fsf@mid.deneb.enyo.de> * Valdis Kletnieks: > On Mon, 03 Nov 2008 10:26:59 +0100, Florian Weimer said: >> * Patrick W. Gilmore: > >> > 3. Standard transit contracts do not guarantee full connectivity >> >> If this were true, why would end users (or, more generally, not >> significantly multi-homed networks) buy transit from such networks? > > Quite frankly, if any potential transit provider tried to make > noises about being able to *guarantee* full connectivity, I'd show > him the door. Obviously, nothing won't stop them from disconnecting customers which are not sufficiently multi-homed, which might adversely affect me, independently of the size of the disconnected network or the nature of the dispute. That being said, there's a difference between disconnecting a customer and making sure, through action or inaction, that their network is no longer reachable from yours. I'd need to litigate to be sure, but I think the latter actually violates contracts we have at work. > Consider the average length of an AS path. Well, in this context, the affected AS paths are really, really short. 8-) > Now consider that your AS is at one end, your transit provider is > the next hop - and there's often 5 or 6 or more AS hops past that. > And that potential transit provider has absolutely *no* control over > what some backhoe just did to connectivity 4 AS down the path... There's a difference between random events such as backhoes and self-inflicting damage as the result of DSWs. > For example, look at the traceroute from my desktop to where your mail > originated: I expect LF.net to isolate me from the results of those wars, both by making the right decisions in advance, and to act to correct problems when they arise. This hasn't always been possible. For instance, during one of the European routing wars in the 90s, I couldn't reach ftp.funet.fi for a couple of days. From fw at deneb.enyo.de Mon Nov 3 13:02:26 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 03 Nov 2008 20:02:26 +0100 Subject: Sprint / Cogent dispute over? In-Reply-To: <g3wsfkq4l6.fsf@nsa.vix.com> (Paul Vixie's message of "Mon, 03 Nov 2008 14:14:29 +0000") References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <366100670811021605o82e5364q5c5452b92eed2963@mail.gmail.com> <490E5D7E.4030505@rollernet.us> <2d106eb50811021829s3dc048d1i987ed8c16d4944a1@mail.gmail.com> <6eb799ab0811022110v68b7768fh12095301477d1eec@mail.gmail.com> <g3wsfkq4l6.fsf@nsa.vix.com> Message-ID: <878ws0vdj1.fsf@mid.deneb.enyo.de> * Paul Vixie: > if cogent signed a trial peering contract which required payment if sprint > determined after three months that cogent did not qualify, then the court's > open questions are was the contract valid (and thus, does cogent owe sprint > money) and why isn't there some kind of common carriage law for IP like in > dialtone to protect the end users from these types of partition events? Even for the phone network, I don't think you've got full isolation of end users from partition. For instance, beyond geographical area codes, full connectivity is not guaranteed (and not given) on the German PSTN. Is this different in the U.S.? Can you really call all phone sex numbers from all residential lines (content filters notwithstanding)? From lowen at pari.edu Mon Nov 3 13:35:21 2008 From: lowen at pari.edu (Lamar Owen) Date: Mon, 3 Nov 2008 14:35:21 -0500 Subject: routing around Sprint's depeering damage In-Reply-To: <200811021528.mA2FSVIY085139@aurora.sol.net> References: <200811021528.mA2FSVIY085139@aurora.sol.net> Message-ID: <200811031435.21899.lowen@pari.edu> On Sunday 02 November 2008 10:28:31 Joe Greco wrote: > previous poster wrote: > > so perhaps look at > > your own setup and decide that you need that 2nd connection to back you > > up when first one fails. This is a simple business logic. > Is it just me, or is this awful logic? Awful or not, this is the enduser business logic. > Really, we DO NOT WANT every site that considers itself to have "mission > critical needs" to be multihomed. This would lead to an explosion in the > size of the routing table. Playing enduser devil's advocate here. "Oh my! You poor provider and your routing table explosion! It's not my problem you need to forklift upgrade your routing gear due to this settlement-free interconnect versus transit stupidity: my business is made or broken by reachability, and I WILL do what I have to do to get that reachability. If it costs you, boo hoo." The more peering disagreements and the more news that "The Internet" is "broken in half!" reaches endusers, the more endusers' boards of directors will require multihoming, and the more it will cost every provider, and, by extension, every enduser. Endusers have been sold the faulty concept of "The Internet" (which we all know only halfway exists as a loose melange of voluntary interconnections to begin with) and they are demanding what they were sold. And, like it or not, each provider's very existence depends upon the endusers' pocketbooks. From jaitken at aitken.com Mon Nov 3 14:21:50 2008 From: jaitken at aitken.com (Jeff Aitken) Date: Mon, 3 Nov 2008 20:21:50 +0000 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <490F4428.2010503@antel.net.uy> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> <620fd17c0811022335l27f64ae2r42f68b161145d7ac@mail.gmail.com> <8A979F72-95E6-4A74-8012-AF98292DCBE6@ianai.net> <490F4428.2010503@antel.net.uy> Message-ID: <20081103202150.GA16609@eagle.aitken.com> On Mon, Nov 03, 2008 at 04:34:16PM -0200, Nicolas Antoniello wrote: > Sorry for my possible ignorance, but could you explain me what are you > calling "transit-free"? Transit-free means that you don't pay anyone else to reach some 3rd-party network. In other words, if I'm Sprint, I don't pay UUNET to get to X. Either X connects directly with me or X pays someone else to get to me. If I can make that claim for all values of X, then I am transit-free. Note that while I don't pay another network for access to its *peers* (that's transit) I might pay for access to its customers. This is typically called "paid peering" or "settlement-based peering", but sometimes it can just be plain transit that's modified with communities to look like peering. To add to the confusion, the latter case might be described differently by both parties; the seller probably says "X is a transit customer of mine", and the buyer says "I have peering with Y", and in this case, neither one is lying (mostly). If you didn't see the reference a month or so ago when Paul sent it, the following link might be interesting to you: http://arstechnica.com/guides/other/peering-and-transit.ars --Jeff From herrin-nanog at dirtside.com Mon Nov 3 14:41:03 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Mon, 3 Nov 2008 15:41:03 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <490F32D6.1020103@rollernet.us> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com> <8FA88C27-C0DB-4366-80E9-668484E09ABC@ianai.net> <20081103154932.GA95305@ussenterprise.ufp.org> <BF5800DD-4D46-45FB-88FD-4DE2310712EE@blyon.com> <490F32D6.1020103@rollernet.us> Message-ID: <3c3e3fca0811031241l3a0d6495i8d1ad93c5a85115f@mail.gmail.com> On Mon, Nov 3, 2008 at 1:34 PM, Nicolas Antoniello <nantoniello at antel.net.uy> wrote: > Sorry for my possible ignorance, but could you explain me what are you > calling "transit-free"? Transit: You pay an ISP to send and receive traffic to and from "the Internet." "The Internet" consists of: his paid customers, his peers and anybody he pays for an Internet Transit connection. When you say, "I have an Internet connection," that means a transit connection. Peering: You arrange with an ISP to send and receive traffic to and from his paid customers only. The peer network -does not- pass your traffic to his peers or transit connections, only to his paid customers Because his paid customers have already paid him to carry this traffic from you (just as yours have paid you to carry the traffic to him) such a connection is often "settlement free" meaning that neither peer network pays the other for the privilege of a connection or the packets sent across it. Transit Free: A network which does not purchase any Transit connections at all. This is presumably because your customers plus the paid customers of all of your Peers together include 100% of the users on the Internet. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 From Rod.Beck at hiberniaatlantic.com Mon Nov 3 14:49:39 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 3 Nov 2008 20:49:39 -0000 Subject: Sprint v. Cogent, some clarity & facts References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com><8FA88C27-C0DB-4366-80E9-668484E09ABC@ianai.net><20081103154932.GA95305@ussenterprise.ufp.org><BF5800DD-4D46-45FB-88FD-4DE2310712EE@blyon.com><490F32D6.1020103@rollernet.us> <3c3e3fca0811031241l3a0d6495i8d1ad93c5a85115f@mail.gmail.com> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB483B9B@bert.HiberniaAtlantic.local> And a 'Tier One' nework is a transit-free network that can reach all end points (end user IP addresses)? Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From davei at otd.com Mon Nov 3 15:12:02 2008 From: davei at otd.com (Dave Israel) Date: Mon, 03 Nov 2008 16:12:02 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB483B9B@bert.HiberniaAtlantic.local> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com><8FA88C27-C0DB-4366-80E9-668484E09ABC@ianai.net><20081103154932.GA95305@ussenterprise.ufp.org><BF5800DD-4D46-45FB-88FD-4DE2310712EE@blyon.com><490F32D6.1020103@rollernet.us> <3c3e3fca0811031241l3a0d6495i8d1ad93c5a85115f@mail.gmail.com> <1E8B940C5E21014AB8BE70B975D40EDB483B9B@bert.HiberniaAtlantic.local> Message-ID: <490F6922.9010607@otd.com> Rod Beck wrote: > And a 'Tier One' nework is a transit-free network that can reach all end points (end user IP addresses) A "Tier One" is best defined as "the ISP the salesman represents." It originally referred to transit-free, settlement-free ISPs, but over time, bigger ISPs began to play with the definition to try to differentiate themselves from the smaller ISPs that did not have the reach they had, and smaller players began glossing over paid peering and similar arrangements and claiming Tier One status. Since there's no formal definition, anybody can claim they are Tier One or that somebody else is not. Don't trust the term. From patrick at ianai.net Mon Nov 3 16:42:14 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Nov 2008 17:42:14 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB483B9B@bert.HiberniaAtlantic.local> References: <MDEHLPKNGKAHNMBLJOLKCEPPANAD.davids@webmaster.com><8FA88C27-C0DB-4366-80E9-668484E09ABC@ianai.net><20081103154932.GA95305@ussenterprise.ufp.org><BF5800DD-4D46-45FB-88FD-4DE2310712EE@blyon.com><490F32D6.1020103@rollernet.us> <3c3e3fca0811031241l3a0d6495i8d1ad93c5a85115f@mail.gmail.com> <1E8B940C5E21014AB8BE70B975D40EDB483B9B@bert.HiberniaAtlantic.local> Message-ID: <CCE464D3-4153-4418-9EC6-3EF6DCEFD47C@ianai.net> On Nov 3, 2008, at 3:49 PM, Rod Beck wrote: > And a 'Tier One' nework is a transit-free network that can reach all > end points (end user IP addresses)? A transit free network that has no settlements. Which means no network is strictly "tier one". Read <http://en.wikipedia.org/w/index.php?title=Tier_1_network >. [*] Interestingly, I wrote in the article that Cogent has settlement with Sprint and is therefore not "tier one". Apparently Cogent disagreed with me.... :-) -- TTFN, patrick [*] I got into a bit of a disagreement with others on Wikipedia because there is no citation for the "facts" in the article. While I understand the desire to have only verifiable, objective facts in Wikipedia, the alternative is to have no information. Perhaps I was being silly, but I prefer to have what I believe is correct info, properly caveated, over nothing. From deepak at ai.net Mon Nov 3 16:42:23 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 3 Nov 2008 17:42:23 -0500 Subject: Sprint / Cogent dispute over? In-Reply-To: <200811031501.mA3F1omo031556@parsley.amaranth.net> References: <366100670811021333j685e64d1u9fcff6d02c3745cc@mail.gmail.com> <409AEFDAAE9C4CD590153AB68AB6EF01@D88CFA77634F40F> <20081102235422.GA15591@srv03.cluenet.de> <200811031501.mA3F1omo031556@parsley.amaranth.net> Message-ID: <D338D1613B32624285BB321A5CF3DB250C6A717A0D@ginga.ai.net> At 06:54 PM 11/2/2008, Daniel Roesen wrote: >On Sun, Nov 02, 2008 at 04:40:20PM -0500, Randy Epstein wrote: > > Problem resolved? > >https://www.sprint.net/cogent.php Since there is active litigation going on over this, it's also possible an attorney said, "hmmm... maybe you should wait until the judge has rendered an opinion -- and they got to their temporary re-establishment." I haven't looked, and don't know if I have access, to the court's motions/filings on this matter. Deepak From gherbert at retro.com Mon Nov 3 16:26:28 2008 From: gherbert at retro.com (George William Herbert) Date: Mon, 03 Nov 2008 14:26:28 -0800 Subject: routing around Sprint's depeering damage In-Reply-To: <41CC83CE-2BEF-493B-8901-60E21F948627@ianai.net> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> <Pine.LNX.4.58.0811031435210.3374@scott.cb3rob.net> <41CC83CE-2BEF-493B-8901-60E21F948627@ianai.net> Message-ID: <200811032226.mA3MQTPc005893@kw.retro.com> Patrick wrote: >On Nov 3, 2008, at 9:41 AM, HRH Sven Olaf Prinz von CyberBunker- >Kamphuis MP wrote: > >>> No, but the providers who provide those connections should be >>> multihomed. >>> If they're not, I'd consider switching providers. Simple as that. > >> multihomed to whichever parties decide to generate split ups on >> purpose >> in the intarrwebbz.. meaning: all of them.. (you can never tell >> which ones >> will get the idea to depeer next, so you have to be multihomed to >> all of >> them or this can still happen) > >I am afraid you are confused. No, you do not have to attach to every >network unless you think every network is going to disconnect from >every other network simultaneously. (Would there even be an Internet >then?) > >If you are attached to two transit-free networks, you are guaranteed >connectivity to the entire Internet unless there is more than one >bifurcation simultaneously. And not just any two bifurcations. >Specifically, both of your upstreams would have to depeer the same >transit free network at the same time. > >Attach to three, and it would require all 3 to depeer someone >simultaneously to affect you. Look at this from the connectivity reliability point of view. With a technical failure, people will start rushing around to get it fixed, and NOCs will cooperate to provide ways around things that are down. Even for major fiber cuts, we see rapid restoration and low downtime. It seems to take major router or management software glitches to have large segments of the net down for all day. MTTR of a depeering is days or weeks. And it's not the sort of thing that people will cooperate to fix. Even worse - eventually we're going to have a legit outage on top of a depeering event, which will ruin a lot of people's days. When this gaming was active (depeering) in the 90s, I walked a couple of million dollars a year in connectivity away from one of the major offenders because my customers had to be able to get to me. I didn't really care what their business justification was - I was paying them for people to be able to reach me, and they couldn't do that. I have had a number of years of primarily being worried about software failures and diverse fiber being groomed behind my back. If depeering is again to be a major cause of outage time, in terms of customer seeing site down time per year, then I need to recalculate all my provider relationships again. Providers who are willing to play depeering games will be assessed a higher estimated outage time per year in my cost/benefits tradeoffs. They will either have to adjust costs appropriately or I will start walking sites again. Sprint isn't currently my direct provider anywhere, but they won't get a chance to become it again anywhere unless either they agree to stop playing peering games, or can lower prices to be competitive with networks with equivalent outage risks. I will not pay a premium cost for inferior ultimate reliability. -george william herbert gherbert at retro.com From gherbert at retro.com Mon Nov 3 16:44:56 2008 From: gherbert at retro.com (George William Herbert) Date: Mon, 03 Nov 2008 14:44:56 -0800 Subject: routing around Sprint's depeering damage In-Reply-To: <20081102190943.GA30474@latency.net> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <20081102190943.GA30474@latency.net> Message-ID: <200811032244.mA3Miulu006045@kw.retro.com> Adam Rothschild wrote: >On 2008-11-02-10:14:14, Matthew Kaufman <matthew at eeph.com> wrote: >> But seriously, it shouldn't be necessary to have two connections at >> work [...] > >This is less than clear, and largely dependent on a specific >organization's [in]ability to function if their internets go down. >End-site multihoming in some form or fashion is a growing requirement, >and folk thinking otherwise need to get their heads out of sand. There was an implicit (and sometimes contractually explicit) social contract associated with buying from a Tier 1 provider. That was that I'd pay a premium for connecting, and that everyone could reach me. That's never a guarantee - I've had both upstream peering games and more conventional network outages in the last 20 years than I can conveniently count. But the social contract was that I was not going to be bitten by my provider playing games with other providers. If I am going to be bitten by that, then I have to take additional mitigating measures, which includes multihoming for smaller sites than I used to do. That costs money. In this particular economic climate, if I have to tell site owners that they need to pay more money in connectivity, hardware, engineering, and ondoing administration time to multihome, they are going to tell me to make it up on the back end, which means that paying for Tier 1 grade connectivity is no longer affordable. Somewhere, inside Sprint, is a salesperson who understands this and has been trying to tell his or her coworkers. Apparently to no good effect... >If anything, these recent de-peerings underscore the lack of wisdom in >end users connecting to (or purchasing CDN services from) members >of the tier 1 club directly. The recent depeerings have two effects: One, they devalue higher priced Tier 1 ISP connectivity because they reintroduce the political/financial depeering risk into overall connectivity reliability, and two, it pushes the boundary downwards in both small/mid tier ISPs and content sites where multihoming is either necessary or strongly advised. That leads to additional cost and engineering time, a need to shift high level industry effort more towards supporting new multihoming sites again (ugh, this is never a fun surge to deal with, as everyone finds out the things BGP is bad for all over again). All on top of the looming IPv6 deployment surge we're all facing. Not to be alarmist, but what the @#$#@%@#(*&$% ? -george william herbert gherbert at retro.com From randy at psg.com Mon Nov 3 16:57:49 2008 From: randy at psg.com (Randy Bush) Date: Tue, 04 Nov 2008 07:57:49 +0900 Subject: routing around Sprint's depeering damage In-Reply-To: <200811032226.mA3MQTPc005893@kw.retro.com> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> <Pine.LNX.4.58.0811031435210.3374@scott.cb3rob.net> <41CC83CE-2BEF-493B-8901-60E21F948627@ianai.net> <200811032226.mA3MQTPc005893@kw.retro.com> Message-ID: <490F81ED.2010709@psg.com> if anyone is actually saying anything new here, please point it out. otherwise this seems like a lot of folk rehashing things from 1992 and every year since, trying to demonstrate how smart they are, which demonstrates how smart they are not. randy From gherbert at retro.com Mon Nov 3 16:51:35 2008 From: gherbert at retro.com (George William Herbert) Date: Mon, 03 Nov 2008 14:51:35 -0800 Subject: routing around Sprint's depeering damage In-Reply-To: <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> Message-ID: <200811032251.mA3MpZUv006394@kw.retro.com> "Justin M. Streiner" <streiner at cluebyfour.org> wrote: >On Sun, 2 Nov 2008, Matthew Kaufman wrote: >> Ah yes, I suspect we can get all the network operators here to agree that any >> customer of another ISP should buy a second connection "just in case". Maybe >> this breakage will turn out to be the best way for everyone to double their >> customer base overnight. >> >> But seriously, it shouldn't be necessary to have two connections at work, two >> connections at home, two connections for each mobile device, just to ensure >> that when large providers stop working together you can still reach what you >> need to reach. > >No, but the providers who provide those connections should be multihomed. >If they're not, I'd consider switching providers. Simple as that. As with fiber, the tendency for multiple diverse upstreams to be groomed together, and / or end up through the same physical pipe up the layers some, is nonzero and in some cases significantly high. The only way to actually reliably defeat that risk is to walk your ISP up the size chart to Tier 1 and total control of what you talk to. That was a much more attractive path in the mid-late 90s than it is today. -george william herbert gherbert at retro.com From charles at thewybles.com Mon Nov 3 17:16:39 2008 From: charles at thewybles.com (Charles Wyble) Date: Mon, 03 Nov 2008 15:16:39 -0800 Subject: routing around Sprint's depeering damage In-Reply-To: <490F81ED.2010709@psg.com> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> <Pine.LNX.4.58.0811031435210.3374@scott.cb3rob.net> <41CC83CE-2BEF-493B-8901-60E21F948627@ianai.net> <200811032226.mA3MQTPc005893@kw.retro.com> <490F81ED.2010709@psg.com> Message-ID: <490F8657.8040407@thewybles.com> Randy Bush wrote: > if anyone is actually saying anything new here, please point it out. > otherwise this seems like a lot of folk rehashing things from 1992 and > every year since, trying to demonstrate how smart they are, which > demonstrates how smart they are not. > Not all of us have been on the list since 92 or other years. Not all of us are as informed about these things as you might be. This is one of the more on topic and informative threads (at least for me) in recent history on NANOG. :) From randy at psg.com Mon Nov 3 17:20:46 2008 From: randy at psg.com (Randy Bush) Date: Tue, 04 Nov 2008 08:20:46 +0900 Subject: routing around Sprint's depeering damage In-Reply-To: <490F8657.8040407@thewybles.com> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> <Pine.LNX.4.58.0811031435210.3374@scott.cb3rob.net> <41CC83CE-2BEF-493B-8901-60E21F948627@ianai.net> <200811032226.mA3MQTPc005893@kw.retro.com> <490F81ED.2010709@psg.com> <490F8657.8040407@thewybles.com> Message-ID: <490F874E.6010502@psg.com> > Not all of us have been on the list since 92 or other years. Not all > of us are as informed about these things as you might be. that's why we have it every year. only this year the volume has been radically increased with no increase in content, just pontification. randy From randy at psg.com Mon Nov 3 17:28:04 2008 From: randy at psg.com (Randy Bush) Date: Tue, 04 Nov 2008 08:28:04 +0900 Subject: trans-oceanic dns secondary exchange Message-ID: <490F8904.7080703@psg.com> hank kilmer and i exchange secondary dns for a small lot of small zones for other old flea scratchers and friends of the family. this last weekend, we had a double failure, where both our servers went down at the same time, i lost a power supply, and hank fried a mobo. so we are seeking a third to jinx, preferably in europe, the middle east, asia, ... old dogs much preferred. and it is probably time to automate a bit, so consistency does not rely on mops. thanks for listening. randy From bradfreeman at gmail.com Mon Nov 3 17:38:58 2008 From: bradfreeman at gmail.com (Brad Freeman) Date: Mon, 3 Nov 2008 23:38:58 +0000 Subject: Any recent predictions for routing table growth? Message-ID: <17473cc0811031538i5a86d9c5he11adfb0006c0fc@mail.gmail.com> Hi, I am looking for some recent estimates of future IPv4 & IPv6 routing table growth, the most recent reliable estimate I can find was done by Vince Fuller in his presentation in March 2007, is there any newer or alternative figures out? Thanks Bradley From bhuffake at caida.org Mon Nov 3 18:23:33 2008 From: bhuffake at caida.org (Bradley Huffaker) Date: Mon, 3 Nov 2008 16:23:33 -0800 Subject: Any recent predictions for routing table growth? In-Reply-To: <17473cc0811031538i5a86d9c5he11adfb0006c0fc@mail.gmail.com> References: <17473cc0811031538i5a86d9c5he11adfb0006c0fc@mail.gmail.com> Message-ID: <20081104002332.GH89726@caida.org> Geoff Huston's has http://www.potaroo.net/tools/ipv4/ which goes up to the present. On Mon, Nov 03, 2008 at 11:38:58PM +0000, Brad Freeman wrote: > Hi, > > I am looking for some recent estimates of future IPv4 & IPv6 routing table > growth, the most recent reliable estimate I can find was done by Vince > Fuller in his presentation in March 2007, is there any newer or alternative > figures out? > > Thanks > > Bradley -- Bradley Huffaker We have all drunk from a well we did not dig CAIDA/SDSC/UCSD - Mark Shields From bradfreeman at gmail.com Mon Nov 3 18:43:14 2008 From: bradfreeman at gmail.com (Bradley Freeman) Date: Tue, 4 Nov 2008 00:43:14 +0000 Subject: Any recent predictions for routing table growth? In-Reply-To: <20081104002332.GH89726@caida.org> References: <17473cc0811031538i5a86d9c5he11adfb0006c0fc@mail.gmail.com> <20081104002332.GH89726@caida.org> Message-ID: <17473cc0811031643i2a0aebaey2c50c9d23affce35@mail.gmail.com> Thanks for that link Bradley (& Joe who replied off list), but IPv4 address depletion has been discussed to exhaustion and I was looking more for the speculative sizes of the routing table in 5 to 10+ years time such as on page 19 of this presentation www.vaf.net/prezos/*r*rg-prague.pdf is there anything similar available? Thanks 2008/11/4 Bradley Huffaker <bhuffake at caida.org> > Geoff Huston's has http://www.potaroo.net/tools/ipv4/ which goes up to > the present. > > On Mon, Nov 03, 2008 at 11:38:58PM +0000, Brad Freeman wrote: > > Hi, > > > > I am looking for some recent estimates of future IPv4 & IPv6 routing > table > > growth, the most recent reliable estimate I can find was done by Vince > > Fuller in his presentation in March 2007, is there any newer or > alternative > > figures out? > > > > Thanks > > > > Bradley > > -- > Bradley Huffaker We have all drunk from a well we did not dig > CAIDA/SDSC/UCSD - Mark Shields > From bhuffake at caida.org Mon Nov 3 18:52:47 2008 From: bhuffake at caida.org (Bradley Huffaker) Date: Mon, 3 Nov 2008 16:52:47 -0800 Subject: Any recent predictions for routing table growth? In-Reply-To: <17473cc0811031643i2a0aebaey2c50c9d23affce35@mail.gmail.com> References: <17473cc0811031538i5a86d9c5he11adfb0006c0fc@mail.gmail.com> <20081104002332.GH89726@caida.org> <17473cc0811031643i2a0aebaey2c50c9d23affce35@mail.gmail.com> Message-ID: <20081104005247.GI89726@caida.org> It doesn't provide you with the breakdown on page 19, but here is the predictions he provides. http://www.potaroo.net/tools/ipv4/fig20.png You can ask him for a breakdown if you like. On Tue, Nov 04, 2008 at 12:43:14AM +0000, Bradley Freeman wrote: > Thanks for that link Bradley (& Joe who replied off list), but IPv4 address > depletion has been discussed to exhaustion and I was looking more for the > speculative sizes of the routing table in 5 to 10+ years time such as on > page 19 of this presentation www.vaf.net/prezos/*r*rg-prague.pdf is there > anything similar available? > > Thanks > > 2008/11/4 Bradley Huffaker <bhuffake at caida.org> > > > Geoff Huston's has http://www.potaroo.net/tools/ipv4/ which goes up to > > the present. > > > > On Mon, Nov 03, 2008 at 11:38:58PM +0000, Brad Freeman wrote: > > > Hi, > > > > > > I am looking for some recent estimates of future IPv4 & IPv6 routing > > table > > > growth, the most recent reliable estimate I can find was done by Vince > > > Fuller in his presentation in March 2007, is there any newer or > > alternative > > > figures out? > > > > > > Thanks > > > > > > Bradley > > > > -- > > Bradley Huffaker We have all drunk from a well we did not dig > > CAIDA/SDSC/UCSD - Mark Shields > > -- Bradley Huffaker We have all drunk from a well we did not dig CAIDA/SDSC/UCSD - Mark Shields From joelja at bogus.com Mon Nov 3 19:03:54 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 03 Nov 2008 17:03:54 -0800 Subject: Any recent predictions for routing table growth? In-Reply-To: <17473cc0811031538i5a86d9c5he11adfb0006c0fc@mail.gmail.com> References: <17473cc0811031538i5a86d9c5he11adfb0006c0fc@mail.gmail.com> Message-ID: <490F9F7A.5000409@bogus.com> In order to double on schedule from the point where it hit 250k routes the rate of prefix growth needs to be on the order of 2k prefixes a week... I'm operating under the assumption that I'm going to need 500k dfz fib entries around mid 2010 which oddly is about inline with where we thought we'd be when we did the fib bof at nanog 39. Brad Freeman wrote: > Hi, > > I am looking for some recent estimates of future IPv4 & IPv6 routing table > growth, the most recent reliable estimate I can find was done by Vince > Fuller in his presentation in March 2007, is there any newer or alternative > figures out? > > Thanks > > Bradley > From gherbert at retro.com Mon Nov 3 19:16:49 2008 From: gherbert at retro.com (George William Herbert) Date: Mon, 03 Nov 2008 17:16:49 -0800 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> Message-ID: <200811040116.mA41Gnse010776@kw.retro.com> Patrick writes: >3. Standard transit contracts do not guarantee full connectivity >If you are a Cogent customer, it is very unlikely your contract will >allow you SLA or other credits for not being able to reach Sprint >unless you negotiated something special. I doubt Sprint's standard >contract is much different. Transit contract SLAs end at AS >boundaries. This is because Network A has no control over Network B >and therefore will not give credit if Network B fails. Of course, you >can still sue, threaten to terminate, etc., but the letter of the >contract almost certainly says nothing about packets going beyond your >transit provider's ASN. I am not aware of any major content provider who still has any agreements in place that don't say anything about routing past the provider's network. Some weren't paying any attention when they signed up initially and didn't get the specific provisions. But once bitten by such, renewals Do Not Happen without additional clauses being inserted. I don't rule out there still being such agreements, but I think that anyone with a clue and enough traffic to think about multihoming has been exposed to this and should have insisted on some legal protection about best-effort to route to rest of world. It never fails to impress me how many people have little clue, though... -george william herbert gherbert at retro.com From patrick at ianai.net Mon Nov 3 20:04:26 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 Nov 2008 21:04:26 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <200811040116.mA41Gnse010776@kw.retro.com> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> <200811040116.mA41Gnse010776@kw.retro.com> Message-ID: <FF620DAE-9A43-4D98-8D51-FD029FDCBD41@ianai.net> On Nov 3, 2008, at 8:16 PM, George William Herbert wrote: > Patrick writes: >> 3. Standard transit contracts do not guarantee full connectivity >> If you are a Cogent customer, it is very unlikely your contract will >> allow you SLA or other credits for not being able to reach Sprint >> unless you negotiated something special. I doubt Sprint's standard >> contract is much different. Transit contract SLAs end at AS >> boundaries. This is because Network A has no control over Network B >> and therefore will not give credit if Network B fails. Of course, >> you >> can still sue, threaten to terminate, etc., but the letter of the >> contract almost certainly says nothing about packets going beyond >> your >> transit provider's ASN. > > I am not aware of any major content provider who still has > any agreements in place that don't say anything about routing > past the provider's network. Content hosting != transit > Some weren't paying any attention when they signed up initially > and didn't get the specific provisions. But once bitten by such, > renewals Do Not Happen without additional clauses being inserted. > > I don't rule out there still being such agreements, but I think that > anyone with a clue and enough traffic to think about multihoming > has been exposed to this and should have insisted on some legal > protection about best-effort to route to rest of world. It never > fails to impress me how many people have little clue, though... "Never underestimate the power of human stupidity." -- TTFN, patrick From mpetach at netflight.com Mon Nov 3 20:59:53 2008 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 3 Nov 2008 18:59:53 -0800 Subject: routing around Sprint's depeering damage In-Reply-To: <490F81ED.2010709@psg.com> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490CEE78.5030506@cox.net> <4c7b1780811020156s54bb4d1bl604794476f40109b@mail.gmail.com> <00d101c93cf7$d9a46c70$8ced4550$@com> <490DC3C6.7090402@eeph.com> <Pine.LNX.4.64.0811030914170.11954@whammy.cluebyfour.org> <Pine.LNX.4.58.0811031435210.3374@scott.cb3rob.net> <41CC83CE-2BEF-493B-8901-60E21F948627@ianai.net> <200811032226.mA3MQTPc005893@kw.retro.com> <490F81ED.2010709@psg.com> Message-ID: <63ac96a50811031859v64c8fa8dh64fc05aaca9fb06c@mail.gmail.com> On 11/3/08, Randy Bush <randy at psg.com> wrote: > if anyone is actually saying anything new here, please point it out. > otherwise this seems like a lot of folk rehashing things from 1992 and > every year since, trying to demonstrate how smart they are, which > demonstrates how smart they are not. > > randy With all due respect, Randy, we're rehashing the thread because the people who *were* around in 1992 failed miserably at fixing these issues then. Perhaps the new crop of people rehashing these issues will figure out a solution that eluded those who had the discussion in 1992, and we can fix the underlying problems so that the discussion need not continue happening every year. Until the underlying issues are fixed, though, I think it's useful to continue discussing and hashing out the problems in the hopes that we can make some forward progress towards solving the underlying issues. Asking people to not talk about areas of the network that are broken because you've heard it all before sounds like a very bad case of osterich-itis. If it's broke, let's try to fix it, not sit around doing our best trying not to talk about it. Matt From glen.kent at gmail.com Tue Nov 4 00:15:43 2008 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 4 Nov 2008 11:45:43 +0530 Subject: NTP Md5 or AutoKey? Message-ID: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> Hi, I was wondering what most folks use for NTP security? Do they use the low cost, light weight symmetric key cryptographic protection method using MD5 or do folks go in for full digital signatures and X.509 certificates (AutoKey Security)? Thanks, Glen From fergdawgster at gmail.com Tue Nov 4 00:23:07 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 3 Nov 2008 22:23:07 -0800 Subject: NTP Md5 or AutoKey? In-Reply-To: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> Message-ID: <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> On Mon, Nov 3, 2008 at 10:15 PM, Glen Kent <glen.kent at gmail.com> wrote: > Hi, > > I was wondering what most folks use for NTP security? > > Do they use the low cost, light weight symmetric key cryptographic > protection method using MD5 or do folks go in for full digital > signatures and X.509 certificates (AutoKey Security)? > I'm just wondering -- in globak scheme of security issue, is NTP security a major issue? Just curious. - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From oberman at es.net Tue Nov 4 00:29:42 2008 From: oberman at es.net (Kevin Oberman) Date: Mon, 03 Nov 2008 22:29:42 -0800 Subject: NTP Md5 or AutoKey? In-Reply-To: Your message of "Mon, 03 Nov 2008 22:23:07 PST." <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> Message-ID: <20081104062942.B54E145010@ptavv.es.net> > Date: Mon, 3 Nov 2008 22:23:07 -0800 > From: "Paul Ferguson" <fergdawgster at gmail.com> > > On Mon, Nov 3, 2008 at 10:15 PM, Glen Kent <glen.kent at gmail.com> wrote: > > > Hi, > > > > I was wondering what most folks use for NTP security? > > > > Do they use the low cost, light weight symmetric key cryptographic > > protection method using MD5 or do folks go in for full digital > > signatures and X.509 certificates (AutoKey Security)? > > > > I'm just wondering -- in globak scheme of security issue, is NTP > security a major issue? > > Just curious. It's probably not a "major issue", but forged NTP data can, in theory, be used to allow the implementation of replay attacks. I'll admit I have never heard of a real-world case. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081103/7098c0c8/attachment.bin> From nanog at daork.net Tue Nov 4 00:30:48 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 4 Nov 2008 19:30:48 +1300 Subject: NTP Md5 or AutoKey? In-Reply-To: <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> Message-ID: <ED736B98-9B9F-42CD-B3C3-807C2735B30E@daork.net> On 4/11/2008, at 7:23 PM, Paul Ferguson wrote: > On Mon, Nov 3, 2008 at 10:15 PM, Glen Kent <glen.kent at gmail.com> > wrote: > >> Hi, >> >> I was wondering what most folks use for NTP security? >> >> Do they use the low cost, light weight symmetric key cryptographic >> protection method using MD5 or do folks go in for full digital >> signatures and X.509 certificates (AutoKey Security)? >> > > I'm just wondering -- in globak scheme of security issue, is NTP > security a major issue? > > Just curious. Out of sync time was a big deal in James Bond 18 (Tomorrow Never Dies). Anyway, pushing time out of sync seems an interesting way to break services that require stuff to be synced up. Kerberos is one such example. Push a KDC out of sync from it's clients, and auth wouldn't happen anymore. Seems like a simple way to kick router admins out of their equipment if you're causing trouble, or at least, slow them down. Of course, this only really works if your network has 3 reliable +secure time sources + 1 for redundancy. I'm not sure that .*pool\.ntp \.org would class as reliable+secure if you're concerned about NTP security. -- Nathan Ward From rdobbins at cisco.com Tue Nov 4 00:39:07 2008 From: rdobbins at cisco.com (Roland Dobbins) Date: Tue, 4 Nov 2008 14:39:07 +0800 Subject: NTP Md5 or AutoKey? In-Reply-To: <ED736B98-9B9F-42CD-B3C3-807C2735B30E@daork.net> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> <ED736B98-9B9F-42CD-B3C3-807C2735B30E@daork.net> Message-ID: <3062EA40-7283-4AC0-8CF3-2C3FA98DC53F@cisco.com> On Nov 4, 2008, at 2:30 PM, Nathan Ward wrote: > Anyway, pushing time out of sync seems an interesting way to break > services that require stuff to be synced up. Kerberos is one such > example. The analytical/forensic fidelity of various forms of telemetry such as NetFlow, syslog, etc. is highly dependent upon an accurate time-hack, as well. ----------------------------------------------------------------------- Roland Dobbins <rdobbins at cisco.com> // +852.9133.2844 mobile History is a great teacher, but it also lies with impunity. -- John Robb From Valdis.Kletnieks at vt.edu Tue Nov 4 00:52:05 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 04 Nov 2008 01:52:05 -0500 Subject: NTP Md5 or AutoKey? In-Reply-To: Your message of "Mon, 03 Nov 2008 22:23:07 PST." <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> Message-ID: <125265.1225781525@turing-police.cc.vt.edu> On Mon, 03 Nov 2008 22:23:07 PST, Paul Ferguson said: > I'm just wondering -- in globak scheme of security issue, is NTP > security a major issue? The biggest problem is that you pretty much have to spoof a server that the client is already configured to be accepting NTP packets from. And *then* you have to remember that your packets can only lie about the time by a very small number of milliseconds or they get tossed out by the NTP packet filter that measures the apparent jitter. Remember, the *real* clock is also sending correct updates. At *best*, you lie like hell, and get the clock thrown out as an "insane" timesource. But at that point, a properly configured clock will go on autopilot till a quorum of sane clocks reappears, so you don't have much chance of wedging in a huge time slew (unless you *really* hit the jackpot, and the client reboots and does an ntpdate and you manage to cram in enough false packets to mis-set the clock then). So in most cases, you can only push the clock around by milliseconds - and that doesn't buy you very much room for a replay attack or similar, because that's under the retransmit timeout for a lost packet. It isn't like you can get away with replaying something from 5 minutes ago. Now, if you wanted to be *dastardly*, you'd figure out where a site's Stratum-1 server(s) have their GPS antennas, and you'd read the recent research on spoofing GPS signals - at *that* point you'd have a good chance of controlling the horizontal and vertical.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081104/08364170/attachment.bin> From glen.kent at gmail.com Tue Nov 4 02:39:20 2008 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 4 Nov 2008 14:09:20 +0530 Subject: NTP Md5 or AutoKey? In-Reply-To: <20081104062942.B54E145010@ptavv.es.net> References: <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> <20081104062942.B54E145010@ptavv.es.net> Message-ID: <92c950310811040039v76ed7cffpee63c1c96c293142@mail.gmail.com> So, can i safely assume that nobody deployes Autokey security for NTP and the best that one does right now is by using the cryptographic authentication provided in the base spec of NTPv4. Cheers, Glen On Tue, Nov 4, 2008 at 11:59 AM, Kevin Oberman <oberman at es.net> wrote: >> Date: Mon, 3 Nov 2008 22:23:07 -0800 >> From: "Paul Ferguson" <fergdawgster at gmail.com> >> >> On Mon, Nov 3, 2008 at 10:15 PM, Glen Kent <glen.kent at gmail.com> wrote: >> >> > Hi, >> > >> > I was wondering what most folks use for NTP security? >> > >> > Do they use the low cost, light weight symmetric key cryptographic >> > protection method using MD5 or do folks go in for full digital >> > signatures and X.509 certificates (AutoKey Security)? >> > >> >> I'm just wondering -- in globak scheme of security issue, is NTP >> security a major issue? >> >> Just curious. > > It's probably not a "major issue", but forged NTP data can, in theory, > be used to allow the implementation of replay attacks. I'll admit I have > never heard of a real-world case. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > From glen.kent at gmail.com Tue Nov 4 02:47:26 2008 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 4 Nov 2008 14:17:26 +0530 Subject: NTP Md5 or AutoKey? In-Reply-To: <125265.1225781525@turing-police.cc.vt.edu> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> <125265.1225781525@turing-police.cc.vt.edu> Message-ID: <92c950310811040047m2c5243c6w6c87648c3e73fb3b@mail.gmail.com> I dont think this is correct. I have seen routing protocol adjacencies going down because of some perturbations in NTP. I understand, any router implementation worth its salt would not use the NTP clock internally, but i have seen some real life issues where OSPF went down because the time moved ahead and it thought that it hadnt heard from the neighbor since a long time. All such bugs were eventually fixed, but this is just one example. There is an emerging need to distribute highly accurate time information over IP and over MPLS packet switched networks (PSNs). A variety of applications require time information to a precision which existing protocols cannot supply. TICTOC is an IETF WG created to develop solutions that meet the requirements of such protocols and applications. Glen > On Tue, Nov 4, 2008 at 12:22 PM, <Valdis.Kletnieks at vt.edu> wrote: > On Mon, 03 Nov 2008 22:23:07 PST, Paul Ferguson said: > >> I'm just wondering -- in globak scheme of security issue, is NTP >> security a major issue? > > The biggest problem is that you pretty much have to spoof a server that > the client is already configured to be accepting NTP packets from. And *then* you have to > remember that your packets can only lie about the time by a very small number > of milliseconds or they get tossed out by the NTP packet filter that measures > the apparent jitter. Remember, the *real* clock is also sending correct > updates. At *best*, you lie like hell, and get the clock thrown out as > an "insane" timesource. But at that point, a properly configured clock > will go on autopilot till a quorum of sane clocks reappears, so you don't > have much chance of wedging in a huge time slew (unless you *really* hit > the jackpot, and the client reboots and does an ntpdate and you manage to > cram in enough false packets to mis-set the clock then). > > So in most cases, you can only push the clock around by milliseconds - and > that doesn't buy you very much room for a replay attack or similar, because > that's under the retransmit timeout for a lost packet. It isn't like you > can get away with replaying something from 5 minutes ago. > > Now, if you wanted to be *dastardly*, you'd figure out where a site's > Stratum-1 server(s) have their GPS antennas, and you'd read the recent > research on spoofing GPS signals - at *that* point you'd have a good chance > of controlling the horizontal and vertical.... > > From ltd at interlink.com.au Tue Nov 4 03:14:15 2008 From: ltd at interlink.com.au (Lincoln Dale) Date: Tue, 4 Nov 2008 20:14:15 +1100 Subject: NTP Md5 or AutoKey? In-Reply-To: <92c950310811040047m2c5243c6w6c87648c3e73fb3b@mail.gmail.com> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com><6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com><125265.1225781525@turing-police.cc.vt.edu> <92c950310811040047m2c5243c6w6c87648c3e73fb3b@mail.gmail.com> Message-ID: <A868F243F1934C26848C2270469A2CFE@ltdbeast> > There is an emerging need to distribute highly accurate time > information over IP and over MPLS packet switched networks (PSNs). good of you to ask. it exists today. http://ieee1588.nist.gov/ cheers, lincoln. From smb at cs.columbia.edu Tue Nov 4 03:39:41 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 4 Nov 2008 04:39:41 -0500 Subject: NTP Md5 or AutoKey? In-Reply-To: <125265.1225781525@turing-police.cc.vt.edu> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> <125265.1225781525@turing-police.cc.vt.edu> Message-ID: <20081104043941.7629feb7@cs.columbia.edu> On Tue, 04 Nov 2008 01:52:05 -0500 Valdis.Kletnieks at vt.edu wrote: > On Mon, 03 Nov 2008 22:23:07 PST, Paul Ferguson said: > > > I'm just wondering -- in globak scheme of security issue, is NTP > > security a major issue? > > The biggest problem is that you pretty much have to spoof a server > that the client is already configured to be accepting NTP packets > from. And *then* you have to remember that your packets can only lie > about the time by a very small number of milliseconds or they get > tossed out by the NTP packet filter that measures the apparent > jitter. Remember, the *real* clock is also sending correct updates. > At *best*, you lie like hell, and get the clock thrown out as an > "insane" timesource. But at that point, a properly configured clock > will go on autopilot till a quorum of sane clocks reappears, so you > don't have much chance of wedging in a huge time slew (unless you > *really* hit the jackpot, and the client reboots and does an ntpdate > and you manage to cram in enough false packets to mis-set the clock > then). > > So in most cases, you can only push the clock around by milliseconds > - and that doesn't buy you very much room for a replay attack or > similar, because that's under the retransmit timeout for a lost > packet. It isn't like you can get away with replaying something from > 5 minutes ago. > > Now, if you wanted to be *dastardly*, you'd figure out where a site's > Stratum-1 server(s) have their GPS antennas, and you'd read the recent > research on spoofing GPS signals - at *that* point you'd have a good > chance of controlling the horizontal and vertical.... > http://nob.cs.ucdavis.edu/bishop/papers/1990-acsac/ is old but does have a good analysis of the problem. --Steve Bellovin, http://www.cs.columbia.edu/~smb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081104/3d0c2f32/attachment.bin> From bmanning at vacation.karoshi.com Tue Nov 4 04:30:09 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 4 Nov 2008 10:30:09 +0000 Subject: NTP Md5 or AutoKey? In-Reply-To: <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> Message-ID: <20081104103009.GA13379@vacation.karoshi.com.> On Mon, Nov 03, 2008 at 10:23:07PM -0800, Paul Ferguson wrote: > On Mon, Nov 3, 2008 at 10:15 PM, Glen Kent <glen.kent at gmail.com> wrote: > > > Hi, > > > > I was wondering what most folks use for NTP security? > > > > Do they use the low cost, light weight symmetric key cryptographic > > protection method using MD5 or do folks go in for full digital > > signatures and X.509 certificates (AutoKey Security)? > > > > I'm just wondering -- in globak scheme of security issue, is NTP > security a major issue? > > Just curious. > > - ferg depends on your POV... in a dns context, TSIG and DNSSEC validation depend on accurate time - failure to resolve data because of a time slip might be considered a significantissue. --bill From glen.kent at gmail.com Tue Nov 4 05:11:00 2008 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 4 Nov 2008 16:41:00 +0530 Subject: NTP Md5 or AutoKey? In-Reply-To: <20081104103009.GA13379@vacation.karoshi.com.> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> <20081104103009.GA13379@vacation.karoshi.com.> Message-ID: <92c950310811040311x3a9e4d4an1aaed0465c5cdd3e@mail.gmail.com> My original question got drowned amidst all this vibrant discussions! Do folks already use or plan to use Autokey for NTP? Glen On Tue, Nov 4, 2008 at 4:00 PM, <bmanning at vacation.karoshi.com> wrote: > On Mon, Nov 03, 2008 at 10:23:07PM -0800, Paul Ferguson wrote: >> On Mon, Nov 3, 2008 at 10:15 PM, Glen Kent <glen.kent at gmail.com> wrote: >> >> > Hi, >> > >> > I was wondering what most folks use for NTP security? >> > >> > Do they use the low cost, light weight symmetric key cryptographic >> > protection method using MD5 or do folks go in for full digital >> > signatures and X.509 certificates (AutoKey Security)? >> > >> >> I'm just wondering -- in globak scheme of security issue, is NTP >> security a major issue? >> >> Just curious. >> >> - ferg > > depends on your POV... in a dns context, TSIG and DNSSEC validation > depend on accurate time - failure to resolve data because of a time slip > might be considered a significantissue. > > --bill > From e.gourcuff at gmail.com Tue Nov 4 07:19:43 2008 From: e.gourcuff at gmail.com (Erwan Gourcuff) Date: Tue, 4 Nov 2008 14:19:43 +0100 Subject: L2tp for DSL In-Reply-To: <20081103000633.GB18948@skywalker.creative.net.au> References: <869993.2701.qm@web33305.mail.mud.yahoo.com> <20081103000633.GB18948@skywalker.creative.net.au> Message-ID: <faf4d5110811040519w424c6432oeda4ef1840f0e93b@mail.gmail.com> MPD on freebsd is a good alternative too. regards erwan 2008/11/3 Adrian Chadd <adrian at creative.net.au> > Try openl2tp or l2tpns. They can both be LNSes. > > > > Adrian > > On Mon, Nov 03, 2008, adrian kok wrote: > > Hi > > > > Do you know any free open source L2tp for NAS? > > > > I know this software was developed so many years > > before but stopped > > > > any information > > > > Thank you > > From david.freedman at uk.clara.net Tue Nov 4 08:49:53 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 04 Nov 2008 14:49:53 +0000 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> Message-ID: <gepmkp$o8e$1@ger.gmane.org> > 2. The Internet cannot "route around" de-peering > I know everyone believes "the Internet routes around failures". While > occasionally true, it does not hold in this case. To "route around" the > "failure" would require transit. See item #1. The internet "routes around" technical failures, not political ones. Dave. From dga at cs.cmu.edu Tue Nov 4 09:13:50 2008 From: dga at cs.cmu.edu (David Andersen) Date: Tue, 4 Nov 2008 10:13:50 -0500 Subject: Any recent predictions for routing table growth? In-Reply-To: <17473cc0811031538i5a86d9c5he11adfb0006c0fc@mail.gmail.com> References: <17473cc0811031538i5a86d9c5he11adfb0006c0fc@mail.gmail.com> Message-ID: <62F64EE2-716D-4388-AA41-1A9958A91618@cs.cmu.edu> Hey, Brad - the latest I know of are ours, but I'm possibly out of date: http://www.cs.cmu.edu/~dga/papers/aip-sigcomm2008-abstract.html Look in section 4.1. The #s were from routeviews, June 30, 2008. The gist: June 2008: 247K entries Growth rate: 17% per year So - June 2009: 288k There's an embarrassing typo in the formula in the paper - it says "2.07 * 10^4" as the base, when it's obvious that it means 2.47 * 10^5. Sigh. I'll get that corrected. :) Also note that our #s differ a bit from, say, CIDR report since we used routeviews as our baseline. If you use the june 6, 2008 CIDR report as your starting point, which starts at 267k, the 17% exponential growth would predict that the October 31, 2008 CIDR report would report 284k prefixes; in reality, it reported 286. So, reasonably close. But you want to start with the # of prefixes that YOU observe, since that's going to be a little different depending on your vantage point. Plug in: STARTING_NUM_PREFIXES * e^(NUM_DAYS_ELAPSED * 0.0004253) e.g., 267000 * e^(147 * 0.0004253) and you'll have a pretty decent prediction unless things change course. :) On Nov 3, 2008, at 6:38 PM, Brad Freeman wrote: > Hi, > > I am looking for some recent estimates of future IPv4 & IPv6 routing > table > growth, the most recent reliable estimate I can find was done by Vince > Fuller in his presentation in March 2007, is there any newer or > alternative > figures out? > > Thanks > > Bradley > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081104/11e7123b/attachment.bin> From patrick at ianai.net Tue Nov 4 09:52:00 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 4 Nov 2008 10:52:00 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <gepmkp$o8e$1@ger.gmane.org> References: <56FE6098-329F-40A9-B2B3-F649E18F801C@ianai.net> <gepmkp$o8e$1@ger.gmane.org> Message-ID: <39296E61-4018-47DF-8635-3C480D738D13@ianai.net> On Nov 4, 2008, at 9:49 AM, David Freedman wrote: >> 2. The Internet cannot "route around" de-peering >> I know everyone believes "the Internet routes around failures". >> While >> occasionally true, it does not hold in this case. To "route >> around" the >> "failure" would require transit. See item #1. > > The internet "routes around" technical failures, not political ones. If two transit free networks have a technical failure which disables all peering between them, the Internet cannot route around it. Intention is not the gating factor here. Intention just -guarantees- a problem exists, turning off BGP sessions and/or light is still the base problem. :-) -- TTFN, patrick From davids at webmaster.com Tue Nov 4 10:02:57 2008 From: davids at webmaster.com (David Schwartz) Date: Tue, 4 Nov 2008 08:02:57 -0800 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <39296E61-4018-47DF-8635-3C480D738D13@ianai.net> Message-ID: <MDEHLPKNGKAHNMBLJOLKIEHFAOAD.davids@webmaster.com> Patrick W. Gilmore wrote: > On Nov 4, 2008, at 9:49 AM, David Freedman wrote: > >> 2. The Internet cannot "route around" de-peering > >> I know everyone believes "the Internet routes around failures". > >> While > >> occasionally true, it does not hold in this case. To "route > >> around" the > >> "failure" would require transit. See item #1. > > > > The internet "routes around" technical failures, not political ones. > If two transit free networks have a technical failure which disables > all peering between them, the Internet cannot route around it. Sure it can. The traffic just flows through any of the providers that still have reliable high-bandwidth connectivity to both of those providers. Unless, of course, a pre-existing political failure prohibits this traffic. The Internet can't route around that political failure. >From a technical standpoint, the Internet is always suffering from multiple political failures. This leaves it vulnerable to small technical failures it could otherwise route around. DS From patrick at ianai.net Tue Nov 4 10:09:31 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 4 Nov 2008 11:09:31 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <MDEHLPKNGKAHNMBLJOLKIEHFAOAD.davids@webmaster.com> References: <MDEHLPKNGKAHNMBLJOLKIEHFAOAD.davids@webmaster.com> Message-ID: <5559A8A3-60C8-4692-BDBD-2D5B990EABB4@ianai.net> On Nov 4, 2008, at 11:02 AM, David Schwartz wrote: > Patrick W. Gilmore wrote: >> On Nov 4, 2008, at 9:49 AM, David Freedman wrote: > >>>> 2. The Internet cannot "route around" de-peering >>>> I know everyone believes "the Internet routes around failures". >>>> While >>>> occasionally true, it does not hold in this case. To "route >>>> around" the >>>> "failure" would require transit. See item #1. >>> >>> The internet "routes around" technical failures, not political ones. > >> If two transit free networks have a technical failure which disables >> all peering between them, the Internet cannot route around it. > > Sure it can. The traffic just flows through any of the providers > that still > have reliable high-bandwidth connectivity to both of those providers. > > Unless, of course, a pre-existing political failure prohibits this > traffic. > The Internet can't route around that political failure. Perhaps you missed the "transit free" part. If Sprint & UUNET have a technical failure causing all peering to go down, Level 3 will not magically transport packets between the two, despite the fact L3 has "reliable high-bandwidth connectivity to both of those providers". How would you propose L3 bill UU & Sprint for it? On second thought, don't answer that, I don't think it would be a useful discussion. Or are you claiming the fact every network does not give every other network transit a "political failure". If you are, we should agree to disagree and move on. > From a technical standpoint, the Internet is always suffering from > multiple > political failures. This leaves it vulnerable to small technical > failures it > could otherwise route around. See above. I do not think it is a "political failure" that I do not give you free transit. -- TTFN, patrick From dot at dotat.at Tue Nov 4 10:49:00 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 4 Nov 2008 16:49:00 +0000 Subject: NTP Md5 or AutoKey? In-Reply-To: <A868F243F1934C26848C2270469A2CFE@ltdbeast> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com><6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com><125265.1225781525@turing-police.cc.vt.edu> <92c950310811040047m2c5243c6w6c87648c3e73fb3b@mail.gmail.com> <A868F243F1934C26848C2270469A2CFE@ltdbeast> Message-ID: <alpine.LSU.2.00.0811041646130.30582@hermes-1.csi.cam.ac.uk> On Tue, 4 Nov 2008, Lincoln Dale wrote: > > There is an emerging need to distribute highly accurate time > > information over IP and over MPLS packet switched networks (PSNs). > > good of you to ask. it exists today. > http://ieee1588.nist.gov/ According to the TICTOC charter, you need more than just IEEE 1588 for accurate time distribution over IP and/or MPLS networks. http://www.ietf.org/html.charters/tictoc-charter.html Tony. -- f.anthony.n.finch <dot at dotat.at> http://dotat.at/ SOLE LUNDY FASTNET IRISH SEA: NORTHEAST 3 OR 4, OCCASIONALLY 5 AT FIRST, BECOMING VARIABLE LATER. SLIGHT OR MODERATE. OCCASIONAL DRIZZLE. MODERATE OR GOOD. From tomb at byrneit.net Tue Nov 4 10:51:19 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 4 Nov 2008 08:51:19 -0800 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <5559A8A3-60C8-4692-BDBD-2D5B990EABB4@ianai.net> References: <MDEHLPKNGKAHNMBLJOLKIEHFAOAD.davids@webmaster.com> <5559A8A3-60C8-4692-BDBD-2D5B990EABB4@ianai.net> Message-ID: <70D072392E56884193E3D2DE09C097A9F89F@pascal.zaphodb.org> The concept of "Transit Free" is a political failure, not a technical one. The protocols are designed, and the original concept behind the Internet is, to propagate all reachability via all paths. IE to use Transit if peering fails. Not doing so is a policy decision that breaks the redundancy in the original design. >-----Original Message----- >From: Patrick W. Gilmore [mailto:patrick at ianai.net] >Sent: Tuesday, November 04, 2008 8:10 AM >To: NANOG list >Subject: Re: Sprint v. Cogent, some clarity & facts > >On Nov 4, 2008, at 11:02 AM, David Schwartz wrote: >> Patrick W. Gilmore wrote: >>> On Nov 4, 2008, at 9:49 AM, David Freedman wrote: >> >>>>> 2. The Internet cannot "route around" de-peering >>>>> I know everyone believes "the Internet routes around failures". >>>>> While >>>>> occasionally true, it does not hold in this case. To "route >>>>> around" the >>>>> "failure" would require transit. See item #1. >>>> >>>> The internet "routes around" technical failures, not political ones. >> >>> If two transit free networks have a technical failure which disables >>> all peering between them, the Internet cannot route around it. >> >> Sure it can. The traffic just flows through any of the providers >> that still >> have reliable high-bandwidth connectivity to both of those providers. >> >> Unless, of course, a pre-existing political failure prohibits this >> traffic. >> The Internet can't route around that political failure. > >Perhaps you missed the "transit free" part. > >If Sprint & UUNET have a technical failure causing all peering to go >down, Level 3 will not magically transport packets between the two, >despite the fact L3 has "reliable high-bandwidth connectivity to both >of those providers". How would you propose L3 bill UU & Sprint for >it? On second thought, don't answer that, I don't think it would be a >useful discussion. > >Or are you claiming the fact every network does not give every other >network transit a "political failure". If you are, we should agree to >disagree and move on. > > >> From a technical standpoint, the Internet is always suffering from >> multiple >> political failures. This leaves it vulnerable to small technical >> failures it >> could otherwise route around. > >See above. I do not think it is a "political failure" that I do not >give you free transit. > >-- >TTFN, >patrick > From patrick at ianai.net Tue Nov 4 10:55:01 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 4 Nov 2008 11:55:01 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <70D072392E56884193E3D2DE09C097A9F89F@pascal.zaphodb.org> References: <MDEHLPKNGKAHNMBLJOLKIEHFAOAD.davids@webmaster.com> <5559A8A3-60C8-4692-BDBD-2D5B990EABB4@ianai.net> <70D072392E56884193E3D2DE09C097A9F89F@pascal.zaphodb.org> Message-ID: <8EB0179B-DB38-479D-9C40-962758C0C2D0@ianai.net> On Nov 4, 2008, at 11:51 AM, Tomas L. Byrnes wrote: > The concept of "Transit Free" is a political failure, not a technical > one. We disagree. > The protocols are designed, and the original concept behind the > Internet > is, to propagate all reachability via all paths. IE to use Transit if > peering fails. > > Not doing so is a policy decision that breaks the redundancy in the > original design. Using the 'original design' (and honestly, your assertion is debatable) would not have allowed the Internet to scale to the size it is today. Or even the size it was 10 years ago. So I guess you could say the current situation is a political success. -- TTFN, patrick >> -----Original Message----- >> From: Patrick W. Gilmore [mailto:patrick at ianai.net] >> Sent: Tuesday, November 04, 2008 8:10 AM >> To: NANOG list >> Subject: Re: Sprint v. Cogent, some clarity & facts >> >> On Nov 4, 2008, at 11:02 AM, David Schwartz wrote: >>> Patrick W. Gilmore wrote: >>>> On Nov 4, 2008, at 9:49 AM, David Freedman wrote: >>> >>>>>> 2. The Internet cannot "route around" de-peering >>>>>> I know everyone believes "the Internet routes around failures". >>>>>> While >>>>>> occasionally true, it does not hold in this case. To "route >>>>>> around" the >>>>>> "failure" would require transit. See item #1. >>>>> >>>>> The internet "routes around" technical failures, not political > ones. >>> >>>> If two transit free networks have a technical failure which >>>> disables >>>> all peering between them, the Internet cannot route around it. >>> >>> Sure it can. The traffic just flows through any of the providers >>> that still >>> have reliable high-bandwidth connectivity to both of those >>> providers. >>> >>> Unless, of course, a pre-existing political failure prohibits this >>> traffic. >>> The Internet can't route around that political failure. >> >> Perhaps you missed the "transit free" part. >> >> If Sprint & UUNET have a technical failure causing all peering to go >> down, Level 3 will not magically transport packets between the two, >> despite the fact L3 has "reliable high-bandwidth connectivity to both >> of those providers". How would you propose L3 bill UU & Sprint for >> it? On second thought, don't answer that, I don't think it would >> be a >> useful discussion. >> >> Or are you claiming the fact every network does not give every other >> network transit a "political failure". If you are, we should agree >> to >> disagree and move on. >> >> >>> From a technical standpoint, the Internet is always suffering from >>> multiple >>> political failures. This leaves it vulnerable to small technical >>> failures it >>> could otherwise route around. >> >> See above. I do not think it is a "political failure" that I do not >> give you free transit. >> >> -- >> TTFN, >> patrick >> > From bradfreeman at gmail.com Tue Nov 4 10:59:19 2008 From: bradfreeman at gmail.com (Bradley Freeman) Date: Tue, 4 Nov 2008 16:59:19 +0000 Subject: Any recent predictions for routing table growth? In-Reply-To: <62F64EE2-716D-4388-AA41-1A9958A91618@cs.cmu.edu> References: <17473cc0811031538i5a86d9c5he11adfb0006c0fc@mail.gmail.com> <62F64EE2-716D-4388-AA41-1A9958A91618@cs.cmu.edu> Message-ID: <17473cc0811040859p6b71a9abuc2dc398955e06a00@mail.gmail.com> Thank you very much David, the Routing Growth estimates is exactly the research I was after. 2008/11/4 David Andersen <dga at cs.cmu.edu> > Hey, Brad - the latest I know of are ours, but I'm possibly out of date: > > http://www.cs.cmu.edu/~dga/papers/aip-sigcomm2008-abstract.html<http://www.cs.cmu.edu/%7Edga/papers/aip-sigcomm2008-abstract.html> > > Look in section 4.1. The #s were from routeviews, June 30, 2008. The > gist: > > June 2008: 247K entries > Growth rate: 17% per year > > So - June 2009: 288k > > There's an embarrassing typo in the formula in the paper - it says "2.07 * > 10^4" as the base, when it's obvious that it means 2.47 * 10^5. Sigh. I'll > get that corrected. :) > > Also note that our #s differ a bit from, say, CIDR report since we used > routeviews as our baseline. If you use the june 6, 2008 CIDR report as your > starting point, which starts at 267k, the 17% exponential growth would > predict that the October 31, 2008 CIDR report would report 284k prefixes; > in reality, it reported 286. So, reasonably close. But you want to start > with the # of prefixes that YOU observe, since that's going to be a little > different depending on your vantage point. > > Plug in: > > STARTING_NUM_PREFIXES * e^(NUM_DAYS_ELAPSED * 0.0004253) > > e.g., 267000 * e^(147 * 0.0004253) > > and you'll have a pretty decent prediction unless things change course. :) > > > On Nov 3, 2008, at 6:38 PM, Brad Freeman wrote: > > Hi, >> >> I am looking for some recent estimates of future IPv4 & IPv6 routing table >> growth, the most recent reliable estimate I can find was done by Vince >> Fuller in his presentation in March 2007, is there any newer or >> alternative >> figures out? >> >> Thanks >> >> Bradley >> >> > From niels=nanog at bakker.net Tue Nov 4 11:30:08 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 4 Nov 2008 18:30:08 +0100 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <70D072392E56884193E3D2DE09C097A9F89F@pascal.zaphodb.org> References: <MDEHLPKNGKAHNMBLJOLKIEHFAOAD.davids@webmaster.com> <5559A8A3-60C8-4692-BDBD-2D5B990EABB4@ianai.net> <70D072392E56884193E3D2DE09C097A9F89F@pascal.zaphodb.org> Message-ID: <20081104173008.GN78345@burnout.tpb.net> * tomb at byrneit.net (Tomas L. Byrnes) [Tue 04 Nov 2008, 17:51 CET]: >The concept of "Transit Free" is a political failure, not a technical >one. Yeah, networks should be free! And Cogent, if they don't get access to Sprint directly, should just set a default route over some public IX where Sprint is also present at to reach their network!! And then hack their routers to do likewise. >The protocols are designed, and the original concept behind the Internet >is, to propagate all reachability via all paths. IE to use Transit if >peering fails. Yeah, the original concept of the internet. Like classful IP routing. >Not doing so is a policy decision that breaks the redundancy in the >original design. Because the original design totally had in mind established players locking out cheaper newcomers and explicitly specified a maximum band where prices for transit had to exist inside of. Please stop it. We've had enough. -- Niels. -- "We humans get marks for consistency. We always opt for civilization after exhausting the alternatives." -- Carl Guderian From michael.dillon at bt.com Tue Nov 4 11:33:08 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 4 Nov 2008 17:33:08 -0000 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <8EB0179B-DB38-479D-9C40-962758C0C2D0@ianai.net> Message-ID: <C0F2465B4F386241A58321C884AC7ECC0922599F@E03MVZ2-UKDY.domain1.systemhost.net> > > The concept of "Transit Free" is a political failure, not a > technical > > one. > > We disagree. Perhaps some examples are needed? If you drive in a screw with a big hammer, the end result is not pleasing. For one, a screw will not have the holding power of a nail. For another, the screw and the hammer are both likely to damage the objects being attached. Nevertheless, you would be hardpressed to say that this is a technical failure. A wise person could have imposed the policy of always using screwdrivers to drive in a screw, and to only drive in nails when using a hammer. Same technology, different results. In the case of peering arrangements, the term "transit free" hides a multitude of sins. It is pure spin, dreamed up by marketing people back in the 90's when the Big Five ISPs were trying to control the market and make it hard for competitors to gain mythical Tier 1 status. In the end, everyone drank the koolaid and the whole arena of network operations has been poisoned by it. Has anyone heard of a backup route? With a longer path so it is never used unless there is a real emergency? Why was there no backup route available to carry the Sprint <-> Cogent traffic? Because there was a political failure in both Sprint and Cogent. Back in 2000 it was acceptable for the big New York banks to have all their eggs in one basket in central Manhattan. In 2002, it was no longer acceptable. Do we really need a 911 magnitude of disaster on the Internet for people to wake up and smell the coffee? The Internet is no longer a kewl tool built and operated by the cognoscenti to meet their own interests. It is now part of every nation's and everbody's critical infrastructure. It needs to be engineered and operated better so that it does not end up partitioning for dumb reasons. --Michael Dillon From Valdis.Kletnieks at vt.edu Tue Nov 4 11:34:05 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 04 Nov 2008 12:34:05 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: Your message of "Tue, 04 Nov 2008 11:09:31 EST." <5559A8A3-60C8-4692-BDBD-2D5B990EABB4@ianai.net> References: <MDEHLPKNGKAHNMBLJOLKIEHFAOAD.davids@webmaster.com> <5559A8A3-60C8-4692-BDBD-2D5B990EABB4@ianai.net> Message-ID: <20369.1225820045@turing-police.cc.vt.edu> On Tue, 04 Nov 2008 11:09:31 EST, "Patrick W. Gilmore" said: > If Sprint & UUNET have a technical failure causing all peering to go > down, Level 3 will not magically transport packets between the two, > despite the fact L3 has "reliable high-bandwidth connectivity to both > of those providers". How would you propose L3 bill UU & Sprint for > it? On second thought, don't answer that, I don't think it would be a > useful discussion. You have to admit that it's probably a very tempting concept for some L3 beancounter, unless the resulting UU<-L3->Sprint firehose is too big for L3's core to drink from... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081104/af7f8c29/attachment.bin> From LarrySheldon at cox.net Tue Nov 4 12:45:20 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 04 Nov 2008 12:45:20 -0600 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <5559A8A3-60C8-4692-BDBD-2D5B990EABB4@ianai.net> References: <MDEHLPKNGKAHNMBLJOLKIEHFAOAD.davids@webmaster.com> <5559A8A3-60C8-4692-BDBD-2D5B990EABB4@ianai.net> Message-ID: <49109840.5020204@cox.net> Patrick W. Gilmore wrote: >> From a technical standpoint, the Internet is always suffering from >> multiple >> political failures. This leaves it vulnerable to small technical >> failures it >> could otherwise route around. > > See above. I do not think it is a "political failure" that I do not > give you free transit. We3 have, I think, a reality failure. The terminology comes from ARP and UUCP days. The reality comes from today, where traffic flows, as a maximum, between nodes that think there is something it for them to allow it to flow. If a packet has evidence of "fare paid" flows. End of story. The difference between "peer" and "transit is the coin used to pay the fare. From lowen at pari.edu Tue Nov 4 13:39:15 2008 From: lowen at pari.edu (Lamar Owen) Date: Tue, 4 Nov 2008 14:39:15 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <8EB0179B-DB38-479D-9C40-962758C0C2D0@ianai.net> References: <MDEHLPKNGKAHNMBLJOLKIEHFAOAD.davids@webmaster.com> Message-ID: <200811041439.15562.lowen@pari.edu> On Tuesday 04 November 2008 11:55:01 Patrick W. Gilmore wrote: > On Nov 4, 2008, at 11:51 AM, Tomas L. Byrnes wrote: > > The concept of "Transit Free" is a political failure, not a technical > > one. > We disagree. [snip] > So I guess you could say the current situation is a political success. I would say a 'qualified' political success. Like most other political solutions to technical problems, the concept of transit-free (and even the differentiation between transit and settlement-free peering) is a best-effort compromise, and works pretty well under most circumstances. But, which is worse: a completely 100% reachable Internet* with massive transit congestion that is massively expensive or the current partitionable Internet* that actually works and is affordable? Note: * There is no such thing as a 100% reachable 'Internet,' just a tangled lattice of interconnections of autonomous systems who provide best-effort interconnections. To what extent there IS an 'Internet' changes every second. From lowen at pari.edu Tue Nov 4 13:39:55 2008 From: lowen at pari.edu (Lamar Owen) Date: Tue, 4 Nov 2008 14:39:55 -0500 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: <63ac96a50811011700h441a411et5785986f6ae5f9fa@mail.gmail.com> References: <ba6c08fd0811010320u5b9cef52o8dc8936f19ef6fc8@mail.gmail.com> Message-ID: <200811041439.55398.lowen@pari.edu> On Saturday 01 November 2008 20:00:46 Matthew Petach wrote: > Unfortunately, as I'm sure you're all too aware, for public companies, it's > very hard to get away with saying "I was doing what was right for the > Internet, not what would make my business the most money" at a > shareholder meeting, or during an earning's call with Wall Street > analysts; they tend to be very unforgiving of actions that aren't in > line with the short-term profit-making goal, to the point where CEOs > have been ousted and class-action lawsuits threatened when it > seems the actions being taken weren't geared to optimize profits > for the shareholders. The next Great Compromise could be over multihoming of endusers (whether the enduser is a content consumer or a content provider is irrelevant; IP at Layer 3 is peer-to-peer anyway, between end systems). After all, if providers are not willing to 'budge' a little 'for the good of the Internet' then why should endusers reduce or give up multihoming aspirations 'for the good of the Internet?' After all, if access to the 'Internet' is a metric for making money, and money is being lost by access to content consumers being cut due to depeering events outside the enduser's control, then it makes business sense for an enduser to multihome, to bring connectivity events closer to the enduser's control. Want to prevent multihoming exploding routing tables? Prevent the desire to multihome by limiting 'partitioning' events. From charles at thewybles.com Tue Nov 4 14:13:31 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 04 Nov 2008 12:13:31 -0800 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: <200811041439.55398.lowen@pari.edu> References: <ba6c08fd0811010320u5b9cef52o8dc8936f19ef6fc8@mail.gmail.com> <200811041439.55398.lowen@pari.edu> Message-ID: <4910ACEB.8090205@thewybles.com> Lamar Owen wrote: > On Saturday 01 November 2008 20:00:46 Matthew Petach wrote: > >> Unfortunately, as I'm sure you're all too aware, for public companies, it's >> very hard to get away with saying "I was doing what was right for the >> Internet, not what would make my business the most money" at a >> shareholder meeting, or during an earning's call with Wall Street >> analysts; they tend to be very unforgiving of actions that aren't in >> line with the short-term profit-making goal, to the point where CEOs >> have been ousted and class-action lawsuits threatened when it >> seems the actions being taken weren't geared to optimize profits >> for the shareholders. >> > > The next Great Compromise could be over multihoming of endusers (whether the > enduser is a content consumer or a content provider is irrelevant; IP at > Layer 3 is peer-to-peer anyway, between end systems). After all, if > providers are not willing to 'budge' a little 'for the good of the Internet' > then why should endusers reduce or give up multihoming aspirations 'for the > good of the Internet?' > > After all, if access to the 'Internet' is a metric for making money, and money > is being lost by access to content consumers being cut due to depeering > events outside the enduser's control, then it makes business sense for an > enduser to multihome, to bring connectivity events closer to the enduser's > control. Want to prevent multihoming exploding routing tables? Prevent the > desire to multihome by limiting 'partitioning' events. > So now I'm going to join Randy and say this is rehashing. We know the "interwebz" are a collection of AS. We know they can partition at any time. We know that certain players have a history of causing this to happen more then others. What I haven't seen discussed in any great detail, is how to limit those events. Some are asking for regulation. Ok. What will that regulation look like? As the technical network operations community, what do we want to see? What stipulations etc? Are a few interruptions that affect a small subset of IP addresses and AS on the net really worth going through the effort to pass regulation around the world? If so, then let's take advantage of a long and rich history of reaching consensus (see the RFC process which I think has work pretty well) and hash out what we want to see. Otherwise let's move on. Charles From dholmes at mwdh2o.com Tue Nov 4 14:13:35 2008 From: dholmes at mwdh2o.com (Holmes,David A) Date: Tue, 4 Nov 2008 12:13:35 -0800 Subject: Metro Ethernet Multicast Support Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E07D48A61@usmsxt104.mwd.h2o> The Metro Ethernet Forum (MEF) MEF10-1 ELAN multipoint-to-multipoint specification says that multicast packets must be replicated out all ports in the ELAN, except the ingress port. Some carriers have taken this literally and built a virtual ELAN service emulating a 1990's style hub in which all multicast packets are replicated out all ports regardless of the L3 multicast routing protocol in use. In the case of PIM sparse mode real physical Ethernet switches use IGMP snooping to construct a directed path through the switch fabric, so that a given established multicast stream is forwarded just like a directed unicast connection with mac/port table entries establishing a single path through the L2 fabric, and no flooding is done. Some carriers flood directed multicast traffic out all ELAN ports even though a single path should be taken. In networks with a large number of directed multicast streams, flooding out all ports uses unnecessary bandwidth, sometimes rendering a 10 Mb port useless due to oversubscription caused by this unnecessary flooding. Can anyone suggest a carrier MEF ELAN multipoint-to-multipoint service that does not flood established directed PIM sparse mode streams? From charles at thewybles.com Tue Nov 4 14:32:11 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 04 Nov 2008 12:32:11 -0800 Subject: On the subject of multihoming Message-ID: <4910B14B.9010108@thewybles.com> I'm working on a small experiment which utilizes multiple outbound links (in the experiments case multiple consumer 3G connections [to 2 Sprint/2 Verizon/1 AT&T], Time Warner Cable Modem and an SBC Global DSL connection. What is the best way to do outbound traffic engineering? I would like to be able to determine the best path possible and send traffic out the appropriate link. Could this be done with a copy of the BGP tables? Obviously as they are consumer connections, I wouldn't get a BGP feed so would need to download a copy, which has the risk of stale data. Perhaps some sort of multihop BGP setup? I have done some research and found a lot of references to small site multihoming without BGP for link redundancy but not for traffic engineering. Thanks. Charles From karnaugh at karnaugh.za.net Tue Nov 4 14:47:18 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Tue, 04 Nov 2008 22:47:18 +0200 Subject: On the subject of multihoming In-Reply-To: <4910B14B.9010108@thewybles.com> References: <4910B14B.9010108@thewybles.com> Message-ID: <4910B4D6.4060302@karnaugh.za.net> On 2008/11/04 10:32 PM Charles Wyble wrote: > Obviously as they are consumer connections, I wouldn't get a BGP feed so > would need to download a copy, which has the risk of stale data. Perhaps > some sort of multihop BGP setup? > > I have done some research and found a lot of references to small site > multihoming without BGP for link redundancy but not for traffic > engineering. I've played with that before. Essentially just EBGP Multi-hop with next-hop rewrites on various community prefixes. Of course I had access to a donor feed, that is probably the largest hurdle. There is good use in general for a public no-distribute feed but I have yet to find such a thing. Is there a reason for that, or could I bribe my datacenter to give me a feed and then create my own public server with some el-cheapo Quagga and a bag of rainbows for hope? From devangnp at gmail.com Tue Nov 4 14:53:46 2008 From: devangnp at gmail.com (devang patel) Date: Tue, 4 Nov 2008 14:53:46 -0600 Subject: MPLS for IPv6 Message-ID: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> Hi, Does any vendor support the MPLS for native IPv6 network? I was working on one testing scenario where I have Cisco 7200 routers and whole network is running only IPv6 and I wanted to run MPLS on the top of that but I found MPLS is not supported on IPv6 networks? is that true? regards Devang Patel From charles at thewybles.com Tue Nov 4 15:04:32 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 04 Nov 2008 13:04:32 -0800 Subject: On the subject of multihoming In-Reply-To: <4910B4D6.4060302@karnaugh.za.net> References: <4910B14B.9010108@thewybles.com> <4910B4D6.4060302@karnaugh.za.net> Message-ID: <4910B8E0.4030703@thewybles.com> Colin Alston wrote: > On 2008/11/04 10:32 PM Charles Wyble wrote: >> Obviously as they are consumer connections, I wouldn't get a BGP feed >> so would need to download a copy, which has the risk of stale data. >> Perhaps some sort of multihop BGP setup? >> >> I have done some research and found a lot of references to small site >> multihoming without BGP for link redundancy but not for traffic >> engineering. > > I've played with that before. Essentially just EBGP Multi-hop with > next-hop rewrites on various community prefixes. Of course I had > access to a donor feed, that is probably the largest hurdle. My first job was at a place with a direct ARIN allocation and BGP to Sprint and AT&T. I'm still friends with the remaining ops person and can probably setup a peering session with him. I also have another buddy with the ability to do BGP via Cogent. > > There is good use in general for a public no-distribute feed but I > have yet to find such a thing. Is there a reason for that, or could I > bribe my datacenter to give me a feed and then create my own public > server with some el-cheapo Quagga and a bag of rainbows for hope? Good question. Perhaps I could peer with my above mentioned sources and http://www.quagga.net/route-server.php or http://www.routeviews.org/ (config instructions at http://www.routeviews.org/config.html) That would be a fairly diverse set of views and hopefully sufficient for my needs. By the way I have a wiki page up with the details (more or less what I outlined already) at http://www.socalwifi.net/index.php/Mesh_Experiment I will write everything up there as well as post back results here. From Gregori.Parker at theplatform.com Tue Nov 4 15:07:13 2008 From: Gregori.Parker at theplatform.com (Gregori Parker) Date: Tue, 4 Nov 2008 13:07:13 -0800 Subject: diverse multisite advertising? Message-ID: <1A9866F953006D45AEE0166066114E091410ECE6@TPMAIL02.corp.theplatform.com> I've been reading up on BGP and asking around, but still havent found a hard yes/no on this...hopefully someone here can provide clarification. If I have a single ASN and an IP allocation from ARIN, can I advertise one half of my prefix from one site and the other half from another distinct non-connected site using the same ASN? If so, are there implications with mutihoming to all unique ISPs (2 per location)? I seem to remember that an AS Path wouldnt be valid with the same AS appearing more than once in non-sequential order, i.e. at the beginning and the end in this case, but am unable to verify since everything I've been reading up on discusses BGP in single-site terms. Thanks in advance, Gregori From nanog-post at rsuc.gweep.net Tue Nov 4 15:15:08 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 4 Nov 2008 16:15:08 -0500 Subject: diverse multisite advertising? In-Reply-To: <1A9866F953006D45AEE0166066114E091410ECE6@TPMAIL02.corp.theplatform.com> References: <1A9866F953006D45AEE0166066114E091410ECE6@TPMAIL02.corp.theplatform.com> Message-ID: <20081104211508.GA42816@gweep.net> On Tue, Nov 04, 2008 at 01:07:13PM -0800, Gregori Parker wrote: > I've been reading up on BGP and asking around, but still havent found a > hard yes/no on this...hopefully someone here can provide clarification. > > If I have a single ASN and an IP allocation from ARIN, can I advertise > one half of my prefix from one site and the other half from another > distinct non-connected site using the same ASN? If so, are there > implications with mutihoming to all unique ISPs (2 per location)? You can do a lot of things. If you want to do it is a matter related to what kind of network you run and what your goals are. > I seem to remember that an AS Path wouldnt be valid with the same AS > appearing more than once in non-sequential order, i.e. at the beginning > and the end in this case, but am unable to verify since everything I've > been reading up on discusses BGP in single-site terms. Your largest concerns will be - how do intend your split sites see each other? GRE/IPSec tunnels are a popular if potentially fragile answer. - deaggregating is antisocial, and depending on your allocation size & in what part of the bit-spectrum it lies, you may need to be concerned about the deaggregates getting filtered. Assuming a decent answer to the first point and you can 'safely' announce the aggregate in both spots to attrach traffic beyind the propagation distance of your deaggregates. You may wish to consider having the same set of providers in each location and examining approaches that make your interior appear more coherent than it is [eg deaggregates with sane MEDS and no-export to allow you to TE across your paid links, and only let the aggregate out past their borders]. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From charles at thewybles.com Tue Nov 4 15:19:59 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 04 Nov 2008 13:19:59 -0800 Subject: MPLS for IPv6 In-Reply-To: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> Message-ID: <4910BC7F.2010003@thewybles.com> devang patel wrote: > Hi, > > Does any vendor support the MPLS for native IPv6 network? > I think the bigger question is what vendors support native IPv6 networks and at what stage of maturity. :) > I was working on one testing scenario where I have Cisco 7200 routers and > whole network is running only IPv6 and I wanted to run MPLS on the top of > that but I found MPLS is not supported on IPv6 networks? is that true? > What sort of environment was this in? A lab environment? Or over a vendors network? http://www.google.com/search?q=ipv6+mpls&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a might be of interest. > regards > Devang Patel > > From charles at thewybles.com Tue Nov 4 15:24:08 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 04 Nov 2008 13:24:08 -0800 Subject: MPLS for IPv6 In-Reply-To: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> Message-ID: <4910BD78.4020409@thewybles.com> devang patel wrote: > Hi, > > Does any vendor support the MPLS for native IPv6 network? > I was working on one testing scenario where I have Cisco 7200 routers and > whole network is running only IPv6 and I wanted to run MPLS on the top of > that but I found MPLS is not supported on IPv6 networks? is that true? > > http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-over_mpls_ps6922_TSD_Products_Configuration_Guide_Chapter.html would say it's possible. However (I'm not an expert at MPLS so forgive me if I'm wrong) isn't MPLS at a lower level and you run IP on top of it? That seems to be what initial research indicates. See the NANOG talk archives for lots of MPLS presentations. From surfer at mauigateway.com Tue Nov 4 15:32:58 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 4 Nov 2008 13:32:58 -0800 Subject: diverse multisite advertising? Message-ID: <20081104133258.4FF0BFCA@resin09.mta.everyone.net> --- Gregori.Parker at theplatform.com wrote: From: "Gregori Parker" <Gregori.Parker at theplatform.com> If I have a single ASN and an IP allocation from ARIN, can I advertise one half of my prefix from one site and the other half from another distinct non-connected site using the same ASN? If so, are there implications with mutihoming to all unique ISPs (2 per location)? ---------------------------------------------- You can find all the details in the NANOG archives. This has been covered many times in grueling detail. scott From kris.foster at gmail.com Tue Nov 4 15:18:47 2008 From: kris.foster at gmail.com (kris foster) Date: Tue, 4 Nov 2008 13:18:47 -0800 Subject: [NANOG-announce] The new NANOG Mailing List Committee Message-ID: <35C5602E-A2B1-42C9-8C29-CF2C6A461CA4@gmail.com> Hi everyone The Steering Committee has selected new Mailing List Committee members. We would like to thank our outgoing member David Barak for all of his work over the last two years. The MLC members and their term lengths are: Randy Epstein - 11 / 2010 Kris Foster - 11 / 2009 Sue Joiner - Merit appointee Simon Lyall - 11 / 2009 Tim Yocum - 11 / 2010 Thank you to everyone who put their names forward to volunteer! Sincerely Kris Foster Mailing List Committee Chair _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From devangnp at gmail.com Tue Nov 4 15:39:36 2008 From: devangnp at gmail.com (devang patel) Date: Tue, 4 Nov 2008 15:39:36 -0600 Subject: MPLS for IPv6 In-Reply-To: <4910BC7F.2010003@thewybles.com> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> <4910BC7F.2010003@thewybles.com> Message-ID: <d0fea3580811041339j71356173h6aa3f6f6898eb6b1@mail.gmail.com> Hi, Its lab environment, just created one topology having few routers and testing it for MPLS VPN for IPv6!!! the thing is enabling MPLS on interface having IPv6 address will not bring up LDP neighbor relationship, and due to that it will not assign the MPLS label to the prefixes!!! so I just want to get information about the same!!! It was suprising me when I was going to the configuration and verification!!! regards Devang Patel On Tue, Nov 4, 2008 at 3:19 PM, Charles Wyble <charles at thewybles.com> wrote: > devang patel wrote: > >> Hi, >> >> Does any vendor support the MPLS for native IPv6 network? >> >> > > I think the bigger question is what vendors support native IPv6 networks > and at what stage > of maturity. :) > >> I was working on one testing scenario where I have Cisco 7200 routers and >> whole network is running only IPv6 and I wanted to run MPLS on the top of >> that but I found MPLS is not supported on IPv6 networks? is that true? >> >> > What sort of environment was this in? A lab environment? Or over a vendors > network? > > > http://www.google.com/search?q=ipv6+mpls&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-amight be of interest. > >> regards >> Devang Patel >> >> >> > > From charles at thewybles.com Tue Nov 4 15:44:41 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 04 Nov 2008 13:44:41 -0800 Subject: On the subject of multihoming In-Reply-To: <4910B8E0.4030703@thewybles.com> References: <4910B14B.9010108@thewybles.com> <4910B4D6.4060302@karnaugh.za.net> <4910B8E0.4030703@thewybles.com> Message-ID: <4910C249.4040509@thewybles.com> Charles Wyble wrote: > Colin Alston wrote: >> On 2008/11/04 10:32 PM Charles Wyble wrote: >>> Obviously as they are consumer connections, I wouldn't get a BGP >>> feed so would need to download a copy, which has the risk of stale >>> data. Perhaps some sort of multihop BGP setup? >>> >>> I have done some research and found a lot of references to small >>> site multihoming without BGP for link redundancy but not for traffic >>> engineering. >> >> I've played with that before. Essentially just EBGP Multi-hop with >> next-hop rewrites on various community prefixes. Of course I had >> access to a donor feed, that is probably the largest hurdle. > > My first job was at a place with a direct ARIN allocation and BGP to > Sprint and AT&T. I'm still friends with the remaining ops person and > can probably setup a peering session with him. I also have another > buddy with the ability to do BGP via Cogent. > >> >> There is good use in general for a public no-distribute feed but I >> have yet to find such a thing. Is there a reason for that, or could I >> bribe my datacenter to give me a feed and then create my own public >> server with some el-cheapo Quagga and a bag of rainbows for hope? > > Good question. Perhaps I could peer with my above mentioned sources and > http://www.quagga.net/route-server.php or http://www.routeviews.org/ > (config instructions at http://www.routeviews.org/config.html) > > That would be a fairly diverse set of views and hopefully sufficient > for my needs. > > By the way I have a wiki page up with the details (more or less what I > outlined already) at http://www.socalwifi.net/index.php/Mesh_Experiment > > I will write everything up there as well as post back results here. > > So changing my search terms a bit to utilizing bgp feeds outbound traffic engineering, returns http://www.caida.org/workshops/isma/0210/ISMAagenda.xml which seems to be near what I want. It certainly provides some interesting reading and ways to measure / analyze the necessary data. From deepak at ai.net Tue Nov 4 16:16:35 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 4 Nov 2008 17:16:35 -0500 Subject: diverse multisite advertising? In-Reply-To: <20081104211508.GA42816@gweep.net> References: <1A9866F953006D45AEE0166066114E091410ECE6@TPMAIL02.corp.theplatform.com> <20081104211508.GA42816@gweep.net> Message-ID: <D338D1613B32624285BB321A5CF3DB250C6A717A15@ginga.ai.net> > I seem to remember that an AS Path wouldnt be valid with the same AS > appearing more than once in non-sequential order, i.e. at the beginning > and the end in this case, but am unable to verify since everything I've > been reading up on discusses BGP in single-site terms. Your largest concerns will be - how do intend your split sites see each other? GRE/IPSec tunnels are a popular if potentially fragile answer. - deaggregating is antisocial, and depending on your allocation size & in what part of the bit-spectrum it lies, you may need to be concerned about the deaggregates getting filtered. Assuming a decent answer to the first point and you can 'safely' announce the aggregate in both spots to attrach traffic beyind the propagation distance of your deaggregates. You may wish to consider having the same set of providers in each location and examining approaches that make your interior appear more coherent than it is [eg deaggregates with sane MEDS and no-export to allow you to TE across your paid links, and only let the aggregate out past their borders]. --- That is really a great, concise answer. If you don't know enough about BGP to understand everything Joe is saying here, you may need help doing it right. Basically what your risk factors are is even if someone said "yes, this is fine." It will probably break somewhere and under some circumstances. And if someone says "no, this won't," you are still faced with joe's first "largest concerns". Deepak From dr at cluenet.de Tue Nov 4 16:36:37 2008 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 4 Nov 2008 23:36:37 +0100 Subject: MPLS for IPv6 In-Reply-To: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> Message-ID: <20081104223637.GA16085@srv03.cluenet.de> On Tue, Nov 04, 2008 at 02:53:46PM -0600, devang patel wrote: > Does any vendor support the MPLS for native IPv6 network? Unfortunately noone of the major vendors have yet implemented MPLS control plane via IPv6 transport. From my understanding, the protocol specs are there, just no implementation. So for now, you still have to use IPv4 for the MPLS network control plane and must either forward IPv6 natively dual-stack alongside IPv4, or transport IPv6 via 6(V)PE. "no customer demand", as usual. It's just us weirdos trying to do such things. :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From mpetach at netflight.com Tue Nov 4 16:40:15 2008 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 4 Nov 2008 14:40:15 -0800 Subject: On the subject of multihoming In-Reply-To: <4910B4D6.4060302@karnaugh.za.net> References: <4910B14B.9010108@thewybles.com> <4910B4D6.4060302@karnaugh.za.net> Message-ID: <63ac96a50811041440r55756631j691928151c3b60d1@mail.gmail.com> On 11/4/08, Colin Alston <karnaugh at karnaugh.za.net> wrote: > There is good use in general for a public no-distribute feed but I have yet > to find such a thing. Is there a reason for that answering that question is easy. Yes, there are a number of reasons that nobody provides one: 1) most people don't want the details of their internal routing policies known to outside entities. Perhaps I pay Level3 for routes, but don't want the rest of the world to know it; if I provide a BGP feed, unless I very carefully sanitize it before it goes out, it will become clear to people outside that there are prefixes seen across the path that would not be seen by an ordinary peer. 2) It requires careful filtering to ensure that nobody recieving the feed accidentally or intentionally uses the routing information in their forwarding table without altering next-hops as appropriate; nobody wants to end up carrying unexpected traffic. 3) Requires ongoing support personnel to maintain and keep it up and running; while not a huge cost, it nonetheless presents a continuous, residual drain on resources that few companies are willing to underwrite 4) It would be of limited value, unless it covers a relatively large swath of the Internet with relatively good splay; having a BGP feed that simply shows a default route from your upstream's upstream's upstream wouldn't really give much useful data to work with. 5) Much of the data is already available with a bit of delay from RIS/RIPE and routeviews; unless you really need the real-time aspect, you might as well just get the data from there. > or could I bribe my > datacenter to give me a feed and then create my own public server with some > el-cheapo Quagga and a bag of rainbows for hope? I'd recommend OpenBGPd -- it's been scaling much better for me, and converges about 8 times faster than Quagga on the internal route collectors I run. Matt From lowen at pari.edu Tue Nov 4 17:11:57 2008 From: lowen at pari.edu (Lamar Owen) Date: Tue, 4 Nov 2008 18:11:57 -0500 Subject: Sending vs requesting. Was: Re: Sprint / Cogent Message-ID: <7973299.7271225840317649.JavaMail.root@scalix.pari.edu> Charles Wyble charles at thewybles.com wrote: > We know they can partition at any time. > We know that certain players have a history of causing this to happen > more then others. > What I haven't seen discussed in any great detail, is how to limit those > events. There are three ways that I know of (feel free to add to this list) to limit the events: 1.) As you mentioned, regulation (or a government run and regulated backbone); 2.) Economic pressures of a free market (cause event, lose customers or cause customers to multihome, thus costing you upgrade money; or other market 'pressures' a la the recent Intercage Capers); 3.) 'For the good of the Internet!' I would much prefer option 2 since regulation is too easy to mess up, and option 3's realistic chances of occurring are slim to none, and Slim done left town. Unless operators really want unfunded yet mandated peering arrangements. Or a return to a government (mix of state and federal) funded backbone a la NSFnet or ARPAnet with mandated (but unfunded, of course) open peering to all Tier 1 (TM) providers on the planet. Something like CATV must-carry rules (47 CFR 76.51 through 76.70). Hah! If you will indulge me a flight of hyperbole for a few moments, I wonder if, perhaps, an extension of 47 CFR 51.701 through 51.717 to cover NSPs would be considered. The FCC might not even need extra regulatory authority from an amendment to the Communications Act of 1934, as amended, to put IP carriers under 47 CFR 51, and it is, relatively speaking, fairly straightforward reading. Costs the FCC a lot less to change existing regulations than to write new ones, too, and falls under an existing Bureau. Operators really would not want this, I would think, as then things can get really complicated really qickly (read the broadcast radio and television regulations in 47 CFR 73, especially something technically specific like 47 CFR 73.186 for an idea of how cumbersome things CAN be made on the technical side). Endusers who just want the thing to work would be all over it. The FCC certainly has the technical expertise in-house to write regs to deal with it. The Commission would issue an NPRM, gather comments and reply comments, issue maybe an FNPRM or three, gather comments and reply comments, mull over it for five years or more, and then issue an R&O that very few will want (at least this is what happened with AM Stereo, HD Radio, and Digital Television). People will file objections to the R&O, the process will churn for a while, maybe with an FR&O, etc. Welcome to the world of regulation. The RFC process is a model of streamlining compared to anything before the Commission. Hmm, on the other hand, maybe that's not hyperbole after all. You and Randy are both right; this issue gets rehashed a lot (this is most certainly far from the first time I've seen the discussion pass by). But the reason it keeps coming up is because it is a real problem, and it hasn't been fixed by the people who can fix it, if they will, without getting the cumbersome beast called regulation into play. From Alex.Campbell at ogilvy.com.au Tue Nov 4 17:20:36 2008 From: Alex.Campbell at ogilvy.com.au (Campbell, Alex) Date: Wed, 5 Nov 2008 10:20:36 +1100 Subject: AT&T routing issue Message-ID: <571885DA209DEA4882A4AE663517EEE403170095@melexch1.stwgroup.net.au> Hi all, We have recently brought up some BGP sessions with a new provider, and have found that we can get end to end connectivity through the new provider to pretty much everywhere except networks behind AT&T (AS7018). We are able to see our routes in AT&T's route server, but all traceroutes from our network to hosts behind 7018 stop at AT&T's border. We are multihomed, so I've local-prefed up our secondary ISP and the problem resolves immediately. Our upstream (AS9443) and their upstream (AS11867) have been chasing this up with AT&T for a couple of days, but don't seem to have had made much progress. Does anyone have any suggestions as to what could be causing this, or a contact at AT&T who might be able to assist? Thanks, Alex From nanog at daork.net Tue Nov 4 17:45:55 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 5 Nov 2008 12:45:55 +1300 Subject: MPLS for IPv6 In-Reply-To: <20081104223637.GA16085@srv03.cluenet.de> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> <20081104223637.GA16085@srv03.cluenet.de> Message-ID: <3D3B5096-8F3D-4EBD-9335-547E99F68DEA@daork.net> On 5/11/2008, at 11:36 AM, Daniel Roesen wrote: > On Tue, Nov 04, 2008 at 02:53:46PM -0600, devang patel wrote: >> Does any vendor support the MPLS for native IPv6 network? > > Unfortunately noone of the major vendors have yet implemented MPLS > control plane via IPv6 transport. From my understanding, the protocol > specs are there, just no implementation. > > So for now, you still have to use IPv4 for the MPLS network control > plane and must either forward IPv6 natively dual-stack alongside IPv4, > or transport IPv6 via 6(V)PE. > > "no customer demand", as usual. It's just us weirdos trying to do such > things. :) Correct, LDP etc. must all be done at IPv4. That can do the MPLS label bits, and IPv6 can then be carried inside MPLS. If you use 10.0.0.0/8 for numbering your point to point links, you get 4-8M links, dependant on whether you do /30 or /31. I don't imagine that represents a problem for many people. -- Nathan Ward From charles at thewybles.com Tue Nov 4 17:52:37 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 04 Nov 2008 15:52:37 -0800 Subject: Sending vs requesting. Was: Re: Sprint / Cogent In-Reply-To: <7973299.7271225840317649.JavaMail.root@scalix.pari.edu> References: <7973299.7271225840317649.JavaMail.root@scalix.pari.edu> Message-ID: <4910E045.5020709@thewybles.com> Lamar Owen wrote: > Charles Wyble charles at thewybles.com wrote: > >> We know they can partition at any time. >> We know that certain players have a history of causing this to happen >> more then others. >> > > >> What I haven't seen discussed in any great detail, is how to limit those >> events. >> > > There are three ways that I know of (feel free to add to this list) to limit the events: > 1.) As you mentioned, regulation (or a government run and regulated backbone); > Right. But what do we want this to look like? > 2.) Economic pressures of a free market (cause event, lose customers or cause customers to multihome, thus costing you upgrade money; or other market 'pressures' a la the recent Intercage Capers); > Mmhmm. That is what we have now right? I think it's worked well enough to avoid the need for regulation and hopefully it will continue to do so. > 3.) 'For the good of the Internet!' > > I would much prefer option 2 since regulation is too easy to mess up, As would I and it seems the rest of the community does as well. > and option 3's realistic chances of occurring are slim to none, and Slim done left town. > LOL. :) > <snip verbage about some existing law> > Hmmmm. I need to read that over. Thank you for the reference. > > Endusers who just want the thing to work would be all over it. The FCC certainly has the technical expertise in-house to write regs to deal with it. The Commission would issue an NPRM, gather comments and reply comments, issue maybe an FNPRM or three, gather comments and reply comments, mull over it for five years or more, and then issue an R&O that very few will want (at least this is what happened with AM Stereo, HD Radio, and Digital Television). People will file objections to the R&O, the process will churn for a while, maybe with an FR&O, etc. Welcome to the world of regulation. The RFC process is a model of streamlining compared to anything before the Commission. Hmm, on the other hand, maybe that's not hyperbole after all. > Very well thought out comments Lamar. Thank you for taking the time to share them. I think the current whitespace debate is a good example of what you outlined in the above paragraph. > > You and Randy are both right; this issue gets rehashed a lot (this is most certainly far from the first time I've seen the discussion pass by). But the reason it keeps coming up is because it is a real problem, and it hasn't been fixed by the people who can fix it, if they will, without getting the cumbersome beast called regulation into play. > Naturally. Now I have something to look at and see how I like it and if I would want to suggest extending the coverage of that regulation. I presume others on the list will want to look at it as well, if they weren't already aware of it. If anyone has evaluated it, I would be interested in hearing your thoughts on the law and how it might apply to the net. From tomb at byrneit.net Tue Nov 4 18:09:43 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 4 Nov 2008 16:09:43 -0800 Subject: FW: Sprint v. Cogent, some clarity & facts Message-ID: <70D072392E56884193E3D2DE09C097A9F8A3@pascal.zaphodb.org> -----Original Message----- From: Tomas L. Byrnes Sent: Tuesday, November 04, 2008 4:08 PM To: 'Niels Bakker' Subject: RE: Sprint v. Cogent, some clarity & facts There was nothing in my post advocating free transit or peering. I merely pointed out that peering only without downstream propagation was a technical error, based on the proper implementation of the protocols as designed. All the discussion of practicality and politics are implementation failures: the first because of crappy routers, the second because of the established player issue you called out. We've all had enough of crappy networks causing unreachability. >-----Original Message----- >From: Niels Bakker [mailto:niels=nanog at bakker.net] >Sent: Tuesday, November 04, 2008 9:30 AM >To: nanog at nanog.org >Subject: Re: Sprint v. Cogent, some clarity & facts > >* tomb at byrneit.net (Tomas L. Byrnes) [Tue 04 Nov 2008, 17:51 CET]: >>The concept of "Transit Free" is a political failure, not a technical >>one. > >Yeah, networks should be free! And Cogent, if they don't get access to >Sprint directly, should just set a default route over some public IX >where Sprint is also present at to reach their network!! And then hack >their routers to do likewise. > > >>The protocols are designed, and the original concept behind the >Internet >>is, to propagate all reachability via all paths. IE to use Transit if >>peering fails. > >Yeah, the original concept of the internet. Like classful IP routing. > > >>Not doing so is a policy decision that breaks the redundancy in the >>original design. > >Because the original design totally had in mind established players >locking out cheaper newcomers and explicitly specified a maximum band >where prices for transit had to exist inside of. > >Please stop it. We've had enough. > > > -- Niels. > >-- >"We humans get marks for consistency. We always opt for > civilization after exhausting the alternatives." > -- Carl Guderian > From nanog at daork.net Tue Nov 4 18:15:44 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 5 Nov 2008 13:15:44 +1300 Subject: Metro Ethernet Multicast Support In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E07D48A61@usmsxt104.mwd.h2o> References: <485ED9BA02629E4BBBA53AC892EDA50E07D48A61@usmsxt104.mwd.h2o> Message-ID: <B61234B7-C96B-464C-BAF2-1B7972A38D71@daork.net> On 5/11/2008, at 9:13 AM, Holmes,David A wrote: > The Metro Ethernet Forum (MEF) MEF10-1 ELAN multipoint-to-multipoint > specification says that multicast packets must be replicated out all > ports in the ELAN, except the ingress port. Some carriers have taken > this literally and built a virtual ELAN service emulating a 1990's > style > hub in which all multicast packets are replicated out all ports > regardless of the L3 multicast routing protocol in use. In the case of > PIM sparse mode real physical Ethernet switches use IGMP snooping to > construct a directed path through the switch fabric, so that a given > established multicast stream is forwarded just like a directed unicast > connection with mac/port table entries establishing a single path > through the L2 fabric, and no flooding is done. Some carriers flood > directed multicast traffic out all ELAN ports even though a single > path > should be taken. In networks with a large number of directed multicast > streams, flooding out all ports uses unnecessary bandwidth, sometimes > rendering a 10 Mb port useless due to oversubscription caused by this > unnecessary flooding. > > Can anyone suggest a carrier MEF ELAN multipoint-to-multipoint service > that does not flood established directed PIM sparse mode streams? Are you looking for a vendor product, or a service? I'm not aware of any vendor products or services that do what you describe. However, I'd recommend perhaps a L3 VPN service with multicast support and pushing your mcast traffic down it, perhaps talk to your L2 service provider and see if they can provide you with this in parallel to your L2 service. -- Nathan Ward From tomb at byrneit.net Tue Nov 4 18:33:08 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 4 Nov 2008 16:33:08 -0800 Subject: On the subject of multihoming In-Reply-To: <4910B14B.9010108@thewybles.com> References: <4910B14B.9010108@thewybles.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F8A4@pascal.zaphodb.org> This sort of thing is usually done with some sort of multi-port outbound NAT device that chooses the source interface to NAT from based on some "quality" metric it generates for the destination, and a state table it keeps for all the outside IPs. Products that do this include FatPipe, Radware Linkproof, and Mushroom networks. >-----Original Message----- >From: Charles Wyble [mailto:charles at thewybles.com] >Sent: Tuesday, November 04, 2008 12:32 PM >To: NANOG list >Subject: On the subject of multihoming > >I'm working on a small experiment which utilizes multiple outbound links >(in the experiments case multiple consumer 3G connections [to 2 Sprint/2 >Verizon/1 AT&T], Time Warner Cable Modem and an SBC Global DSL >connection. > >What is the best way to do outbound traffic engineering? I would like to >be able to determine the best path possible and send traffic out the >appropriate link. > >Could this be done with a copy of the BGP tables? > >Obviously as they are consumer connections, I wouldn't get a BGP feed so >would need to download a copy, which has the risk of stale data. Perhaps >some sort of multihop BGP setup? > >I have done some research and found a lot of references to small site >multihoming without BGP for link redundancy but not for traffic >engineering. > > >Thanks. > >Charles > From cgucker at onesc.net Tue Nov 4 20:51:53 2008 From: cgucker at onesc.net (Charles Gucker) Date: Tue, 4 Nov 2008 21:51:53 -0500 Subject: AT&T routing issue In-Reply-To: <571885DA209DEA4882A4AE663517EEE403170095@melexch1.stwgroup.net.au> References: <571885DA209DEA4882A4AE663517EEE403170095@melexch1.stwgroup.net.au> Message-ID: <c85424b0811041851m6b3edac2q85c890938b9440b2@mail.gmail.com> On Tue, Nov 4, 2008 at 6:20 PM, Campbell, Alex <Alex.Campbell at ogilvy.com.au> wrote: > Hi all, > > > > We have recently brought up some BGP sessions with a new provider, and > have found that we can get end to end connectivity through the new > provider to pretty much everywhere except networks behind AT&T (AS7018). > > We are able to see our routes in AT&T's route server, but all > traceroutes from our network to hosts behind 7018 stop at AT&T's border. > We are multihomed, so I've local-prefed up our secondary ISP and the > problem resolves immediately. > > Our upstream (AS9443) and their upstream (AS11867) have been chasing > this up with AT&T for a couple of days, but don't seem to have had made > much progress. In short yes. AT&T uses a customer specific access list to perform a uRPF like function. That is, if your provider did not request for their provider to have AT&T update their filter. > Does anyone have any suggestions as to what could be causing this, or a > contact at AT&T who might be able to assist? Since you are experiencing this issue only when you send your traffic out (eventually though AT&T) it points to the inbound ACL on AT&T's border. I have been bitten by this too many times, especially when customers, or customers of customers don't properly inform the other of the new netblock. I would be curious to find out if the issue you are facing is specific with every network you are announcing or just one or two networks. As for who would assist, this request is suppose to go through: AT&T MIS Maintenance 888-613-6330 Prompt-3, 2 rm-awmis at ems.att.com charles From brian at meganet.net Tue Nov 4 21:05:46 2008 From: brian at meganet.net (Brian Wallingford) Date: Tue, 4 Nov 2008 22:05:46 -0500 (EST) Subject: AT&T routing issue In-Reply-To: <c85424b0811041851m6b3edac2q85c890938b9440b2@mail.gmail.com> References: <571885DA209DEA4882A4AE663517EEE403170095@melexch1.stwgroup.net.au> <c85424b0811041851m6b3edac2q85c890938b9440b2@mail.gmail.com> Message-ID: <Pine.GSO.4.58.0811042153210.21749@evccyr> :In short yes. AT&T uses a customer specific access list to perform a :uRPF like function. That is, if your provider did not request for :their provider to have AT&T update their filter. Indeed. We've used ATT MIS for many years and have been happy with their policies (which have blunted quite a few DDOS attacks), and their response to acl mod requests. They do tend to take longer than I'd like (on the order of several business days) for standard requests, though if you request expedition, response time is impressive. Overall, thumbs up. :AT&T MIS Maintenance :888-613-6330 Prompt-3, 2 :rm-awmis at ems.att.com Yep. Always quite responsive. As with any other vendor, if you feel the person handling the call isn't qualified, escalate. From Alex.Campbell at ogilvy.com.au Tue Nov 4 21:45:59 2008 From: Alex.Campbell at ogilvy.com.au (Campbell, Alex) Date: Wed, 5 Nov 2008 14:45:59 +1100 Subject: AT&T routing issue References: <571885DA209DEA4882A4AE663517EEE403170095@melexch1.stwgroup.net.au> <c85424b0811041851m6b3edac2q85c890938b9440b2@mail.gmail.com> <Pine.GSO.4.58.0811042153210.21749@evccyr> Message-ID: <571885DA209DEA4882A4AE663517EEE403170422@melexch1.stwgroup.net.au> Many thanks to all those who replied. It did turn out to be a filter that needed updating at 7018, which was very quickly fixed by their team. -----Original Message----- From: Brian Wallingford [mailto:brian at meganet.net] Sent: Wednesday, 5 November 2008 2:06 PM To: Charles Gucker Cc: Campbell, Alex; nanog at nanog.org Subject: Re: AT&T routing issue :In short yes. AT&T uses a customer specific access list to perform a :uRPF like function. That is, if your provider did not request for :their provider to have AT&T update their filter. Indeed. We've used ATT MIS for many years and have been happy with their policies (which have blunted quite a few DDOS attacks), and their response to acl mod requests. They do tend to take longer than I'd like (on the order of several business days) for standard requests, though if you request expedition, response time is impressive. Overall, thumbs up. :AT&T MIS Maintenance :888-613-6330 Prompt-3, 2 :rm-awmis at ems.att.com Yep. Always quite responsive. As with any other vendor, if you feel the person handling the call isn't qualified, escalate. From nelson.lai at indiatimes.com Sat Nov 1 22:59:54 2008 From: nelson.lai at indiatimes.com (Nelson Lai) Date: Sun, 2 Nov 2008 09:29:54 +0530 (IST) Subject: Why do some companies get depeered and some don't? Message-ID: <1647682233.259371225598394242.JavaMail.root@mbv2.indiatimes.com> What I mean is, how come networks like Teleglobe, Limelight, etc. don't get depeered by others, but Cogent does? I'm sure Cogent isn't the only one with bad ratios. -- Hyundai to launch the i20 in India. Catch the exclusive preview on ZigWheels.com http://www.zigwheels.com/b2cam/newsDetails.action?name=Emb11_20080731&path=/INDT/News/Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW From mike.lyon at gmail.com Wed Nov 5 01:35:20 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 4 Nov 2008 23:35:20 -0800 Subject: Why do some companies get depeered and some don't? In-Reply-To: <1647682233.259371225598394242.JavaMail.root@mbv2.indiatimes.com> References: <1647682233.259371225598394242.JavaMail.root@mbv2.indiatimes.com> Message-ID: <1b5c1c150811042335x1199afd4y194818632db34b4f@mail.gmail.com> Those with bad or uneven ratios then purchase transit and don't let themselves get depeered... On 11/1/08, Nelson Lai <nelson.lai at indiatimes.com> wrote: > What I mean is, how come networks like Teleglobe, Limelight, etc. don't get > depeered by others, but Cogent does? I'm sure Cogent isn't the only one with > bad ratios. > > > -- > Hyundai to launch the i20 in India. Catch the exclusive preview on > ZigWheels.com > http://www.zigwheels.com/b2cam/newsDetails.action?name=Emb11_20080731&path=/INDT/News/Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW > > -- Sent from my mobile device From blakjak at blakjak.net Wed Nov 5 03:15:51 2008 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 5 Nov 2008 22:15:51 +1300 (NZDT) Subject: Why do some companies get depeered and some don't? In-Reply-To: <1b5c1c150811042335x1199afd4y194818632db34b4f@mail.gmail.com> References: <1647682233.259371225598394242.JavaMail.root@mbv2.indiatimes.com> <1b5c1c150811042335x1199afd4y194818632db34b4f@mail.gmail.com> Message-ID: <Pine.LNX.4.62.0811052214160.13577@maverick.blakjak.net> I'm sure someone else must've seen it before. Surely even assymetric peering agreements are mutually beneficial... ISPs are also content providers, either directly or through their customers... peering is going to have a flow-on effect in terms of reducing the cost of offering content to the people you peer with too, right? Why all the focus on even or non-even-ness of up/down ratios in the first place? Mark. On Tue, 4 Nov 2008, Mike Lyon wrote: > Those with bad or uneven ratios then purchase transit and don't let > themselves get depeered... > > On 11/1/08, Nelson Lai <nelson.lai at indiatimes.com> wrote: >> What I mean is, how come networks like Teleglobe, Limelight, etc. don't get >> depeered by others, but Cogent does? I'm sure Cogent isn't the only one with >> bad ratios. >> >> >> -- >> Hyundai to launch the i20 in India. Catch the exclusive preview on >> ZigWheels.com >> http://www.zigwheels.com/b2cam/newsDetails.action?name=Emb11_20080731&path=/INDT/News/Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW >> >> > > -- > Sent from my mobile device > > From glen.kent at gmail.com Wed Nov 5 05:11:21 2008 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 5 Nov 2008 16:41:21 +0530 Subject: Ixia, Juniper going green? Message-ID: <92c950310811050311k4ef92e74nc347665b7fd8b43e@mail.gmail.com> http://www.lightreading.com/document.asp?doc_id=166871 I wonder what impact this would put on other vendors to turn down their power consumptions and turn, as Juniper and Ixia like to put it - Green! BTW, the specs are a little skewed because they're only measuring power consumption when the router is only forwarding traffic, i.e., there is no traffic going to CPU. Also any idea about the genesis of this ECR initiative (http://www.ecrinitiative.org/) and what their eventual goal is ? Glen From jasper at unleash.co.nz Wed Nov 5 05:14:06 2008 From: jasper at unleash.co.nz (Jasper Bryant-Greene) Date: Thu, 6 Nov 2008 00:14:06 +1300 Subject: Why do some companies get depeered and some don't? In-Reply-To: <Pine.LNX.4.62.0811052214160.13577@maverick.blakjak.net> References: <1647682233.259371225598394242.JavaMail.root@mbv2.indiatimes.com> <1b5c1c150811042335x1199afd4y194818632db34b4f@mail.gmail.com> <Pine.LNX.4.62.0811052214160.13577@maverick.blakjak.net> Message-ID: <A85C8BA1-A510-407D-ADF6-F0B4942D1BD0@unleash.co.nz> Isn't it because the receiver is more likely to backhaul the traffic further, due to hot-potato routing - at least in the case of large networks with multiple points of interconnect? -jasper On 5/11/2008, at 10:15 PM, Mark Foster <blakjak at blakjak.net> wrote: > I'm sure someone else must've seen it before. > > Surely even assymetric peering agreements are mutually beneficial... > ISPs are also content providers, either directly or through their > customers... peering is going to have a flow-on effect in terms of > reducing the cost of offering content to the people you peer with > too, right? > > Why all the focus on even or non-even-ness of up/down ratios in the > first place? > > Mark. > > On Tue, 4 Nov 2008, Mike Lyon wrote: > >> Those with bad or uneven ratios then purchase transit and don't let >> themselves get depeered... >> >> On 11/1/08, Nelson Lai <nelson.lai at indiatimes.com> wrote: >>> What I mean is, how come networks like Teleglobe, Limelight, etc. >>> don't get >>> depeered by others, but Cogent does? I'm sure Cogent isn't the >>> only one with >>> bad ratios. >>> >>> >>> -- >>> Hyundai to launch the i20 in India. Catch the exclusive preview on >>> ZigWheels.com >>> http://www.zigwheels.com/b2cam/newsDetails.action?name=Emb11_20080731&path=/INDT/News/Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW >>> >>> >> >> -- >> Sent from my mobile device >> >> > From eugen at imacandi.net Wed Nov 5 05:19:08 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 05 Nov 2008 13:19:08 +0200 Subject: routing around Sprint's depeering damage In-Reply-To: <87od0yxhkf.fsf@mid.deneb.enyo.de> References: <a3c2bd6c0811011659w61e20f1o73e4c749df44f1bb@mail.gmail.com> <490D64C3.9040207@rollernet.us> <87od0yxhkf.fsf@mid.deneb.enyo.de> Message-ID: <4911812C.1060906@imacandi.net> Florian Weimer wrote: > * Seth Mattinen: > >> 4. Multihome. > > Or get upstream from someone who does, and who is small enough to be > able to get additional upstream upon short notice. I know that this > solution isn't always cost-effective. 8-/ > > (Multihoming alone isn't a solution because it's hard to figure out > how independent your peering partners are.) > That's the easy part in the US: multihome with Verizon, Level3, Cogent, Sprint and AT&T :)) From patrick at ianai.net Wed Nov 5 09:05:55 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 5 Nov 2008 10:05:55 -0500 Subject: Why do some companies get depeered and some don't? In-Reply-To: <A85C8BA1-A510-407D-ADF6-F0B4942D1BD0@unleash.co.nz> References: <1647682233.259371225598394242.JavaMail.root@mbv2.indiatimes.com> <1b5c1c150811042335x1199afd4y194818632db34b4f@mail.gmail.com> <Pine.LNX.4.62.0811052214160.13577@maverick.blakjak.net> <A85C8BA1-A510-407D-ADF6-F0B4942D1BD0@unleash.co.nz> Message-ID: <71ABD316-EF78-4FF5-AA5D-AA0C7E4A3B15@ianai.net> On Nov 5, 2008, at 6:14 AM, Jasper Bryant-Greene wrote: > Isn't it because the receiver is more likely to backhaul the traffic > further, due to hot-potato routing - at least in the case of large > networks with multiple points of interconnect? That's the reason given. One can argue over whether it is the "real" reason. Since we just had a long and thorough discussion of this in the last few days on this very list, perhaps the people who are wondering about this could read the archives and not bother the other 10K of us on something we answered _yesterday_? -- TTFN, patrick > On 5/11/2008, at 10:15 PM, Mark Foster <blakjak at blakjak.net> wrote: > >> I'm sure someone else must've seen it before. >> >> Surely even assymetric peering agreements are mutually >> beneficial... ISPs are also content providers, either directly or >> through their customers... peering is going to have a flow-on >> effect in terms of reducing the cost of offering content to the >> people you peer with too, right? >> >> Why all the focus on even or non-even-ness of up/down ratios in the >> first place? >> >> Mark. >> >> On Tue, 4 Nov 2008, Mike Lyon wrote: >> >>> Those with bad or uneven ratios then purchase transit and don't let >>> themselves get depeered... >>> >>> On 11/1/08, Nelson Lai <nelson.lai at indiatimes.com> wrote: >>>> What I mean is, how come networks like Teleglobe, Limelight, etc. >>>> don't get >>>> depeered by others, but Cogent does? I'm sure Cogent isn't the >>>> only one with >>>> bad ratios. >>>> >>>> >>>> -- >>>> Hyundai to launch the i20 in India. Catch the exclusive preview on >>>> ZigWheels.com >>>> http://www.zigwheels.com/b2cam/newsDetails.action?name=Emb11_20080731&path=/INDT/News/Emb11_20080731&page=1&pagecount=2&utm_source=indmail&utm_medium=footer&utm_content=tracking&utm_campaign=Nletter_07oct2008_ZW >>>> >>>> >>> >>> -- >>> Sent from my mobile device >>> >>> >> > From vixie at isc.org Wed Nov 5 09:11:09 2008 From: vixie at isc.org (Paul Vixie) Date: Wed, 05 Nov 2008 15:11:09 +0000 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC0922599F@E03MVZ2-UKDY.domain1.systemhost.net> (michael dillon's message of "Tue\, 4 Nov 2008 17\:33\:08 -0000") References: <8EB0179B-DB38-479D-9C40-962758C0C2D0@ianai.net> <C0F2465B4F386241A58321C884AC7ECC0922599F@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <g363n2p5rm.fsf@nsa.vix.com> (note: i don't think sprint or cogent is being evil in this situation.) <michael.dillon at bt.com> writes: > Has anyone heard of a backup route? With a longer path so it is never > used unless there is a real emergency? Why was there no backup route > available to carry the Sprint <-> Cogent traffic? Because there was a > political failure in both Sprint and Cogent. what you're calling a political failure could be what others call a rate war. i'd imagine that cogent's cost structure lower than most networks' (since their published prices are so low and since they're not pumping new money in from the outside and since they have no non-IP business they could be using to support "dumping"). if cogent's rates aare also lowest then the other large networks might be losing customers toward cogent and those other large networks might feel they are hurting their own cause by peering, settlement free, with this new-economy competitor. if that's the case then the "political failure" you describe might be a matter of cogent saying "we don't want our prices to our customers to reflect the capital inefficiencies of other networks" and those other networks saying "we do." note, i'm not on the inside and i'm working only from public knowledge here and so this is all supposition. but calling it "political failure" when these possibilities exist seems like a stretch. there'd be no other leverage whereby cogent could protect the price point its customers seem to like so well. i'm not saying a cogent customer will be glad to trade some instability to get those prices, but i am saying that if this long chain of guesses is accurate it likely also represents the ONLY way to drive efficiency in a competitive capital-intensive market. > Back in 2000 it was acceptable for the big New York banks to have all > their eggs in one basket in central Manhattan. In 2002, it was no longer > acceptable. Do we really need a 911 magnitude of disaster on the > Internet for people to wake up and smell the coffee? The Internet is no > longer a kewl tool built and operated by the cognoscenti to meet their > own interests. It is now part of every nation's and everbody's critical > infrastructure. It needs to be engineered and operated better so that it > does not end up partitioning for dumb reasons. that sounds like justification for government regulation, if true. -- Paul Vixie From michael.dillon at bt.com Wed Nov 5 09:52:26 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 5 Nov 2008 15:52:26 -0000 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <g363n2p5rm.fsf@nsa.vix.com> Message-ID: <C0F2465B4F386241A58321C884AC7ECC092DCA39@E03MVZ2-UKDY.domain1.systemhost.net> > what you're calling a political failure could be what others > call a rate war. I only used the term "political failure" because it was the best match of the two options given. But you are right that it is necessary to let go of those terms and maybe, define your own, if you want to get to a deep understanding of what is going on. > but i am saying that if this long chain of guesses is > accurate it likely also represents the ONLY way to drive > efficiency in a competitive capital-intensive market. In other words, the market demands more efficiency and gives their resources (money) to those willing to provide it. This is generally how any given industry makes step changes in efficiency, due to competitive pressures. > It is now part of every nation's and > everbody's > > critical infrastructure. It needs to be engineered and > operated better > > so that it does not end up partitioning for dumb reasons. > > that sounds like justification for government regulation, if true. Not at all. It is justification for ISP management to stop peddling the same old, same old, and to restructure their businesses to be more like a utility. Granted, there is more margin to be made in vale-added services, but the core network operation needs to be run as an efficient utility, not have its inefficiency propped up by some lucrative voice products. Cogent seems to be operating according to the pure utility model. If the other ISPs don't want to get dragged into that space, they need to partition their businesses so that the high-priced services provide actual added value to customers over and above the generic Internet transit service. Regulation is just a way to prop up inefficient businesses as we should have all learned with the global telco disaster from the 1960's onward. As the sophistication of technology rose exponentially along with drastic drops in prices, telcos just ate up the extra margin by becoming more inefficient, until finally the regulators said enough is enough, and opened the doors to competition. --Michael Dillon From cchurc05 at harris.com Wed Nov 5 10:34:16 2008 From: cchurc05 at harris.com (Church, Charles) Date: Wed, 5 Nov 2008 10:34:16 -0600 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC092DCA39@E03MVZ2-UKDY.domain1.systemhost.net> References: <g363n2p5rm.fsf@nsa.vix.com> <C0F2465B4F386241A58321C884AC7ECC092DCA39@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <FA1BA229357DB640B944218F3585FECA019BDA82@mspe2k1.cs.myharris.net> -----Original Message----- From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] Sent: Wednesday, November 05, 2008 10:52 AM To: nanog at merit.edu Subject: RE: Sprint v. Cogent, some clarity & facts > what you're calling a political failure could be what others > call a rate war. I didn't really care about this, but now I'm curious. Since their peering was a 'trial', I'm assuming it hasn't always been there. Prior to Sprint and Cogent peering directly with each other, how did they communicate? Why was that functionality broken after they started peering? From drais at icantclick.org Wed Nov 5 10:54:49 2008 From: drais at icantclick.org (david raistrick) Date: Wed, 5 Nov 2008 16:54:49 +0000 (UTC) Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <FA1BA229357DB640B944218F3585FECA019BDA82@mspe2k1.cs.myharris.net> References: <g363n2p5rm.fsf@nsa.vix.com> <C0F2465B4F386241A58321C884AC7ECC092DCA39@E03MVZ2-UKDY.domain1.systemhost.net> <FA1BA229357DB640B944218F3585FECA019BDA82@mspe2k1.cs.myharris.net> Message-ID: <alpine.BSF.0.999.0811051653570.55439@murf.icantclick.org> On Wed, 5 Nov 2008, Church, Charles wrote: > I didn't really care about this, but now I'm curious. Since their > peering was a 'trial', I'm assuming it hasn't always been there. Prior > to Sprint and Cogent peering directly with each other, how did they > communicate? Why was that functionality broken after they started > peering? They purchased transit (through NTT I believe) for connectivity to sprint. They removed that, because their goal has been to be transit-free. --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From lowen at pari.edu Wed Nov 5 10:59:09 2008 From: lowen at pari.edu (Lamar Owen) Date: Wed, 5 Nov 2008 11:59:09 -0500 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) Message-ID: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> Charles Wyble charles at thewybles.com wrote: > Lamar Owen wrote: > > There are three ways that I know of (feel free to add to this list) to limit the events: > > 1.) As you mentioned, regulation (or a government run and regulated backbone); > Right. But what do we want this to look like? Well, since I've already stepped out on a limb, here goes my try at a rough outline of what such a regulation might look like (with the caveat that this is likely too simple to actually make it as a regulation): 1.) Define the regulation's scope, that it is, who is being regulated and why. In this case, I would say 'transit-free Internet carriers' are the who, and to maintain a 'complete Internet' is the why. 2.) Allocate regulatory responsibility and enforcement authority to an entity. I would suggest the FCC would be appropriate. (This outline might then be the start of a 47 CFR 221 or similar). 3.) Define 'transit-free Internet carrier.' This has been done already by Patrick Gilmore and others, and done quite well. 4.) Define 'complete Internet.' I'm staying away from that one. ;-) 5.) Define 'peering arrangement.' This has also been done quite well by others, so I'll not repeat that here. 6.) Mandate that all transit-free Internet carriers shall maintain peering arrangements with all other transit-free Internet carriers to maintain a complete Internet (citing some law that makes a 'complete Internet' a national security matter, or somesuch, and belongs in 47 CFR 221 as a result). 7.) Mandate that only carriers who voluntarily accept this regulation may use the term 'Tier 1 Internet Provider' and provide penalties for Internet providers who wish to 'opt-out' of the regulation but who do not obtain transit from another provider. IOW, become a Tier 2, no need for regulation. 8.) Authorize the issuance of a 'Tier 1 Internet Provider' license (that must be renewed periodically, with documentation supporting the Tier 1 status) to participating transit-free Internet carriers (for a fee to cover the opex). 9.) Authorize the FCC's Enforcement Bureau to enforce. This is, IMHO, the best case regulatory scenario. But I reserve the right to be wrong. Not that it is a desired scenario, but as far as regulation goes I think it would be the scenario that does the least harm. > Hmmmm. I need to read that over. Thank you for the reference. You're very welcome. My previous career was as a broadcast chief operator. Knowing 47 CFR Parts 1, 2, 73, 74, and 101 was part of that job (and a part I do not miss). Radio (both amateur and professional) used to be, prior to the late 1920's, an unregulated free-for-all similar to the current state of the Internet; but that proved to be unworkable, eventually producing the Communications Act of 1934, which established the Federal Communications Commission with real authority to regulate radio. If you want to see just how technically ridiculous such regulation can get, research the term 'CONELRAD' for a horrifying example. Now, on the flipside, current providers who also happen to be LEC's covered by 47 CFR 51 might actually not mind the addition of IP carriage to Part 51's scope. Makes everything consistent for them and their legal departments. But Part 51 is quite a bit more cumbersome than the simple 'Regulate the Tier 1's only' outline above, and carriers who are not already covered by Part 51 would likely raise a holy tantrum about it. But I'm sure there are loopholes in my rough outline above; it's too simple to be real regulation. :-) From LarrySheldon at cox.net Wed Nov 5 11:12:36 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 05 Nov 2008 11:12:36 -0600 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> References: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> Message-ID: <4911D404.3070400@cox.net> Lamar Owen wrote: > Charles Wyble charles at thewybles.com wrote: >> Lamar Owen wrote: >>> There are three ways that I know of (feel free to add to this >>> list) to limit the events: 1.) As you mentioned, regulation (or a >>> government run and regulated backbone); Which government? > >> Right. But what do we want this to look like? > > Well, since I've already stepped out on a limb, here goes my try at a > rough outline of what such a regulation might look like (with the > caveat that this is likely too simple to actually make it as a > regulation): Which government? > > 1.) Define the regulation's scope, that it is, who is being regulated > and why. In this case, I would say 'transit-free Internet carriers' > are the who, and to maintain a 'complete Internet' is the why. In which country? > > 2.) Allocate regulatory responsibility and enforcement authority to > an entity. I would suggest the FCC would be appropriate. (This > outline might then be the start of a 47 CFR 221 or similar). Is every part of "the Internet" going to recognize the sovereignty of the United States Federal Communications Commission (assuming they staff up to be able to administer this and the Fairness Doctrine)? > > 3.) Define 'transit-free Internet carrier.' This has been done > already by Patrick Gilmore and others, and done quite well. > > 4.) Define 'complete Internet.' I'm staying away from that one. ;-) > > 5.) Define 'peering arrangement.' This has also been done quite well > by others, so I'll not repeat that here. > > 6.) Mandate that all transit-free Internet carriers shall maintain > peering arrangements with all other transit-free Internet carriers to > maintain a complete Internet (citing some law that makes a 'complete > Internet' a national security matter, or somesuch, and belongs in 47 > CFR 221 as a result). How will that work in, say, China? Or Iran > > 7.) Mandate that only carriers who voluntarily accept this regulation > may use the term 'Tier 1 Internet Provider' and provide penalties for > Internet providers who wish to 'opt-out' of the regulation but who do > not obtain transit from another provider. IOW, become a Tier 2, no > need for regulation. > > 8.) Authorize the issuance of a 'Tier 1 Internet Provider' license > (that must be renewed periodically, with documentation supporting the > Tier 1 status) to participating transit-free Internet carriers (for a > fee to cover the opex). > > 9.) Authorize the FCC's Enforcement Bureau to enforce. > > This is, IMHO, the best case regulatory scenario. But I reserve the > right to be wrong. Not that it is a desired scenario, but as far as > regulation goes I think it would be the scenario that does the least > harm. > >> Hmmmm. I need to read that over. Thank you for the reference. > > You're very welcome. My previous career was as a broadcast chief > operator. Knowing 47 CFR Parts 1, 2, 73, 74, and 101 was part of > that job (and a part I do not miss). Radio (both amateur and > professional) used to be, prior to the late 1920's, an unregulated > free-for-all similar to the current state of the Internet; but that > proved to be unworkable, eventually producing the Communications Act > of 1934, which established the Federal Communications Commission with > real authority to regulate radio. > > If you want to see just how technically ridiculous such regulation > can get, research the term 'CONELRAD' for a horrifying example. > > Now, on the flipside, current providers who also happen to be LEC's > covered by 47 CFR 51 might actually not mind the addition of IP > carriage to Part 51's scope. Makes everything consistent for them > and their legal departments. But Part 51 is quite a bit more > cumbersome than the simple 'Regulate the Tier 1's only' outline > above, and carriers who are not already covered by Part 51 would > likely raise a holy tantrum about it. > > But I'm sure there are loopholes in my rough outline above; it's too > simple to be real regulation. :-) One World Government at last! -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From lowen at pari.edu Wed Nov 5 12:04:27 2008 From: lowen at pari.edu (Lamar Owen) Date: Wed, 5 Nov 2008 13:04:27 -0500 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) Message-ID: <12378369.7991225908267126.JavaMail.root@scalix.pari.edu> Larry Sheldon LarrySheldon at cox.net wrote: > How will that work in, say, China? Or Iran [snip] > > But I'm sure there are loopholes in my rough outline above; it's too > > simple to be real regulation. :-) > One World Government at last! Just one of the many loopholes in my simplistic outline, and the most difficult thing of all about regulating 'the Internet.' So, would prefacing my outline with 'In the USA, this could be done for that portion of 'the Internet' provider infrastructure within the jurisdiction of the USA' close that hole to a degree? (not really) Like I said, I am not touching the definition of the 'complete Internet' (and I even left a clue to this hole in that line). From LarrySheldon at cox.net Wed Nov 5 12:09:05 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 05 Nov 2008 12:09:05 -0600 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <12378369.7991225908267126.JavaMail.root@scalix.pari.edu> References: <12378369.7991225908267126.JavaMail.root@scalix.pari.edu> Message-ID: <4911E141.3070206@cox.net> Lamar Owen wrote: > Larry Sheldon LarrySheldon at cox.net wrote: >> How will that work in, say, China? Or Iran > [snip] >>> But I'm sure there are loopholes in my rough outline above; it's >>> too simple to be real regulation. :-) > >> One World Government at last! > > Just one of the many loopholes in my simplistic outline, and the most > difficult thing of all about regulating 'the Internet.' > > So, would prefacing my outline with 'In the USA, this could be done > for that portion of 'the Internet' provider infrastructure within the > jurisdiction of the USA' close that hole to a degree? (not really) > > Like I said, I am not touching the definition of the 'complete > Internet' (and I even left a clue to this hole in that line). Do you see that as more than a minor nuisance? I see it as a deal breaker. From lowen at pari.edu Wed Nov 5 12:23:52 2008 From: lowen at pari.edu (Lamar Owen) Date: Wed, 5 Nov 2008 13:23:52 -0500 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) Message-ID: <4720804.8121225909432391.JavaMail.root@scalix.pari.edu> Larry Sheldon LarrySheldon at cox.net wote: > Do you see that as more than a minor nuisance? > I see it as a deal breaker. Yet another reason I vastly prefer no such regulation. Yet endusers with clout (such as NASA, who was on both sides of this latest partitioning) may try to get some form of regulation of the providers in their respective countries, and then it will be a major pain for everyone. From web at typo.org Wed Nov 5 12:41:47 2008 From: web at typo.org (Wayne E. Bouchard) Date: Wed, 5 Nov 2008 11:41:47 -0700 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> References: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> Message-ID: <20081105184147.GA12786@typo.org> On Wed, Nov 05, 2008 at 11:59:09AM -0500, Lamar Owen wrote: > You're very welcome. My previous career was as a broadcast chief operator. Knowing 47 CFR Parts 1, 2, 73, 74, and 101 was part of that job (and a part I do not miss). Radio (both amateur and professional) used to be, prior to the late 1920's, an unregulated free-for-all similar to the current state of the Internet; but that proved to be unworkable, eventually producing the Communications Act of 1934, which established the Federal Communications Commission with real authority to regulate radio. Yeah, and we're all just thrilled at how the FCC has conducted itself over the past 20 years, aren't we? (Speaking as one who grew around the technical side of broadcasting.) :-/ I'm undecided wether such regulation is a good thing or not. I agree that the current state of affairs is ultimately unworkable but government's role is to provide necessary restraints to protect the ability of new competitors to enter into the market place and to enable fair competition, not to regulate for the sake of regulating. With yesterday's results, I do not believe this is quite the right time to be persuing such actions since there is now a worrisome imbalance in the system. See, thing is, if "tier 1" becomes regulated, "tier 2" will almost certainly follow. Probably much more open, but regulation will still follow. (Open doors are hard to close.) When you get right down to it, this discussion really sounds like a request for something along the lines of Telecom '96. Not sure I like that thought or not. I'm still undecided as to wether that was a good or a bad thing but leaning towards good. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From Martin.Hannigan at verneglobal.com Wed Nov 5 12:54:06 2008 From: Martin.Hannigan at verneglobal.com (Martin Hannigan) Date: Wed, 5 Nov 2008 18:54:06 -0000 Subject: Ixia, Juniper going green? References: <92c950310811050311k4ef92e74nc347665b7fd8b43e@mail.gmail.com> Message-ID: <BF08482709F8B24484F80A48DE20BEF3707CC4@agusto.kerfisleiga.is> Going green on your hardware is not necessarily about consumption as it is efficiency and I think that there is much difficulty in showing that on a piece of hardware without relation to capacity, cooling, or some other meaningful output. PUE is reasonable to some extent to measure a facilities efficiency. Watts per gig or meg seems a reasonable measure for this and Force10 was talking about that ions ago, but I have to wonder why Juniper and IXIA aren't doing this in conjunction with the Green Grid. -M< -- Martin Hannigan hannigan at verneglobal.com <mailto:hannigan at verneglobal.com> Verne Global http://www.verneglobal.com <http://www.verneglobal.com/> Keflavik, Iceland ________________________________ From: Glen Kent [mailto:glen.kent at gmail.com] Sent: Wed 05-Nov-08 06:11 To: OPS Gurus Subject: Ixia, Juniper going green? http://www.lightreading.com/document.asp?doc_id=166871 I wonder what impact this would put on other vendors to turn down their power consumptions and turn, as Juniper and Ixia like to put it - Green! BTW, the specs are a little skewed because they're only measuring power consumption when the router is only forwarding traffic, i.e., there is no traffic going to CPU. Also any idea about the genesis of this ECR initiative (http://www.ecrinitiative.org/) and what their eventual goal is ? Glen From erol at easydns.com Wed Nov 5 14:45:14 2008 From: erol at easydns.com (Erol) Date: Wed, 5 Nov 2008 15:45:14 -0500 Subject: Google Contact Message-ID: <20081105204514.GA9079@corp.easydns.com> Can someone from Google/Gmail contact me offlist. This is with regards to some mail issues we're experiencing. I wasn't able to find anything of use on the gmail site, or their user forum. Thx. /erol -- erol at easydns.com easyDNS Technologies Inc. From surfer at mauigateway.com Wed Nov 5 14:46:05 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 5 Nov 2008 12:46:05 -0800 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) Message-ID: <20081105124605.69FFD370@resin15.mta.everyone.net> Here I go again with networks are borderless, global entities, not a US (or any country) regulable thingie... ;-) Would the below regulation cover only the part of their network that is in the US or will it cover the global scope of their network? If only the US part (I'd hate to think the US would try regulate someone's network in another country) then, say, part of their network in the other countries doesn't conform to US regulations. How will the regulators require the company stop the non-conforming bits from crossing the associated physical borders. No need to answer. Rhetorical question... scott --- lowen at pari.edu wrote: From: Lamar Owen <lowen at pari.edu> To: Charles Wyble <charles at thewybles.com> Cc: nanog at nanog.org Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) Date: Wed, 5 Nov 2008 11:59:09 -0500 Charles Wyble charles at thewybles.com wrote: > Lamar Owen wrote: > > There are three ways that I know of (feel free to add to this list) to limit the events: > > 1.) As you mentioned, regulation (or a government run and regulated backbone); > Right. But what do we want this to look like? Well, since I've already stepped out on a limb, here goes my try at a rough outline of what such a regulation might look like (with the caveat that this is likely too simple to actually make it as a regulation): 1.) Define the regulation's scope, that it is, who is being regulated and why. In this case, I would say 'transit-free Internet carriers' are the who, and to maintain a 'complete Internet' is the why. 2.) Allocate regulatory responsibility and enforcement authority to an entity. I would suggest the FCC would be appropriate. (This outline might then be the start of a 47 CFR 221 or similar). 3.) Define 'transit-free Internet carrier.' This has been done already by Patrick Gilmore and others, and done quite well. 4.) Define 'complete Internet.' I'm staying away from that one. ;-) 5.) Define 'peering arrangement.' This has also been done quite well by others, so I'll not repeat that here. 6.) Mandate that all transit-free Internet carriers shall maintain peering arrangements with all other transit-free Internet carriers to maintain a complete Internet (citing some law that makes a 'complete Internet' a national security matter, or somesuch, and belongs in 47 CFR 221 as a result). 7.) Mandate that only carriers who voluntarily accept this regulation may use the term 'Tier 1 Internet Provider' and provide penalties for Internet providers who wish to 'opt-out' of the regulation but who do not obtain transit from another provider. IOW, become a Tier 2, no need for regulation. 8.) Authorize the issuance of a 'Tier 1 Internet Provider' license (that must be renewed periodically, with documentation supporting the Tier 1 status) to participating transit-free Internet carriers (for a fee to cover the opex). 9.) Authorize the FCC's Enforcement Bureau to enforce. This is, IMHO, the best case regulatory scenario. But I reserve the right to be wrong. Not that it is a desired scenario, but as far as regulation goes I think it would be the scenario that does the least harm. > Hmmmm. I need to read that over. Thank you for the reference. You're very welcome. My previous career was as a broadcast chief operator. Knowing 47 CFR Parts 1, 2, 73, 74, and 101 was part of that job (and a part I do not miss). Radio (both amateur and professional) used to be, prior to the late 1920's, an unregulated free-for-all similar to the current state of the Internet; but that proved to be unworkable, eventually producing the Communications Act of 1934, which established the Federal Communications Commission with real authority to regulate radio. If you want to see just how technically ridiculous such regulation can get, research the term 'CONELRAD' for a horrifying example. Now, on the flipside, current providers who also happen to be LEC's covered by 47 CFR 51 might actually not mind the addition of IP carriage to Part 51's scope. Makes everything consistent for them and their legal departments. But Part 51 is quite a bit more cumbersome than the simple 'Regulate the Tier 1's only' outline above, and carriers who are not already covered by Part 51 would likely raise a holy tantrum about it. But I'm sure there are loopholes in my rough outline above; it's too simple to be real regulation. :-) From surfer at mauigateway.com Wed Nov 5 14:49:24 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 5 Nov 2008 12:49:24 -0800 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) Message-ID: <20081105124924.69FFD07F@resin15.mta.everyone.net> --- LarrySheldon at cox.net wrote: : Which government? : Which government? : In which country? : How will that work in, say, China? Or Iran ------------------------------------------ Oops. Note to self: read all responses before replying. Apologies to the list folk for redundancy... : One World Government at last! bzzzt! wrong answer. :-) scott --- LarrySheldon at cox.net wrote: From: Larry Sheldon <LarrySheldon at cox.net> To: undisclosed-recipients: ; CC: nanog at nanog.org Subject: Re: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) Date: Wed, 05 Nov 2008 11:12:36 -0600 Lamar Owen wrote: > Charles Wyble charles at thewybles.com wrote: >> Lamar Owen wrote: >>> There are three ways that I know of (feel free to add to this >>> list) to limit the events: 1.) As you mentioned, regulation (or a >>> government run and regulated backbone); Which government? > >> Right. But what do we want this to look like? > > Well, since I've already stepped out on a limb, here goes my try at a > rough outline of what such a regulation might look like (with the > caveat that this is likely too simple to actually make it as a > regulation): Which government? > > 1.) Define the regulation's scope, that it is, who is being regulated > and why. In this case, I would say 'transit-free Internet carriers' > are the who, and to maintain a 'complete Internet' is the why. In which country? > > 2.) Allocate regulatory responsibility and enforcement authority to > an entity. I would suggest the FCC would be appropriate. (This > outline might then be the start of a 47 CFR 221 or similar). Is every part of "the Internet" going to recognize the sovereignty of the United States Federal Communications Commission (assuming they staff up to be able to administer this and the Fairness Doctrine)? > > 3.) Define 'transit-free Internet carrier.' This has been done > already by Patrick Gilmore and others, and done quite well. > > 4.) Define 'complete Internet.' I'm staying away from that one. ;-) > > 5.) Define 'peering arrangement.' This has also been done quite well > by others, so I'll not repeat that here. > > 6.) Mandate that all transit-free Internet carriers shall maintain > peering arrangements with all other transit-free Internet carriers to > maintain a complete Internet (citing some law that makes a 'complete > Internet' a national security matter, or somesuch, and belongs in 47 > CFR 221 as a result). How will that work in, say, China? Or Iran > > 7.) Mandate that only carriers who voluntarily accept this regulation > may use the term 'Tier 1 Internet Provider' and provide penalties for > Internet providers who wish to 'opt-out' of the regulation but who do > not obtain transit from another provider. IOW, become a Tier 2, no > need for regulation. > > 8.) Authorize the issuance of a 'Tier 1 Internet Provider' license > (that must be renewed periodically, with documentation supporting the > Tier 1 status) to participating transit-free Internet carriers (for a > fee to cover the opex). > > 9.) Authorize the FCC's Enforcement Bureau to enforce. > > This is, IMHO, the best case regulatory scenario. But I reserve the > right to be wrong. Not that it is a desired scenario, but as far as > regulation goes I think it would be the scenario that does the least > harm. > >> Hmmmm. I need to read that over. Thank you for the reference. > > You're very welcome. My previous career was as a broadcast chief > operator. Knowing 47 CFR Parts 1, 2, 73, 74, and 101 was part of > that job (and a part I do not miss). Radio (both amateur and > professional) used to be, prior to the late 1920's, an unregulated > free-for-all similar to the current state of the Internet; but that > proved to be unworkable, eventually producing the Communications Act > of 1934, which established the Federal Communications Commission with > real authority to regulate radio. > > If you want to see just how technically ridiculous such regulation > can get, research the term 'CONELRAD' for a horrifying example. > > Now, on the flipside, current providers who also happen to be LEC's > covered by 47 CFR 51 might actually not mind the addition of IP > carriage to Part 51's scope. Makes everything consistent for them > and their legal departments. But Part 51 is quite a bit more > cumbersome than the simple 'Regulate the Tier 1's only' outline > above, and carriers who are not already covered by Part 51 would > likely raise a holy tantrum about it. > > But I'm sure there are loopholes in my rough outline above; it's too > simple to be real regulation. :-) One World Government at last! -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From deepak at ai.net Wed Nov 5 15:20:24 2008 From: deepak at ai.net (Deepak Jain) Date: Wed, 5 Nov 2008 16:20:24 -0500 Subject: NTP Md5 or AutoKey? In-Reply-To: <ED736B98-9B9F-42CD-B3C3-807C2735B30E@daork.net> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> <ED736B98-9B9F-42CD-B3C3-807C2735B30E@daork.net> Message-ID: <D338D1613B32624285BB321A5CF3DB250C6A717A2C@ginga.ai.net> Of course, this only really works if your network has 3 reliable +secure time sources + 1 for redundancy. I'm not sure that .*pool\.ntp \.org would class as reliable+secure if you're concerned about NTP security. It's important to recognize that "secure" NTP has nothing to do with real World time, and everything to do with all your secure systems being on *the same* time, whatever that is. It really doesn't matter (much) if your secure NTP cluster gets its time from an inconsistent source [provided it won't allow changes of too great a magnitude at a time] but as long as they are all on the *same* time, you can maintain your security. >From an SPs point-of-view, security is very odd. It doesn't matter how well your "internal" systems are if you are sending mail with the wrong time (say some future date) and MTAs at your customers are rejecting them. Deepak From sven at cyberbunker.com Wed Nov 5 15:21:15 2008 From: sven at cyberbunker.com (HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP) Date: Wed, 5 Nov 2008 21:21:15 +0000 (GMT) Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <12378369.7991225908267126.JavaMail.root@scalix.pari.edu> References: <12378369.7991225908267126.JavaMail.root@scalix.pari.edu> Message-ID: <Pine.LNX.4.58.0811052108230.2078@scott.cb3rob.net> speaking about regulation, as a party providing an important piece of infrastructure to the muggles in the matrix, we would expect some gratitude from the various highly incompetent "governators" around the world, instead of pissing off isps with more regulations, primarily pushed by the various illegal kartells that form the "entertainment industry" (on which we should pull hostile takeovers to shut them down once and for good and noone will even miss them and their stupid dvds but that's besides the point), it would be nice if the "internet community" would from now on reside directly under the UN (no more local laws and other annoying interference) and our technical staff would at least get cars with sirens etc to go to datacenters -fast- if the need arises. (just basic -requirements-, nothing fancy) let's just face it, noone here (besides those in china) give a rats ass about what china wants (no falun gong) or that sweden has anti porn laws which have 24 as their criteria or other local crap, for some weird reason the local crap from the USA seems to be widely accepted -still-, but in fact the real problem is just that the scope of the internet goes well over the obsolete country borders from the past, and therefore any form of regulation should do so as well. nothing wrong with regulation, but as the reach of the internet is a tad bigger than that of a muggle tv station, it should be global, and as we own the infrastructure and they cannot do without us, we get to vote who goes into the new (not the fcc, as thats us only anyway) regulating body. (or we might as well pull the plug and keep our individual parts of the internet for ourselves, which sends them all back to the stoneage). after all, if you break it, you get to keep both parts. I'm quite sure noone in europe or asia gives anything about anything the FCC may say or do and larger transit-less networks will just move their headquarters to such places should it get in the way. On Wed, 5 Nov 2008, Lamar Owen wrote: > Larry Sheldon LarrySheldon at cox.net wrote: > > How will that work in, say, China? Or Iran > [snip] > > > But I'm sure there are loopholes in my rough outline above; it's too > > > simple to be real regulation. :-) > > > One World Government at last! > > Just one of the many loopholes in my simplistic outline, and the most difficult thing of all about regulating 'the Internet.' > > So, would prefacing my outline with 'In the USA, this could be done for that portion of 'the Internet' provider infrastructure within the jurisdiction of the USA' close that hole to a degree? (not really) > > Like I said, I am not touching the definition of the 'complete Internet' (and I even left a clue to this hole in that line). > > > X-CONTACT-FILTER-MATCH: "nanog" > From herrin-nanog at dirtside.com Wed Nov 5 16:32:53 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 5 Nov 2008 17:32:53 -0500 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <4911D404.3070400@cox.net> References: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> <4911D404.3070400@cox.net> Message-ID: <3c3e3fca0811051432i21e068eahf9933e59365eb76c@mail.gmail.com> On Wed, Nov 5, 2008 at 12:12 PM, Larry Sheldon <LarrySheldon at cox.net> wrote: >>> Lamar Owen wrote: >>>> There are three ways that I know of (feel free to add to this >>>> list) to limit the events: 1.) As you mentioned, regulation (or a >>>> government run and regulated backbone); > > Which government? First, let me say that I think peering regulation is a terrible idea. No matter how cleverly you plan it, the result will be that fewer small companies can participate. That's the character of regulation: compliance creates more barriers to entry than it removes. That having been said, jurisdiction is a red herring. Every transit-free provider does at least some of its business in the United States. Economic reality compels them to continue to do so for the foreseeable future. That's all the hook the Feds need. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 From surfer at mauigateway.com Wed Nov 5 16:46:27 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 5 Nov 2008 14:46:27 -0800 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) Message-ID: <20081105144627.69FFF1B2@resin15.mta.everyone.net> --- herrin-nanog at dirtside.com wrote: That having been said, jurisdiction is a red herring. Every transit-free provider does at least some of its business in the United States. Economic reality compels them to continue to do so for the foreseeable future. That's all the hook the Feds need. --------------------------------------------- Are you saying that if any part of a network touches US soil it can be regulated by the US govt over the entirety of the network? For my part, this is not an attempt to change the subject or divert the argument (red herring). It is a valid question with operational impact. scott From a.harrowell at gmail.com Wed Nov 5 17:01:33 2008 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 5 Nov 2008 23:01:33 +0000 Subject: Internet partitioning event regulations (was: RE: Sending vs r equesting. Was: Re: Sprint / Cogent) Message-ID: <g7T4LR5RDQZb.QMDsQpjK@smtp.gmail.com> Have we yet had a peering war that was genuinely international, i.e. the partition was between net X in country Y and net Z in country W? Rather than between X's Y and Z's Y divisions, which wd both be in Y jurisdiction? - original message - Subject: Re: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) From: "Scott Weeks" <surfer at mauigateway.com> Date: 05/11/2008 10:47 pm --- herrin-nanog at dirtside.com wrote: That having been said, jurisdiction is a red herring. Every transit-free provider does at least some of its business in the United States. Economic reality compels them to continue to do so for the foreseeable future. That's all the hook the Feds need. --------------------------------------------- Are you saying that if any part of a network touches US soil it can be regulated by the US govt over the entirety of the network? For my part, this is not an attempt to change the subject or divert the argument (red herring). It is a valid question with operational impact. scott From michael.dillon at bt.com Wed Nov 5 17:03:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 5 Nov 2008 23:03:51 -0000 Subject: Internet partitioning event regulations (was: RE: Sendingvs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <20081105144627.69FFF1B2@resin15.mta.everyone.net> Message-ID: <C0F2465B4F386241A58321C884AC7ECC092DCDB4@E03MVZ2-UKDY.domain1.systemhost.net> > Are you saying that if any part of a network touches US soil > it can be regulated by the US govt over the entirety of the > network? For my part, this is not an attempt to change the > subject or divert the argument (red herring). It is a valid > question with operational impact. That's not how companies work. What you see as a single company operating a single worldwide network, is actually a web of companies with interlocking directorships and share structures. In each country they will probably have 3 or 4 corporate entities. One owns the network assets, one employs all the people in Sales, another employs the network ops people, and 4th one mops up the other employees and is a holding company for the other three. None of them do any billing because that is all done by subsidiary companies in Luxembourg and Ireland. Etc, etc. This is done for a variety of reasons but regulation is definitely one of them. In most countries you need a licence to operate telecom networks, and the licence holder will be the local operating company, not the head office company that consolidates the ownership underneath a share symbol traded on your favorite stock exchange. Spend some time hanging out with finance and legal people in a big company. You may find it almost as fascinating as designing networks. An additional point is that when one company acquires another and it gets reviewed for potential antitrust issues, this often impacts the company structure because a local regulator wants to see that the local corporate entity is not 100% controlled by a foreign corporation. This makes it easier for the government to target regulations at the domestic entity. --Michael Dillon From kloch at kl.net Wed Nov 5 17:04:30 2008 From: kloch at kl.net (Kevin Loch) Date: Wed, 05 Nov 2008 18:04:30 -0500 Subject: Internet partitioning event regulations In-Reply-To: <3c3e3fca0811051432i21e068eahf9933e59365eb76c@mail.gmail.com> References: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> <4911D404.3070400@cox.net> <3c3e3fca0811051432i21e068eahf9933e59365eb76c@mail.gmail.com> Message-ID: <4912267E.5090601@kl.net> William Herrin wrote: > On Wed, Nov 5, 2008 at 12:12 PM, Larry Sheldon <LarrySheldon at cox.net> wrote: >>>> Lamar Owen wrote: >>>>> There are three ways that I know of (feel free to add to this >>>>> list) to limit the events: 1.) As you mentioned, regulation (or a >>>>> government run and regulated backbone); >> Which government? > > First, let me say that I think peering regulation is a terrible idea. > No matter how cleverly you plan it, the result will be that fewer > small companies can participate. That's the character of regulation: > compliance creates more barriers to entry than it removes. The problem isn't that which networks don't peer with each other it is that some networks don't buy transit from anyone. That is what causes partition related outages and distortions in peering policies. If regulation could be part of the 'solution' then that would be the place to start. But despite the flaws with the current environment it really isn't that bad and any regulation would likely be a disaster for the industry. - Kevin From mpalmer at hezmatt.org Wed Nov 5 17:05:13 2008 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 6 Nov 2008 10:05:13 +1100 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <20081105144627.69FFF1B2@resin15.mta.everyone.net> References: <20081105144627.69FFF1B2@resin15.mta.everyone.net> Message-ID: <20081105230513.GK5084@hezmatt.org> On Wed, Nov 05, 2008 at 02:46:27PM -0800, Scott Weeks wrote: > --- herrin-nanog at dirtside.com wrote: > > That having been said, jurisdiction is a red herring. Every > transit-free provider does at least some of its business in the United > States. Economic reality compels them to continue to do so for the > foreseeable future. That's all the hook the Feds need. > --------------------------------------------- > > Are you saying that if any part of a network touches US soil it can be > regulated by the US govt over the entirety of the network? For my part, > this is not an attempt to change the subject or divert the argument (red > herring). It is a valid question with operational impact. <hearsay> A good friend of mine who works for a local (Australian) bank is constantly complaining about SOX compliance, which he has to do because there's a related entity to the company he works for which does financial business in the US. </hearsay> It's not beyond the realm of possibility for a government (any government, not *just* the US) to say "if you want to do business in our jurisdiction, you will abide by the following rules", which may include rules regarding what related entities located in other countries do. Not that you'd really need such a regulation for peering; so much of the "core backbone" is US-based[1] that even just a regulation controlling how peering worked for equipment and entities in the US would have the desired effect -- after all, the US government would (in the short term, at least) mostly be interested in making sure that the Internet worked within the US. It might also (further) encourage companies to host more stuff in the US, if they can lower their risk of connectivity problems to US-based eyeballs. - Matt [1] How many depeerings have happened in other countries that have had such a major effect on global connectivity? -- One of the Rules Of Flight is, or should be: Pullout Altitude Is Not A Signed Quantity. -- Anthony de Boer, in the monastery From web at typo.org Wed Nov 5 17:13:17 2008 From: web at typo.org (Wayne E. Bouchard) Date: Wed, 5 Nov 2008 16:13:17 -0700 Subject: Internet partitioning event regulations (was: RE: Sendingvs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC092DCDB4@E03MVZ2-UKDY.domain1.systemhost.net> References: <20081105144627.69FFF1B2@resin15.mta.everyone.net> <C0F2465B4F386241A58321C884AC7ECC092DCDB4@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <20081105231317.GA15038@typo.org> To add to Michael's point, I will say that while US Laws cannot apply to a company globally, it is perfectly reasonable for the US govt to say "If you wish to do business in this country, your operations within the USA will follow these rules." This is how every other industry is regulated. Just because the internet is less tangible doesn't make this particular sort of regulation any less valid. It just has to restrict itself in scope to interactions within US goverened territory. (Wherever the physical equipment is, thats the country you're in and those are the rules you follow. That has already been established.So if something were desired, there is no reason it cannot be deemed enforcable. -Wayne On Wed, Nov 05, 2008 at 11:03:51PM -0000, michael.dillon at bt.com wrote: > > Are you saying that if any part of a network touches US soil > > it can be regulated by the US govt over the entirety of the > > network? For my part, this is not an attempt to change the > > subject or divert the argument (red herring). It is a valid > > question with operational impact. > > That's not how companies work. What you see as a single > company operating a single worldwide network, is actually > a web of companies with interlocking directorships and > share structures. In each country they will probably have > 3 or 4 corporate entities. One owns the network assets, > one employs all the people in Sales, another employs > the network ops people, and 4th one mops up the other > employees and is a holding company for the other three. > None of them do any billing because that is all done by > subsidiary companies in Luxembourg and Ireland. Etc, etc. > > This is done for a variety of reasons but regulation is > definitely one of them. In most countries you need a > licence to operate telecom networks, and the licence > holder will be the local operating company, not the > head office company that consolidates the ownership > underneath a share symbol traded on your favorite stock > exchange. > > Spend some time hanging out with finance and legal people > in a big company. You may find it almost as fascinating > as designing networks. > > An additional point is that when one company acquires another > and it gets reviewed for potential antitrust issues, this > often impacts the company structure because a local regulator > wants to see that the local corporate entity is not 100% > controlled by a foreign corporation. This makes it easier > for the government to target regulations at the domestic > entity. > > --Michael Dillon > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From surfer at mauigateway.com Wed Nov 5 17:59:52 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 5 Nov 2008 15:59:52 -0800 Subject: Internet partitioning event regulations (was: RE: Sendingvs requesting. Was: Re: Sprint / Cogent) Message-ID: <20081105155952.69FFEE5A@resin15.mta.everyone.net> --- michael.dillon at bt.com wrote: "That's not how companies work. What you see as a single company operating a single worldwide network, is actually a web of companies with interlocking directorships and share structures. In each country they will probably have 3 or 4 corporate entities." Ok, I hadn't thought of that. I was thinking of one company in a non-US country with some assets in the US (but most not) and being held to US regulations network-wide. How would you stop the traffic that was not following US regulations from hitting the US? A:HNLL7710# configure router 1500 bgp as-path-ignore us-based-as-paths ? Not there... ;-) "Spend some time hanging out with finance and legal people in a big company. You may find it almost as fascinating as designing networks." As much as I hate to admit it, I believe I'd enjoy geeking-out on that for a while... scott From joelja at bogus.com Wed Nov 5 18:18:10 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 05 Nov 2008 16:18:10 -0800 Subject: Internet partitioning event regulations (was: RE: Sendingvs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <20081105155952.69FFEE5A@resin15.mta.everyone.net> References: <20081105155952.69FFEE5A@resin15.mta.everyone.net> Message-ID: <491237C2.4050403@bogus.com> Scott Weeks wrote: > Ok, I hadn't thought of that. I was thinking of one company in a > non-US country with some assets in the US (but most not) and being > held to US regulations network-wide. How would you stop the traffic > that was not following US regulations from hitting the US? Ask ISPs with networks on both side of the US Canada border who have the candian government for a customer, they do it today. > A:HNLL7710# configure router 1500 bgp as-path-ignore > us-based-as-paths ? > > Not there... ;-) From surfer at mauigateway.com Wed Nov 5 18:23:48 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 5 Nov 2008 16:23:48 -0800 Subject: Internet partitioning event regulations (was: RE: Sendingvs requesting. Was: Re: Sprint / Cogent) Message-ID: <20081105162348.6F2B2E52@resin15.mta.everyone.net> --- joelja at bogus.com wrote: From: Joel Jaeggli <joelja at bogus.com> Scott Weeks wrote: > Ok, I hadn't thought of that. I was thinking of one company in a > non-US country with some assets in the US (but most not) and being > held to US regulations network-wide. How would you stop the traffic > that was not following US regulations from hitting the US? Ask ISPs with networks on both side of the US Canada border who have the candian government for a customer, they do it today. ---------------------------------------------- They stop the bits from flowing on one part of the ISP's network to the Canadian Government and not the other part? scott From streiner at cluebyfour.org Wed Nov 5 18:52:56 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 5 Nov 2008 19:52:56 -0500 (EST) Subject: Ixia, Juniper going green? In-Reply-To: <92c950310811050311k4ef92e74nc347665b7fd8b43e@mail.gmail.com> References: <92c950310811050311k4ef92e74nc347665b7fd8b43e@mail.gmail.com> Message-ID: <Pine.LNX.4.64.0811051948180.6047@whammy.cluebyfour.org> On Wed, 5 Nov 2008, Glen Kent wrote: > http://www.lightreading.com/document.asp?doc_id=166871 > > I wonder what impact this would put on other vendors to turn down > their power consumptions and turn, as Juniper and Ixia like to put it > - Green! I do recall some people bashing Cisco products for their power consumption at a recent tech event I attended. Granted, that event was Juniper-centric :) Given the economic (rising power and cooling costs) and sometimes logistical (lack of power available in a facility) realities of operating networks and data centers, I'm sure everyone would love for their gear to draw less power. How many watts could actually be saved remains to be seen... jms From kris.foster at gmail.com Wed Nov 5 19:16:00 2008 From: kris.foster at gmail.com (kris foster) Date: Wed, 5 Nov 2008 17:16:00 -0800 Subject: Internet partitioning event regulations (was: RE: Sendingvs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <20081105162348.6F2B2E52@resin15.mta.everyone.net> References: <20081105162348.6F2B2E52@resin15.mta.everyone.net> Message-ID: <7949F574-7369-4B55-B02B-B472F94BAB01@gmail.com> Hi everyone, The Mailing List Committee would like to remind everyone that postings of a political nature are not considered operational. From the acceptable use policy [1]: 6. Postings of political, philosophical, and legal nature are prohibited. Please refrain from follow up posts on the subject in this thread. We encourage you to continue your conversation in a more appropriate forum. Kris Foster Mailing List Committee Chair [1] http://www.nanog.org/mailinglist/ From Valdis.Kletnieks at vt.edu Wed Nov 5 20:00:12 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 05 Nov 2008 21:00:12 -0500 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) In-Reply-To: Your message of "Wed, 05 Nov 2008 14:46:27 PST." <20081105144627.69FFF1B2@resin15.mta.everyone.net> References: <20081105144627.69FFF1B2@resin15.mta.everyone.net> Message-ID: <84700.1225936812@turing-police.cc.vt.edu> On Wed, 05 Nov 2008 14:46:27 PST, Scott Weeks said: > Are you saying that if any part of a network touches US soil it can be > regulated by the US govt over the entirety of the network? For my part, this > is not an attempt to change the subject or divert the argument (red herring). > It is a valid question with operational impact. Who owns the DNS root? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081105/5bb9a89c/attachment.bin> From jtraylor at networkinglinux.net Wed Nov 5 20:08:03 2008 From: jtraylor at networkinglinux.net (Jonathan Traylor) Date: Wed, 5 Nov 2008 20:08:03 -0600 Subject: Google SMTP acceptance policy? Message-ID: <20081106020803.GA7376@gonzo.fearandloathing.org> Anyone have guidance on how to legimately stay out of Google/GMail's spam classifier and arrive at the inbox? We have a domain that is relatively newly registered, has proper MTA configuration and SPF records that I haven't been able to find on any blocklist, but GMail sends email from it straight to the spam folder. I haven't been able to find useful documentation for GMail in this regard around the web. Have looked at abuse.net's info, links and resources. Thanks, -- Jonathan From jtrooney at nexdlevel.com Wed Nov 5 20:34:51 2008 From: jtrooney at nexdlevel.com (Jeff Rooney) Date: Wed, 5 Nov 2008 20:34:51 -0600 Subject: Savvis contact Message-ID: <D57CA3A4-23E6-4EB6-B852-AC36DE902859@nexdlevel.com> Any Savvis net ops out there, can you please contact me off list? Thanks -- Jeff Rooney jtrooney at nexdlevel.com From frnkblk at iname.com Wed Nov 5 22:06:12 2008 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 5 Nov 2008 22:06:12 -0600 Subject: Google SMTP acceptance policy? In-Reply-To: <20081106020803.GA7376@gonzo.fearandloathing.org> References: <20081106020803.GA7376@gonzo.fearandloathing.org> Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAA1yA4fMz3oTK8+q7AdmpjXAQAAAAA=@iname.com> Have you worked through this Q/A process? http://mail.google.com/support/bin/answer.py?answer=80369 I went through it and at the end it says there's not a way to whitelist a domain. For Bulk e-mail senders: https://mail.google.com/support/bin/answer.py?answer=17205 There's this checklist, too: https://mail.google.com/support/bin/answer.py?answer=81126 And here's a form to fill out: https://mail.google.com/support/bin/request.py?ctx=bulksend&nomods=1 Frank -----Original Message----- From: Jonathan Traylor [mailto:jtraylor at networkinglinux.net] Sent: Wednesday, November 05, 2008 8:08 PM To: nanog at nanog.org Subject: Google SMTP acceptance policy? Anyone have guidance on how to legimately stay out of Google/GMail's spam classifier and arrive at the inbox? We have a domain that is relatively newly registered, has proper MTA configuration and SPF records that I haven't been able to find on any blocklist, but GMail sends email from it straight to the spam folder. I haven't been able to find useful documentation for GMail in this regard around the web. Have looked at abuse.net's info, links and resources. Thanks, -- Jonathan From sking at kingrst.com Wed Nov 5 22:30:30 2008 From: sking at kingrst.com (Steven King) Date: Wed, 05 Nov 2008 23:30:30 -0500 Subject: Google SMTP acceptance policy? In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAA1yA4fMz3oTK8+q7AdmpjXAQAAAAA=@iname.com> References: <20081106020803.GA7376@gonzo.fearandloathing.org> <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAA1yA4fMz3oTK8+q7AdmpjXAQAAAAA=@iname.com> Message-ID: <491272E6.5060001@kingrst.com> >From my experience it just takes time. As users mark your email as legitimate and not as spam your domain will build a good report Google. Also, try implementing DKIM to help Google to verify the email. Frank Bulk wrote: > Have you worked through this Q/A process? > http://mail.google.com/support/bin/answer.py?answer=80369 > I went through it and at the end it says there's not a way to whitelist a > domain. > > For Bulk e-mail senders: > https://mail.google.com/support/bin/answer.py?answer=17205 > > There's this checklist, too: > https://mail.google.com/support/bin/answer.py?answer=81126 > > And here's a form to fill out: > https://mail.google.com/support/bin/request.py?ctx=bulksend&nomods=1 > > Frank > > -----Original Message----- > From: Jonathan Traylor [mailto:jtraylor at networkinglinux.net] > Sent: Wednesday, November 05, 2008 8:08 PM > To: nanog at nanog.org > Subject: Google SMTP acceptance policy? > > Anyone have guidance on how to legimately stay out of Google/GMail's spam > classifier and arrive at the inbox? > > We have a domain that is relatively newly registered, has proper MTA > configuration and SPF records that I haven't been able to find on any > blocklist, but GMail sends email from it straight to the spam folder. > > I haven't been able to find useful documentation for GMail in this regard > around the web. Have looked at abuse.net's info, links and resources. > > Thanks, > > -- > Jonathan > > > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From ops.lists at gmail.com Wed Nov 5 23:17:02 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 6 Nov 2008 10:47:02 +0530 Subject: Google SMTP acceptance policy? In-Reply-To: <20081106020803.GA7376@gonzo.fearandloathing.org> References: <20081106020803.GA7376@gonzo.fearandloathing.org> Message-ID: <bb0e440a0811052117y78773f94m221831ccfd2fc30f@mail.gmail.com> On Thu, Nov 6, 2008 at 7:38 AM, Jonathan Traylor <jtraylor at networkinglinux.net> wrote: > Anyone have guidance on how to legimately stay out of Google/GMail's spam > classifier and arrive at the inbox? This is good advice for anybody running mailing lists - regardless of which ISP they're delivering to http://www.spamresource.com/2007/01/how-to-deliver-mail-to-aol.html srs From randy at psg.com Wed Nov 5 23:23:56 2008 From: randy at psg.com (Randy Bush) Date: Thu, 06 Nov 2008 14:23:56 +0900 Subject: Google SMTP acceptance policy? In-Reply-To: <bb0e440a0811052117y78773f94m221831ccfd2fc30f@mail.gmail.com> References: <20081106020803.GA7376@gonzo.fearandloathing.org> <bb0e440a0811052117y78773f94m221831ccfd2fc30f@mail.gmail.com> Message-ID: <49127F6C.1090108@psg.com> the problem i have with google smtp is in the reverse direction drop condition = ${if isip4{$sender_host_address}} message = blocked because $sender_host_address is \ in blacklist at $dnslist_domain: $dnslist_text !dnslists = list.dnswl.org dnslists = dialups.mail-abuse.org \ : rbl-plus.mail-abuse.org \ : qil.mail-abuse.com logwrite = REJECT because $sender_host_address listed in $dnslist_domain i.e. i do dns blacklists proceeded by a white list. and when goog adds a new smtp outbound, users say folk get bounces, i have to chase them down and then go through dnswl.org's process. major pita and mail does get lost. randy From glen.kent at gmail.com Thu Nov 6 00:10:09 2008 From: glen.kent at gmail.com (Glen Kent) Date: Thu, 6 Nov 2008 11:40:09 +0530 Subject: Ixia, Juniper going green? In-Reply-To: <Pine.LNX.4.64.0811051948180.6047@whammy.cluebyfour.org> References: <92c950310811050311k4ef92e74nc347665b7fd8b43e@mail.gmail.com> <Pine.LNX.4.64.0811051948180.6047@whammy.cluebyfour.org> Message-ID: <92c950310811052210q4db2cab2h3fc3ba7b7677297b@mail.gmail.com> Just saw www.vnl.in Agreed that they're not making routers, but if a base station can be made, then am sure some inroads can be made in data comm too .. ! Glen On Thu, Nov 6, 2008 at 6:22 AM, Justin M. Streiner <streiner at cluebyfour.org> wrote: > On Wed, 5 Nov 2008, Glen Kent wrote: > >> http://www.lightreading.com/document.asp?doc_id=166871 >> >> I wonder what impact this would put on other vendors to turn down >> their power consumptions and turn, as Juniper and Ixia like to put it >> - Green! > > I do recall some people bashing Cisco products for their power consumption > at a recent tech event I attended. Granted, that event was Juniper-centric > :) > > Given the economic (rising power and cooling costs) and sometimes logistical > (lack of power available in a facility) realities of operating networks and > data centers, I'm sure everyone would love for their gear to draw less > power. How many watts could actually be saved remains to be seen... > > jms > From kraig.beahn at gmail.com Thu Nov 6 02:46:10 2008 From: kraig.beahn at gmail.com (Kraig Beahn) Date: Thu, 6 Nov 2008 03:46:10 -0500 Subject: Sprint v. Cogent, some clarity & facts In-Reply-To: <alpine.BSF.0.999.0811051653570.55439@murf.icantclick.org> References: <g363n2p5rm.fsf@nsa.vix.com> <C0F2465B4F386241A58321C884AC7ECC092DCA39@E03MVZ2-UKDY.domain1.systemhost.net> <FA1BA229357DB640B944218F3585FECA019BDA82@mspe2k1.cs.myharris.net> <alpine.BSF.0.999.0811051653570.55439@murf.icantclick.org> Message-ID: <a9be677f0811060046t4d1f6219h420f3357d4fcd21f@mail.gmail.com> Cogent transition or prep work this morning? AS 2914 NTT? Anyone else seeing similar changes abroad? ************ CORE INFRASTRUCTURE AFFECTING ALERT ************* -------------------------------------------------------------- BGP Status Change Sequence No: 1225957222 -------------------------------------------------------------- Change Status Type : origin / Origin Set Change -------------------------------------------------------------- BGP Monitored Prefix : 63.166.22.0/24 -------------------------------------------------------------- Update/Detection Time: 1225942611 / 1225957221 BGP ASN Update Time : 1225942611 -------------------------------------------------------------- BGP Set : 1239 -------------------------------------------------------------- BGP Gain(s) : 1239 -------------------------------------------------------------- BGP Loss(s) : -------------------------------------------------------------- Originating Entity : Synips / L2Networks -------------------------------------------------------------- ************ CORE INFRASTRUCTURE AFFECTING ALERT ************* -------------------------------------------------------------- BGP Status Change Sequence No: 1225957222 -------------------------------------------------------------- Change Status Type : last-hop / Last Hop Change -------------------------------------------------------------- BGP Monitored Prefix : 63.166.22.0/24 -------------------------------------------------------------- Update/Detection Time: 1225942611 / 1225957221 BGP ASN Update Time : 1225942611 -------------------------------------------------------------- BGP Set : 2914 -------------------------------------------------------------- BGP Gain(s) : 2914 -------------------------------------------------------------- BGP Loss(s) : -------------------------------------------------------------- Originating Entity : Synips / L2Networks -------------------------------------------------------------- OrgName: NTT America, Inc. OrgID: NTTAM-1 <http://ws.arin.net/whois/?queryinput=O%20!%20NTTAM-1> Address: 8005 South Chester Street Address: Suite 200 City: Centennial StateProv: CO PostalCode: 80112 Country: US ReferralServer: rwhois://rwhois.gin.ntt.net:4321/ ASNumber: 2914 ASName: NTT-COMMUNICATIONS-2914 <http://ws.arin.net/whois/?queryinput=A%20.%20NTT-COMMUNICATIONS-2914> ASHandle: AS2914 <http://ws.arin.net/whois/?queryinput=A%20!%20AS2914> Comment: RegDate: 1998-12-07 Updated: 2006-09-06 RTechHandle: PEERI-ARIN<http://ws.arin.net/whois/?queryinput=P%20!%20PEERI-ARIN> RTechName: Peering RTechPhone: +1-303-645-1900 RTechEmail: peering at ntt.net OrgAbuseHandle: NAAC-ARIN<http://ws.arin.net/whois/?queryinput=P%20!%20NAAC-ARIN> OrgAbuseName: NTT America Abuse Contact OrgAbusePhone: +1-800-551-1630 OrgAbuseEmail: abuse at ntt.net OrgNOCHandle: NASC-ARIN<http://ws.arin.net/whois/?queryinput=P%20!%20NASC-ARIN> OrgNOCName: NTT America Support Contact OrgNOCPhone: +1-800-551-1630 OrgNOCEmail: support at us.ntt.net OrgTechHandle: VIPAR-ARIN<http://ws.arin.net/whois/?queryinput=P%20!%20VIPAR-ARIN> OrgTechName: VIPAR OrgTechPhone: +1-303-645-1900 OrgTechEmail: vipar at us.ntt.net From p.caci at seabone.net Thu Nov 6 02:47:02 2008 From: p.caci at seabone.net (Pierfrancesco Caci) Date: Thu, 06 Nov 2008 09:47:02 +0100 Subject: Internet partitioning event regulations In-Reply-To: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> (Lamar Owen's message of "Wed, 5 Nov 2008 11:59:09 -0500") References: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> Message-ID: <871vxpxmux.fsf@clarabella.noc.seabone.net> :-> "Lamar" == Lamar Owen <lowen at pari.edu> writes: > Charles Wyble charles at thewybles.com wrote: >> Lamar Owen wrote: >> > There are three ways that I know of (feel free to add to this list) to limit the events: >> > 1.) As you mentioned, regulation (or a government run and regulated backbone); >> Right. But what do we want this to look like? > Well, since I've already stepped out on a limb, here goes my try > at a rough outline of what such a regulation might look like > (with the caveat that this is likely too simple to actually make > it as a regulation): [...] > 2.) Allocate regulatory responsibility and enforcement authority > to an entity. I would suggest the FCC would be appropriate. > (This outline might then be the start of a 47 CFR 221 or > similar). [...] > 6.) Mandate that all transit-free Internet carriers shall > maintain peering arrangements with all other transit-free > Internet carriers to maintain a complete Internet (citing some > law that makes a 'complete Internet' a national security matter, > or somesuch, and belongs in 47 CFR 221 as a result). [...] > 8.) Authorize the issuance of a 'Tier 1 Internet Provider' > license (that must be renewed periodically, with documentation > supporting the Tier 1 status) to participating transit-free > Internet carriers (for a fee to cover the opex). > 9.) Authorize the FCC's Enforcement Bureau to enforce. err... do you realize there's about 6.4 * 10^9 other people outside of the USA, don't you? -- ------------------------------------------------------------------------------- Pierfrancesco Caci | Network & System Administrator - INOC-DBA: 6762*PFC p.caci at seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/ Linux clarabella 2.6.15-29-server #1 SMP Mon Sep 24 17:37:57 UTC 2007 i686 GNU/Linux From kraig.beahn at gmail.com Thu Nov 6 02:48:59 2008 From: kraig.beahn at gmail.com (Kraig Beahn) Date: Thu, 6 Nov 2008 03:48:59 -0500 Subject: Cogent, Sprint and NTT? Message-ID: <a9be677f0811060048l76c7ba00p1aeb02f774c0c16d@mail.gmail.com> Cogent transition or prep work this morning? AS 2914 NTT? Anyone else seeing similar changes abroad? ************ CORE INFRASTRUCTURE AFFECTING ALERT ************* -------------------------------------------------------------- BGP Status Change Sequence No: 1225957222 -------------------------------------------------------------- Change Status Type : origin / Origin Set Change -------------------------------------------------------------- BGP Monitored Prefix : 63.166.22.0/24 -------------------------------------------------------------- Update/Detection Time: 1225942611 / 1225957221 BGP ASN Update Time : 1225942611 -------------------------------------------------------------- BGP Set : 1239 -------------------------------------------------------------- BGP Gain(s) : 1239 -------------------------------------------------------------- BGP Loss(s) : -------------------------------------------------------------- Originating Entity : Synips / L2Networks -------------------------------------------------------------- ************ CORE INFRASTRUCTURE AFFECTING ALERT ************* -------------------------------------------------------------- BGP Status Change Sequence No: 1225957222 -------------------------------------------------------------- Change Status Type : last-hop / Last Hop Change -------------------------------------------------------------- BGP Monitored Prefix : 63.166.22.0/24 -------------------------------------------------------------- Update/Detection Time: 1225942611 / 1225957221 BGP ASN Update Time : 1225942611 -------------------------------------------------------------- BGP Set : 2914 -------------------------------------------------------------- BGP Gain(s) : 2914 -------------------------------------------------------------- BGP Loss(s) : -------------------------------------------------------------- Originating Entity : Synips / L2Networks -------------------------------------------------------------- OrgName: NTT America, Inc. OrgID: NTTAM-1 <http://ws.arin.net/whois/?queryinput=O%20!%20NTTAM-1> Address: 8005 South Chester Street Address: Suite 200 City: Centennial StateProv: CO PostalCode: 80112 Country: US ReferralServer: rwhois://rwhois.gin.ntt.net:4321/ ASNumber: 2914 ASName: NTT-COMMUNICATIONS-2914 <http://ws.arin.net/whois/?queryinput=A%20.%20NTT-COMMUNICATIONS-2914> ASHandle: AS2914 <http://ws.arin.net/whois/?queryinput=A%20!%20AS2914> Comment: RegDate: 1998-12-07 Updated: 2006-09-06 RTechHandle: PEERI-ARIN<http://ws.arin.net/whois/?queryinput=P%20!%20PEERI-ARIN> RTechName: Peering RTechPhone: +1-303-645-1900 RTechEmail: peering at ntt.net OrgAbuseHandle: NAAC-ARIN<http://ws.arin.net/whois/?queryinput=P%20!%20NAAC-ARIN> OrgAbuseName: NTT America Abuse Contact OrgAbusePhone: +1-800-551-1630 OrgAbuseEmail: abuse at ntt.net OrgNOCHandle: NASC-ARIN<http://ws.arin.net/whois/?queryinput=P%20!%20NASC-ARIN> OrgNOCName: NTT America Support Contact OrgNOCPhone: +1-800-551-1630 OrgNOCEmail: support at us.ntt.net OrgTechHandle: VIPAR-ARIN<http://ws.arin.net/whois/?queryinput=P%20!%20VIPAR-ARIN> OrgTechName: VIPAR OrgTechPhone: +1-303-645-1900 OrgTechEmail: vipar at us.ntt.net May be just a 'fluke', but we thought the timing was odd. Hope all is well, Kraig From nick at foobar.org Thu Nov 6 04:12:14 2008 From: nick at foobar.org (Nick Hilliard) Date: Thu, 06 Nov 2008 10:12:14 +0000 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <84700.1225936812@turing-police.cc.vt.edu> References: <20081105144627.69FFF1B2@resin15.mta.everyone.net> <84700.1225936812@turing-police.cc.vt.edu> Message-ID: <4912C2FE.1000908@foobar.org> On 06/11/2008 02:00, Valdis.Kletnieks at vt.edu wrote: > Who owns the DNS root? The US Government claims to. However, asserting authority over the DNS root is a different matter to a mere claim to ownership, and if the US Government were to unilaterally decide on an action which directly acted against the interests of various other stakeholders in the DNS root (say, the rest of the world - and hey, did anyone mention that there are about 6.4 * 10^9 people outside the USA?), then there are a variety of remedies to the situation, most of which involve balkanisation and all of which are pretty unpalatable to all stakeholders, including the US. IOW: the DNS root is a system based on trust, rather than mandate of the the USG. Nick From kurtis at kurtis.pp.se Thu Nov 6 07:56:36 2008 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 6 Nov 2008 14:56:36 +0100 Subject: NTP Md5 or AutoKey? In-Reply-To: <A868F243F1934C26848C2270469A2CFE@ltdbeast> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com><6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com><125265.1225781525@turing-police.cc.vt.edu> <92c950310811040047m2c5243c6w6c87648c3e73fb3b@mail.gmail.com> <A868F243F1934C26848C2270469A2CFE@ltdbeast> Message-ID: <205F37BA-769A-438D-B342-CA8403366B2D@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4 nov 2008, at 10.14, Lincoln Dale wrote: >> There is an emerging need to distribute highly accurate time >> information over IP and over MPLS packet switched networks (PSNs). > > good of you to ask. it exists today. > http://ieee1588.nist.gov/ Just a shame the world is not built on Ethernets. IETF tried to do TICTOC which will/could have done a better time-transfer over any IP network. But...let's see... Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkS95QACgkQAFdZ6xrc/t5kvQCgscel1cEN2rid9sznzaAGPbi0 7BAAn1BsqRrZzFMTfDJHbctMeGkXxVKu =7A5W -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Thu Nov 6 07:57:21 2008 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 6 Nov 2008 14:57:21 +0100 Subject: NTP Md5 or AutoKey? In-Reply-To: <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> Message-ID: <5A61F20A-10F8-436F-AB62-4BDB8BCE5D91@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4 nov 2008, at 07.23, Paul Ferguson wrote: > > I'm just wondering -- in globak scheme of security issue, is NTP > security a major issue? > > Just curious. Maybe not NTP per se but timing is. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkS98IACgkQAFdZ6xrc/t5TFgCgsCtZvsgwdVvaJYflTLVPxI4D zpQAn39r49MJ3VKU4SrHCnYoVpqpU8Ej =chKQ -----END PGP SIGNATURE----- From jtraylor at networkinglinux.net Thu Nov 6 17:30:57 2008 From: jtraylor at networkinglinux.net (Jonathan Traylor) Date: Thu, 6 Nov 2008 17:30:57 -0600 Subject: Google SMTP acceptance policy? In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAA1yA4fMz3oTK8+q7AdmpjXAQAAAAA=@iname.com> References: <20081106020803.GA7376@gonzo.fearandloathing.org> <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAA1yA4fMz3oTK8+q7AdmpjXAQAAAAA=@iname.com> Message-ID: <20081106233056.GA22900@gonzo.fearandloathing.org> Thanks. These links have been of some assistance, however some of the questions seem irrelevant to the specified situation once the a first handful are answered. Perhaps they are intended to be a test of a person's comprehensive ability (or not). Someone off-list mentioned the possible google 'sandbox effect'[1] seen with new web presences, which relates to some 'build your reptition long and solid' responses. I have been able to make contact with a few that will hopefully result in a more transparent solution then 'wait and see.' [1] http://tinyurl.com/636twn Thanks to all who responsed on and off-list. -- Jonathan On Wed, Nov 05, 2008 at 10:06:12PM -0600, Frank Bulk wrote: > Have you worked through this Q/A process? > http://mail.google.com/support/bin/answer.py?answer=80369 > I went through it and at the end it says there's not a way to whitelist a > domain. > > For Bulk e-mail senders: > https://mail.google.com/support/bin/answer.py?answer=17205 > > There's this checklist, too: > https://mail.google.com/support/bin/answer.py?answer=81126 > > And here's a form to fill out: > https://mail.google.com/support/bin/request.py?ctx=bulksend&nomods=1 From kb3ien+nanog at databit7.com Thu Nov 6 23:03:17 2008 From: kb3ien+nanog at databit7.com (kb3ien+nanog at databit7.com) Date: Fri, 7 Nov 2008 05:03:17 +0000 (UTC) Subject: On the subject of multihoming In-Reply-To: <4910B14B.9010108@thewybles.com> References: <4910B14B.9010108@thewybles.com> Message-ID: <Pine.NEB.4.64.0811070457570.13626@andromeda.ziaspace.com> Yes bgp multihop is a GREAT* way to figure out if a cablemodem** is even /really/ online. Alas, I've not see much on the traffic engineering side either. * Read "the only way i've found to do this with cisco's ios" ** or any other pipe for that matter. On Tue, 4 Nov 2008, Charles Wyble wrote: > Date: Tue, 04 Nov 2008 12:32:11 -0800 > From: Charles Wyble <charles at thewybles.com> > To: NANOG list <nanog at nanog.org> > Subject: On the subject of multihoming > > I'm working on a small experiment which utilizes multiple outbound links (in > the experiments case multiple consumer 3G connections [to 2 Sprint/2 > Verizon/1 AT&T], Time Warner Cable Modem and an SBC Global DSL connection. > > What is the best way to do outbound traffic engineering? I would like to be > able to determine the best path possible and send traffic out the appropriate > link. > > Could this be done with a copy of the BGP tables? > > Obviously as they are consumer connections, I wouldn't get a BGP feed so > would need to download a copy, which has the risk of stale data. Perhaps some > sort of multihop BGP setup? > > I have done some research and found a lot of references to small site > multihoming without BGP for link redundancy but not for traffic engineering. > > > Thanks. > > Charles > > From swmike at swm.pp.se Fri Nov 7 01:27:58 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 7 Nov 2008 08:27:58 +0100 (CET) Subject: ECN Message-ID: <alpine.DEB.1.10.0811070815360.10993@uplift.swm.pp.se> Hi, On LKML (Linux Kernel Mailing List) there is talk <http://lkml.org/lkml/2008/11/4/151> about shipping the Linux kernel with ECN turned on by default (it was on by default a few years back but that change was reverted due to too many sites dropping ECN enabled SYNs). Recent investigations <http://www.imperialviolet.org/binary/ecntest.pdf> shows that 0.5% of end hosts will drop SYN packets with ECN turned on. This is approximately the same rate I have seen for A/AAAA adoption in this tread <http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01585.html>. Do we in the operational ISP community have an opinion on ECN adoption that we want to voice? As far as I can discern from <http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftwrdecn.html> for ECN to actually be useful, we (the ISPs) have to turn this option on in the routers as well. Is anyone doing this today? What vendors support it? When I thought about it, the IP core (10G links etc) first came to mind, and there it's fairly easy to roll out (since I guess a lot of us do WRED already), but what about on slower links? Would it make sense to have our DSLAMs do this? What about DSL/cable modems (well, vendors should first realise that FIFO is not great to begin with :P) ? <http://www.icir.org/tbit/> is a summary page I found on ECN that looks like a good resource for further reading. Is anyone looking into including ECN configuration into some BCP document? -- Mikael Abrahamsson email: swmike at swm.pp.se From david.freedman at uk.clara.net Fri Nov 7 03:14:26 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 07 Nov 2008 09:14:26 +0000 Subject: ECN In-Reply-To: <alpine.DEB.1.10.0811070815360.10993@uplift.swm.pp.se> References: <alpine.DEB.1.10.0811070815360.10993@uplift.swm.pp.se> Message-ID: <gf10ti$i4k$1@ger.gmane.org> > When I thought about it, the IP core (10G links etc) first came to mind, > and there it's fairly easy to roll out (since I guess a lot of us do > WRED already), but what about on slower links? Would it make sense to > have our DSLAMs do this? What about DSL/cable modems (well, vendors > should first realise that FIFO is not great to begin with :P) ? Implementing this in an MPLS core is not an easy task, you can really only do this on the edge, when the MPLS labelled packet arrives at an LSR, we don't know if it contains a TCP segment or not (fancy deep h/w implementations excluded), all we know is that , if there is congestion, we can discard it based on the EXP bits in the shim. Dave. From david.freedman at uk.clara.net Fri Nov 7 03:22:33 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 07 Nov 2008 09:22:33 +0000 Subject: MPLS for IPv6 In-Reply-To: <20081104223637.GA16085@srv03.cluenet.de> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> <20081104223637.GA16085@srv03.cluenet.de> Message-ID: <491408D9.2040902@uk.clara.net> Well, don't know about anybody else, but I've been asking vendors for LDP6 for a while now, every time we approach them for new projects and they always look embarrassed when they realise that they a. don't have it b. are not involved in the standards process (draft-manral-mpls-ldp-ipv6-02) So please, if you are spending your hard earned cash, please ask for an LDP6 implementation, "no demand" should not be the case. Dave. Daniel Roesen wrote: > On Tue, Nov 04, 2008 at 02:53:46PM -0600, devang patel wrote: >> Does any vendor support the MPLS for native IPv6 network? > > Unfortunately noone of the major vendors have yet implemented MPLS > control plane via IPv6 transport. From my understanding, the protocol > specs are there, just no implementation. > > So for now, you still have to use IPv4 for the MPLS network control > plane and must either forward IPv6 natively dual-stack alongside IPv4, > or transport IPv6 via 6(V)PE. > > "no customer demand", as usual. It's just us weirdos trying to do such > things. :) > > > Best regards, > Daniel > From bjorn at mork.no Fri Nov 7 03:32:36 2008 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 07 Nov 2008 10:32:36 +0100 Subject: ECN In-Reply-To: <gf10ti$i4k$1@ger.gmane.org> (David Freedman's message of "Fri, 07 Nov 2008 09:14:26 +0000") References: <alpine.DEB.1.10.0811070815360.10993@uplift.swm.pp.se> <gf10ti$i4k$1@ger.gmane.org> Message-ID: <871vxnx4nf.fsf@obelix.mork.no> David Freedman <david.freedman at uk.clara.net> writes: > Implementing this in an MPLS core is not an easy task, you can really > only do this on the edge, when the MPLS labelled packet arrives at an > LSR, we don't know if it contains a TCP segment or not (fancy deep h/w > implementations excluded), all we know is that , if there is congestion, > we can discard it based on the EXP bits in the shim. Please see RFC 5129 Bj?rn From cidr-report at potaroo.net Fri Nov 7 05:00:07 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Nov 2008 22:00:07 +1100 (EST) Subject: BGP Update Report Message-ID: <200811071100.mA7B07Fd029473@wattle.apnic.net> BGP Update Report Interval: 06-Oct-08 -to- 06-Nov-08 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 190435 1.7% 169.6 -- SIFY-AS-IN Sify Limited 2 - AS10396 163475 1.5% 2069.3 -- COQUI-NET - DATACOM CARIBE, INC. 3 - AS4538 149721 1.3% 29.5 -- ERX-CERNET-BKB China Education and Research Network Center 4 - AS6389 111964 1.0% 25.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 5 - AS1803 87137 0.8% 61.8 -- ICMNET-5 - Sprint 6 - AS6629 81928 0.7% 1260.4 -- NOAA-AS - NOAA 7 - AS20115 67980 0.6% 29.3 -- CHARTER-NET-HKY-NC - Charter Communications 8 - AS23126 65226 0.6% 282.4 -- CENTURYTEL-SOLUTIONS-LLC - CenturyTel Solutions, LLC 9 - AS8151 59659 0.5% 41.7 -- Uninet S.A. de C.V. 10 - AS9051 57707 0.5% 358.4 -- IDM Autonomous System 11 - AS6298 55678 0.5% 26.5 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 12 - AS5691 51713 0.5% 3977.9 -- MITRE-AS-5 - The MITRE Corporation 13 - AS2386 47914 0.4% 29.0 -- INS-AS - AT&T Data Communications Services 14 - AS7643 46600 0.4% 26.2 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 15 - AS209 43031 0.4% 13.6 -- ASN-QWEST - Qwest Communications Corporation 16 - AS6458 42281 0.4% 103.4 -- Telgua 17 - AS10986 41094 0.4% 461.7 -- Intermedia Comunicaciones S.A. 18 - AS7046 40490 0.4% 68.9 -- UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 19 - AS17974 40393 0.4% 49.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS22492 37053 0.3% 12351.0 -- TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 26113 0.2% 26113.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS43299 20671 0.2% 20671.0 -- TELECONTACT-AS Telecontact Ltd. 3 - AS22492 37053 0.3% 12351.0 -- 4 - AS37026 21597 0.2% 10798.5 -- SALT-ASN 5 - AS14106 19463 0.2% 9731.5 -- LEPMED01 - Leprechaun, LLC 6 - AS29282 25136 0.2% 8378.7 -- EMENTOR-AS Enfo Oyj 7 - AS30287 5351 0.1% 5351.0 -- ALON-USA - ALON USA, LP 8 - AS40194 4287 0.0% 4287.0 -- INHOUSE-ASSOCIATES-LC - Inhouse Associates, L.C. 9 - AS5691 51713 0.5% 3977.9 -- MITRE-AS-5 - The MITRE Corporation 10 - AS21603 36731 0.3% 3673.1 -- Universidad La Salle, AC 11 - AS14220 18225 0.2% 3645.0 -- I2A - I 20 Access 12 - AS4130 16403 0.1% 3280.6 -- UPITT-AS - University of Pittsburgh 13 - AS30969 26216 0.2% 3277.0 -- TAN-NET TransAfrica Networks 14 - AS41007 15516 0.1% 3103.2 -- CTCASTANA CTC ASTANA, KZ 15 - AS25799 2787 0.0% 2787.0 -- HOLMAN - Holman Enterprises 16 - AS23082 13759 0.1% 2751.8 -- MPHI - Michigan Public Health Institute 17 - AS29910 2505 0.0% 2505.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 18 - AS5033 21839 0.2% 2426.6 -- ISW - Internet Specialties West Inc. 19 - AS23917 2383 0.0% 2383.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 20 - AS22247 2115 0.0% 2115.0 -- LETOURNEAUUNIVERSITY - LeTourneau University TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 221.134.222.0/24 62667 0.5% AS9583 -- SIFY-AS-IN Sify Limited 2 - 210.214.151.0/24 60146 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 192.12.120.0/24 51378 0.4% AS5691 -- MITRE-AS-5 - The MITRE Corporation 4 - 221.135.80.0/24 44512 0.4% AS9583 -- SIFY-AS-IN Sify Limited 5 - 194.126.143.0/24 44323 0.4% AS9051 -- IDM Autonomous System 6 - 12.2.46.0/24 37016 0.3% AS22492 -- 7 - 200.33.104.0/23 36141 0.3% AS21603 -- Universidad La Salle, AC 8 - 192.102.88.0/24 27029 0.2% AS6629 -- NOAA-AS - NOAA 9 - 198.77.177.0/24 26874 0.2% AS6629 -- NOAA-AS - NOAA 10 - 192.35.129.0/24 26796 0.2% AS6629 -- NOAA-AS - NOAA 11 - 12.8.7.0/24 26113 0.2% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 12 - 221.128.192.0/18 24436 0.2% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 13 - 64.162.116.0/24 21615 0.2% AS5033 -- ISW - Internet Specialties West Inc. 14 - 78.40.24.0/21 20671 0.2% AS43299 -- TELECONTACT-AS Telecontact Ltd. 15 - 196.42.0.0/20 19289 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 16 - 72.50.96.0/20 19216 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 17 - 77.95.144.0/22 17544 0.1% AS29282 -- EMENTOR-AS Enfo Oyj 18 - 150.212.224.0/19 16299 0.1% AS4130 -- UPITT-AS - University of Pittsburgh 19 - 89.4.131.0/24 14317 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 196.27.104.0/21 12955 0.1% AS30969 -- TAN-NET TransAfrica Networks Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From david.freedman at uk.clara.net Fri Nov 7 05:00:07 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 07 Nov 2008 11:00:07 +0000 Subject: ECN In-Reply-To: <871vxnx4nf.fsf@obelix.mork.no> References: <alpine.DEB.1.10.0811070815360.10993@uplift.swm.pp.se> <gf10ti$i4k$1@ger.gmane.org> <871vxnx4nf.fsf@obelix.mork.no> Message-ID: <gf173n$6bn$1@ger.gmane.org> Interesting , I hadn't followed this since draft-ietf-mpls-ecn-00, , I eagerly await a vendor implementation :) Dave. Bj?rn Mork wrote: > David Freedman <david.freedman at uk.clara.net> writes: > >> Implementing this in an MPLS core is not an easy task, you can really >> only do this on the edge, when the MPLS labelled packet arrives at an >> LSR, we don't know if it contains a TCP segment or not (fancy deep h/w >> implementations excluded), all we know is that , if there is congestion, >> we can discard it based on the EXP bits in the shim. > > Please see RFC 5129 > > > Bj?rn > > From cidr-report at potaroo.net Fri Nov 7 05:00:01 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Nov 2008 22:00:01 +1100 (EST) Subject: The Cidr Report Message-ID: <200811071100.mA7B01Gx029447@wattle.apnic.net> This report has been generated at Fri Nov 7 21:37:28 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 31-10-08 286084 173833 01-11-08 285919 173798 02-11-08 286141 173214 03-11-08 286324 173843 04-11-08 286582 175158 05-11-08 287251 176072 06-11-08 287660 176586 07-11-08 287743 177356 AS Summary 29924 Number of ASes in routing system 12670 Number of ASes announcing only one prefix 5055 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88277504 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 07Nov08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 287934 177341 110593 38.4% All ASes AS4538 5055 873 4182 82.7% ERX-CERNET-BKB China Education and Research Network Center AS6389 4365 358 4007 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 3042 1349 1693 55.7% ASN-QWEST - Qwest Communications Corporation AS1785 1693 212 1481 87.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS6298 2080 697 1383 66.5% ASN-CXA-PH-6298-CBS - Cox Communications Inc. AS4755 1518 290 1228 80.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1410 296 1114 79.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1572 557 1015 64.6% TWTC - tw telecom holdings, inc. AS6478 1650 721 929 56.3% ATT-INTERNET3 - AT&T WorldNet Services AS22773 1005 94 911 90.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1402 566 836 59.6% Uninet S.A. de C.V. AS11492 1211 468 743 61.4% CABLEONE - CABLE ONE, INC. AS19262 931 244 687 73.8% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1596 922 674 42.2% INS-AS - AT&T Data Communications Services AS18566 1059 426 633 59.8% COVAD - Covad Communications Co. AS9498 696 118 578 83.0% BBIL-AP BHARTI Airtel Ltd. AS18101 784 223 561 71.6% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS855 596 124 472 79.2% CANET-ASN-4 - Bell Aliant AS7545 613 141 472 77.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS4808 630 159 471 74.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 605 158 447 73.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 522 79 443 84.9% GIGAINFRA BB TECHNOLOGY Corp. AS9443 526 85 441 83.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS22047 567 128 439 77.4% VTR BANDA ANCHA S.A. AS7018 1439 1003 436 30.3% ATT-INTERNET4 - AT&T WorldNet Services AS4134 880 464 416 47.3% CHINANET-BACKBONE No.31,Jin-rong Street AS4668 688 275 413 60.0% LGNET-AS-KR LG CNS AS7011 923 515 408 44.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4780 730 336 394 54.0% SEEDNET Digital United Inc. AS7029 479 87 392 81.8% WINDSTREAM - Windstream Communications Inc Total 40267 11968 28299 70.3% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 87.254.160.0/19 AS34754 TELNET-AS Telnet Ltd. 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 119.31.232.0/21 AS38870 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 121.50.175.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 124.109.16.0/21 AS38137 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 169.254.0.0/16 AS13184 HANSENET HanseNet Telekommunikation GmbH 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.0.187.0/24 AS19132 200.5.32.0/21 AS19132 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/21 AS38205 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.168.80.0/21 AS24034 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 202.191.8.0/21 AS10223 UECOMM-AU Uecomm Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 212.13.0.0/19 AS38964 ADTEL-AS Advantage Telecom JSC 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From swmike at swm.pp.se Fri Nov 7 05:04:12 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 7 Nov 2008 12:04:12 +0100 (CET) Subject: ECN In-Reply-To: <gf10ti$i4k$1@ger.gmane.org> References: <alpine.DEB.1.10.0811070815360.10993@uplift.swm.pp.se> <gf10ti$i4k$1@ger.gmane.org> Message-ID: <alpine.DEB.1.10.0811071202260.10993@uplift.swm.pp.se> On Fri, 7 Nov 2008, David Freedman wrote: > Implementing this in an MPLS core is not an easy task, you can really > only do this on the edge, when the MPLS labelled packet arrives at an > LSR, we don't know if it contains a TCP segment or not (fancy deep h/w > implementations excluded), all we know is that , if there is congestion, > we can discard it based on the EXP bits in the shim. I did some more checking and neither 12000 (IOS) nor CRS-1 seems to support WRED with ECN (at least the command doesn't show when I create a policy-map), so I'm going to ping my Cisco SE and hear about what's going on. -- Mikael Abrahamsson email: swmike at swm.pp.se From michal at krsek.cz Fri Nov 7 08:17:28 2008 From: michal at krsek.cz (Michal Krsek) Date: Fri, 07 Nov 2008 15:17:28 +0100 Subject: Internet partitioning event regulations (was: RE: Sending vs requesting. Was: Re: Sprint / Cogent) In-Reply-To: <3c3e3fca0811051432i21e068eahf9933e59365eb76c@mail.gmail.com> References: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> <4911D404.3070400@cox.net> <3c3e3fca0811051432i21e068eahf9933e59365eb76c@mail.gmail.com> Message-ID: <49144DF8.6060302@krsek.cz> > First, let me say that I think peering regulation is a terrible idea. > No matter how cleverly you plan it, the result will be that fewer > small companies can participate. That's the character of regulation: > compliance creates more barriers to entry than it removes. > > That having been said, jurisdiction is a red herring. Every > transit-free provider does at least some of its business in the United > States. Economic reality compels them to continue to do so for the > foreseeable future. That's all the hook the Feds need. > Have you kept in your mind that this may be changed in future? I know, we are talking in NANOG, but ... Some regions works on Internet development a bit faster than US and in future, this regulation may motivate some overseas players to stop peering in US. For example LINX and AMS-IX are good place to get peering in EU. Regards MK From Valdis.Kletnieks at vt.edu Fri Nov 7 11:31:22 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 07 Nov 2008 12:31:22 -0500 Subject: ECN In-Reply-To: Your message of "Fri, 07 Nov 2008 08:27:58 +0100." <alpine.DEB.1.10.0811070815360.10993@uplift.swm.pp.se> References: <alpine.DEB.1.10.0811070815360.10993@uplift.swm.pp.se> Message-ID: <27621.1226079082@turing-police.cc.vt.edu> On Fri, 07 Nov 2008 08:27:58 +0100, Mikael Abrahamsson said: > for ECN to actually be useful, we (the ISPs) have to turn this option on > in the routers as well. Is anyone doing this today? What vendors support > it? The only thing that's *required* for it to help is that the routers and firewalls not actually *molest* the bits in the TCP SYN packet. If you pass them and *do nothing else*, it at least has the potential of being useful at some other router along the path. And let's face it - if *your* router is congested enough for ECN to matter, there's a fairly good chance that the router one hop up/downstream is *also* seeing some effects. Even if *you* don't do anything else, your neighbor might - helping you out in the bargain. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081107/392d134b/attachment.bin> From cscora at apnic.net Fri Nov 7 12:11:43 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Nov 2008 04:11:43 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200811071811.mA7IBhMG021382@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <pfs at cisco.com>. Routing Table Report 04:00 +10GMT Sat 08 Nov, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 272998 Prefixes after maximum aggregation: 131801 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 133598 Total ASes present in the Internet Routing Table: 29730 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 25883 Origin ASes announcing only one prefix: 12609 Transit ASes present in the Internet Routing Table: 3847 Transit-only ASes present in the Internet Routing Table: 84 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 574 Unregistered ASNs in the Routing Table: 202 Number of 32-bit ASNs allocated by the RIRs: 62 Prefixes from 32-bit ASNs in the Routing Table: 9 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 202 Number of addresses announced to Internet: 1920631360 Equivalent to 114 /8s, 122 /16s and 130 /24s Percentage of available address space announced: 51.8 Percentage of allocated address space announced: 62.6 Percentage of available address space allocated: 82.8 Percentage of address space in use by end-sites: 74.2 Total number of prefixes smaller than registry allocations: 134144 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62514 Total APNIC prefixes after maximum aggregation: 23424 APNIC Deaggregation factor: 2.67 Prefixes being announced from the APNIC address blocks: 59420 Unique aggregates announced from the APNIC address blocks: 26950 APNIC Region origin ASes present in the Internet Routing Table: 3452 APNIC Prefixes per ASN: 17.21 APNIC Region origin ASes announcing only one prefix: 932 APNIC Region transit ASes present in the Internet Routing Table: 535 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 380616864 Equivalent to 22 /8s, 175 /16s and 192 /24s Percentage of available APNIC address space announced: 81.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123687 Total ARIN prefixes after maximum aggregation: 64998 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 93211 Unique aggregates announced from the ARIN address blocks: 35626 ARIN Region origin ASes present in the Internet Routing Table: 12572 ARIN Prefixes per ASN: 7.41 ARIN Region origin ASes announcing only one prefix: 4862 ARIN Region transit ASes present in the Internet Routing Table: 1198 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 368498336 Equivalent to 21 /8s, 246 /16s and 214 /24s Percentage of available ARIN address space announced: 75.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 59832 Total RIPE prefixes after maximum aggregation: 36005 RIPE Deaggregation factor: 1.66 Prefixes being announced from the RIPE address blocks: 55490 Unique aggregates announced from the RIPE address blocks: 37170 RIPE Region origin ASes present in the Internet Routing Table: 12142 RIPE Prefixes per ASN: 4.57 RIPE Region origin ASes announcing only one prefix: 6395 RIPE Region transit ASes present in the Internet Routing Table: 1842 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 377756960 Equivalent to 22 /8s, 132 /16s and 29 /24s Percentage of available RIPE address space announced: 86.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22261 Total LACNIC prefixes after maximum aggregation: 5619 LACNIC Deaggregation factor: 3.96 Prefixes being announced from the LACNIC address blocks: 20244 Unique aggregates announced from the LACNIC address blocks: 11339 LACNIC Region origin ASes present in the Internet Routing Table: 1028 LACNIC Prefixes per ASN: 19.69 LACNIC Region origin ASes announcing only one prefix: 338 LACNIC Region transit ASes present in the Internet Routing Table: 169 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 57736192 Equivalent to 3 /8s, 112 /16s and 252 /24s Percentage of available LACNIC address space announced: 57.4 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4151 Total AfriNIC prefixes after maximum aggregation: 1323 AfriNIC Deaggregation factor: 3.14 Prefixes being announced from the AfriNIC address blocks: 4434 Unique aggregates announced from the AfriNIC address blocks: 2165 AfriNIC Region origin ASes present in the Internet Routing Table: 266 AfriNIC Prefixes per ASN: 16.67 AfriNIC Region origin ASes announcing only one prefix: 82 AfriNIC Region transit ASes present in the Internet Routing Table: 52 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 12919552 Equivalent to 0 /8s, 197 /16s and 35 /24s Percentage of available AfriNIC address space announced: 25.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 17488 1409 99 102 Hathway IP Over Cable Interne 4755 1310 516 177 TATA Communications formerly 9583 1110 87 476 Sify Limited 4766 886 6409 364 Korea Telecom (KIX) 4134 878 13772 361 CHINANET-BACKBONE 23577 815 35 700 Korea Telecom (ATM-MPLS) 18101 783 161 67 Reliance Infocom Ltd Internet 4780 727 357 63 Digital United Inc. 9498 694 295 54 BHARTI BT INTERNET LTD. 4808 630 1172 143 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4356 3417 340 bellsouth.net, inc. 209 3042 4035 623 Qwest 6298 2079 326 690 Cox Communicatons 1785 1693 717 154 PaeTec Communications, Inc. 20115 1660 1452 725 Charter Communications 6478 1650 363 193 AT&T Worldnet Services 2386 1587 700 898 AT&T Data Communications Serv 4323 1575 1084 377 Time Warner Telecom 7018 1402 5869 970 AT&T WorldNet Services 11492 1210 149 16 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 429 1766 381 TDC Tele Danmark 30890 348 94 188 SC Kappa Invexim SRL 3301 332 1429 303 TeliaNet Sweden 3215 331 2788 99 France Telecom Transpac 8866 331 111 23 Bulgarian Telecommunication C 3320 326 7063 275 Deutsche Telekom AG 8452 325 188 11 TEDATA 5462 300 794 27 Telewest Broadband 25233 289 44 24 Awalnet 8551 287 270 37 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1400 2848 218 UniNet S.A. de C.V. 11830 670 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 10620 545 126 59 TVCABLE BOGOTA 7303 494 243 69 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 420 85 49 ENTEL CHILE S.A. 11172 405 118 72 Servicios Alestra S.A de C.V 28573 341 468 23 NET Servicos de Comunicao S.A 14117 330 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 562 73 45 LINKdotNET AS number 3741 270 856 226 The Internet Solution 20858 256 34 3 EgyNet 2018 238 215 140 Tertiary Education Network 6713 142 135 11 Itissalat Al-MAGHRIB 33783 141 10 15 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 5713 114 555 63 Telkom SA Ltd 29571 113 13 9 Ci Telecom Autonomous system 33776 109 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4356 3417 340 bellsouth.net, inc. 209 3042 4035 623 Qwest 6298 2079 326 690 Cox Communicatons 1785 1693 717 154 PaeTec Communications, Inc. 20115 1660 1452 725 Charter Communications 6478 1650 363 193 AT&T Worldnet Services 2386 1587 700 898 AT&T Data Communications Serv 4323 1575 1084 377 Time Warner Telecom 17488 1409 99 102 Hathway IP Over Cable Interne 7018 1402 5869 970 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 3042 2419 Qwest 1785 1693 1539 PaeTec Communications, Inc. 6478 1650 1457 AT&T Worldnet Services 6298 2079 1389 Cox Communicatons 17488 1409 1307 Hathway IP Over Cable Interne 4323 1575 1198 Time Warner Telecom 11492 1210 1194 Cable One 8151 1400 1182 UniNet S.A. de C.V. 4755 1310 1133 TATA Communications formerly 18566 1059 1049 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.191.124.0/22 2905 Verizon South Africa 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:9 /10:18 /11:46 /12:149 /13:298 /14:538 /15:1067 /16:10137 /17:4427 /18:7668 /19:16493 /20:19336 /21:19024 /22:24005 /23:24859 /24:142112 /25:840 /26:1017 /27:832 /28:88 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2851 4356 bellsouth.net, inc. 6298 2053 2079 Cox Communicatons 209 1756 3042 Qwest 2386 1269 1587 AT&T Data Communications Serv 17488 1198 1409 Hathway IP Over Cable Interne 11492 1187 1210 Cable One 1785 1156 1693 PaeTec Communications, Inc. 6478 1105 1650 AT&T Worldnet Services 18566 1040 1059 Covad Communications 9583 977 1110 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:154 12:2178 13:2 15:21 16:3 17:5 20:35 24:1087 32:54 38:518 40:92 41:775 43:1 44:2 47:13 52:3 55:3 56:3 57:26 58:516 59:533 60:452 61:1032 62:1139 63:2009 64:3277 65:2428 66:3501 67:1313 68:808 69:2331 70:878 71:137 72:2065 73:7 74:1276 75:167 76:290 77:878 78:517 79:282 80:924 81:865 82:609 83:397 84:584 85:1025 86:509 87:704 88:347 89:1353 90:25 91:1661 92:288 93:963 94:326 95:34 96:86 97:128 98:386 99:15 113:40 114:119 115:144 116:1005 117:402 118:241 119:516 120:102 121:609 122:855 123:444 124:861 125:1226 128:353 129:217 130:135 131:407 132:72 133:9 134:186 135:31 136:224 137:102 138:145 139:83 140:414 141:111 142:391 143:298 144:302 145:52 146:373 147:140 148:605 149:211 150:129 151:208 152:150 153:136 154:10 155:274 156:174 157:302 158:168 159:282 160:273 161:140 162:247 163:135 164:518 165:503 166:361 167:341 168:630 169:155 170:454 171:40 172:10 173:129 174:1 187:18 188:1 189:308 190:2373 192:5825 193:4153 194:3291 195:2639 196:1018 198:3717 199:3308 200:5551 201:1479 202:7672 203:8036 204:3927 205:2189 206:2310 207:2772 208:3717 209:3459 210:2589 211:1093 212:1537 213:1631 214:69 215:25 216:4355 217:1252 218:351 219:421 220:1059 221:418 222:302 End of report From leslie at craigslist.org Fri Nov 7 15:30:32 2008 From: leslie at craigslist.org (Leslie) Date: Fri, 7 Nov 2008 13:30:32 -0800 Subject: Advice/resources for setting up TACACS server Message-ID: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> Hi -- We are currently trying to set up a TACACS server for authentication to our network gear and have it run on suse linux hosts. Does anyone have any advice/good webpages or guides regarding this? Thank you very much in advance! Leslie From nanog at castalie.org Fri Nov 7 15:38:04 2008 From: nanog at castalie.org (Simon Vallet) Date: Fri, 7 Nov 2008 22:38:04 +0100 Subject: Advice/resources for setting up TACACS server In-Reply-To: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> References: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> Message-ID: <20081107223804.7074da39@mlejnas.priv.castalie.org> Hi, On Fri, 7 Nov 2008 13:30:32 -0800 Leslie <leslie at craigslist.org> wrote: > We are currently trying to set up a TACACS server for authentication > to our network gear and have it run on suse linux hosts. Does anyone > have any advice/good webpages or guides regarding this? I really don't mean to troll, but I think you probably should authenticate against RADIUS instead. Simon From leslie at craigslist.org Fri Nov 7 15:44:23 2008 From: leslie at craigslist.org (Leslie) Date: Fri, 7 Nov 2008 13:44:23 -0800 Subject: Advice/resources for setting up TACACS server In-Reply-To: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> References: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> Message-ID: <952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org> The best answer actually does seem to be to use freeradius instead of tacacs, so I will probably go with that (though if anyone has any good tips on freeradius, please, let me know) Leslie On Nov 7, 2008, at 1:30 PM, Leslie wrote: > Hi -- > > We are currently trying to set up a TACACS server for authentication > to our network gear and have it run on suse linux hosts. Does > anyone have any advice/good webpages or guides regarding this? > > Thank you very much in advance! > > Leslie From rmaunier at neotelecoms.com Fri Nov 7 15:53:09 2008 From: rmaunier at neotelecoms.com (Raphael Maunier) Date: Fri, 07 Nov 2008 22:53:09 +0100 Subject: Advice/resources for setting up TACACS server In-Reply-To: <952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org> References: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> <952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org> Message-ID: <4914B8C5.3030206@neotelecoms.com> Hi, You can extract information from this doc : Installation of Tacacs+, Rancid, Cvsweb http://www.debian-administration.org/articles/429 Freeradius will need more time to implement, but easier to manage after. -- Rapha?l Maunier NEO TELECOMS Engineering Manager 2 rue du Chemin Vert 92110 Clichy - France rmaunier at neotelecoms.com Leslie a ?crit : > The best answer actually does seem to be to use freeradius instead of > tacacs, so I will probably go with that (though if anyone has any good > tips on freeradius, please, let me know) > > Leslie > > On Nov 7, 2008, at 1:30 PM, Leslie wrote: > >> Hi -- >> >> We are currently trying to set up a TACACS server for authentication >> to our network gear and have it run on suse linux hosts. Does anyone >> have any advice/good webpages or guides regarding this? >> >> Thank you very much in advance! >> >> Leslie > > From sking at kingrst.com Fri Nov 7 16:39:14 2008 From: sking at kingrst.com (Steven King) Date: Fri, 07 Nov 2008 17:39:14 -0500 Subject: Advice/resources for setting up TACACS server In-Reply-To: <952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org> References: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> <952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org> Message-ID: <4914C392.9010500@kingrst.com> I disagree with the RADIUS suggestion. TACACS+ is a much more secure protocol. It encrypts the packet contents and has a more secure handshake procedure. Leslie wrote: > The best answer actually does seem to be to use freeradius instead of > tacacs, so I will probably go with that (though if anyone has any good > tips on freeradius, please, let me know) > > Leslie > > On Nov 7, 2008, at 1:30 PM, Leslie wrote: > >> Hi -- >> >> We are currently trying to set up a TACACS server for authentication >> to our network gear and have it run on suse linux hosts. Does anyone >> have any advice/good webpages or guides regarding this? >> >> Thank you very much in advance! >> >> Leslie > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From eddy at fasteddy.org Fri Nov 7 16:43:53 2008 From: eddy at fasteddy.org (Eddy Martinez) Date: Fri, 7 Nov 2008 14:43:53 -0800 Subject: Advice/resources for setting up TACACS server In-Reply-To: <4914C392.9010500@kingrst.com> References: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> <952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org> <4914C392.9010500@kingrst.com> Message-ID: <2FF1C77F-93CC-4196-AF74-EEC425189354@fasteddy.org> I second the TACACS+ Thats what you want. Same effort for the most part, to implement. Eddy On Nov 7, 2008, at 2:39 PM, Steven King wrote: > I disagree with the RADIUS suggestion. TACACS+ is a much more secure > protocol. It encrypts the packet contents and has a more secure > handshake procedure. > > Leslie wrote: >> The best answer actually does seem to be to use freeradius instead of >> tacacs, so I will probably go with that (though if anyone has any >> good >> tips on freeradius, please, let me know) >> >> Leslie >> >> On Nov 7, 2008, at 1:30 PM, Leslie wrote: >> >>> Hi -- >>> >>> We are currently trying to set up a TACACS server for authentication >>> to our network gear and have it run on suse linux hosts. Does >>> anyone >>> have any advice/good webpages or guides regarding this? >>> >>> Thank you very much in advance! >>> >>> Leslie >> >> > > -- > Steve King > > Network Engineer - Liquid Web, Inc. > Cisco Certified Network Associate > CompTIA Linux+ Certified Professional > CompTIA A+ Certified Professional > > From leslie at craigslist.org Fri Nov 7 16:56:44 2008 From: leslie at craigslist.org (Leslie) Date: Fri, 7 Nov 2008 14:56:44 -0800 Subject: Advice/resources for setting up TACACS server In-Reply-To: <2FF1C77F-93CC-4196-AF74-EEC425189354@fasteddy.org> References: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> <952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org> <4914C392.9010500@kingrst.com> <2FF1C77F-93CC-4196-AF74-EEC425189354@fasteddy.org> Message-ID: <A423995B-08B4-429A-9A1F-60BDB64D59B9@craigslist.org> Do you have any suggestions for a free tacacs server which will run on linux ? I have so far been unable to find any and the tacacs+ source code hasn't been updated since around 2000 Leslie On Nov 7, 2008, at 2:43 PM, Eddy Martinez wrote: > I second the TACACS+ > > Thats what you want. Same effort for the most part, to implement. > > Eddy > > On Nov 7, 2008, at 2:39 PM, Steven King wrote: > >> I disagree with the RADIUS suggestion. TACACS+ is a much more secure >> protocol. It encrypts the packet contents and has a more secure >> handshake procedure. >> >> Leslie wrote: >>> The best answer actually does seem to be to use freeradius instead >>> of >>> tacacs, so I will probably go with that (though if anyone has any >>> good >>> tips on freeradius, please, let me know) >>> >>> Leslie >>> >>> On Nov 7, 2008, at 1:30 PM, Leslie wrote: >>> >>>> Hi -- >>>> >>>> We are currently trying to set up a TACACS server for >>>> authentication >>>> to our network gear and have it run on suse linux hosts. Does >>>> anyone >>>> have any advice/good webpages or guides regarding this? >>>> >>>> Thank you very much in advance! >>>> >>>> Leslie >>> >>> >> >> -- >> Steve King >> >> Network Engineer - Liquid Web, Inc. >> Cisco Certified Network Associate >> CompTIA Linux+ Certified Professional >> CompTIA A+ Certified Professional >> >> > From jeremy at hq.newdream.net Fri Nov 7 17:01:39 2008 From: jeremy at hq.newdream.net (Jeremy Hanmer) Date: Fri, 7 Nov 2008 15:01:39 -0800 Subject: Advice/resources for setting up TACACS server In-Reply-To: <A423995B-08B4-429A-9A1F-60BDB64D59B9@craigslist.org> References: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> <952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org> <4914C392.9010500@kingrst.com> <2FF1C77F-93CC-4196-AF74-EEC425189354@fasteddy.org> <A423995B-08B4-429A-9A1F-60BDB64D59B9@craigslist.org> Message-ID: <A3C991F4-C8CC-4314-AE45-D2C926FF4D02@hq.newdream.net> We use tac_plus with good results: http://www.shrubbery.net/tac_plus/ On Nov 7, 2008, at 2:56 PM, Leslie wrote: > Do you have any suggestions for a free tacacs server which will run > on linux ? I have so far been unable to find any and the tacacs+ > source code hasn't been updated since around 2000 > > Leslie > > On Nov 7, 2008, at 2:43 PM, Eddy Martinez wrote: > >> I second the TACACS+ >> >> Thats what you want. Same effort for the most part, to implement. >> >> Eddy >> >> On Nov 7, 2008, at 2:39 PM, Steven King wrote: >> >>> I disagree with the RADIUS suggestion. TACACS+ is a much more secure >>> protocol. It encrypts the packet contents and has a more secure >>> handshake procedure. >>> >>> Leslie wrote: >>>> The best answer actually does seem to be to use freeradius >>>> instead of >>>> tacacs, so I will probably go with that (though if anyone has any >>>> good >>>> tips on freeradius, please, let me know) >>>> >>>> Leslie >>>> >>>> On Nov 7, 2008, at 1:30 PM, Leslie wrote: >>>> >>>>> Hi -- >>>>> >>>>> We are currently trying to set up a TACACS server for >>>>> authentication >>>>> to our network gear and have it run on suse linux hosts. Does >>>>> anyone >>>>> have any advice/good webpages or guides regarding this? >>>>> >>>>> Thank you very much in advance! >>>>> >>>>> Leslie >>>> >>>> >>> >>> -- >>> Steve King >>> >>> Network Engineer - Liquid Web, Inc. >>> Cisco Certified Network Associate >>> CompTIA Linux+ Certified Professional >>> CompTIA A+ Certified Professional >>> >>> >> > > From sauron at the-infinite.org Fri Nov 7 17:03:14 2008 From: sauron at the-infinite.org (Dominic J. Eidson) Date: Fri, 7 Nov 2008 17:03:14 -0600 (CST) Subject: Advice/resources for setting up TACACS server In-Reply-To: <A423995B-08B4-429A-9A1F-60BDB64D59B9@craigslist.org> References: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> <952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org> <4914C392.9010500@kingrst.com> <2FF1C77F-93CC-4196-AF74-EEC425189354@fasteddy.org> <A423995B-08B4-429A-9A1F-60BDB64D59B9@craigslist.org> Message-ID: <Pine.LNX.4.64.0811071702570.27587@morannon.the-infinite.org> It's not free, but I want to praise Radiator (http://www.open.com.au/radiator/) as a great radius/tacacs+ server. (I have previously battled both with freeradius and openradius.) - d. On Fri, 7 Nov 2008, Leslie wrote: > Do you have any suggestions for a free tacacs server which will run on linux > ? I have so far been unable to find any and the tacacs+ source code hasn't > been updated since around 2000 > > Leslie > > On Nov 7, 2008, at 2:43 PM, Eddy Martinez wrote: > >> I second the TACACS+ >> >> Thats what you want. Same effort for the most part, to implement. >> >> Eddy >> >> On Nov 7, 2008, at 2:39 PM, Steven King wrote: >> >> > I disagree with the RADIUS suggestion. TACACS+ is a much more secure >> > protocol. It encrypts the packet contents and has a more secure >> > handshake procedure. >> > >> > Leslie wrote: >> > > The best answer actually does seem to be to use freeradius instead of >> > > tacacs, so I will probably go with that (though if anyone has any good >> > > tips on freeradius, please, let me know) >> > > >> > > Leslie >> > > >> > > On Nov 7, 2008, at 1:30 PM, Leslie wrote: >> > > >> > > > Hi -- >> > > > >> > > > We are currently trying to set up a TACACS server for authentication >> > > > to our network gear and have it run on suse linux hosts. Does anyone >> > > > have any advice/good webpages or guides regarding this? >> > > > >> > > > Thank you very much in advance! >> > > > >> > > > Leslie >> > > >> > > >> > >> > -- >> > Steve King >> > >> > Network Engineer - Liquid Web, Inc. >> > Cisco Certified Network Associate >> > CompTIA Linux+ Certified Professional >> > CompTIA A+ Certified Professional >> > >> > >> > -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli ---------------------------------------------------------------------------- http://www.dominiceidson.com/ From gtb at slac.stanford.edu Fri Nov 7 17:04:56 2008 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Fri, 7 Nov 2008 15:04:56 -0800 Subject: Advice/resources for setting up TACACS server In-Reply-To: <A423995B-08B4-429A-9A1F-60BDB64D59B9@craigslist.org> References: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org><952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org><4914C392.9010500@kingrst.com><2FF1C77F-93CC-4196-AF74-EEC425189354@fasteddy.org> <A423995B-08B4-429A-9A1F-60BDB64D59B9@craigslist.org> Message-ID: <D0D0330CBD07114D85B70B784E80C2F2022FCD6E@exch-mail2.win.slac.stanford.edu> > Do you have any suggestions for a free tacacs server which > will run on linux ? I have so far been unable to find any > and the tacacs+ source code hasn't been updated since > around 2000 Available (and maintained) at: http://www.shrubbery.net/tac_plus/ (direct download link: ftp://ftp.shrubbery.net/pub/tac_plus) The latest was last updated end of year 2007 From bn at ucsd.edu Fri Nov 7 17:13:30 2008 From: bn at ucsd.edu (Bao Nguyen) Date: Fri, 7 Nov 2008 15:13:30 -0800 Subject: Advice/resources for setting up TACACS server In-Reply-To: <D0D0330CBD07114D85B70B784E80C2F2022FCD6E@exch-mail2.win.slac.stanford.edu> References: <96B4C9B6-EF31-47DE-BBFA-56AD29CC1283@craigslist.org> <952F746D-33C3-44BC-8235-F079065FDA53@craigslist.org> <4914C392.9010500@kingrst.com> <2FF1C77F-93CC-4196-AF74-EEC425189354@fasteddy.org> <A423995B-08B4-429A-9A1F-60BDB64D59B9@craigslist.org> <D0D0330CBD07114D85B70B784E80C2F2022FCD6E@exch-mail2.win.slac.stanford.edu> Message-ID: <47b36b290811071513r1af87c5ft6a9dbab5d9de1e34@mail.gmail.com> First time poster, long time lurker. Also if you are going RADIUS route. There's a simple web shell boot version available at http://www.zeroshell.net/eng/radiusdetails/ that support RADIUS. -bn On Fri, Nov 7, 2008 at 3:04 PM, Buhrmaster, Gary <gtb at slac.stanford.edu>wrote: > > > Do you have any suggestions for a free tacacs server which > > will run on linux ? I have so far been unable to find any > > and the tacacs+ source code hasn't been updated since > > around 2000 > > Available (and maintained) at: > > http://www.shrubbery.net/tac_plus/ > > (direct download link: ftp://ftp.shrubbery.net/pub/tac_plus) > > The latest was last updated end of year 2007 > > From Franklin.A.Ervin at frb.gov Sat Nov 8 07:01:30 2008 From: Franklin.A.Ervin at frb.gov (Franklin.A.Ervin at frb.gov) Date: Sat, 8 Nov 2008 08:01:30 -0500 Subject: Frank Ervin is out of the office. Message-ID: <OFC2CD9470.58ED836B-ON852574FB.00478C74-852574FB.00478C74@frbog.frb.gov> I will be out of the office starting 11/08/2008 and will not return until 11/12/2008. Please direct all requests for assistance to the 'IT Web Support' mailbox. Thank you. From hank at efes.iucc.ac.il Sat Nov 8 10:31:43 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 8 Nov 2008 18:31:43 +0200 (IST) Subject: ECN In-Reply-To: <27621.1226079082@turing-police.cc.vt.edu> References: <alpine.DEB.1.10.0811070815360.10993@uplift.swm.pp.se> <27621.1226079082@turing-police.cc.vt.edu> Message-ID: <Pine.LNX.4.64.0811081828310.2350@efes.iucc.ac.il> On Fri, 7 Nov 2008, Valdis.Kletnieks at vt.edu wrote: > On Fri, 07 Nov 2008 08:27:58 +0100, Mikael Abrahamsson said: >> for ECN to actually be useful, we (the ISPs) have to turn this option on >> in the routers as well. Is anyone doing this today? What vendors support >> it? > > The only thing that's *required* for it to help is that the routers and > firewalls not actually *molest* the bits in the TCP SYN packet. If you pass > them and *do nothing else*, it at least has the potential of being useful at > some other router along the path. And let's face it - if *your* router is > congested enough for ECN to matter, there's a fairly good chance that the > router one hop up/downstream is *also* seeing some effects. Even if *you* don't > do anything else, your neighbor might - helping you out in the bargain. See: http://www.icir.org/floyd/ecn.html http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftwrdecn.html -Hank From kch670 at eecs.northwestern.edu Sun Nov 9 17:24:04 2008 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Sun, 9 Nov 2008 17:24:04 -0600 Subject: Dmain names for the interfaces of a router Message-ID: <e81393830811091524n220acaabi6fe651f3568471b5@mail.gmail.com> Hi everyone, my question is that, in practice, if there are different interfaces (different IP addresses) on the same border router having different domain names? thanks. From brandon.galbraith at gmail.com Sun Nov 9 17:28:54 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sun, 9 Nov 2008 17:28:54 -0600 Subject: Dmain names for the interfaces of a router In-Reply-To: <e81393830811091524n220acaabi6fe651f3568471b5@mail.gmail.com> References: <e81393830811091524n220acaabi6fe651f3568471b5@mail.gmail.com> Message-ID: <366100670811091528q72420af9j8843961c659ab14c@mail.gmail.com> On 11/9/08, Kai Chen <kch670 at eecs.northwestern.edu> wrote: > > Hi everyone, my question is that, in practice, if there are different > interfaces (different IP addresses) on the same border router having > different domain names? thanks. > > I've found this quite helpful: http://www-td.rutgers.edu/documentation/Reference/RUNet_Network_Device_Naming_Convention/ -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From mtinka at globaltransit.net Sun Nov 9 19:46:24 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 10 Nov 2008 09:46:24 +0800 Subject: MPLS for IPv6 In-Reply-To: <491408D9.2040902@uk.clara.net> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com> <20081104223637.GA16085@srv03.cluenet.de> <491408D9.2040902@uk.clara.net> Message-ID: <200811100946.25379.mtinka@globaltransit.net> On Friday 07 November 2008 17:22:33 David Freedman wrote: > So please, if you are spending your hard earned cash, > please ask for an LDP6 implementation, "no demand" should > not be the case. I sent our SE's at C & J yet another reminder about this. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081110/2bbf3056/attachment.bin> From stasinia at msoe.edu Sun Nov 9 20:00:44 2008 From: stasinia at msoe.edu (Stasiniewicz, Adam) Date: Sun, 9 Nov 2008 20:00:44 -0600 Subject: Comcast Abuse Contact Message-ID: <009401c942d8$24b99100$6e2cb300$@edu> Hello, I have a case open with the abuse department that is stalled. Could someone, who can help me escalate this case, contact me off list? Thank you! Adam Stasiniewicz Direct: 575-233-7672 From mkohno at juniper.net Mon Nov 10 00:36:46 2008 From: mkohno at juniper.net (Miya Kohno) Date: Mon, 10 Nov 2008 14:36:46 +0800 Subject: MPLS for IPv6 In-Reply-To: <200811100946.25379.mtinka@globaltransit.net> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com><20081104223637.GA16085@srv03.cluenet.de><491408D9.2040902@uk.clara.net> <200811100946.25379.mtinka@globaltransit.net> Message-ID: <AC69DA36E7838140ADA1C2B9026F8DD60A788908@emailhk1.jnpr.net> <with my vendor hat off...> If we consider the phases in terms of IPv6 deployment...., Ph-0: IPv4 only Ph-1: IPv4/v6 dual stack + v4/v6 coexistence technologies Ph-2: IPv6 only I suppose MPLS v6 control plane would become necessary at Ph-2, or a later stage of Ph-1. In the meantime, MPLS can be viewed as one of the v4/v6 coexistence technologies. IPv6 traffic can be carried over v4 signaled MPLS LSP in various ways (i.e. 6PE/6VPN, static mapping onto TE-LSP, IGP cutthrough..). Miya > -----Original Message----- > From: Mark Tinka [mailto:mtinka at globaltransit.net] > Sent: Monday, November 10, 2008 10:46 AM > To: nanog at nanog.org > Cc: David Freedman > Subject: Re: MPLS for IPv6 > > On Friday 07 November 2008 17:22:33 David Freedman wrote: > > > So please, if you are spending your hard earned cash, > please ask for > > an LDP6 implementation, "no demand" should not be the case. > > I sent our SE's at C & J yet another reminder about this. > > Mark. > From nanog at studio442.com.au Mon Nov 10 00:53:10 2008 From: nanog at studio442.com.au (Julien Goodwin) Date: Mon, 10 Nov 2008 17:53:10 +1100 Subject: MPLS for IPv6 In-Reply-To: <AC69DA36E7838140ADA1C2B9026F8DD60A788908@emailhk1.jnpr.net> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com><20081104223637.GA16085@srv03.cluenet.de><491408D9.2040902@uk.clara.net> <200811100946.25379.mtinka@globaltransit.net> <AC69DA36E7838140ADA1C2B9026F8DD60A788908@emailhk1.jnpr.net> Message-ID: <4917DA56.6090001@studio442.com.au> On 10/11/08 17:36, Miya Kohno wrote: > <with my vendor hat off...> > > If we consider the phases in terms of IPv6 deployment...., > > Ph-0: IPv4 only > Ph-1: IPv4/v6 dual stack + v4/v6 coexistence technologies > Ph-2: IPv6 only Hmm, not quite. I'd say: v4 only v4/v6 dual stack, with v4 being primary (for network management, routing, etc) v4/v6 dual stack, with v6 primary v6 only Julien From mkohno at juniper.net Mon Nov 10 01:01:59 2008 From: mkohno at juniper.net (Miya Kohno) Date: Mon, 10 Nov 2008 15:01:59 +0800 Subject: MPLS for IPv6 In-Reply-To: <4917DA56.6090001@studio442.com.au> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com><20081104223637.GA16085@srv03.cluenet.de><491408D9.2040902@uk.clara.net> <200811100946.25379.mtinka@globaltransit.net> <AC69DA36E7838140ADA1C2B9026F8DD60A788908@emailhk1.jnpr.net> <4917DA56.6090001@studio442.com.au> Message-ID: <AC69DA36E7838140ADA1C2B9026F8DD60A788909@emailhk1.jnpr.net> Hi Julien, > > If we consider the phases in terms of IPv6 deployment...., > > > > Ph-0: IPv4 only > > Ph-1: IPv4/v6 dual stack + v4/v6 coexistence technologies > > Ph-2: IPv6 only > > Hmm, not quite. I'd say: > > v4 only > v4/v6 dual stack, with v4 being primary (for network > management, routing, etc) > v4/v6 dual stack, with v6 primary > v6 only "A later phase of Ph-1" in my previous email corresponds to your "v4/v6 dual stack with v6 primary". And, putting aside whether if it's evil, a certain coexistence technologies would be needed for the phase transition. Miya From david.freedman at uk.clara.net Mon Nov 10 02:54:03 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 10 Nov 2008 08:54:03 -0000 Subject: MPLS for IPv6 References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com><20081104223637.GA16085@srv03.cluenet.de><491408D9.2040902@uk.clara.net> <200811100946.25379.mtinka@globaltransit.net> <AC69DA36E7838140ADA1C2B9026F8DD60A788908@emailhk1.jnpr.net> Message-ID: <FFBEC1DE79841C4C965378BBDA5913FC4CDDA4@EXVS01.claranet.local> <snip> I suppose MPLS v6 control plane would become necessary at Ph-2, or a later stage of Ph-1. </snip> This is a stupidly simple to implement feature, telling us "we're not ready yet" is not a sensible thing to do, any technology we can have sooner will ease the transition for many people should they choose to implement it. I would be interested to know what your views on this are with your vendor hat on :) Dave. > -----Original Message----- > From: Mark Tinka [mailto:mtinka at globaltransit.net] > Sent: Monday, November 10, 2008 10:46 AM > To: nanog at nanog.org > Cc: David Freedman > Subject: Re: MPLS for IPv6 > > On Friday 07 November 2008 17:22:33 David Freedman wrote: > > > So please, if you are spending your hard earned cash, > please ask for > > an LDP6 implementation, "no demand" should not be the case. > > I sent our SE's at C & J yet another reminder about this. > > Mark. > From mkohno at juniper.net Mon Nov 10 03:43:12 2008 From: mkohno at juniper.net (Miya Kohno) Date: Mon, 10 Nov 2008 17:43:12 +0800 Subject: MPLS for IPv6 In-Reply-To: <FFBEC1DE79841C4C965378BBDA5913FC4CDDA4@EXVS01.claranet.local> References: <d0fea3580811041253l6d7a86e3h69c968ccdcfdddac@mail.gmail.com><20081104223637.GA16085@srv03.cluenet.de><491408D9.2040902@uk.clara.net> <200811100946.25379.mtinka@globaltransit.net> <AC69DA36E7838140ADA1C2B9026F8DD60A788908@emailhk1.jnpr.net> <FFBEC1DE79841C4C965378BBDA5913FC4CDDA4@EXVS01.claranet.local> Message-ID: <AC69DA36E7838140ADA1C2B9026F8DD60A78890B@emailhk1.jnpr.net> > I would be interested to know what your views on this are with your vendor hat on :) Business case conciliates resource contentions... :) From LarrySheldon at cox.net Mon Nov 10 09:24:38 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 10 Nov 2008 09:24:38 -0600 Subject: Internet partitioning event regulations In-Reply-To: <871vxpxmux.fsf@clarabella.noc.seabone.net> References: <18252591.7901225904349660.JavaMail.root@scalix.pari.edu> <871vxpxmux.fsf@clarabella.noc.seabone.net> Message-ID: <49185236.9050203@cox.net> Pierfrancesco Caci wrote: > err... do you realize there's about 6.4 * 10^9 other people outside of > the USA, don't you? Caution: I was "admonished" by the cabal for saying just that. From j at arpa.com Mon Nov 10 20:50:08 2008 From: j at arpa.com (jamie rishaw) Date: Mon, 10 Nov 2008 20:50:08 -0600 Subject: as 7018 leaks? Message-ID: <e6e9128b0811101850n5357893dg6823608e2e150f07@mail.gmail.com> Anyone noticing issues with as 7018? Seems to be leaking a lot of random stuff. Including every prefix of mine, tho that may be partially coincidental as they're one of my transits.. Check out dampened paths for 7018. A few views outside of jamies-world seem to confirm this.. -jamie From mtinka at globaltransit.net Mon Nov 10 20:54:01 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 11 Nov 2008 10:54:01 +0800 Subject: Potential Prefix Hijack Message-ID: <200811111054.09473.mtinka@globaltransit.net> Hi all. Anyone know how we can contact AS16735 and their upstream AS27664. We think they are hijacking a number of our prefixes (AS24218- and AS17992-originated). Thanks BGPmon: e.g., ==================== Possible Prefix Hijack (Code: 11) 1 number of peer(s) detected this updates for your prefix 61.11.208.0/20: Update details: 2008-11-11 02:24 (UTC) 61.11.208.0/20 Announced by: AS16735 (Companhia de Telecomunicacoes do Brasil Central) Transit AS: 27664 (CTBC Multim?dia) ASpath: 27664 16735 ===================== RIPE's RIS BGPlay confirms the same, for about the last hour. E-mails to them won't get there (of course), so our NOC are contacting them via Gmail/Yahoo. All help appreciated. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081111/f22b0043/attachment.bin> From woody at pch.net Mon Nov 10 21:00:47 2008 From: woody at pch.net (Bill Woodcock) Date: Mon, 10 Nov 2008 19:00:47 -0800 (PST) Subject: Potential Prefix Hijack In-Reply-To: <200811111054.09473.mtinka@globaltransit.net> References: <200811111054.09473.mtinka@globaltransit.net> Message-ID: <Pine.SOC.4.61.0811101856240.27523@paixhost.pch.net> On Tue, 11 Nov 2008, Mark Tinka wrote: > Anyone know how we can contact AS16735 and their upstream > AS27664. We think they are hijacking a number of our > prefixes (AS24218- and AS17992-originated). Have you tried CERT-BR? Uh... I was about to say "they're usually very responsive, and good at coordinating this sort of thing." And then their web site failed to load, because the prefix it's in is flapping. Hm. Fred, you still awake? -Bill From peiffer at umn.edu Mon Nov 10 21:04:29 2008 From: peiffer at umn.edu (Tim Peiffer) Date: Mon, 10 Nov 2008 21:04:29 -0600 Subject: Potential Prefix Hijack In-Reply-To: <200811111054.09473.mtinka@globaltransit.net> References: <200811111054.09473.mtinka@globaltransit.net> Message-ID: <4918F63D.3060407@umn.edu> Mark Tinka wrote: > Hi all. > > Anyone know how we can contact AS16735 and their upstream > AS27664. We think they are hijacking a number of our > prefixes (AS24218- and AS17992-originated). Thanks BGPmon: > > All 19 of my prefixes for AS57, AS217 and AS1998 are being hijacked by the same ASN. I sent a note to the ASN contact adrianamr at CTBCTELECOM.NET.BR. I can't seem to contact lacnic for more than a few queries without being blacked out. Tim Peiffer Network Support Engineer Office of Information Technology University of Minnesota/NorthernLights GigaPOP % Joint Whois - whois.lacnic.net % This server accepts single ASN, IPv4 or IPv6 queries % LACNIC resource: whois.lacnic.net % Copyright LACNIC lacnic.net % The data below is provided for information purposes % and to assist persons in obtaining information about or % related to AS and IP numbers registrations % By submitting a whois query, you agree to use this data % only for lawful purposes. % 2008-11-11 00:51:09 (BRST -02:00) aut-num: AS16735 owner: Companhia de Telecomunicacoes do Brasil Central ownerid: BR-CTBC1-LACNIC responsible: Adriana Maria Rocha Paula address: Av Jo?o Pinheiro, 620, Centro address: 38400-126 - Uberl?ndia - MG country: BR phone: +34 3256 2575 [2575] owner-c: AMP routing-c: AMP abuse-c: AMP created: 20000605 changed: 20040415 nic-hdl: AMP person: Adriana Maria Rocha Paula e-mail: adrianamr at CTBCTELECOM.NET.BR address: Rua Jos? Alves Garcia, 415, address: 38400710 - Uberl?ndia - country: BR phone: +34 3256 2575 [2575] created: 20040628 changed: 20040628 % whois.lacnic.net accepts only direct match queries. % Types of queries are: POCs, ownerid, CIDR blocks, IP % and AS numbers. > e.g., > > ==================== > Possible Prefix Hijack (Code: 11) > 1 number of peer(s) detected this updates for your prefix > 61.11.208.0/20: > Update details: 2008-11-11 02:24 (UTC) > 61.11.208.0/20 > Announced by: AS16735 (Companhia de Telecomunicacoes do > Brasil Central) > Transit AS: 27664 (CTBC Multim?dia) > ASpath: 27664 16735 > ===================== > > RIPE's RIS BGPlay confirms the same, for about the last > hour. > > E-mails to them won't get there (of course), so our NOC are > contacting them via Gmail/Yahoo. > > All help appreciated. > > Cheers, > > Mark. > From charlie at playloudermsp.com Mon Nov 10 21:06:18 2008 From: charlie at playloudermsp.com (Charlie Allom) Date: Tue, 11 Nov 2008 03:06:18 +0000 Subject: Potential Prefix Hijack In-Reply-To: <200811111054.09473.mtinka@globaltransit.net> References: <200811111054.09473.mtinka@globaltransit.net> Message-ID: <20081111030618.GW39900@eatyourpets.com> On Tue, Nov 11, 2008 at 10:54:01AM +0800, Mark Tinka wrote: > Hi all. > > Anyone know how we can contact AS16735 and their upstream > AS27664. We think they are hijacking a number of our > prefixes (AS24218- and AS17992-originated). Thanks BGPmon: Mine too - 94.228.64.0/20 89.200.216.0/21 193.34.28.0/23 Except I see it as AS16735: (47998 is me) BGP routing table entry for 94.228.64.0/20 Paths: (3 available, best #3, table Default-IP-Routing-Table) Advertised to non peer-group peers: 193.0.0.71 27664 16735 200.219.130.21 from 200.219.130.21 (200.160.127.255) Origin IGP, localpref 100, valid, external Last update: Tue Nov 11 02:54:12 2008 19089 12956 5511 8928 47998 200.219.130.10 from 200.219.130.10 (200.225.95.3) Origin IGP, localpref 100, valid, external Community: 12956:65535 Last update: Mon Nov 10 18:40:54 2008 22548 16735 200.160.0.130 from 200.160.0.130 (200.160.0.137) Origin IGP, localpref 100, valid, external, best Last update: Tue Nov 11 02:51:57 2008 > RIPE's RIS BGPlay confirms the same, for about the last > hour. yep since 2am GMT. C. -- 020 7729 4797 http://blog.playlouder.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081111/582f3bd0/attachment.bin> From mtinka at globaltransit.net Mon Nov 10 21:06:42 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 11 Nov 2008 11:06:42 +0800 Subject: Potential Prefix Hijack In-Reply-To: <Pine.SOC.4.61.0811101856240.27523@paixhost.pch.net> References: <200811111054.09473.mtinka@globaltransit.net> <Pine.SOC.4.61.0811101856240.27523@paixhost.pch.net> Message-ID: <200811111106.49575.mtinka@globaltransit.net> On Tuesday 11 November 2008 11:00:47 Bill Woodcock wrote: > Have you tried CERT-BR? Yes, we contacted them as well. We still have IP reachability to them from this end. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081111/190baa5d/attachment.bin> From netfortius at gmail.com Mon Nov 10 21:32:06 2008 From: netfortius at gmail.com (Network Fortius) Date: Mon, 10 Nov 2008 21:32:06 -0600 Subject: Potential Prefix Hijack In-Reply-To: <200811111054.09473.mtinka@globaltransit.net> References: <200811111054.09473.mtinka@globaltransit.net> Message-ID: <ffe0b3100811101932g5bbad2b9h32e29355da0f3b83@mail.gmail.com> Same problems here, for AS26028 Stefan On Mon, Nov 10, 2008 at 8:54 PM, Mark Tinka <mtinka at globaltransit.net>wrote: > Hi all. > > Anyone know how we can contact AS16735 and their upstream > AS27664. We think they are hijacking a number of our > prefixes (AS24218- and AS17992-originated). Thanks BGPmon: > > e.g., > > ==================== > Possible Prefix Hijack (Code: 11) > 1 number of peer(s) detected this updates for your prefix > 61.11.208.0/20: > Update details: 2008-11-11 02:24 (UTC) > 61.11.208.0/20 > Announced by: AS16735 (Companhia de Telecomunicacoes do > Brasil Central) > Transit AS: 27664 (CTBC Multim?dia) > ASpath: 27664 16735 > ===================== > > RIPE's RIS BGPlay confirms the same, for about the last > hour. > > E-mails to them won't get there (of course), so our NOC are > contacting them via Gmail/Yahoo. > > All help appreciated. > > Cheers, > > Mark. > From j at arpa.com Mon Nov 10 21:36:49 2008 From: j at arpa.com (jamie) Date: Mon, 10 Nov 2008 21:36:49 -0600 Subject: Potential Prefix Hijack In-Reply-To: <ffe0b3100811101932g5bbad2b9h32e29355da0f3b83@mail.gmail.com> References: <200811111054.09473.mtinka@globaltransit.net> <ffe0b3100811101932g5bbad2b9h32e29355da0f3b83@mail.gmail.com> Message-ID: <6ff30abd0811101936v585210bbx3752bc6d72dea783@mail.gmail.com> Obvious, since I posted about it earlier, but confirmed here as well. Has anyone made contact with these guys? I have yet to... On Mon, Nov 10, 2008 at 9:32 PM, Network Fortius <netfortius at gmail.com>wrote: > Same problems here, for AS26028 > Stefan > > On Mon, Nov 10, 2008 at 8:54 PM, Mark Tinka <mtinka at globaltransit.net > >wrote: > > > Hi all. > > > > Anyone know how we can contact AS16735 and their upstream > > AS27664. We think they are hijacking a number of our > > prefixes (AS24218- and AS17992-originated). Thanks BGPmon: > > > > e.g., > > > > ==================== > > Possible Prefix Hijack (Code: 11) > > 1 number of peer(s) detected this updates for your prefix > > 61.11.208.0/20: > > Update details: 2008-11-11 02:24 (UTC) > > 61.11.208.0/20 > > Announced by: AS16735 (Companhia de Telecomunicacoes do > > Brasil Central) > > Transit AS: 27664 (CTBC Multim?dia) > > ASpath: 27664 16735 > > ===================== > > > > RIPE's RIS BGPlay confirms the same, for about the last > > hour. > > > > E-mails to them won't get there (of course), so our NOC are > > contacting them via Gmail/Yahoo. > > > > All help appreciated. > > > > Cheers, > > > > Mark. > > > From swm at emanon.com Mon Nov 10 22:01:05 2008 From: swm at emanon.com (Scott Morris) Date: Mon, 10 Nov 2008 23:01:05 -0500 Subject: Potential Prefix Hijack In-Reply-To: <6ff30abd0811101936v585210bbx3752bc6d72dea783@mail.gmail.com> References: <200811111054.09473.mtinka@globaltransit.net><ffe0b3100811101932g5bbad2b9h32e29355da0f3b83@mail.gmail.com> <6ff30abd0811101936v585210bbx3752bc6d72dea783@mail.gmail.com> Message-ID: <7714E4E748FD46A48BEFB1D52C09CC2F@scott66ed7b03d> I sent e-mails to the AS contacts, but don't expect that to do much in the middle of the night. No live person at the phone numbers. I can't even get their web site to come up, although if they're re-routing the entire BGP table internally, go figure. :) BGPMon's a great thing though! Somebody's been bad tonight. Scott -----Original Message----- From: jamie [mailto:j at arpa.com] Sent: Monday, November 10, 2008 10:37 PM To: Network Fortius Cc: nanog at nanog.org Subject: Re: Potential Prefix Hijack Obvious, since I posted about it earlier, but confirmed here as well. Has anyone made contact with these guys? I have yet to... On Mon, Nov 10, 2008 at 9:32 PM, Network Fortius <netfortius at gmail.com>wrote: > Same problems here, for AS26028 > Stefan > > On Mon, Nov 10, 2008 at 8:54 PM, Mark Tinka <mtinka at globaltransit.net > >wrote: > > > Hi all. > > > > Anyone know how we can contact AS16735 and their upstream AS27664. > > We think they are hijacking a number of our prefixes (AS24218- and > > AS17992-originated). Thanks BGPmon: > > > > e.g., > > > > ==================== > > Possible Prefix Hijack (Code: 11) > > 1 number of peer(s) detected this updates for your prefix > > 61.11.208.0/20: > > Update details: 2008-11-11 02:24 (UTC) 61.11.208.0/20 Announced by: > > AS16735 (Companhia de Telecomunicacoes do Brasil Central) Transit > > AS: 27664 (CTBC Multim?dia) > > ASpath: 27664 16735 > > ===================== > > > > RIPE's RIS BGPlay confirms the same, for about the last hour. > > > > E-mails to them won't get there (of course), so our NOC are > > contacting them via Gmail/Yahoo. > > > > All help appreciated. > > > > Cheers, > > > > Mark. > > > From surfer at mauigateway.com Mon Nov 10 23:29:34 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 10 Nov 2008 21:29:34 -0800 Subject: Fwd: RE: Potential Prefix Hijack Message-ID: <20081110212934.87D123A4@resin14.mta.everyone.net> Using bgplay.routeviews.org/bgplay for my prefixes (also hijacked) it looks like the damage is only to ASs downstream of either (or both) ASN 3130 and/or ASN 2914. Given the large number of respondents to the thread, it looks like a possible case of no filtering by upstreams and full table announcements/withdrawals over a period of about 40 minutes beginning 23:22 11/10/2008 GMT. There was also a problem at 17:09:30 2008 GMT for our prefixes. scott ps. subthread on what's working and how with these prefix hijack alert systems: BGPmon alerted on this and PHAS did not. They're the only two I am on at this time. The 3.5 hour period has not happened for PHAS's damping technique to work. I have 10 separate emails from BGPmon From kyled at noelcomm.com Mon Nov 10 23:53:21 2008 From: kyled at noelcomm.com (Kyle Duren) Date: Mon, 10 Nov 2008 21:53:21 -0800 Subject: Potential Prefix Hijack In-Reply-To: <mailman.77660.1226381376.43406.nanog@nanog.org> References: <mailman.77660.1226381376.43406.nanog@nanog.org> Message-ID: <49191DD1.9090709@noelcomm.com> I too have noticed the slip-up from Brazil, here at AS26935, all of our prefixes appear from them also, PHAS also did nothing for me, but RIPE tools and BGPmon both show issues. If anyone from RIPE reads this, awesome job on the tools guys! If anyone from GLBX reads this, have you had any contact with the offenders? -Kyle From frnkblk at iname.com Tue Nov 11 00:12:07 2008 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 11 Nov 2008 00:12:07 -0600 Subject: Potential Prefix Hijack In-Reply-To: <4918F63D.3060407@umn.edu> References: <200811111054.09473.mtinka@globaltransit.net> <4918F63D.3060407@umn.edu> Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAG26CjpPmLTpB7z+MW6D8hAQAAAAA=@iname.com> More contact people here: http://www.bovespa.com.br/Companies/FormConsultaImpressao.asp?CodCVM=21032 If I knew someone (readily available) who spoke Portuguese I would call them, but alas, they are sleeping and not technical. Frank -----Original Message----- From: Tim Peiffer [mailto:peiffer at umn.edu] Sent: Monday, November 10, 2008 9:04 PM To: mtinka at globaltransit.net Cc: nanog at nanog.org Subject: Re: Potential Prefix Hijack Mark Tinka wrote: > Hi all. > > Anyone know how we can contact AS16735 and their upstream > AS27664. We think they are hijacking a number of our > prefixes (AS24218- and AS17992-originated). Thanks BGPmon: > > All 19 of my prefixes for AS57, AS217 and AS1998 are being hijacked by the same ASN. I sent a note to the ASN contact adrianamr at CTBCTELECOM.NET.BR. I can't seem to contact lacnic for more than a few queries without being blacked out. Tim Peiffer Network Support Engineer Office of Information Technology University of Minnesota/NorthernLights GigaPOP % Joint Whois - whois.lacnic.net % This server accepts single ASN, IPv4 or IPv6 queries % LACNIC resource: whois.lacnic.net % Copyright LACNIC lacnic.net % The data below is provided for information purposes % and to assist persons in obtaining information about or % related to AS and IP numbers registrations % By submitting a whois query, you agree to use this data % only for lawful purposes. % 2008-11-11 00:51:09 (BRST -02:00) aut-num: AS16735 owner: Companhia de Telecomunicacoes do Brasil Central ownerid: BR-CTBC1-LACNIC responsible: Adriana Maria Rocha Paula address: Av Jo?o Pinheiro, 620, Centro address: 38400-126 - Uberl?ndia - MG country: BR phone: +34 3256 2575 [2575] owner-c: AMP routing-c: AMP abuse-c: AMP created: 20000605 changed: 20040415 nic-hdl: AMP person: Adriana Maria Rocha Paula e-mail: adrianamr at CTBCTELECOM.NET.BR address: Rua Jos? Alves Garcia, 415, address: 38400710 - Uberl?ndia - country: BR phone: +34 3256 2575 [2575] created: 20040628 changed: 20040628 % whois.lacnic.net accepts only direct match queries. % Types of queries are: POCs, ownerid, CIDR blocks, IP % and AS numbers. > e.g., > > ==================== > Possible Prefix Hijack (Code: 11) > 1 number of peer(s) detected this updates for your prefix > 61.11.208.0/20: > Update details: 2008-11-11 02:24 (UTC) > 61.11.208.0/20 > Announced by: AS16735 (Companhia de Telecomunicacoes do > Brasil Central) > Transit AS: 27664 (CTBC Multim?dia) > ASpath: 27664 16735 > ===================== > > RIPE's RIS BGPlay confirms the same, for about the last > hour. > > E-mails to them won't get there (of course), so our NOC are > contacting them via Gmail/Yahoo. > > All help appreciated. > > Cheers, > > Mark. > From gustavo at nexthop.com.br Tue Nov 11 00:21:05 2008 From: gustavo at nexthop.com.br (Gustavo Rodrigues Ramos) Date: Tue, 11 Nov 2008 04:21:05 -0200 Subject: Potential Prefix Hijack In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAG26CjpPmLTpB7z+MW6D8hAQAAAAA=@iname.com> References: <200811111054.09473.mtinka@globaltransit.net> <4918F63D.3060407@umn.edu> <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAG26CjpPmLTpB7z+MW6D8hAQAAAAA=@iname.com> Message-ID: <73d1f88a0811102221x228afd59s89880eb6f863f828@mail.gmail.com> I've just contacted (after three looong hours waiting...) and forward those e-mails to them. Hope that helps ... Can someone confirm that the issue is still happening? Maybe a show bgp something would help me talk to them. On Tue, Nov 11, 2008 at 4:12 AM, Frank Bulk <frnkblk at iname.com> wrote: > More contact people here: > http://www.bovespa.com.br/Companies/FormConsultaImpressao.asp?CodCVM=21032 > > If I knew someone (readily available) who spoke Portuguese I would call them, but alas, they are sleeping and not technical. > > Frank > > -----Original Message----- > From: Tim Peiffer [mailto:peiffer at umn.edu] > Sent: Monday, November 10, 2008 9:04 PM > To: mtinka at globaltransit.net > Cc: nanog at nanog.org > Subject: Re: Potential Prefix Hijack > > Mark Tinka wrote: >> Hi all. >> >> Anyone know how we can contact AS16735 and their upstream >> AS27664. We think they are hijacking a number of our >> prefixes (AS24218- and AS17992-originated). Thanks BGPmon: >> >> > All 19 of my prefixes for AS57, AS217 and AS1998 are being hijacked by > the same ASN. I sent a note to the ASN contact > adrianamr at CTBCTELECOM.NET.BR. I can't seem to contact lacnic for more > than a few queries without being blacked out. > > > Tim Peiffer > Network Support Engineer > Office of Information Technology > University of Minnesota/NorthernLights GigaPOP > > % Joint Whois - whois.lacnic.net > % This server accepts single ASN, IPv4 or IPv6 queries > > % LACNIC resource: whois.lacnic.net > > > % Copyright LACNIC lacnic.net > % The data below is provided for information purposes > % and to assist persons in obtaining information about or > % related to AS and IP numbers registrations > % By submitting a whois query, you agree to use this data > % only for lawful purposes. > % 2008-11-11 00:51:09 (BRST -02:00) > > aut-num: AS16735 > owner: Companhia de Telecomunicacoes do Brasil Central > ownerid: BR-CTBC1-LACNIC > responsible: Adriana Maria Rocha Paula > address: Av Jo?o Pinheiro, 620, Centro > address: 38400-126 - Uberl?ndia - MG > country: BR > phone: +34 3256 2575 [2575] > owner-c: AMP > routing-c: AMP > abuse-c: AMP > created: 20000605 > changed: 20040415 > > nic-hdl: AMP > person: Adriana Maria Rocha Paula > e-mail: adrianamr at CTBCTELECOM.NET.BR > address: Rua Jos? Alves Garcia, 415, > address: 38400710 - Uberl?ndia - > country: BR > phone: +34 3256 2575 [2575] > created: 20040628 > changed: 20040628 > > % whois.lacnic.net accepts only direct match queries. > % Types of queries are: POCs, ownerid, CIDR blocks, IP > % and AS numbers. > > >> e.g., >> >> ==================== >> Possible Prefix Hijack (Code: 11) >> 1 number of peer(s) detected this updates for your prefix >> 61.11.208.0/20: >> Update details: 2008-11-11 02:24 (UTC) >> 61.11.208.0/20 >> Announced by: AS16735 (Companhia de Telecomunicacoes do >> Brasil Central) >> Transit AS: 27664 (CTBC Multim?dia) >> ASpath: 27664 16735 >> ===================== >> >> RIPE's RIS BGPlay confirms the same, for about the last >> hour. >> >> E-mails to them won't get there (of course), so our NOC are >> contacting them via Gmail/Yahoo. >> >> All help appreciated. >> >> Cheers, >> >> Mark. >> > > > > > From hank at efes.iucc.ac.il Tue Nov 11 00:30:54 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 11 Nov 2008 08:30:54 +0200 (IST) Subject: Fwd: RE: Potential Prefix Hijack In-Reply-To: <20081110212934.87D123A4@resin14.mta.everyone.net> References: <20081110212934.87D123A4@resin14.mta.everyone.net> Message-ID: <Pine.LNX.4.64.0811110830230.13765@efes.iucc.ac.il> On Mon, 10 Nov 2008, Scott Weeks wrote: > > > > Using bgplay.routeviews.org/bgplay for my prefixes (also hijacked) it looks like the damage is only to ASs downstream of either (or both) ASN 3130 and/or ASN 2914. > > Given the large number of respondents to the thread, it looks like a possible case of no filtering by upstreams and full table announcements/withdrawals over a period of about 40 minutes beginning 23:22 11/10/2008 GMT. There was also a problem at 17:09:30 2008 GMT for our prefixes. AS378 and AS1680 suffered as well. -Hank From paul at blacknight.com Tue Nov 11 05:53:23 2008 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Tue, 11 Nov 2008 11:53:23 +0000 Subject: Potential Prefix Hijack In-Reply-To: <200811111054.09473.mtinka@globaltransit.net> References: <200811111054.09473.mtinka@globaltransit.net> Message-ID: <D175CB0A04FE634587DA0987F3C4231020665483E5@iddawg.blacknight.local> We too saw this issue. 2008-11-11 01:56:36 GMT they took over one of our /20's ... Paul Kelly Technical Director Blacknight Internet Solutions ltd Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353 (0) 59 9183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: paul at blacknight.ie web: http://www.blacknight.ie Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 > -----Original Message----- > From: Mark Tinka [mailto:mtinka at globaltransit.net] > Sent: Tuesday, November 11, 2008 2:54 AM > To: nanog at nanog.org > Subject: Potential Prefix Hijack > > Hi all. > > Anyone know how we can contact AS16735 and their upstream > AS27664. We think they are hijacking a number of our > prefixes (AS24218- and AS17992-originated). Thanks BGPmon: > > e.g., > > ==================== > Possible Prefix Hijack (Code: 11) > 1 number of peer(s) detected this updates for your prefix > 61.11.208.0/20: > Update details: 2008-11-11 02:24 (UTC) > 61.11.208.0/20 > Announced by: AS16735 (Companhia de Telecomunicacoes do > Brasil Central) > Transit AS: 27664 (CTBC Multimdia) > ASpath: 27664 16735 > ===================== > > RIPE's RIS BGPlay confirms the same, for about the last > hour. > > E-mails to them won't get there (of course), so our NOC are > contacting them via Gmail/Yahoo. > > All help appreciated. > > Cheers, > > Mark. > From ml at t-b-o-h.net Tue Nov 11 06:00:44 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Tue, 11 Nov 2008 07:00:44 -0500 (EST) Subject: Potential Prefix Hijack In-Reply-To: <Pine.SOC.4.61.0811101856240.27523@paixhost.pch.net> Message-ID: <200811111200.mABC0iu2011660@himinbjorg.tucs-beachin-obx-house.com> > > On Tue, 11 Nov 2008, Mark Tinka wrote: > > Anyone know how we can contact AS16735 and their upstream > > AS27664. We think they are hijacking a number of our > > prefixes (AS24218- and AS17992-originated). > > Have you tried CERT-BR? Uh... I was about to say "they're usually very > responsive, and good at coordinating this sort of thing." And then their > web site failed to load, because the prefix it's in is flapping. Hm. > > Fred, you still awake? > > -Bill > > Odd, we were just hijacked too, one match to the same AS: Prefix: 64.193.164.0/24 AS Path: 27664 16735 Seen by Route Collector: 15 Peer IP: 200.219.130.21 Peer AS Number: 27664 Timestamp (GMT): 1:56, Nov 11 2008 And a match from other AS's Prefix: 192.136.64.0/24 AS Path: 22548 16735 Seen by Route Collector: 15 Peer IP: 200.160.0.130 Peer AS Number: 22548 Timestamp (GMT): 1:59, Nov 11 2008 Prefix: 64.193.164.0/24 AS Path: 22548 16735 Seen by Route Collector: 15 Peer IP: 200.160.0.130 Peer AS Number: 22548 Timestamp (GMT): 1:56, Nov 11 2008 Tuc From nuno.vieira at nfsi.pt Tue Nov 11 06:33:43 2008 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Tue, 11 Nov 2008 12:33:43 +0000 (WET) Subject: Potential Prefix Hijack In-Reply-To: <316672631.33721226406276486.JavaMail.root@zimbra.nfsi.pt> Message-ID: <481274893.33741226406823879.JavaMail.root@zimbra.nfsi.pt> Howdy, We were hijacked aswell, by 27664 16735 Our affected prefixes were: 94.46.0.0/16 194.88.142.0/23 194.11.23.0/24 82.102.0.0/18 195.246.238.0/23 194.107.127.0/24 81.92.192.0/19 193.227.238.0/23 We are trying to contact them in order to get some feedback, and some good explanation for this. In the meanwhile, there are lots of evidence spread around (thanks to RIS RIPE, Routeviews, BGPmon and others) http://www.ris.ripe.net/dashboard/27664 http://www.ris.ripe.net/dashboard/16735 In the meanwhile we are sending notices to the Upstreams of those ASN's, in order for them to apply proper filtering to their downstream customers to avoid situations like this. On the List i was able to found: AS8167 - TELESC AS6762 - SEABONE AS12956 - TELEFONICA AS3549 - GLOBAL CROSSING AS17379 - Interlig I welcome others to do the same, in order to avoid replicas for this situation. Regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Network Fortius" <netfortius at gmail.com> wrote: > Same problems here, for AS26028 > Stefan > > On Mon, Nov 10, 2008 at 8:54 PM, Mark Tinka > <mtinka at globaltransit.net>wrote: > > > Hi all. > > > > Anyone know how we can contact AS16735 and their upstream > > AS27664. We think they are hijacking a number of our > > prefixes (AS24218- and AS17992-originated). Thanks BGPmon: > > > > e.g., > > > > ==================== > > Possible Prefix Hijack (Code: 11) > > 1 number of peer(s) detected this updates for your prefix > > 61.11.208.0/20: > > Update details: 2008-11-11 02:24 (UTC) > > 61.11.208.0/20 > > Announced by: AS16735 (Companhia de Telecomunicacoes do > > Brasil Central) > > Transit AS: 27664 (CTBC Multim?dia) > > ASpath: 27664 16735 > > ===================== > > > > RIPE's RIS BGPlay confirms the same, for about the last > > hour. > > > > E-mails to them won't get there (of course), so our NOC are > > contacting them via Gmail/Yahoo. > > > > All help appreciated. > > > > Cheers, > > > > Mark. > > From raymond at prolocation.net Tue Nov 11 06:38:50 2008 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 11 Nov 2008 13:38:50 +0100 (CET) Subject: Potential Prefix Hijack In-Reply-To: <481274893.33741226406823879.JavaMail.root@zimbra.nfsi.pt> References: <481274893.33741226406823879.JavaMail.root@zimbra.nfsi.pt> Message-ID: <alpine.LFD.2.00.0811111338090.25419@control.prolocation.net> Hi! > We were hijacked aswell, by 27664 16735 > > Our affected prefixes were: > > 94.46.0.0/16 > 194.88.142.0/23 > 194.11.23.0/24 > 82.102.0.0/18 > 195.246.238.0/23 > 194.107.127.0/24 > 81.92.192.0/19 > 193.227.238.0/23 > > We are trying to contact them in order to get some feedback, and some good explanation for this. The obviously were leaking full routing, are we all gonna annnounce 'my prefix was in there also?' Bye, Raymond. From patrick at ianai.net Tue Nov 11 06:42:29 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 11 Nov 2008 07:42:29 -0500 Subject: Potential Prefix Hijack In-Reply-To: <alpine.LFD.2.00.0811111338090.25419@control.prolocation.net> References: <481274893.33741226406823879.JavaMail.root@zimbra.nfsi.pt> <alpine.LFD.2.00.0811111338090.25419@control.prolocation.net> Message-ID: <E52844A4-F40F-48E7-B4FD-EB1E57009789@ianai.net> Possibly silly question: If a small ISP is leaking a full table and you cannot reach them, why not contact their upstreams? Can't really check a router from here, but I saw (for instance) Verio mentioned. I am certain as2914 runs a 24/7 NOC and is responsive. -- TTFN, patrick From ml at t-b-o-h.net Tue Nov 11 06:48:22 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Tue, 11 Nov 2008 07:48:22 -0500 (EST) Subject: Potential Prefix Hijack In-Reply-To: <alpine.LFD.2.00.0811111338090.25419@control.prolocation.net> Message-ID: <200811111248.mABCmM01013216@himinbjorg.tucs-beachin-obx-house.com> > > Hi! > > > We were hijacked aswell, by 27664 16735 > > > > Our affected prefixes were: > > > > 94.46.0.0/16 > > 194.88.142.0/23 > > 194.11.23.0/24 > > 82.102.0.0/18 > > 195.246.238.0/23 > > 194.107.127.0/24 > > 81.92.192.0/19 > > 193.227.238.0/23 > > > > We are trying to contact them in order to get some feedback, and some good explanation for this. > > The obviously were leaking full routing, are we all gonna annnounce 'my > prefix was in there also?' > ACTUALLY............ They didn't hijack ALL my netblocks... I have 3. One was completely untouched, 1 was only hijacked by 1 site, and the last was hijacked by 2 different sites. :) Tuc From raymond at prolocation.net Tue Nov 11 06:52:37 2008 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 11 Nov 2008 13:52:37 +0100 (CET) Subject: Potential Prefix Hijack In-Reply-To: <200811111248.mABCmM01013216@himinbjorg.tucs-beachin-obx-house.com> References: <200811111248.mABCmM01013216@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <alpine.LFD.2.00.0811111351540.25419@control.prolocation.net> Hi! >>> 94.46.0.0/16 >>> 194.88.142.0/23 >>> 194.11.23.0/24 >>> 82.102.0.0/18 >>> 195.246.238.0/23 >>> 194.107.127.0/24 >>> 81.92.192.0/19 >>> 193.227.238.0/23 >>> >>> We are trying to contact them in order to get some feedback, and some good explanation for this. >> The obviously were leaking full routing, are we all gonna annnounce 'my >> prefix was in there also?' > ACTUALLY............ They didn't hijack ALL my netblocks... I have 3. One was completely > untouched, 1 was only hijacked by 1 site, and the last was hijacked by 2 different sites. :) So their router had most likely a hard time and stuff was flapping, i see something like that in the BGPLay output also. Bye, Raymond. From nuno.vieira at nfsi.pt Tue Nov 11 08:01:29 2008 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Tue, 11 Nov 2008 14:01:29 +0000 (WET) Subject: Potential Prefix Hijack In-Reply-To: <alpine.LFD.2.00.0811111338090.25419@control.prolocation.net> Message-ID: <2057986816.33891226412089411.JavaMail.root@zimbra.nfsi.pt> That's not true, as not all our prefixes were hijacked nor leaked, since they were originating them. If they were leaking them you might be able to see further AS's on the AS-PATH, incluiding the legitimate AS for originating those prefixes. My point here is also about peers and upstreams to set properly filter or max-prefix settings to avoid those nasty things. Am i seeing things in a blur way ? or this is supposed to happen as wind flows ? regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Raymond Dijkxhoorn" <raymond at prolocation.net> wrote: > Hi! > > > We were hijacked aswell, by 27664 16735 > > > > Our affected prefixes were: > > > > 94.46.0.0/16 > > 194.88.142.0/23 > > 194.11.23.0/24 > > 82.102.0.0/18 > > 195.246.238.0/23 > > 194.107.127.0/24 > > 81.92.192.0/19 > > 193.227.238.0/23 > > > > We are trying to contact them in order to get some feedback, and > some good explanation for this. > > The obviously were leaking full routing, are we all gonna annnounce > 'my > prefix was in there also?' > > Bye, > Raymond. From raymond at prolocation.net Tue Nov 11 08:12:32 2008 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 11 Nov 2008 15:12:32 +0100 (CET) Subject: Potential Prefix Hijack In-Reply-To: <2057986816.33891226412089411.JavaMail.root@zimbra.nfsi.pt> References: <2057986816.33891226412089411.JavaMail.root@zimbra.nfsi.pt> Message-ID: <alpine.LFD.2.00.0811111509260.10596@control.prolocation.net> Hi! > That's not true, as not all our prefixes were hijacked nor leaked, > since they were originating them. If they were leaking them you might > be able to see further AS's on the AS-PATH, incluiding the legitimate > AS for originating those prefixes. We have seen issues like this also when a customer was leaking full routes, and his router ws not able to coop with the BGP tables. This gave really really strange things, simmilar like here, some prefixes were there and some not. Completely random. > Am i seeing things in a blur way ? or this is supposed to happen as > wind flows ? Upstreams should filter things properly. Thats a sure thing. OR max prefix limit customers like that.... Bye, Raymond. From fneves at registro.br Tue Nov 11 09:54:50 2008 From: fneves at registro.br (Frederico A C Neves) Date: Tue, 11 Nov 2008 13:54:50 -0200 Subject: Potential Prefix Hijack In-Reply-To: <Pine.SOC.4.61.0811101856240.27523@paixhost.pch.net> References: <200811111054.09473.mtinka@globaltransit.net> <Pine.SOC.4.61.0811101856240.27523@paixhost.pch.net> Message-ID: <20081111155450.GD38265@registro.br> Hi Bill, On Mon, Nov 10, 2008 at 07:00:47PM -0800, Bill Woodcock wrote: > On Tue, 11 Nov 2008, Mark Tinka wrote: > > Anyone know how we can contact AS16735 and their upstream > > AS27664. We think they are hijacking a number of our > > prefixes (AS24218- and AS17992-originated). > > Have you tried CERT-BR? Uh... I was about to say "they're usually very > responsive, and good at coordinating this sort of thing." And then their > web site failed to load, because the prefix it's in is flapping. Hm. > > Fred, you still awake? Not at the time of the event :-( AFAIK the event was local to CTBC (AS16735) and their customers. This is our case and as we host RRC15 at PTTMetro S?o Paulo, and feed it with a full routing BGP feed it triggered the reports from bgpmon [1]. CTBC is still pending to explain the event, > -Bill Fred [1] http://bgpmon.net/blog/?p=80 From mabrown at renesys.com Tue Nov 11 13:14:41 2008 From: mabrown at renesys.com (Martin A. Brown) Date: Tue, 11 Nov 2008 13:14:41 -0600 Subject: Potential Prefix Hijack In-Reply-To: <20081111155450.GD38265@registro.br> References: <200811111054.09473.mtinka@globaltransit.net> <Pine.SOC.4.61.0811101856240.27523@paixhost.pch.net> <20081111155450.GD38265@registro.br> Message-ID: <alpine.LRH.2.00.0811111158270.10275@parsnip.renesys.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, As several people have already observed here, AS 16735 announced almost the whole Internet last night to two of its peers (AS 27664, 174213 routes and AS 22548, 111231 routes). These routes were not propagated to the global Internet--and as Frederico A C Neves has confirmed, it was a localized event. For more detail on what happened, see Frederico's post [0] and the BGPMon site's summary [1]. We also have a slightly more detailed analysis here [2]. - -Martin [0] http://www.merit.edu/mail.archives/nanog/msg12813.html [1] http://bgpmon.net/blog/?p=80 [2] http://www.renesys.com/blog/2008/11/brazil-leak-if-a-tree-falls-in.shtml - -- Martin A. Brown --- Renesys Corporation --- mabrown at renesys.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFJGdmkdXQGngQsWbkRAkEQAKCNUj6C6B0fVf3JOpp3nHnfyBGMYgCg1t6q xAGn9T2yn9FuFeXGXCaBDnU= =2kVx -----END PGP SIGNATURE----- From ml at t-b-o-h.net Tue Nov 11 19:59:28 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Tue, 11 Nov 2008 20:59:28 -0500 (EST) Subject: Cable re-management Message-ID: <200811120159.mAC1xSvu023362@himinbjorg.tucs-beachin-obx-house.com> Hi, I wondered if any of the NANO's (Specifically NYCNANO's) have ever brought in another company, or offered as a service to the general world cable re-management. I know Hugh O'Kane is a big place that does it, but I'm looking for said services in NYC. I have client datatel closets that REALLY need color coding, cables cut to length, A-B labeling, etc. For an added bonus, they would potentially be able to build out an entire FLOOR of a building from scratch. Private replies please, will summarize to any who ask. Thanks, Tuc/TBOH From lorell at hathcock.org Tue Nov 11 20:17:12 2008 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 11 Nov 2008 20:17:12 -0600 Subject: hosted PBX/VOIP thru VPN? Message-ID: <041301c9446c$c6a33030$53e99090$@org> All: My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet. I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors. The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true. Specifically the ASNs in the middle are Level 3, Sprint and Time Warner. Thoughts? Should I try to dissuade him from this if performance is his main motivator? Thanks! Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | lorell at OfficeConnect.net ocbannerjoomla -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 7350 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081111/8cd6de1e/attachment.jpg> From nanog at daork.net Tue Nov 11 20:25:57 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 12 Nov 2008 15:25:57 +1300 Subject: hosted PBX/VOIP thru VPN? In-Reply-To: <041301c9446c$c6a33030$53e99090$@org> References: <041301c9446c$c6a33030$53e99090$@org> Message-ID: <AFC11F98-5664-45B7-AFCA-4FAB3605A037@daork.net> On 12/11/2008, at 3:17 PM, Lorell Hathcock wrote: > All: > > My customer wants to try to improve performance to his ATAs by > creating a > VPN from his network to the VOIP provider's network through the > internet. > Thoughts? Should I try to dissuade him from this if performance is > his main > motivator? Yep. I've done this sort of thing to get around NAT problems, that's about it. Perhaps their theory is that a VPN gives them a "private" network, and they've heard that "private" networks do VoIP better. Obviously, a VPN doesn't give you control of the packets on the wire like a private network does, so that theory doesn't work. -- Nathan Ward From ge at linuxbox.org Tue Nov 11 20:37:05 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 11 Nov 2008 20:37:05 -0600 (CST) Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd) Message-ID: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> ---------- Forwarded message ---------- Date: Tue, 11 Nov 2008 18:22:42 -0800 From: Paul Ferguson <fergdawgster at gmail.com> To: funsec at linuxbox.org Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Via Security Fix. [snip] A U.S. based Web hosting firm that security experts say was responsible for facilitating more than 75 percent of the junk e-mail blasted out each day globally has been knocked offline following reports from Security Fix on evidence gathered about criminal activity emanating from the network. For the past four months, Security Fix has been gathering data from the security industry about McColo Corp., a San Jose, Calif., based Web hosting service whose client list experts say includes some of the most disreputable cyber-criminal gangs in business today. On Monday, Security Fix contacted the Internet providers that manage more than 90 percent of the company's connection to the larger Internet, sending them information about badness at McColo as documented by the security industry. [snip] More: http://voices.washingtonpost.com/securityfix/2008/11/major_source_of_online _scams_a.html Also, more details will become available real soon now... - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJGj2hq1pz9mNUZTMRAsUaAJ4g4AzgLzD+NB9jvtlQu2kWwxY9UgCfakeM RzvY4TKA6HqN8jePb8AJlOY= =r3Oz -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list. From tims at donet.com Tue Nov 11 21:24:21 2008 From: tims at donet.com (Tim Sanderson) Date: Tue, 11 Nov 2008 22:24:21 -0500 Subject: hosted PBX/VOIP thru VPN? In-Reply-To: <041301c9446c$c6a33030$53e99090$@org> References: <041301c9446c$c6a33030$53e99090$@org> Message-ID: <C8780EC81EAFB24B94943243BA5BCC54294BCE5DDB@intexch07.internal.donet.com> Yes, dissuade him. If anything a VPN will add latency unless possibly gear is replaced to provide the VPN that is significantly greater than current. But... if a provider en-route decided to "slow down" competing voice traffic, the VPN would hide it from the filters which might make it seem like voice traffic was speeding up. Of course that is a major "if". Shouldn't take much to lab it, and show the customer the difference in quality, if any. Regardless, if the customer insists, it's billable so why not you than someone else. Just make sure said customer knows that you are not recommending the solution and why. If you implement the VPN and voice quality does not improve, you are covered. -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Lorell Hathcock [mailto:lorell at hathcock.org] Sent: Tuesday, November 11, 2008 9:17 PM, if any To: nanog at nanog.org Subject: hosted PBX/VOIP thru VPN? All: My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet. I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors. The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true. Specifically the ASNs in the middle are Level 3, Sprint and Time Warner. Thoughts? Should I try to dissuade him from this if performance is his main motivator? Thanks! Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | lorell at OfficeConnect.net ocbannerjoomla From mike-nanog at tiedyenetworks.com Tue Nov 11 21:52:55 2008 From: mike-nanog at tiedyenetworks.com (mike) Date: Tue, 11 Nov 2008 19:52:55 -0800 Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd) In-Reply-To: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> Message-ID: <491A5317.8090109@tiedyenetworks.com> Since 11/5, my spam load has dropped from about 400,000 attempts per day to less than 40,000 ! And most of this I had noted was comming from what looked like compromised web hosts - eg: same host/domain name representing 10 or 20 addresses in any given range). I am shocked at the sudden and dramatic downtick but also equally delighted! Way to go! Gadi Evron wrote: > > Via Security Fix. > > [snip] > > A U.S. based Web hosting firm that security experts say was > responsible for > facilitating more than 75 percent of the junk e-mail blasted out each day > globally has been knocked offline following reports from Security Fix on > evidence gathered about criminal activity emanating from the network. From jtodd at loligo.com Tue Nov 11 22:03:44 2008 From: jtodd at loligo.com (John Todd) Date: Tue, 11 Nov 2008 20:03:44 -0800 Subject: hosted PBX/VOIP thru VPN? In-Reply-To: <041301c9446c$c6a33030$53e99090$@org> References: <041301c9446c$c6a33030$53e99090$@org> Message-ID: <EF704BF9-70EC-422F-AA1F-1AB748C79ED2@loligo.com> On Nov 11, 2008, at 6:17 PM, Lorell Hathcock wrote: > All: > > My customer wants to try to improve performance to his ATAs by > creating a > VPN from his network to the VOIP provider's network through the > internet. > > I have to admit, the idea caught me flat footed. At the outset, it > seems > like we would want to do it just to improve security for end users. > However, > my customer wants it because he thinks it will improve performance > (i.e. > voice quality). We are suffering from poor VOIP quality due to the > Sprint / > Cogent depeering and subsequent squirming by our vendors. > > The only reason I can think that VOIP thru a VPN would help is that > *perhaps* routers in the middle on ASNs I have no control over *may* > prioritize VPN traffic higher than regular traffic. They opposite > could > also be true. > > Specifically the ASNs in the middle are Level 3, Sprint and Time > Warner. > > Thoughts? Should I try to dissuade him from this if performance is > his main > motivator? The implementation of a VPN indeed would probably not result in an improvement of your customer' RTP packet delivery, either for jitter or packet loss. If you wish to see if RTP is being meddled with, try changing the RTP port numbers on the ATA or on the remote side to something less typical of the RTP port range - try something <10000. While some deep-packet inspections will dig through each packet to categorize and stomp on RTP voice audio, it is probably not the case that anyone in the path you describe is applying anything other than port number and protocol (UDP/TCP) inspections, if they are doing any such punitive QOS at all. I would be very interested to learn if you or anyone does know of a transit carrier who is de-pref'ing RTP packets as a peered transit provider (or non-paid peering partner.) This doesn't mean static "end customers" - I'm really talking about traffic that is ingress/egress from some other ASN, even if that ASN is paying for transit. This would be a fairly major departure from any type of QOS or de- preferencing that I've seen before, and I'm sure the list would be interested in any results as well. The root cause of the problem your customer describes also needs to be identified - that will tell you a lot. Wireshark a few calls and see what you can see on the RTP packet path. Without more specifics on the "bad performance", it will be difficult to determine if this is even a network issue at all - maybe it's just a sub-standard ITSP, gateway, or even PSTN path on the far side of the equation. A very slight chance exists that due to round-robin routing you are getting out-of-order packets in one or both directions of the media stream. RTP does not recover well from OOO packets. Try some traceroutes in the RTP port range to see what happens. You can see one direction for the traceroute UDP outbound and watch for multi- pathing, and you can see the other direction with wireshark on inbound OOO RTP streams to your customer. If the problem is out-of-order RTP packets, then there are some things that a GRE tunnel plus some creative route announcements/static routes might be able to solve, and those are left as an exercise for the reader. But a "VPN" is almost always going to be the wrong answer for VoIP performance increases - GRE is better suited for encapsulating UDP, and I run VoIP connections over GRE all the time due to the perverse and unfortunate routing situation for my home network, which resides at the end of a consumer- grade cable IP connection. I would not recommend even GRE as a matter of course for VoIP RTP transport; I merely say that it is possible, and in some fringe cases the only solution available. FWIW: Snom (a SIP-based desk phone) now includes a built-in IPSEC tunnel protocol stack so the phone can securely establish connections back to the PBX or other endpoints. The reasons for doing this are not clearly not performance-oriented - they are security-oriented. It even will encapsulate traffic from any hosts attached to the one-port switch on the back. Desk phones are getting pretty scary. I'm waiting for "sh ip bgp" for my Cisco 7960... http://wiki.snom.com/VPN http://www.snom.com/en/products/snom-370-voip-phone/ JT From aawolfe at gmail.com Wed Nov 12 05:39:19 2008 From: aawolfe at gmail.com (Aaron Wolfe) Date: Wed, 12 Nov 2008 06:39:19 -0500 Subject: hosted PBX/VOIP thru VPN? In-Reply-To: <041301c9446c$c6a33030$53e99090$@org> References: <041301c9446c$c6a33030$53e99090$@org> Message-ID: <e44ad6640811120339m5eb6a248j171d13c93549393d@mail.gmail.com> On Tue, Nov 11, 2008 at 9:17 PM, Lorell Hathcock <lorell at hathcock.org> wrote: > All: > > > > My customer wants to try to improve performance to his ATAs by creating a > VPN from his network to the VOIP provider's network through the internet. > > > > I have to admit, the idea caught me flat footed. At the outset, it seems > like we would want to do it just to improve security for end users. However, > my customer wants it because he thinks it will improve performance (i.e. > voice quality). We are suffering from poor VOIP quality due to the Sprint / > Cogent depeering and subsequent squirming by our vendors. > > > > The only reason I can think that VOIP thru a VPN would help is that > *perhaps* routers in the middle on ASNs I have no control over *may* > prioritize VPN traffic higher than regular traffic. They opposite could > also be true. > > > > Specifically the ASNs in the middle are Level 3, Sprint and Time Warner. > > > > Thoughts? Should I try to dissuade him from this if performance is his main > motivator? > Your customer may have seen this article (or a similar one): http://www.oreillynet.com/etel/blog/2006/03/strangely_ssl_vpns_can_help_vo.html After reading it a year ago, I've found their discoveries to hold true on my own (small) projects with voip. In a nutshell: "In every case, adding an SSL VPN to a VoIP call over a good broadband network improved call quality. So in effect, wrapping a VoIP call in SSL gives it more structure, kind of like the rind of good Brie. What we had not counted on was the huge difference between what VoIP requires (64Kbps) and a typical broadband connection of 500Kbps or more. Because the broadband connection was so fast, TCP was able to repair the impairments without reducing voice quality. " May or may not apply to your situation, but if bandwidth isn't scarce then I wouldn't be surprised if your customer is correct, at very least they are not crazy :) Good luck -Aaron > > > Thanks! > > > > Sincerely, > > > > Lorell Hathcock > > > > OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | > lorell at OfficeConnect.net > > > > ocbannerjoomla > > > > > > From nanog at daork.net Wed Nov 12 06:01:19 2008 From: nanog at daork.net (Nathan Ward) Date: Thu, 13 Nov 2008 01:01:19 +1300 Subject: hosted PBX/VOIP thru VPN? In-Reply-To: <e44ad6640811120339m5eb6a248j171d13c93549393d@mail.gmail.com> References: <041301c9446c$c6a33030$53e99090$@org> <e44ad6640811120339m5eb6a248j171d13c93549393d@mail.gmail.com> Message-ID: <C3ED3B38-4299-4869-9A0D-443FBAFD31DA@daork.net> On 13/11/2008, at 12:39 AM, Aaron Wolfe wrote: > Because the broadband connection was so fast, TCP was able to > repair the impairments without reducing voice quality. " That works fine if latency+window size is low, so that segments are retransmitted quickly. You really should also do the math and factor in the latency that comes from doing something like this, assuming you lose a packet. G. 114 recommends an end to end latency of no more than 150ms for voice applications, where over 400ms is unacceptable (between 150 and 400 you should indicate that performance is not ideal). Finally, some audio codecs work well with fairly high amounts of loss - I'd recommend doing something like that first. iLBC does this really well. G.729 etc. do not - they rely on context, so a single packet lost results in several packets of lost audio (and so, silence). iLBC doesn't rely on context, and quality degrades during packet loss before you get silence. The i stands for Internet - so no surprise it works great in typical Internet conditions. -- Nathan Ward From rmacharia at gmail.com Wed Nov 12 06:40:39 2008 From: rmacharia at gmail.com (Raymond Macharia) Date: Wed, 12 Nov 2008 15:40:39 +0300 Subject: Router Choice Message-ID: <ac036ce50811120440x8139b1fq170fd13b5d0a61ef@mail.gmail.com> Hello fellow nanogers, I am a long time user of Cisco gear and currently evaluating an alternative for my network expansion. currently the one that looks like it will be able to do the job iare Alcatel-Lucent 7710/7750 service routers. I am looking for real life experience of those who have used it and what I may need to watch out for (if anything) I have seen in some of their documentation features like Non-stop Services (NSS) and Non-stop Routing (NSR). are these features real world deployable. oh, just to add I want to use the routers as P routers in my IP/MPLS core Regards -- Raymond Macharia From eduardo at intron.com.br Wed Nov 12 06:52:57 2008 From: eduardo at intron.com.br (=?ISO-8859-1?Q?Eduardo_Ascen=E7o_Reis?=) Date: Wed, 12 Nov 2008 10:52:57 -0200 Subject: Potential Prefix Hijack In-Reply-To: <alpine.LRH.2.00.0811111158270.10275@parsnip.renesys.com> References: <200811111054.09473.mtinka@globaltransit.net> <Pine.SOC.4.61.0811101856240.27523@paixhost.pch.net> <20081111155450.GD38265@registro.br> <alpine.LRH.2.00.0811111158270.10275@parsnip.renesys.com> Message-ID: <45e3c45f0811120452s36ba81a7s41830951b7a33366@mail.gmail.com> Dear Fellows, I would like to add some information to this thread from AS27664 perspective. Both AS27664 (CTBC Multim?dia) and AS22548 (Nic.br) share two common points: 1. They are IP transit customers from AS16735 (CTBC Telecom). 2. They feed with full BGP routing table the RIS/RIPE project located at PTTMetro-SP, Brazil (rrc15). I checked all BGP updates of 2008111[01] from Route Views Archive Project [1] and looked for prefixes originated by AS16735. I compared those with the prefixes officially allocated by Registro.br to AS16735 [2] and did not find any case o prefixes from different AS. This analyses confirms that yesterday AS16735 issue of IP prefixes Hijacking was not globally propagated. It seems that only some AS16735's Internet customers (like AS27664 and AS22548) were affect by this problem. Regards, -- Eduardo Ascen?o Reis [1] http://archive.routeviews.org/ [2] https://registro.br/cgi-bin/whois/ From fyocum at gmail.com Wed Nov 12 07:33:57 2008 From: fyocum at gmail.com (Frank Yocum) Date: Wed, 12 Nov 2008 08:33:57 -0500 Subject: hosted PBX/VOIP thru VPN? In-Reply-To: <041301c9446c$c6a33030$53e99090$@org> References: <AclEbMVfzg84btTNS0uWarz0rAZ6FA==> <041301c9446c$c6a33030$53e99090$@org> Message-ID: <2770edf00811120533t3e3e1d05v5fe0969a8b308af1@mail.gmail.com> Lorell, It has been my experience that the VPN traffic will not be prioritize through the Internet. Why don't you suggest a test site for a comparison. Frank On Tue, Nov 11, 2008 at 9:17 PM, Lorell Hathcock <lorell at hathcock.org>wrote: > All: > > > > My customer wants to try to improve performance to his ATAs by creating a > VPN from his network to the VOIP provider's network through the internet. > > > > I have to admit, the idea caught me flat footed. At the outset, it seems > like we would want to do it just to improve security for end users. > However, > my customer wants it because he thinks it will improve performance (i.e. > voice quality). We are suffering from poor VOIP quality due to the Sprint > / > Cogent depeering and subsequent squirming by our vendors. > > > > The only reason I can think that VOIP thru a VPN would help is that > *perhaps* routers in the middle on ASNs I have no control over *may* > prioritize VPN traffic higher than regular traffic. They opposite could > also be true. > > > > Specifically the ASNs in the middle are Level 3, Sprint and Time Warner. > > > > Thoughts? Should I try to dissuade him from this if performance is his > main > motivator? > > > > Thanks! > > > > Sincerely, > > > > Lorell Hathcock > > > > OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | > lorell at OfficeConnect.net > > > > ocbannerjoomla > > > > > > From neil at domino.org Wed Nov 12 07:45:12 2008 From: neil at domino.org (Neil J. McRae) Date: Wed, 12 Nov 2008 13:45:12 -0000 (GMT) Subject: Router Choice In-Reply-To: <ac036ce50811120440x8139b1fq170fd13b5d0a61ef@mail.gmail.com> References: <ac036ce50811120440x8139b1fq170fd13b5d0a61ef@mail.gmail.com> Message-ID: <3806.62.208.225.86.1226497512.squirrel@webmail2.domino.org> On Wed, November 12, 2008 12:40, Raymond Macharia wrote: > Hello fellow nanogers, > I am a long time user of Cisco gear and currently evaluating an > alternative > for my network expansion. currently the one that looks like it will be > able > to do the job iare Alcatel-Lucent 7710/7750 service routers. > I am looking for real life experience of those who have used it and what I > may need to watch out for (if anything) I have seen in some of their > documentation features like Non-stop Services (NSS) and Non-stop Routing > (NSR). are these features real world deployable. > oh, just to add I want to use the routers as P routers in my IP/MPLS core I've deployed hundreds of these boxes as PE devices and they work _very well_ indeed. Not sure specifically about the non-stop part of it other than we have some of this deployed and it seems to work but is an area I think ALU could expand upon (and I believe they plan too). The ALU-Trimetra chaps based in San Jose and in Belgium are superb to work with also. -- Neil J. McRae -- Alive and Kicking. neil at DOMINO.ORG From sliplever at gmail.com Wed Nov 12 08:43:30 2008 From: sliplever at gmail.com (Dan Snyder) Date: Wed, 12 Nov 2008 09:43:30 -0500 Subject: Router Choice In-Reply-To: <ac036ce50811120440x8139b1fq170fd13b5d0a61ef@mail.gmail.com> References: <ac036ce50811120440x8139b1fq170fd13b5d0a61ef@mail.gmail.com> Message-ID: <D0AA0B5D-9EE6-4B60-8043-89D3A017EB77@gmail.com> I think that the 7750SR routers are great and you won't be let down. We used to have an all Cisco network and I was skeptical at first but they have been great. As for nss and nsr when we tested this by failing a cpm we saw less than 50 ms of traffic loss. I would see if you could go to either California or Canada to one of ALUs labs and have it demonstrated for you. hth, Dan Sent from my iPhone On Nov 12, 2008, at 7:40 AM, "Raymond Macharia" <rmacharia at gmail.com> wrote: > Hello fellow nanogers, > I am a long time user of Cisco gear and currently evaluating an > alternative > for my network expansion. currently the one that looks like it will > be able > to do the job iare Alcatel-Lucent 7710/7750 service routers. > I am looking for real life experience of those who have used it and > what I > may need to watch out for (if anything) I have seen in some of their > documentation features like Non-stop Services (NSS) and Non-stop > Routing > (NSR). are these features real world deployable. > oh, just to add I want to use the routers as P routers in my IP/MPLS > core > > Regards > -- > Raymond Macharia From devangnp at gmail.com Wed Nov 12 09:31:47 2008 From: devangnp at gmail.com (devang patel) Date: Wed, 12 Nov 2008 09:31:47 -0600 Subject: Router Choice In-Reply-To: <D0AA0B5D-9EE6-4B60-8043-89D3A017EB77@gmail.com> References: <ac036ce50811120440x8139b1fq170fd13b5d0a61ef@mail.gmail.com> <D0AA0B5D-9EE6-4B60-8043-89D3A017EB77@gmail.com> Message-ID: <d0fea3580811120731n577d954cp46c376eb14e72bb9@mail.gmail.com> I guess they have good lab in Plano, TX also!!!I worked on the same routers for IPTV deployment and really they are best!!! regards Devang Patel On Wed, Nov 12, 2008 at 8:43 AM, Dan Snyder <sliplever at gmail.com> wrote: > I think that the 7750SR routers are great and you won't be let down. We > used to have an all Cisco network and I was skeptical at first but they have > been great. > > As for nss and nsr when we tested this by failing a cpm we saw less than 50 > ms of traffic loss. I would see if you could go to either California or > Canada to one of ALUs labs and have it demonstrated for you. > > hth, > Dan > > > > Sent from my iPhone > > > On Nov 12, 2008, at 7:40 AM, "Raymond Macharia" <rmacharia at gmail.com> > wrote: > > Hello fellow nanogers, >> I am a long time user of Cisco gear and currently evaluating an >> alternative >> for my network expansion. currently the one that looks like it will be >> able >> to do the job iare Alcatel-Lucent 7710/7750 service routers. >> I am looking for real life experience of those who have used it and what I >> may need to watch out for (if anything) I have seen in some of their >> documentation features like Non-stop Services (NSS) and Non-stop Routing >> (NSR). are these features real world deployable. >> oh, just to add I want to use the routers as P routers in my IP/MPLS core >> >> Regards >> -- >> Raymond Macharia >> > > From scott at sonic.net Wed Nov 12 11:18:05 2008 From: scott at sonic.net (Scott Doty) Date: Wed, 12 Nov 2008 09:18:05 -0800 Subject: On the subject of multihoming In-Reply-To: <4910B14B.9010108@thewybles.com> References: <4910B14B.9010108@thewybles.com> Message-ID: <491B0FCD.7010605@sonic.net> [ resent to list, was sent from the wrong address -sd ] Charles Wyble wrote: > I'm working on a small experiment which utilizes multiple outbound > links (in the experiments case multiple consumer 3G connections [to 2 > Sprint/2 Verizon/1 AT&T], Time Warner Cable Modem and an SBC Global > DSL connection. > > What is the best way to do outbound traffic engineering? I would like > to be able to determine the best path possible and send traffic out > the appropriate link. Not sure if this is useful, but I thought I'd contribute a point on the curve... from NANOG 9: http://www.academ.com/nanog/feb1997/multihoming.html Obquote: from Paul Vixie's presentation, from Stan Barber's notes, here is the "meat of the matter": _ _ _ _ _ _ _ Per-interface Default Route * BSD TCP binds outbound route to PCB on SYN-ACK * Our trick: remember the inbound interface identity from the SYN * Each interface has its own "default route" * For outbound TCP and all UDP, a normal default is also needed. _ _ _ _ _ _ _ Hope that helps... -Scott From nazgul at somewhere.com Wed Nov 12 11:30:45 2008 From: nazgul at somewhere.com (Kee Hinckley) Date: Wed, 12 Nov 2008 11:30:45 -0600 Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd) In-Reply-To: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> Message-ID: <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> After reading this, and the (Washington Post I believe--I'm away from my laptop right now) article on this, two things are bothering me. The article expressed a good deal of frustration with the (lack of) speed with which law enforcement has been tackling these issues. What wasn't clear was whether any attempt had been made to involve them prior to the shutdown. At the very least, it seems that this makes any prosecution more difficult. While it appears that folks did a great job of following the network connections--to nail the individuals involved you need to follow the money. Even worse, what if the FBI *was* investigating them already, and now their target has been shut down? Unless there was behind-the-scenes cooperation that hasn't been reported, someone (on either the technical or law enforcement side) was not behaving responsibly. This should have been a coordinated shutdown--simultaneously involving closing network connections and arresting individuals. Secondly, aren't we still playing whack-a-mole here? The network controlled over a million compromised PCs. Those machines are still compromised. Since the individuals who controlled them are evidently still at large, I think it's safe to assume that the keys to those machines are still out there. If that's the case, then those machines will be up and spamming again inside of a week. The only thing that might delay that would be if the primary payment processors really were taken offline as well. I don't want to open the "counter-virus" can of worms. But how hard would it have been to identify the control sequences for those PCs and change them to random sequences? Shutting down a central control center is good news, but taking 1.5 million PCs permanently (at least until next infection) out of a botnet would be really impressive. Maybe more information will prove me wrong, but right now this seems more like a lost opportunity than a great success. I was quite surprised to hear that so many operations were centralized in one place. I doubt that opportunity is going to come again. Kee Hinckley CEO/CTO Somewhere, Inc. From xploitable at gmail.com Wed Nov 12 11:37:12 2008 From: xploitable at gmail.com (n3td3v) Date: Wed, 12 Nov 2008 17:37:12 +0000 Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd) In-Reply-To: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> Message-ID: <4b6ee9310811120937w4240e3efxeab0633e296789db@mail.gmail.com> The more we allow Gadi Evron to post the more this list turns into a rehash of digg and reddit news aggregation web sites. On Wed, Nov 12, 2008 at 2:37 AM, Gadi Evron <ge at linuxbox.org> wrote: > > > ---------- Forwarded message ---------- > Date: Tue, 11 Nov 2008 18:22:42 -0800 > From: Paul Ferguson <fergdawgster at gmail.com> > To: funsec at linuxbox.org > Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked > Offline > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Via Security Fix. > > [snip] > > A U.S. based Web hosting firm that security experts say was responsible for > facilitating more than 75 percent of the junk e-mail blasted out each day > globally has been knocked offline following reports from Security Fix on > evidence gathered about criminal activity emanating from the network. > > For the past four months, Security Fix has been gathering data from the > security industry about McColo Corp., a San Jose, Calif., based Web hosting > service whose client list experts say includes some of the most > disreputable cyber-criminal gangs in business today. > > On Monday, Security Fix contacted the Internet providers that manage more > than 90 percent of the company's connection to the larger Internet, sending > them information about badness at McColo as documented by the security > industry. > > [snip] > > More: > http://voices.washingtonpost.com/securityfix/2008/11/major_source_of_online > _scams_a.html > > Also, more details will become available real soon now... > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFJGj2hq1pz9mNUZTMRAsUaAJ4g4AzgLzD+NB9jvtlQu2kWwxY9UgCfakeM > RzvY4TKA6HqN8jePb8AJlOY= > =r3Oz > -----END PGP SIGNATURE----- > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > _______________________________________________ > Fun and Misc security discussion for OT posts. > https://linuxbox.org/cgi-bin/mailman/listinfo/funsec > Note: funsec is a public and open mailing list. > > From mohitlad at gmail.com Wed Nov 12 11:37:29 2008 From: mohitlad at gmail.com (Mohit Lad) Date: Wed, 12 Nov 2008 09:37:29 -0800 Subject: Potential Prefix Hijack Message-ID: <eea785af0811120937n2c387d63q88036b1d900c247d@mail.gmail.com> The local scope of the event is also the reason that PHAS did not catch the hijack. Nevertheless, its good to have different services for hijack detection running independently, especially if they are getting different feeds. Even a hijack that is local in scope is worth alerting about; if not anything, at least to ensure it stays local :) -Mohit On Nov 12, 2008, at 4:52 AM, Eduardo Ascen?o Reis wrote: Dear Fellows, I would like to add some information to this thread from AS27664 perspective. Both AS27664 (CTBC Multim?dia) and AS22548 (Nic.br) share two common points: 1. They are IP transit customers from AS16735 (CTBC Telecom). 2. They feed with full BGP routing table the RIS/RIPE project located at PTTMetro-SP, Brazil (rrc15). I checked all BGP updates of 2008111[01] from Route Views Archive Project [1] and looked for prefixes originated by AS16735. I compared those with the prefixes officially allocated by Registro.br to AS16735 [2] and did not find any case o prefixes from different AS. This analyses confirms that yesterday AS16735 issue of IP prefixes Hijacking was not globally propagated. It seems that only some AS16735's Internet customers (like AS27664 and AS22548) were affect by this problem. Regards, -- Eduardo Ascen?o Reis [1] http://archive.routeviews.org/ [2] https://registro.br/cgi-bin/whois/ From fergdawgster at gmail.com Wed Nov 12 11:53:56 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 12 Nov 2008 09:53:56 -0800 Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd) In-Reply-To: <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> Message-ID: <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Nov 12, 2008 at 9:30 AM, Kee Hinckley <nazgul at somewhere.com> wrote: > After reading this, and the (Washington Post I believe--I'm away from my > laptop right now) article on this, two things are bothering me. > > The article expressed a good deal of frustration with the (lack of) speed > with which law enforcement has been tackling these issues. What wasn't > clear was whether any attempt had been made to involve them prior to the > shutdown. Don't assume what you don't know. :-) - - ferg p.s. McColo's upstream providers are completely within their rights to terminate connectivity if they feel that they have violated their contractual terms of service. -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJGxggq1pz9mNUZTMRAsAwAKCUWdQAbTEZ+O5nWA/d1ED2fGSCQQCeJMUS PmOiEoLms6r/V1IxJqcLMlk= =2xEG -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From leothelion.murtaza at gmail.com Wed Nov 12 11:55:08 2008 From: leothelion.murtaza at gmail.com (Murtaza) Date: Wed, 12 Nov 2008 22:55:08 +0500 Subject: On the subject of multihoming In-Reply-To: <491B0FCD.7010605@sonic.net> References: <4910B14B.9010108@thewybles.com> <491B0FCD.7010605@sonic.net> Message-ID: <949b74980811120955w17341788p322c2ebe67615274@mail.gmail.com> Right now wee are also looking into the same question with the help of Overlay Routing. As far as Multihoming is concerned, there is a good work by jenifer rexford http://www.cs.princeton.edu/~jrex/papers/multipath06.pdf<http://www.cs.princeton.edu/%7Ejrex/papers/multipath06.pdf>. In fact IETF guys were thinking to include it in BGP implementation. Hope it would be helpful On Wed, Nov 12, 2008 at 10:18 PM, Scott Doty <scott at sonic.net> wrote: > [ resent to list, was sent from the wrong address -sd ] > > Charles Wyble wrote: > >> I'm working on a small experiment which utilizes multiple outbound links >> (in the experiments case multiple consumer 3G connections [to 2 Sprint/2 >> Verizon/1 AT&T], Time Warner Cable Modem and an SBC Global DSL connection. >> >> What is the best way to do outbound traffic engineering? I would like to >> be able to determine the best path possible and send traffic out the >> appropriate link. >> > > Not sure if this is useful, but I thought I'd contribute a point on the > curve... > > from NANOG 9: > > http://www.academ.com/nanog/feb1997/multihoming.html > > Obquote: from Paul Vixie's presentation, > from Stan Barber's notes, here is the "meat of the matter": > > _ _ _ _ _ _ _ > Per-interface Default Route > > * BSD TCP binds outbound route to PCB on SYN-ACK > * Our trick: remember the inbound interface identity from the SYN > * Each interface has its own "default route" > * For outbound TCP and all UDP, a normal default is also needed. > > _ _ _ _ _ _ _ > > Hope that helps... > > -Scott > > > > -- Ghulam Murtaza Lahore University of Management Sciences From chort at smtps.net Wed Nov 12 12:20:41 2008 From: chort at smtps.net (Brian Keefer) Date: Wed, 12 Nov 2008 10:20:41 -0800 Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd) In-Reply-To: <491A5317.8090109@tiedyenetworks.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <491A5317.8090109@tiedyenetworks.com> Message-ID: <ABFF9951-CD1C-4C86-8056-1184AF09394F@smtps.net> On Nov 11, 2008, at 7:52 PM, mike wrote: > > > Since 11/5, my spam load has dropped from about 400,000 attempts > per day to less than 40,000 ! And most of this I had noted was > comming from what looked like compromised web hosts - eg: same host/ > domain name representing 10 or 20 addresses in any given range). I > am shocked at the sudden and dramatic downtick but also equally > delighted! Way to go! > > > Gadi Evron wrote: >> >> Via Security Fix. >> >> [snip] >> >> A U.S. based Web hosting firm that security experts say was >> responsible for >> facilitating more than 75 percent of the junk e-mail blasted out >> each day >> globally has been knocked offline following reports from Security >> Fix on >> evidence gathered about criminal activity emanating from the network. > We noticed a very sudden 50% reduction yesterday. Now to see how long it lasts... -- bk From NNewman at nw3c.org Wed Nov 12 13:16:57 2008 From: NNewman at nw3c.org (Nick Newman) Date: Wed, 12 Nov 2008 14:16:57 -0500 Subject: [funsec] McColo: Major Source of Online Scams and Spams KnockedOffline (fwd) In-Reply-To: <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org><02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> Message-ID: <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int> I do know that the CA AG office ignores any complaints received from the Internet Crime Complaint Center (IC3), which bars many complaints state/local LE would have received from the public about McColo. Law enforcement (in the US, anyway), by nature, is 99% reactive and 1% proactive; no complaints to LE results in no response from LE. It's hard to tell if any local/state/federal agencies knew-about/were-investigating McColo (it was the same with Intercage), but the bigger question is: does it really matter? How many cops does it take to throw a community lynching? -- Nick Nicholas R.?Newman Computer Crimes Specialist National White Collar Crime Center 1000 Technology Drive, Suite 2130 Fairmont, WV 26554 ? 1-877-628-7674 x2244 nnewman at nw3c.org -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at gmail.com] Sent: Wednesday, November 12, 2008 12:54 PM To: Kee Hinckley Cc: nanog at merit.edu Subject: Re: [funsec] McColo: Major Source of Online Scams and Spams KnockedOffline (fwd) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Nov 12, 2008 at 9:30 AM, Kee Hinckley <nazgul at somewhere.com> wrote: > After reading this, and the (Washington Post I believe--I'm away from my > laptop right now) article on this, two things are bothering me. > > The article expressed a good deal of frustration with the (lack of) speed > with which law enforcement has been tackling these issues. What wasn't > clear was whether any attempt had been made to involve them prior to the > shutdown. Don't assume what you don't know. :-) - - ferg p.s. McColo's upstream providers are completely within their rights to terminate connectivity if they feel that they have violated their contractual terms of service. -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJGxggq1pz9mNUZTMRAsAwAKCUWdQAbTEZ+O5nWA/d1ED2fGSCQQCeJMUS PmOiEoLms6r/V1IxJqcLMlk= =2xEG -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From algorythm at gmail.com Wed Nov 12 13:44:58 2008 From: algorythm at gmail.com (Jason Ross) Date: Wed, 12 Nov 2008 14:44:58 -0500 Subject: [funsec] McColo: Major Source of Online Scams and Spams KnockedOffline (fwd) In-Reply-To: <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int> Message-ID: <355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> On Wed, Nov 12, 2008 at 14:16, Nick Newman <NNewman at nw3c.org> wrote: > How many cops does it take to throw a community lynching? > None. The question that remains is: Why is the community having to resort to lynching? Following the metaphor and using the US "Old West" as an example, lynchings were largely due to one of the following: * a lack of organized law enforcement * a lack of effective law enforcement * an outraged mob following the lead of a few with their own agenda in the heat of some moment I don't think the latter point applies (though some have argued it very much does). The former two points though very much do IMO, and I think this was the point Kee was making. To put it another way: How can we as network operators help law enforcement become more organized and effective such that lynchings are no longer needed? I'm not convinced there's an adequate answer to that question given the current structure of "the internet", and the nature of how things work. ( I suppose there's room in there for an argument that community lynchings are the most effective way to deal with the problems that arise, though I don't think such is the case. ) -- Jason From ge at linuxbox.org Wed Nov 12 14:04:10 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 12 Nov 2008 14:04:10 -0600 (CST) Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd) In-Reply-To: <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> Message-ID: <alpine.DEB.0.999999.0811121403190.12648@linuxbox.org> On Wed, 12 Nov 2008, Kee Hinckley wrote: > After reading this, and the (Washington Post I believe--I'm away from my > laptop right now) article on this, two things are bothering me. > > The article expressed a good deal of frustration with the (lack of) speed > with which law enforcement has been tackling these issues. What wasn't clear > was whether any attempt had been made to involve them prior to the shutdown. > At the very least, it seems that this makes any prosecution more difficult. > While it appears that folks did a great job of following the network > connections--to nail the individuals involved you need to follow the money. > Even worse, what if the FBI *was* investigating them already, and now their > target has been shut down? Unless there was behind-the-scenes cooperation > that hasn't been reported, someone (on either the technical or law > enforcement side) was not behaving responsibly. This should have been a > coordinated shutdown--simultaneously involving closing network connections > and arresting individuals. > > Secondly, aren't we still playing whack-a-mole here? The network controlled > over a million compromised PCs. Those machines are still compromised. Since > the individuals who controlled them are evidently still at large, I think > it's safe to assume that the keys to those machines are still out there. If > that's the case, then those machines will be up and spamming again inside of > a week. The only thing that might delay that would be if the primary payment > processors really were taken offline as well. I don't want to open the > "counter-virus" can of worms. But how hard would it have been to identify the > control sequences for those PCs and change them to random sequences? Shutting > down a central control center is good news, but taking 1.5 million PCs > permanently (at least until next infection) out of a botnet would be really > impressive. > > Maybe more information will prove me wrong, but right now this seems more > like a lost opportunity than a great success. I was quite surprised to hear > that so many operations were centralized in one place. I doubt that > opportunity is going to come again. All your points sound valid to me, but I am already proved wrong that while I believed this to be a great precedent and a strategic move... it wouldn't happen again. It did... twice, since Atrivo, Estdomians (kinda) and now mccolo. > Kee Hinckley > CEO/CTO Somewhere, Inc. From jeffshultz at wvi.com Wed Nov 12 14:55:32 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Wed, 12 Nov 2008 12:55:32 -0800 Subject: [funsec] McColo: Major Source of Online Scams and Spams KnockedOffline (fwd) In-Reply-To: <355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int> <355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> Message-ID: <491B42C4.7080805@wvi.com> Jason Ross wrote: > On Wed, Nov 12, 2008 at 14:16, Nick Newman <NNewman at nw3c.org> wrote: >> How many cops does it take to throw a community lynching? >> > > None. > The question that remains is: Why is the community having to resort to lynching? > > Following the metaphor and using the US "Old West" as an example, > lynchings were largely due to one of the following: > > * a lack of organized law enforcement > * a lack of effective law enforcement The problem is that to fix either of those problems you'd have to wade through a fever swamp of "facists online!" claims from all the pseudo-anarchists who start twitching at the thought of any agency imposing it's will on the internet. -- Jeff Shultz From LarrySheldon at cox.net Wed Nov 12 15:35:16 2008 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 12 Nov 2008 15:35:16 -0600 Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd) In-Reply-To: <4b6ee9310811120937w4240e3efxeab0633e296789db@mail.gmail.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <4b6ee9310811120937w4240e3efxeab0633e296789db@mail.gmail.com> Message-ID: <491B4C14.8010009@cox.net> n3td3v wrote: > The more we allow Gadi Evron to post the more this list turns into a > rehash of digg and reddit news aggregation web sites. Well, I'll just drop off the list so you you can talk uninterrupted about Important Operational Matters like "who's got a freebie DSL connection for me in Inner Sweatsock, Mumbolia?" From sfischer1967 at gmail.com Wed Nov 12 15:44:23 2008 From: sfischer1967 at gmail.com (Steven Fischer) Date: Wed, 12 Nov 2008 16:44:23 -0500 Subject: [funsec] McColo: Major Source of Online Scams and Spams KnockedOffline (fwd) In-Reply-To: <491B42C4.7080805@wvi.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int> <355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> <491B42C4.7080805@wvi.com> Message-ID: <500ffb690811121344sf3889d7tc2e0358ca6410cc5@mail.gmail.com> I wonder how many of these "pseudo-anarchists" are bewailing the lack of regulation in the financial markets, given the events of the past couple of months? A certain amount of regulation and oversight is needed, both in the financial world and on the Internet. I am all for seeing how little we can get by with, but clearly, some is needed. On Wed, Nov 12, 2008 at 3:55 PM, Jeff Shultz <jeffshultz at wvi.com> wrote: > Jason Ross wrote: > >> On Wed, Nov 12, 2008 at 14:16, Nick Newman <NNewman at nw3c.org> wrote: >> >>> How many cops does it take to throw a community lynching? >>> >>> >> None. >> The question that remains is: Why is the community having to resort to >> lynching? >> >> Following the metaphor and using the US "Old West" as an example, >> lynchings were largely due to one of the following: >> >> * a lack of organized law enforcement >> * a lack of effective law enforcement >> > > The problem is that to fix either of those problems you'd have to wade > through a fever swamp of "facists online!" claims from all the > pseudo-anarchists who start twitching at the thought of any agency imposing > it's will on the internet. > > -- > Jeff Shultz > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From beckman at angryox.com Wed Nov 12 15:47:40 2008 From: beckman at angryox.com (Peter Beckman) Date: Wed, 12 Nov 2008 16:47:40 -0500 Subject: Verizon/UU.net/Alternet Routing issue Message-ID: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com> At about 4:24pm EDT, I lost connectivity from Verizon to destinations in New York, Seattle and others. Came back up (4:46pm) while composing this email. Anyone else notice? Major problem or minor routing issue? Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. localrouter 67.6% 395 0.6 1.6 0.5 18.8 2.3 2. 10.1.41.15 0.0% 395 5.7 5.1 1.8 306.0 17.4 3. P4-2.LCR-02.WASHDC.verizon-g 0.0% 395 7.4 2.7 1.2 19.0 2.5 4. 130.81.29.218 0.0% 395 6.0 3.8 1.8 40.9 4.2 5. 152.63.39.177 0.0% 395 8.6 6.8 3.9 71.3 4.4 152.63.36.213 6. 152.63.69.113 71.6% 395 120.7 44.0 31.2 186.7 30.3 7. POS7-0-0.GW4.IND6.ALTER.NET 30.7% 395 1179. 133.3 121.3 1179. 79.5 8. 152.63.67.250 93.9% 395 121.5 125.4 121.0 186.2 13.0 9. POS6-0-0.GW4.IND6.ALTER.NET 53.0% 395 318.9 217.7 206.8 722.0 43.3 10. 152.63.67.250 96.2% 395 211.1 211.1 209.0 215.7 1.8 11. POS6-0-0.GW4.IND6.ALTER.NET 67.0% 395 422.1 305.9 294.9 692.1 37.5 12. 152.63.67.250 97.5% 394 295.1 298.0 295.1 303.6 2.5 13. POS6-0-0.GW4.IND6.ALTER.NET 73.5% 394 523.9 391.5 382.1 523.9 17.7 14. 152.63.67.250 98.7% 392 388.5 386.6 381.9 389.5 3.1 15. POS6-0-0.GW4.IND6.ALTER.NET 82.6% 392 632.9 481.2 468.6 632.9 22.2 16. 152.63.67.250 99.2% 388 472.7 472.2 470.2 473.6 1.8 17. POS6-0-0.GW4.IND6.ALTER.NET 85.8% 388 737.0 573.3 559.4 737.0 27.8 18. 152.63.67.250 99.2% 387 560.5 562.0 560.5 565.1 2.7 19. POS6-0-0.GW4.IND6.ALTER.NET 89.6% 387 839.0 664.8 644.9 839.0 38.6 20. 152.63.67.250 99.2% 387 649.3 649.6 649.3 649.9 0.3 21. POS6-0-0.GW4.IND6.ALTER.NET 94.8% 383 946.4 763.8 734.6 946.4 48.5 22. 152.63.67.250 99.7% 376 735.5 735.5 735.5 735.5 0.0 23. POS6-0-0.GW4.IND6.ALTER.NET 92.5% 376 895.4 842.2 819.1 909.0 26.8 24. ??? 25. POS6-0-0.GW4.IND6.ALTER.NET 96.7% 365 1153. 955.9 908.9 1153. 78.7 26. ??? 27. POS6-0-0.GW4.IND6.ALTER.NET 96.6% 328 1261. 1057. 998.8 1261. 86.8 28. 152.63.67.250 99.6% 245 999.3 999.3 999.3 999.3 0.0 29. POS6-0-0.GW4.IND6.ALTER.NET 98.8% 245 1189. 1123. 1086. 1189. 57.5 30. ??? Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From ddunkin at netos.net Wed Nov 12 15:49:25 2008 From: ddunkin at netos.net (Darryl Dunkin) Date: Wed, 12 Nov 2008 13:49:25 -0800 Subject: Verizon/UU.net/Alternet Routing issue References: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com> Message-ID: <56F5BC5F404CF84896C447397A1AAF20A0FDA5@MAIL.nosi.netos.com> Yes, all our traffic was dying over at UUNet, yet it was still being announced it. It just came up before I could send anything to outages. -----Original Message----- From: Peter Beckman [mailto:beckman at angryox.com] Sent: Wednesday, November 12, 2008 13:48 To: nanog at nanog.org Subject: Verizon/UU.net/Alternet Routing issue At about 4:24pm EDT, I lost connectivity from Verizon to destinations in New York, Seattle and others. Came back up (4:46pm) while composing this email. Anyone else notice? Major problem or minor routing issue? Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. localrouter 67.6% 395 0.6 1.6 0.5 18.8 2.3 2. 10.1.41.15 0.0% 395 5.7 5.1 1.8 306.0 17.4 3. P4-2.LCR-02.WASHDC.verizon-g 0.0% 395 7.4 2.7 1.2 19.0 2.5 4. 130.81.29.218 0.0% 395 6.0 3.8 1.8 40.9 4.2 5. 152.63.39.177 0.0% 395 8.6 6.8 3.9 71.3 4.4 152.63.36.213 6. 152.63.69.113 71.6% 395 120.7 44.0 31.2 186.7 30.3 7. POS7-0-0.GW4.IND6.ALTER.NET 30.7% 395 1179. 133.3 121.3 1179. 79.5 8. 152.63.67.250 93.9% 395 121.5 125.4 121.0 186.2 13.0 9. POS6-0-0.GW4.IND6.ALTER.NET 53.0% 395 318.9 217.7 206.8 722.0 43.3 10. 152.63.67.250 96.2% 395 211.1 211.1 209.0 215.7 1.8 11. POS6-0-0.GW4.IND6.ALTER.NET 67.0% 395 422.1 305.9 294.9 692.1 37.5 12. 152.63.67.250 97.5% 394 295.1 298.0 295.1 303.6 2.5 13. POS6-0-0.GW4.IND6.ALTER.NET 73.5% 394 523.9 391.5 382.1 523.9 17.7 14. 152.63.67.250 98.7% 392 388.5 386.6 381.9 389.5 3.1 15. POS6-0-0.GW4.IND6.ALTER.NET 82.6% 392 632.9 481.2 468.6 632.9 22.2 16. 152.63.67.250 99.2% 388 472.7 472.2 470.2 473.6 1.8 17. POS6-0-0.GW4.IND6.ALTER.NET 85.8% 388 737.0 573.3 559.4 737.0 27.8 18. 152.63.67.250 99.2% 387 560.5 562.0 560.5 565.1 2.7 19. POS6-0-0.GW4.IND6.ALTER.NET 89.6% 387 839.0 664.8 644.9 839.0 38.6 20. 152.63.67.250 99.2% 387 649.3 649.6 649.3 649.9 0.3 21. POS6-0-0.GW4.IND6.ALTER.NET 94.8% 383 946.4 763.8 734.6 946.4 48.5 22. 152.63.67.250 99.7% 376 735.5 735.5 735.5 735.5 0.0 23. POS6-0-0.GW4.IND6.ALTER.NET 92.5% 376 895.4 842.2 819.1 909.0 26.8 24. ??? 25. POS6-0-0.GW4.IND6.ALTER.NET 96.7% 365 1153. 955.9 908.9 1153. 78.7 26. ??? 27. POS6-0-0.GW4.IND6.ALTER.NET 96.6% 328 1261. 1057. 998.8 1261. 86.8 28. 152.63.67.250 99.6% 245 999.3 999.3 999.3 999.3 0.0 29. POS6-0-0.GW4.IND6.ALTER.NET 98.8% 245 1189. 1123. 1086. 1189. 57.5 30. ??? Beckman ------------------------------------------------------------------------ --- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ------------------------------------------------------------------------ --- From NNewman at nw3c.org Wed Nov 12 15:52:12 2008 From: NNewman at nw3c.org (Nick Newman) Date: Wed, 12 Nov 2008 16:52:12 -0500 Subject: [funsec] McColo: Major Source of Online Scams andSpams KnockedOffline (fwd) In-Reply-To: <491B42C4.7080805@wvi.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int><355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> <491B42C4.7080805@wvi.com> Message-ID: <DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int> There's a common misconception of what LE does online (and when I say LE, I'm talking mostly state/local agencies): if you watch CSI or any other show that has anything to do with computer crimes, there is always a team of uber-geeks at every single agency (no matter how big it is) who spend 50% of their time online looking for phishing sites, CP sites, fraud sites and on and on. The real world isn't like that at all. For example, one state police agency we're familiar with has a team of *two guys* that do almost all of the computer forensics work for the *entire state*. Considering the caseload they have (if I remember correctly, a computer has a turn-around time of 6 months, a cell phone about a week; this is because every avenue a defense attorney is going to take has to be covered), there quite simply is not time to do anything proactive online (such as analyze spam to find out most of it is coming from a couple particularly nasty web hosting companies on the other side of the country). In most small agencies, the "computer forensics guy" is just the guy that knows more about computers than anyone else (read as, he figured out which port on the back of the computer was the USB port to hook up a new printer). A handful of agencies nationwide are fortunate enough to have a CSI-esque computer forensics unit, but most do not. Let's compare these two scenarios: 1. The world-wide community of people who essentially run the Internet have had enough with a nasty webhosting company in California. They've determined that the majority of spam world-wide originates from this company offering bullet-proof hosting. So they call the upstream providers and get them cut off. NastySitesUnlimited tries to switch providers, but are disconnected again. And again. And again. A few days later, company files for bankruptcy because no one will give them an uplink to the 'net. Problem solved. End of story. 2. Some LE agency serves a search warrant for "any digital evidence" and collects hundreds of terabytes of worth of data. 5 years later, after everything is processed (and during this time, things at Nasty Hosting Company have continued as normal, thanks to regular backups), charges are finally brought against some entity in the business, he gets thrown in jail for a few years and fined heavily, business gets renamed (VP takes over) and it's almost like nothing ever happened. Which happened faster and was more effective? On to the question about how network operators can help LE: *Collect the data that proves a company such as Intercage/McColo is harboring cybercriminals* and get with your local FBI/Secret Service field office (or your state's Attorney General's office) (or both) and submit a complaint at IC3's website (www.ic3.gov) because we have an excellent team of analysts that track information like that. Package up the evidence you have and send it out. If we lived in a perfect world, there would be a third scenario: 3. The world-wide community of people who essentially run the Internet have had enough with a nasty webhosting company in California. So they gather an abundance of super-damning evidence and submit it to LE. LE starts an investigation with the outstanding leads provided in the package, and starts making arrests. The CEO and a few others at NastySitesUnlimited get sentenced and thrown in jail. Business at NastySitesUnlimited continues as usual until they are cut off from the Internet a few days later because no one will give them upstream service. It took a little bit longer, but the culprits are in jail and the business has been lynched. Kee had an excellent question when he asked if anyone tried notifying LE, and the answer to that is probably not. It's hard to tell what would've happened if LE was involved (who knows, maybe SS or FBI were working on it). LE does care, it's just a matter of resources available. If you get the evidence together and in a matter that explains itself, it will get handled effectively (though probably not as fast as "Intercaging" a company). -- Nick Nicholas R.?Newman Computer Crimes Specialist National White Collar Crime Center 1000 Technology Drive, Suite 2130 Fairmont, WV 26554 ? 1-877-628-7674 x2244 nnewman at nw3c.org -----Original Message----- From: Jeff Shultz [mailto:jeffshultz at wvi.com] Sent: Wednesday, November 12, 2008 3:56 PM To: NANOG list Subject: Re: [funsec] McColo: Major Source of Online Scams andSpams KnockedOffline (fwd) Jason Ross wrote: > On Wed, Nov 12, 2008 at 14:16, Nick Newman <NNewman at nw3c.org> wrote: >> How many cops does it take to throw a community lynching? >> > > None. > The question that remains is: Why is the community having to resort to lynching? > > Following the metaphor and using the US "Old West" as an example, > lynchings were largely due to one of the following: > > * a lack of organized law enforcement > * a lack of effective law enforcement The problem is that to fix either of those problems you'd have to wade through a fever swamp of "facists online!" claims from all the pseudo-anarchists who start twitching at the thought of any agency imposing it's will on the internet. -- Jeff Shultz From mwalter at 3z.net Wed Nov 12 15:52:43 2008 From: mwalter at 3z.net (Mike Walter) Date: Wed, 12 Nov 2008 16:52:43 -0500 Subject: Verizon/UU.net/Alternet Routing issue In-Reply-To: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com> References: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com> Message-ID: <A16877978862E44E9F4EECD23635750E68F494@zionex1.ZION.local> Yes, we saw the same thing and all seems to be better now. Was on hold and hung up. Mike Walter, MCP Systems Administrator 3z.net a PCD Company http://www.3z.net "When Success is the Only Solution think 3z.net" -----Original Message----- From: Peter Beckman [mailto:beckman at angryox.com] Sent: Wednesday, November 12, 2008 4:48 PM To: nanog at nanog.org Subject: Verizon/UU.net/Alternet Routing issue At about 4:24pm EDT, I lost connectivity from Verizon to destinations in New York, Seattle and others. Came back up (4:46pm) while composing this email. Anyone else notice? Major problem or minor routing issue? Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. localrouter 67.6% 395 0.6 1.6 0.5 18.8 2.3 2. 10.1.41.15 0.0% 395 5.7 5.1 1.8 306.0 17.4 3. P4-2.LCR-02.WASHDC.verizon-g 0.0% 395 7.4 2.7 1.2 19.0 2.5 4. 130.81.29.218 0.0% 395 6.0 3.8 1.8 40.9 4.2 5. 152.63.39.177 0.0% 395 8.6 6.8 3.9 71.3 4.4 152.63.36.213 6. 152.63.69.113 71.6% 395 120.7 44.0 31.2 186.7 30.3 7. POS7-0-0.GW4.IND6.ALTER.NET 30.7% 395 1179. 133.3 121.3 1179. 79.5 8. 152.63.67.250 93.9% 395 121.5 125.4 121.0 186.2 13.0 9. POS6-0-0.GW4.IND6.ALTER.NET 53.0% 395 318.9 217.7 206.8 722.0 43.3 10. 152.63.67.250 96.2% 395 211.1 211.1 209.0 215.7 1.8 11. POS6-0-0.GW4.IND6.ALTER.NET 67.0% 395 422.1 305.9 294.9 692.1 37.5 12. 152.63.67.250 97.5% 394 295.1 298.0 295.1 303.6 2.5 13. POS6-0-0.GW4.IND6.ALTER.NET 73.5% 394 523.9 391.5 382.1 523.9 17.7 14. 152.63.67.250 98.7% 392 388.5 386.6 381.9 389.5 3.1 15. POS6-0-0.GW4.IND6.ALTER.NET 82.6% 392 632.9 481.2 468.6 632.9 22.2 16. 152.63.67.250 99.2% 388 472.7 472.2 470.2 473.6 1.8 17. POS6-0-0.GW4.IND6.ALTER.NET 85.8% 388 737.0 573.3 559.4 737.0 27.8 18. 152.63.67.250 99.2% 387 560.5 562.0 560.5 565.1 2.7 19. POS6-0-0.GW4.IND6.ALTER.NET 89.6% 387 839.0 664.8 644.9 839.0 38.6 20. 152.63.67.250 99.2% 387 649.3 649.6 649.3 649.9 0.3 21. POS6-0-0.GW4.IND6.ALTER.NET 94.8% 383 946.4 763.8 734.6 946.4 48.5 22. 152.63.67.250 99.7% 376 735.5 735.5 735.5 735.5 0.0 23. POS6-0-0.GW4.IND6.ALTER.NET 92.5% 376 895.4 842.2 819.1 909.0 26.8 24. ??? 25. POS6-0-0.GW4.IND6.ALTER.NET 96.7% 365 1153. 955.9 908.9 1153. 78.7 26. ??? 27. POS6-0-0.GW4.IND6.ALTER.NET 96.6% 328 1261. 1057. 998.8 1261. 86.8 28. 152.63.67.250 99.6% 245 999.3 999.3 999.3 999.3 0.0 29. POS6-0-0.GW4.IND6.ALTER.NET 98.8% 245 1189. 1123. 1086. 1189. 57.5 30. ??? Beckman ------------------------------------------------------------------------ --- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ------------------------------------------------------------------------ --- From andrew2 at one.net Wed Nov 12 15:54:04 2008 From: andrew2 at one.net (andrew2 at one.net) Date: Wed, 12 Nov 2008 16:54:04 -0500 Subject: Verizon/UU.net/Alternet Routing issue In-Reply-To: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com> Message-ID: <016401c94511$2e694020$800101df@andrew2> Peter Beckman wrote: > At about 4:24pm EDT, I lost connectivity from Verizon to destinations > in > New York, Seattle and others. Came back up (4:46pm) while composing > this > email. Anyone else notice? Major problem or minor routing issue? > > Beckman I'm still on hold with Verizon -- has anyone heard anything official from them? I'm hesitant to turn that circuit back up... Andrew Cruse From alan at halachmi.net Wed Nov 12 15:54:04 2008 From: alan at halachmi.net (Alan Halachmi) Date: Wed, 12 Nov 2008 16:54:04 -0500 (EST) Subject: Verizon/UU.net/Alternet Routing issue In-Reply-To: <56F5BC5F404CF84896C447397A1AAF20A0FDA5@MAIL.nosi.netos.com> References: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com> <56F5BC5F404CF84896C447397A1AAF20A0FDA5@MAIL.nosi.netos.com> Message-ID: <Pine.GSO.4.64.0811121653330.11160@phronyy.vagreany.unynpuzv.arg> Same here... I'm a Verizon FiOS customer... My Vonage line went dead in the middle of a call... On Wed, 12 Nov 2008, Darryl Dunkin wrote: ddunki>Yes, all our traffic was dying over at UUNet, yet it was still being ddunki>announced it. It just came up before I could send anything to outages. ddunki> ddunki>-----Original Message----- ddunki>From: Peter Beckman [mailto:beckman at angryox.com] ddunki>Sent: Wednesday, November 12, 2008 13:48 ddunki>To: nanog at nanog.org ddunki>Subject: Verizon/UU.net/Alternet Routing issue ddunki> ddunki>At about 4:24pm EDT, I lost connectivity from Verizon to destinations in ddunki>New York, Seattle and others. Came back up (4:46pm) while composing ddunki>this ddunki>email. Anyone else notice? Major problem or minor routing issue? ddunki> ddunki> Packets Pings ddunki> Host Loss% Snt Last Avg Best Wrst ddunki>StDev ddunki> 1. localrouter 67.6% 395 0.6 1.6 0.5 18.8 ddunki>2.3 ddunki> 2. 10.1.41.15 0.0% 395 5.7 5.1 1.8 306.0 ddunki>17.4 ddunki> 3. P4-2.LCR-02.WASHDC.verizon-g 0.0% 395 7.4 2.7 1.2 19.0 ddunki>2.5 ddunki> 4. 130.81.29.218 0.0% 395 6.0 3.8 1.8 40.9 ddunki>4.2 ddunki> 5. 152.63.39.177 0.0% 395 8.6 6.8 3.9 71.3 ddunki>4.4 ddunki> 152.63.36.213 ddunki> 6. 152.63.69.113 71.6% 395 120.7 44.0 31.2 186.7 ddunki>30.3 ddunki> 7. POS7-0-0.GW4.IND6.ALTER.NET 30.7% 395 1179. 133.3 121.3 1179. ddunki>79.5 ddunki> 8. 152.63.67.250 93.9% 395 121.5 125.4 121.0 186.2 ddunki>13.0 ddunki> 9. POS6-0-0.GW4.IND6.ALTER.NET 53.0% 395 318.9 217.7 206.8 722.0 ddunki>43.3 ddunki>10. 152.63.67.250 96.2% 395 211.1 211.1 209.0 215.7 ddunki>1.8 ddunki>11. POS6-0-0.GW4.IND6.ALTER.NET 67.0% 395 422.1 305.9 294.9 692.1 ddunki>37.5 ddunki>12. 152.63.67.250 97.5% 394 295.1 298.0 295.1 303.6 ddunki>2.5 ddunki>13. POS6-0-0.GW4.IND6.ALTER.NET 73.5% 394 523.9 391.5 382.1 523.9 ddunki>17.7 ddunki>14. 152.63.67.250 98.7% 392 388.5 386.6 381.9 389.5 ddunki>3.1 ddunki>15. POS6-0-0.GW4.IND6.ALTER.NET 82.6% 392 632.9 481.2 468.6 632.9 ddunki>22.2 ddunki>16. 152.63.67.250 99.2% 388 472.7 472.2 470.2 473.6 ddunki>1.8 ddunki>17. POS6-0-0.GW4.IND6.ALTER.NET 85.8% 388 737.0 573.3 559.4 737.0 ddunki>27.8 ddunki>18. 152.63.67.250 99.2% 387 560.5 562.0 560.5 565.1 ddunki>2.7 ddunki>19. POS6-0-0.GW4.IND6.ALTER.NET 89.6% 387 839.0 664.8 644.9 839.0 ddunki>38.6 ddunki>20. 152.63.67.250 99.2% 387 649.3 649.6 649.3 649.9 ddunki>0.3 ddunki>21. POS6-0-0.GW4.IND6.ALTER.NET 94.8% 383 946.4 763.8 734.6 946.4 ddunki>48.5 ddunki>22. 152.63.67.250 99.7% 376 735.5 735.5 735.5 735.5 ddunki>0.0 ddunki>23. POS6-0-0.GW4.IND6.ALTER.NET 92.5% 376 895.4 842.2 819.1 909.0 ddunki>26.8 ddunki>24. ??? ddunki>25. POS6-0-0.GW4.IND6.ALTER.NET 96.7% 365 1153. 955.9 908.9 1153. ddunki>78.7 ddunki>26. ??? ddunki>27. POS6-0-0.GW4.IND6.ALTER.NET 96.6% 328 1261. 1057. 998.8 1261. ddunki>86.8 ddunki>28. 152.63.67.250 99.6% 245 999.3 999.3 999.3 999.3 ddunki>0.0 ddunki>29. POS6-0-0.GW4.IND6.ALTER.NET 98.8% 245 1189. 1123. 1086. 1189. ddunki>57.5 ddunki>30. ??? ddunki> ddunki>Beckman ddunki>------------------------------------------------------------------------ ddunki>--- ddunki>Peter Beckman Internet ddunki>Guy ddunki>beckman at angryox.com ddunki>http://www.angryox.com/ ddunki>------------------------------------------------------------------------ ddunki>--- ddunki> ddunki> Best, Alan From jay at west.net Wed Nov 12 15:56:39 2008 From: jay at west.net (Jay Hennigan) Date: Wed, 12 Nov 2008 13:56:39 -0800 Subject: [funsec] McColo: Major Source of Online Scams and Spams KnockedOffline (fwd) In-Reply-To: <355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int> <355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> Message-ID: <491B5117.3020106@west.net> Jason Ross wrote: > On Wed, Nov 12, 2008 at 14:16, Nick Newman <NNewman at nw3c.org> wrote: >> How many cops does it take to throw a community lynching? >> > > None. > The question that remains is: Why is the community having to resort to lynching? I think we're using the wrong metaphors here. A community lynching would be storming his datacenter and setting his servers on fire. That didn't happen. A better metaphor would be a rowdy patron in an upscale bar attempting to deal drugs and being tossed out by the bouncer. Although dealing drugs is illegal, the people in the bar are more concerned about getting rid of the jerk than throwing his butt in jail (although that would be nice as well). If law enforcement is busy with gang warfare in another part of town, their priority in responding to a rowdy in a bar is going to be low, especially if there's a bouncer who is capable of dealing with the problem. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From j at arpa.com Wed Nov 12 16:14:47 2008 From: j at arpa.com (jamie rishaw) Date: Wed, 12 Nov 2008 16:14:47 -0600 Subject: Verizon/UU.net/Alternet Routing issue In-Reply-To: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com> References: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com> Message-ID: <e6e9128b0811121414q341d79dcmf87567fd4440c7a5@mail.gmail.com> Confirmed here as well; Saw loss on DS3s between 424 and 440 EST. BGP survived but routing didnt .. No RCA yet from VZN (on hold). On Wed, Nov 12, 2008 at 3:47 PM, Peter Beckman <beckman at angryox.com> wrote: > At about 4:24pm EDT, I lost connectivity from Verizon to destinations in > New York, Seattle and others. Came back up (4:46pm) while composing this > email. Anyone else notice? Major problem or minor routing issue? > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. localrouter 67.6% 395 0.6 1.6 0.5 18.8 2.3 > 2. 10.1.41.15 0.0% 395 5.7 5.1 1.8 306.0 > 17.4 > 3. P4-2.LCR-02.WASHDC.verizon-g 0.0% 395 7.4 2.7 1.2 19.0 2.5 > 4. 130.81.29.218 0.0% 395 6.0 3.8 1.8 40.9 > 4.2 > 5. 152.63.39.177 0.0% 395 8.6 6.8 3.9 71.3 > 4.4 > 152.63.36.213 > 6. 152.63.69.113 71.6% 395 120.7 44.0 31.2 186.7 > 30.3 > 7. POS7-0-0.GW4.IND6.ALTER.NET 30.7% 395 1179. 133.3 121.3 1179. > 79.5 > 8. 152.63.67.250 93.9% 395 121.5 125.4 121.0 186.2 > 13.0 > 9. POS6-0-0.GW4.IND6.ALTER.NET 53.0% 395 318.9 217.7 206.8 722.0 > 43.3 > 10. 152.63.67.250 96.2% 395 211.1 211.1 209.0 215.7 > 1.8 > 11. POS6-0-0.GW4.IND6.ALTER.NET 67.0% 395 422.1 305.9 294.9 692.1 > 37.5 > 12. 152.63.67.250 97.5% 394 295.1 298.0 295.1 303.6 > 2.5 > 13. POS6-0-0.GW4.IND6.ALTER.NET 73.5% 394 523.9 391.5 382.1 523.9 > 17.7 > 14. 152.63.67.250 98.7% 392 388.5 386.6 381.9 389.5 > 3.1 > 15. POS6-0-0.GW4.IND6.ALTER.NET 82.6% 392 632.9 481.2 468.6 632.9 > 22.2 > 16. 152.63.67.250 99.2% 388 472.7 472.2 470.2 473.6 > 1.8 > 17. POS6-0-0.GW4.IND6.ALTER.NET 85.8% 388 737.0 573.3 559.4 737.0 > 27.8 > 18. 152.63.67.250 99.2% 387 560.5 562.0 560.5 565.1 > 2.7 > 19. POS6-0-0.GW4.IND6.ALTER.NET 89.6% 387 839.0 664.8 644.9 839.0 > 38.6 > 20. 152.63.67.250 99.2% 387 649.3 649.6 649.3 649.9 > 0.3 > 21. POS6-0-0.GW4.IND6.ALTER.NET 94.8% 383 946.4 763.8 734.6 946.4 > 48.5 > 22. 152.63.67.250 99.7% 376 735.5 735.5 735.5 735.5 > 0.0 > 23. POS6-0-0.GW4.IND6.ALTER.NET 92.5% 376 895.4 842.2 819.1 909.0 > 26.8 > 24. ??? > 25. POS6-0-0.GW4.IND6.ALTER.NET 96.7% 365 1153. 955.9 908.9 1153. > 78.7 > 26. ??? > 27. POS6-0-0.GW4.IND6.ALTER.NET 96.6% 328 1261. 1057. 998.8 1261. > 86.8 > 28. 152.63.67.250 99.6% 245 999.3 999.3 999.3 999.3 > 0.0 > 29. POS6-0-0.GW4.IND6.ALTER.NET 98.8% 245 1189. 1123. 1086. 1189. > 57.5 > 30. ??? > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com > http://www.angryox.com/ > --------------------------------------------------------------------------- > > -- ..!google!arpa.com!j From charles at thewybles.com Wed Nov 12 16:29:08 2008 From: charles at thewybles.com (Charles Wyble) Date: Wed, 12 Nov 2008 14:29:08 -0800 Subject: [funsec] McColo: Major Source of Online Scams andSpams KnockedOffline (fwd) In-Reply-To: <DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int><355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> <491B42C4.7080805@wvi.com> <DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int> Message-ID: <491B58B4.5070906@thewybles.com> > On to the question about how network operators can help LE: *Collect the data that proves a company such as Intercage/McColo is harboring cybercriminals* and get with your local FBI/Secret Service field office (or your state's Attorney General's office) (or both) and submit a complaint at IC3's website (www.ic3.gov) because we have an excellent team of analysts that track information like that. Package up the evidence you have and send it out. > Excellent point. Something like the fine folks at http://hostexploit.com/ are doing. I also believe SANS has some excellent courses on forensics, and things like chain of custody etc. Not sure how much that applies to these sort of scenarios but it can't hurt to package/handle the evidence in as compliant a manner as possible. From pjasa at univision.net Wed Nov 12 16:26:55 2008 From: pjasa at univision.net (Paul Jasa) Date: Wed, 12 Nov 2008 17:26:55 -0500 Subject: Verizon/UU.net/Alternet Routing issue References: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com> <e6e9128b0811121414q341d79dcmf87567fd4440c7a5@mail.gmail.com> Message-ID: <49BDC04765D40849A4170C966AD69A9D0623F9@MIA-EX01.utg.uvn.net> Same here. Saw the issue from Los Angeles, and from New York. Traces were dropping a few hops into the Verizon cloud. BGP stayed up, but routing went nowhere. Paul ________________________________ From: jamie rishaw [mailto:j at arpa.com] Sent: Wed 11/12/2008 3:14 PM To: Peter Beckman Cc: nanog at nanog.org Subject: Re: Verizon/UU.net/Alternet Routing issue Confirmed here as well; Saw loss on DS3s between 424 and 440 EST. BGP survived but routing didnt .. No RCA yet from VZN (on hold). On Wed, Nov 12, 2008 at 3:47 PM, Peter Beckman <beckman at angryox.com> wrote: > At about 4:24pm EDT, I lost connectivity from Verizon to destinations in > New York, Seattle and others. Came back up (4:46pm) while composing this > email. Anyone else notice? Major problem or minor routing issue? > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. localrouter 67.6% 395 0.6 1.6 0.5 18.8 2.3 > 2. 10.1.41.15 0.0% 395 5.7 5.1 1.8 306.0 > 17.4 > 3. P4-2.LCR-02.WASHDC.verizon-g 0.0% 395 7.4 2.7 1.2 19.0 2.5 > 4. 130.81.29.218 0.0% 395 6.0 3.8 1.8 40.9 > 4.2 > 5. 152.63.39.177 0.0% 395 8.6 6.8 3.9 71.3 > 4.4 > 152.63.36.213 > 6. 152.63.69.113 71.6% 395 120.7 44.0 31.2 186.7 > 30.3 > 7. POS7-0-0.GW4.IND6.ALTER.NET 30.7% 395 1179. 133.3 121.3 1179. > 79.5 > 8. 152.63.67.250 93.9% 395 121.5 125.4 121.0 186.2 > 13.0 > 9. POS6-0-0.GW4.IND6.ALTER.NET 53.0% 395 318.9 217.7 206.8 722.0 > 43.3 > 10. 152.63.67.250 96.2% 395 211.1 211.1 209.0 215.7 > 1.8 > 11. POS6-0-0.GW4.IND6.ALTER.NET 67.0% 395 422.1 305.9 294.9 692.1 > 37.5 > 12. 152.63.67.250 97.5% 394 295.1 298.0 295.1 303.6 > 2.5 > 13. POS6-0-0.GW4.IND6.ALTER.NET 73.5% 394 523.9 391.5 382.1 523.9 > 17.7 > 14. 152.63.67.250 98.7% 392 388.5 386.6 381.9 389.5 > 3.1 > 15. POS6-0-0.GW4.IND6.ALTER.NET 82.6% 392 632.9 481.2 468.6 632.9 > 22.2 > 16. 152.63.67.250 99.2% 388 472.7 472.2 470.2 473.6 > 1.8 > 17. POS6-0-0.GW4.IND6.ALTER.NET 85.8% 388 737.0 573.3 559.4 737.0 > 27.8 > 18. 152.63.67.250 99.2% 387 560.5 562.0 560.5 565.1 > 2.7 > 19. POS6-0-0.GW4.IND6.ALTER.NET 89.6% 387 839.0 664.8 644.9 839.0 > 38.6 > 20. 152.63.67.250 99.2% 387 649.3 649.6 649.3 649.9 > 0.3 > 21. POS6-0-0.GW4.IND6.ALTER.NET 94.8% 383 946.4 763.8 734.6 946.4 > 48.5 > 22. 152.63.67.250 99.7% 376 735.5 735.5 735.5 735.5 > 0.0 > 23. POS6-0-0.GW4.IND6.ALTER.NET 92.5% 376 895.4 842.2 819.1 909.0 > 26.8 > 24. ??? > 25. POS6-0-0.GW4.IND6.ALTER.NET 96.7% 365 1153. 955.9 908.9 1153. > 78.7 > 26. ??? > 27. POS6-0-0.GW4.IND6.ALTER.NET 96.6% 328 1261. 1057. 998.8 1261. > 86.8 > 28. 152.63.67.250 99.6% 245 999.3 999.3 999.3 999.3 > 0.0 > 29. POS6-0-0.GW4.IND6.ALTER.NET 98.8% 245 1189. 1123. 1086. 1189. > 57.5 > 30. ??? > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com > http://www.angryox.com/ > --------------------------------------------------------------------------- > > -- ..!google!arpa.com!j The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system From MBraun at firstam.com Wed Nov 12 17:05:52 2008 From: MBraun at firstam.com (Braun, Mike) Date: Wed, 12 Nov 2008 15:05:52 -0800 Subject: Verizon/UU.net/Alternet Routing issue In-Reply-To: <49BDC04765D40849A4170C966AD69A9D0623F9@MIA-EX01.utg.uvn.net> References: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com><e6e9128b0811121414q341d79dcmf87567fd4440c7a5@mail.gmail.com> <49BDC04765D40849A4170C966AD69A9D0623F9@MIA-EX01.utg.uvn.net> Message-ID: <CCC465742E47CC4090095AE1FF1C5B5910256858@CREDPWY01SXCH02.credit.credco.net> I was told this was a Level3 router leaking bad routes into Verizon, and was told the problem is now resolved. Mike -----Original Message----- From: Paul Jasa [mailto:pjasa at univision.net] Sent: Wednesday, November 12, 2008 2:27 PM To: jamie rishaw; Peter Beckman Cc: nanog at nanog.org Subject: RE: Verizon/UU.net/Alternet Routing issue Same here. Saw the issue from Los Angeles, and from New York. Traces were dropping a few hops into the Verizon cloud. BGP stayed up, but routing went nowhere. Paul ________________________________ From: jamie rishaw [mailto:j at arpa.com] Sent: Wed 11/12/2008 3:14 PM To: Peter Beckman Cc: nanog at nanog.org Subject: Re: Verizon/UU.net/Alternet Routing issue Confirmed here as well; Saw loss on DS3s between 424 and 440 EST. BGP survived but routing didnt .. No RCA yet from VZN (on hold). On Wed, Nov 12, 2008 at 3:47 PM, Peter Beckman <beckman at angryox.com> wrote: > At about 4:24pm EDT, I lost connectivity from Verizon to destinations in > New York, Seattle and others. Came back up (4:46pm) while composing this > email. Anyone else notice? Major problem or minor routing issue? > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. localrouter 67.6% 395 0.6 1.6 0.5 18.8 2.3 > 2. 10.1.41.15 0.0% 395 5.7 5.1 1.8 306.0 > 17.4 > 3. P4-2.LCR-02.WASHDC.verizon-g 0.0% 395 7.4 2.7 1.2 19.0 2.5 > 4. 130.81.29.218 0.0% 395 6.0 3.8 1.8 40.9 > 4.2 > 5. 152.63.39.177 0.0% 395 8.6 6.8 3.9 71.3 > 4.4 > 152.63.36.213 > 6. 152.63.69.113 71.6% 395 120.7 44.0 31.2 186.7 > 30.3 > 7. POS7-0-0.GW4.IND6.ALTER.NET 30.7% 395 1179. 133.3 121.3 1179. > 79.5 > 8. 152.63.67.250 93.9% 395 121.5 125.4 121.0 186.2 > 13.0 > 9. POS6-0-0.GW4.IND6.ALTER.NET 53.0% 395 318.9 217.7 206.8 722.0 > 43.3 > 10. 152.63.67.250 96.2% 395 211.1 211.1 209.0 215.7 > 1.8 > 11. POS6-0-0.GW4.IND6.ALTER.NET 67.0% 395 422.1 305.9 294.9 692.1 > 37.5 > 12. 152.63.67.250 97.5% 394 295.1 298.0 295.1 303.6 > 2.5 > 13. POS6-0-0.GW4.IND6.ALTER.NET 73.5% 394 523.9 391.5 382.1 523.9 > 17.7 > 14. 152.63.67.250 98.7% 392 388.5 386.6 381.9 389.5 > 3.1 > 15. POS6-0-0.GW4.IND6.ALTER.NET 82.6% 392 632.9 481.2 468.6 632.9 > 22.2 > 16. 152.63.67.250 99.2% 388 472.7 472.2 470.2 473.6 > 1.8 > 17. POS6-0-0.GW4.IND6.ALTER.NET 85.8% 388 737.0 573.3 559.4 737.0 > 27.8 > 18. 152.63.67.250 99.2% 387 560.5 562.0 560.5 565.1 > 2.7 > 19. POS6-0-0.GW4.IND6.ALTER.NET 89.6% 387 839.0 664.8 644.9 839.0 > 38.6 > 20. 152.63.67.250 99.2% 387 649.3 649.6 649.3 649.9 > 0.3 > 21. POS6-0-0.GW4.IND6.ALTER.NET 94.8% 383 946.4 763.8 734.6 946.4 > 48.5 > 22. 152.63.67.250 99.7% 376 735.5 735.5 735.5 735.5 > 0.0 > 23. POS6-0-0.GW4.IND6.ALTER.NET 92.5% 376 895.4 842.2 819.1 909.0 > 26.8 > 24. ??? > 25. POS6-0-0.GW4.IND6.ALTER.NET 96.7% 365 1153. 955.9 908.9 1153. > 78.7 > 26. ??? > 27. POS6-0-0.GW4.IND6.ALTER.NET 96.6% 328 1261. 1057. 998.8 1261. > 86.8 > 28. 152.63.67.250 99.6% 245 999.3 999.3 999.3 999.3 > 0.0 > 29. POS6-0-0.GW4.IND6.ALTER.NET 98.8% 245 1189. 1123. 1086. 1189. > 57.5 > 30. ??? > > Beckman > ------------------------------------------------------------------------ --- > Peter Beckman Internet Guy > beckman at angryox.com > http://www.angryox.com/ > ------------------------------------------------------------------------ --- > > -- .!google!arpa.com!j The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM. From simonw at zynet.net Thu Nov 13 03:27:33 2008 From: simonw at zynet.net (Simon Waters) Date: Thu, 13 Nov 2008 09:27:33 +0000 Subject: [funsec] McColo: Major Source of Online Scams =?utf-8?q?andSpams=09KnockedOffline?= (fwd) In-Reply-To: <DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <491B42C4.7080805@wvi.com> <DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int> Message-ID: <200811130927.33919.simonw@zynet.net> On Wednesday 12 November 2008 21:52:12 Nick Newman wrote: > > Let's compare these two scenarios: > > 1. The world-wide community of people who essentially run the Internet have > had enough with a nasty webhosting company in California. They've > determined that the majority of spam world-wide originates from this > company offering bullet-proof hosting. So they call the upstream providers > and get them cut off. > 2. Some LE agency serves a search warrant for "any digital evidence" and > collects hundreds of terabytes of worth of data. 5 years later.... These aren't mutually exclusive. > nw3c.org Grr - those stupid DreamWeaver menus that only work in 66% of browsers. From bambenek at gmail.com Thu Nov 13 06:30:39 2008 From: bambenek at gmail.com (John Bambenek) Date: Thu, 13 Nov 2008 06:30:39 -0600 Subject: [funsec] McColo: Major Source of Online Scams andSpams KnockedOffline (fwd) In-Reply-To: <491B58B4.5070906@thewybles.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int><355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> <491B42C4.7080805@wvi.com> <DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int> <491B58B4.5070906@thewybles.com> Message-ID: <491C1DEF.9070704@gmail.com> Something to keep in mind. I don't believe it was McColo that was the end provider of "badware" per se (and I could be proven wrong), they simply played the enabling role by hosting it and looked the other way. Now don't get me wrong, they ought to be kicked offline for externalizing their costs on the rest of us, but what criminal charges could be filed here? I'm not a lawyer but the person actually committing the crime and a person who willing provides tools to someone committing a crime are in completely different boats. We could criminalize hosting malicious tools, but then what of nessus, nmap, wireshark and the host of security tools that are effectively "dual use"? Child porn being an obvious exception of course, but the point remains. Negligence is bad and perhaps there are criminal remedies that can be brought to bear (I'm not a lawyer, I don't play one on the intarwebs) but I would imagine they would be minor in comparison. That said, of course this information should be turned over to law enforcement. It often is. j Charles Wyble wrote: > >> On to the question about how network operators can help LE: *Collect >> the data that proves a company such as Intercage/McColo is harboring >> cybercriminals* and get with your local FBI/Secret Service field >> office (or your state's Attorney General's office) (or both) and >> submit a complaint at IC3's website (www.ic3.gov) because we have an >> excellent team of analysts that track information like that. Package >> up the evidence you have and send it out. > > > Excellent point. Something like the fine folks at > http://hostexploit.com/ are doing. > > I also believe SANS has some excellent courses on forensics, and > things like chain of custody etc. Not sure how much that applies to > these sort of scenarios but it can't hurt to package/handle the > evidence in as compliant a manner as possible. > > > From NNewman at nw3c.org Thu Nov 13 07:05:42 2008 From: NNewman at nw3c.org (Nick Newman) Date: Thu, 13 Nov 2008 08:05:42 -0500 Subject: [funsec] McColo: Major Source of OnlineScams andSpams KnockedOffline (fwd) In-Reply-To: <491B58B4.5070906@thewybles.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int><355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> <491B42C4.7080805@wvi.com><DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int> <491B58B4.5070906@thewybles.com> Message-ID: <DF569A62D4A461488173EBE91C043224037C27C3@POSTOFFICE.nw3c.int> Personally, I haven't been to any SANS courses, but I have a few coworkers who have and have been nothing but impressed with their material. They have an incident response class that deals with packaging up material for LE (what's important and what's not-so-much, forensic "soundness", and chain-of-custody). Nicholas R.?Newman Computer Crimes Specialist National White Collar Crime Center 1000 Technology Drive, Suite 2130 Fairmont, WV 26554 ? 1-877-628-7674 x2244 nnewman at nw3c.org -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Wednesday, November 12, 2008 5:29 PM To: NANOG list Subject: Re: [funsec] McColo: Major Source of OnlineScams andSpams KnockedOffline (fwd) > On to the question about how network operators can help LE: *Collect the data that proves a company such as Intercage/McColo is harboring cybercriminals* and get with your local FBI/Secret Service field office (or your state's Attorney General's office) (or both) and submit a complaint at IC3's website (www.ic3.gov) because we have an excellent team of analysts that track information like that. Package up the evidence you have and send it out. > Excellent point. Something like the fine folks at http://hostexploit.com/ are doing. I also believe SANS has some excellent courses on forensics, and things like chain of custody etc. Not sure how much that applies to these sort of scenarios but it can't hurt to package/handle the evidence in as compliant a manner as possible. From revolver.onslaught at gmail.com Thu Nov 13 07:13:17 2008 From: revolver.onslaught at gmail.com (Revolver Onslaught) Date: Thu, 13 Nov 2008 14:13:17 +0100 Subject: mail traffic Message-ID: <6e4abe2d0811130513r45c75d02teae1698b4389a797@mail.gmail.com> Hi everybody, I'm working for an ISP who manages several countries. On 11/13, we noticed that our incoming traffic was divided by 2 (SMTP hits). All the countries we manage were affected by. Did you enconuter the same problem ? Regards, RO From leo.vegoda at icann.org Thu Nov 13 07:14:54 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 13 Nov 2008 14:14:54 +0100 Subject: 110/8 and 111/8 allocated to APNIC Message-ID: <814189F7-A87D-4D4F-817B-45FDE438BD04@icann.org> Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in November 2008: 110/8 and 111/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081113/7e07fe4b/attachment.bin> From ops.lists at gmail.com Thu Nov 13 07:27:31 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 13 Nov 2008 18:57:31 +0530 Subject: mail traffic In-Reply-To: <6e4abe2d0811130513r45c75d02teae1698b4389a797@mail.gmail.com> References: <6e4abe2d0811130513r45c75d02teae1698b4389a797@mail.gmail.com> Message-ID: <bb0e440a0811130527h7cd9a597w677364cc7fab2369@mail.gmail.com> Problem? That aint a problem. Just that mccolo got taken down and half the bots around suddenly stopped. On Thu, Nov 13, 2008 at 6:43 PM, Revolver Onslaught <revolver.onslaught at gmail.com> wrote: > Hi everybody, > > > I'm working for an ISP who manages several countries. On 11/13, we > noticed that our incoming traffic > was divided by 2 (SMTP hits). All the countries we manage were affected by. > > > Did you enconuter the same problem ? > > Regards, > RO > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From rsk at gsp.org Thu Nov 13 07:27:40 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 13 Nov 2008 08:27:40 -0500 Subject: [funsec] McColo: Major Source of Online Scams and Spams Knocked Offline (fwd) In-Reply-To: <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> Message-ID: <20081113132740.GA9815@gsp.org> On Wed, Nov 12, 2008 at 11:30:45AM -0600, Kee Hinckley wrote: > The article expressed a good deal of frustration with the (lack of) > speed with which law enforcement has been tackling these issues. Law enforcement is almost a complete non-factor in dealing with online abuse. Action is erratic, slow and incompetent at best; it tends to only happen when one of four things is true: (a) someone's running for office (b) positive PR is needed (c) a government has been publicly embarrrassed and needs a scapegoat or (d) someone with sufficient political connections, money, and/or power wants it. And even when it happens, it's ineffective: for example, token prosecutions of spammers have done nothing to make the spam problem any better. Multiple spyware vendors have settled their cases for pitifully small sums and then gone right back to work. But even if that weren't true, even if law enforcement worldwide had adequate staff, resources, training, clue, etc. to attempt something useful -- the necessary legal framework really doesn't exist. Abusers can dissolve their shadow companies, form new ones, relocate (possibly across international borders), modify their tactics, etc. Peer-to-peer action continues to be the best available option -- one that needs to be exercised far more often. ---Rsk From simonw at zynet.net Thu Nov 13 07:33:32 2008 From: simonw at zynet.net (Simon Waters) Date: Thu, 13 Nov 2008 13:33:32 +0000 Subject: mail traffic In-Reply-To: <6e4abe2d0811130513r45c75d02teae1698b4389a797@mail.gmail.com> References: <6e4abe2d0811130513r45c75d02teae1698b4389a797@mail.gmail.com> Message-ID: <200811131333.32507.simonw@zynet.net> On Thursday 13 November 2008 13:13:17 Revolver Onslaught wrote: > > Did you enconuter the same problem ? The view here is see McColo thread. Spamcop and DCC report significant drop coincident with McColo going offline. I just wish I could say the same about local spam volumes. We were blocking most bot spam thanks to the CBL and greylisting, so I suspect that the received volumes won't be affected that much. Still someone should probably prod law enforcement, as this counts as circumstantial evidence of criminal activity ;) From matthias at leisi.net Thu Nov 13 07:40:07 2008 From: matthias at leisi.net (Matthias Leisi) Date: Thu, 13 Nov 2008 14:40:07 +0100 (CET) Subject: mail traffic In-Reply-To: <bb0e440a0811130527h7cd9a597w677364cc7fab2369@mail.gmail.com> References: <6e4abe2d0811130513r45c75d02teae1698b4389a797@mail.gmail.com> <bb0e440a0811130527h7cd9a597w677364cc7fab2369@mail.gmail.com> Message-ID: <54487.195.186.55.199.1226583607.squirrel@mail.leisi.net> > Problem? That aint a problem. Just that mccolo got taken down and > half the bots around suddenly stopped. Unfortunately, the bots themselves are still there, and may come back to life in the near future (or be re-infected by the Next Bot Model). I hope that someone already analyzed the bots and found out how they will try to contact their masters in such a case... -- Matthias From eric-list at truenet.com Thu Nov 13 09:09:24 2008 From: eric-list at truenet.com (Eric Tykwinski) Date: Thu, 13 Nov 2008 10:09:24 -0500 Subject: Verizon/UU.net/Alternet Routing issue In-Reply-To: <CCC465742E47CC4090095AE1FF1C5B5910256858@CREDPWY01SXCH02.credit.credco.net> References: <alpine.BSF.2.00.0811121643060.14410@nog.angryox.com><e6e9128b0811121414q341d79dcmf87567fd4440c7a5@mail.gmail.com><49BDC04765D40849A4170C966AD69A9D0623F9@MIA-EX01.utg.uvn.net> <CCC465742E47CC4090095AE1FF1C5B5910256858@CREDPWY01SXCH02.credit.credco.net> Message-ID: <277FB8D1D48A4F028AE235F15F6A94FA@ERICDESKTOP> Anyone else still seeing routing issues from Verizon's network still? We are getting intermittent routing to/from our IP space. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: Braun, Mike [mailto:MBraun at firstam.com] Sent: Wednesday, November 12, 2008 6:06 PM To: nanog at nanog.org Subject: RE: Verizon/UU.net/Alternet Routing issue I was told this was a Level3 router leaking bad routes into Verizon, and was told the problem is now resolved. Mike -----Original Message----- From: Paul Jasa [mailto:pjasa at univision.net] Sent: Wednesday, November 12, 2008 2:27 PM To: jamie rishaw; Peter Beckman Cc: nanog at nanog.org Subject: RE: Verizon/UU.net/Alternet Routing issue Same here. Saw the issue from Los Angeles, and from New York. Traces were dropping a few hops into the Verizon cloud. BGP stayed up, but routing went nowhere. Paul ________________________________ From: jamie rishaw [mailto:j at arpa.com] Sent: Wed 11/12/2008 3:14 PM To: Peter Beckman Cc: nanog at nanog.org Subject: Re: Verizon/UU.net/Alternet Routing issue Confirmed here as well; Saw loss on DS3s between 424 and 440 EST. BGP survived but routing didnt .. No RCA yet from VZN (on hold). On Wed, Nov 12, 2008 at 3:47 PM, Peter Beckman <beckman at angryox.com> wrote: > At about 4:24pm EDT, I lost connectivity from Verizon to destinations in > New York, Seattle and others. Came back up (4:46pm) while composing this > email. Anyone else notice? Major problem or minor routing issue? > > Packets Pings > Host Loss% Snt Last Avg Best Wrst StDev > 1. localrouter 67.6% 395 0.6 1.6 0.5 18.8 2.3 > 2. 10.1.41.15 0.0% 395 5.7 5.1 1.8 306.0 > 17.4 > 3. P4-2.LCR-02.WASHDC.verizon-g 0.0% 395 7.4 2.7 1.2 19.0 2.5 > 4. 130.81.29.218 0.0% 395 6.0 3.8 1.8 40.9 > 4.2 > 5. 152.63.39.177 0.0% 395 8.6 6.8 3.9 71.3 > 4.4 > 152.63.36.213 > 6. 152.63.69.113 71.6% 395 120.7 44.0 31.2 186.7 > 30.3 > 7. POS7-0-0.GW4.IND6.ALTER.NET 30.7% 395 1179. 133.3 121.3 1179. > 79.5 > 8. 152.63.67.250 93.9% 395 121.5 125.4 121.0 186.2 > 13.0 > 9. POS6-0-0.GW4.IND6.ALTER.NET 53.0% 395 318.9 217.7 206.8 722.0 > 43.3 > 10. 152.63.67.250 96.2% 395 211.1 211.1 209.0 215.7 > 1.8 > 11. POS6-0-0.GW4.IND6.ALTER.NET 67.0% 395 422.1 305.9 294.9 692.1 > 37.5 > 12. 152.63.67.250 97.5% 394 295.1 298.0 295.1 303.6 > 2.5 > 13. POS6-0-0.GW4.IND6.ALTER.NET 73.5% 394 523.9 391.5 382.1 523.9 > 17.7 > 14. 152.63.67.250 98.7% 392 388.5 386.6 381.9 389.5 > 3.1 > 15. POS6-0-0.GW4.IND6.ALTER.NET 82.6% 392 632.9 481.2 468.6 632.9 > 22.2 > 16. 152.63.67.250 99.2% 388 472.7 472.2 470.2 473.6 > 1.8 > 17. POS6-0-0.GW4.IND6.ALTER.NET 85.8% 388 737.0 573.3 559.4 737.0 > 27.8 > 18. 152.63.67.250 99.2% 387 560.5 562.0 560.5 565.1 > 2.7 > 19. POS6-0-0.GW4.IND6.ALTER.NET 89.6% 387 839.0 664.8 644.9 839.0 > 38.6 > 20. 152.63.67.250 99.2% 387 649.3 649.6 649.3 649.9 > 0.3 > 21. POS6-0-0.GW4.IND6.ALTER.NET 94.8% 383 946.4 763.8 734.6 946.4 > 48.5 > 22. 152.63.67.250 99.7% 376 735.5 735.5 735.5 735.5 > 0.0 > 23. POS6-0-0.GW4.IND6.ALTER.NET 92.5% 376 895.4 842.2 819.1 909.0 > 26.8 > 24. ??? > 25. POS6-0-0.GW4.IND6.ALTER.NET 96.7% 365 1153. 955.9 908.9 1153. > 78.7 > 26. ??? > 27. POS6-0-0.GW4.IND6.ALTER.NET 96.6% 328 1261. 1057. 998.8 1261. > 86.8 > 28. 152.63.67.250 99.6% 245 999.3 999.3 999.3 999.3 > 0.0 > 29. POS6-0-0.GW4.IND6.ALTER.NET 98.8% 245 1189. 1123. 1086. 1189. > 57.5 > 30. ??? > > Beckman > ------------------------------------------------------------------------ --- > Peter Beckman Internet Guy > beckman at angryox.com > http://www.angryox.com/ > ------------------------------------------------------------------------ --- > > -- .!google!arpa.com!j The information contained in this e-mail and any attached documents may be privileged, confidential and protected from disclosure. If you are not the intended recipient you may not read, copy, distribute or use this information. If you have received this communication in error, please notify the sender immediately by replying to this message and then delete it from your system -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM. From dhubbard at dino.hostasaurus.com Thu Nov 13 09:17:56 2008 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 13 Nov 2008 10:17:56 -0500 Subject: Verizon/UU.net/Alternet Routing issue Message-ID: <FCD26398C5EDE746BFC47F43EA52A17304162D91@dino.ad.hostasaurus.com> From: Eric Tykwinski [mailto:eric-list at truenet.com] > > Anyone else still seeing routing issues from Verizon's network still? > We are getting intermittent routing to/from our IP space. > > Sincerely, > > Eric Tykwinski We're in Tampa and seeing issues with customers of ours in the northeast on Verizon; they can't get to us at all, traces from them make it about three hops and die. We have connectivity to uunet and Level 3 in addition to some others. I took down the uunet to see if that was it with no change, haven't taken down any of the others yet. David From andrew2 at one.net Thu Nov 13 09:25:24 2008 From: andrew2 at one.net (andrew2 at one.net) Date: Thu, 13 Nov 2008 10:25:24 -0500 Subject: Verizon/UU.net/Alternet Routing issue In-Reply-To: <277FB8D1D48A4F028AE235F15F6A94FA@ERICDESKTOP> Message-ID: <028201c945a4$0cd81290$800101df@andrew2> Eric Tykwinski wrote: > Anyone else still seeing routing issues from Verizon's network still? > We are getting intermittent routing to/from our IP space. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > I've gotten word that some people on Verizon DSL in the Philly area are having trouble reaching our network, but haven't been able to confirm yet. Andrew From Skywing at valhallalegends.com Thu Nov 13 10:01:30 2008 From: Skywing at valhallalegends.com (Skywing) Date: Thu, 13 Nov 2008 10:01:30 -0600 Subject: [funsec] McColo: Major Source of Online Scams andSpams KnockedOffline (fwd) Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BEF937A21F@caralain.haven.nynaeve.net> I don't think you want to do that. It has been done in Germany, and there's been, for example, a chilling effect on legitimate security research that just makes *everyone* worse off. Precisely in that case because, as you noted, dual use tools exist - and as you made note as an unpleasant possibility in your message, they got caught up in the middle of this sort of legislation. Trying to regulate distribution of something on the Internet is both futile and dangerous, in general, IMO. It is certainly not going to make a dent on what malicious people do (they're probably breaking the law already or out of jurisdiction anyway). The only real side effect of such action that I can see is much pain and angst by legitimate people trying to do their job and wondering if they are going to risk having their lives ruined by running afoul of ill-conceived legislature trying to ban distribution of "tools". This is not the correct path, I think. Whatever the correct path is is likely to be a much more complex target, but many attempts at legislating the Internet often come out as so broad that you could find a way to use them against any ordinary sysadmin. I thik that given past attempts, it is unlikly that there will be legislature that is both effective at criminalizing McColo and avoids the sort of environment where basic general Internet use is risky from a legal perspective. (And we're perhaps a tad too close to that now. One does not wish to consider what'd happen if one got link-bombed with a shady site hosting "illegal" content that showers you in a badness pop-up deluge, and then got pulled over for a full computer search by the border patrol. Does trying to explain the concept of that situation before a jury as a defense for having a porn pic sitting around in your browser cache sound appealing?) Now, I'm not trying to say that the correct laws cannot be made. But you had better be damn sure they're the right laws before they get passed. Many of the issues here are subtle and significant, ones that traditionally Internet-facing laws hve glossed over to th public detriment. Explaining such things to legislators is hard enough; you don't want to be stuck trying to fend off wrong charges from an overzealous prosecutor on subtle and highly technical grounds if you find yourself. Because the danger from making the *wrong* laws is so great here, we really need to be very careful what we're calling for. - S -----Original Message----- From: John Bambenek <bambenek at gmail.com> Sent: Thursday, November 13, 2008 06:31 To: Charles Wyble <charles at thewybles.com> Cc: NANOG list <nanog at nanog.org> Subject: Re: [funsec] McColo: Major Source of Online Scams andSpams KnockedOffline (fwd) Something to keep in mind. I don't believe it was McColo that was the end provider of "badware" per se (and I could be proven wrong), they simply played the enabling role by hosting it and looked the other way. Now don't get me wrong, they ought to be kicked offline for externalizing their costs on the rest of us, but what criminal charges could be filed here? I'm not a lawyer but the person actually committing the crime and a person who willing provides tools to someone committing a crime are in completely different boats. We could criminalize hosting malicious tools, but then what of nessus, nmap, wireshark and the host of security tools that are effectively "dual use"? Child porn being an obvious exception of course, but the point remains. Negligence is bad and perhaps there are criminal remedies that can be brought to bear (I'm not a lawyer, I don't play one on the intarwebs) but I would imagine they would be minor in comparison. That said, of course this information should be turned over to law enforcement. It often is. j Charles Wyble wrote: > >> On to the question about how network operators can help LE: *Collect >> the data that proves a company such as Intercage/McColo is harboring >> cybercriminals* and get with your local FBI/Secret Service field >> office (or your state's Attorney General's office) (or both) and >> submit a complaint at IC3's website (www.ic3.gov) because we have an >> excellent team of analysts that track information like that. Package >> up the evidence you have and send it out. > > > Excellent point. Something like the fine folks at > http://hostexploit.com/ are doing. > > I also believe SANS has some excellent courses on forensics, and > things like chain of custody etc. Not sure how much that applies to > these sort of scenarios but it can't hurt to package/handle the > evidence in as compliant a manner as possible. > > > From clewis at nortel.com Thu Nov 13 10:39:33 2008 From: clewis at nortel.com (Chris Lewis) Date: Thu, 13 Nov 2008 11:39:33 -0500 Subject: [funsec] McColo: Major Source of Online Scams andSpams KnockedOffline (fwd) In-Reply-To: <491C1DEF.9070704@gmail.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int><355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> <491B42C4.7080805@wvi.com> <DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int> <491B58B4.5070906@thewybles.com> <491C1DEF.9070704@gmail.com> Message-ID: <491C5845.6090500@nortel.com> John Bambenek wrote: > Something to keep in mind. I don't believe it was McColo that was the > end provider of "badware" per se (and I could be proven wrong), they > simply played the enabling role by hosting it and looked the other way. > Now don't get me wrong, they ought to be kicked offline for > externalizing their costs on the rest of us, but what criminal charges > could be filed here? Aiding and abetting and conspiracy come to mind at the very least. Knowingly facilitating child porn should have quite a few possiblities too. But they're really hard things to prosecute on the Internet, in the face of the plausible deniability shields they work at so carefully to erect. > That said, of course this information should be turned over to law > enforcement. It often is. Don't assume it hasn't already. Previously. Repeatedly. And I don't think the dust has quite settled yet. From surfer at mauigateway.com Thu Nov 13 12:28:52 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 13 Nov 2008 10:28:52 -0800 Subject: Prefix Hijack Tool Comaprision Message-ID: <20081113102852.9376A4BF@resin15.mta.everyone.net> With this last hijack, we see the comparison between PHAS and BGPmon. Does anyone use other hijack tools who would be willing to compare to these two tools wrt time to alert, number of alerts, etc. during this event? How do folks find the extent of the damage? Using BGPlay only or are their other good tools for assessing damage? scott From hank at efes.iucc.ac.il Thu Nov 13 12:57:35 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 13 Nov 2008 20:57:35 +0200 Subject: Prefix Hijack Tool Comaprision In-Reply-To: <20081113102852.9376A4BF@resin15.mta.everyone.net> Message-ID: <5.1.0.14.2.20081113205551.00ae6d48@efes.iucc.ac.il> At 10:28 AM 13-11-08 -0800, Scott Weeks wrote: >With this last hijack, we see the comparison between PHAS and >BGPmon. Does anyone use other hijack tools who would be willing to >compare to these two tools wrt time to alert, number of alerts, etc. >during this event? > >How do folks find the extent of the damage? Using BGPlay only or are >their other good tools for assessing damage? > >scott I use all 4 - BGPmon, RIPE, PHAS, and Watchmy.net. BGPMon kicks ass on all of them. RIPE showed up 5-6 hours later. PHAS and Watchmy were nowhere to be seen. -Hank From todd at renesys.com Thu Nov 13 13:32:19 2008 From: todd at renesys.com (Todd Underwood) Date: Thu, 13 Nov 2008 19:32:19 +0000 Subject: Prefix Hijack Tool Comaprision In-Reply-To: <5.1.0.14.2.20081113205551.00ae6d48@efes.iucc.ac.il> References: <20081113102852.9376A4BF@resin15.mta.everyone.net> <5.1.0.14.2.20081113205551.00ae6d48@efes.iucc.ac.il> Message-ID: <20081113193219.GV20914@renesys.com> hank, all, On Thu, Nov 13, 2008 at 08:57:35PM +0200, Hank Nussbacher wrote: > I use all 4 - BGPmon, RIPE, PHAS, and Watchmy.net. > > BGPMon kicks ass on all of them. RIPE showed up 5-6 hours later. PHAS and > Watchmy were nowhere to be seen. is that a bug or a feature? this was a non-event in a tiny corner of the internet. it's interesting, but it's not operationally significant. i would not consider the fact that PHAS and Watchmy didn't alert any particular criticism of them. but perhaps there was something else to which you were referring. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd at renesys.com http://www.renesys.com/blog From surfer at mauigateway.com Thu Nov 13 13:41:39 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 13 Nov 2008 11:41:39 -0800 Subject: Prefix Hijack Tool Comaprision Message-ID: <20081113114139.937F2234@resin09.mta.everyone.net> --- todd at renesys.com wrote: From: Todd Underwood <todd at renesys.com> interesting, but it's not operationally significant. i would not consider the fact that PHAS and Watchmy didn't alert any particular criticism of them. but perhaps there was something else to which you were referring. ---------------------------------- I think he was just referring to and answering my question. I hope to see how these tools work in 'small' incidents as well as large-scale incidents. Knowing the tool's capabilities increases one's ability to assess the damage while troubleshooting. scott From a.harrowell at gmail.com Thu Nov 13 13:56:26 2008 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 13 Nov 2008 19:56:26 +0000 Subject: Prefix Hijack Tool Comaprision Message-ID: <mmTWG8Tckr9z.JrvHRB1Z@smtp.gmail.com> It may be the North American NOG, but it's been said before that it functions as a GNOG, G for Global. I don't think Brazil is insignificant. I respect Todd's work greatly, but I think he's wrong on this point. - original message - Subject: Re: Prefix Hijack Tool Comaprision From: "Scott Weeks" <surfer at mauigateway.com> Date: 13/11/2008 7:42 pm --- todd at renesys.com wrote: From: Todd Underwood <todd at renesys.com> interesting, but it's not operationally significant. i would not consider the fact that PHAS and Watchmy didn't alert any particular criticism of them. but perhaps there was something else to which you were referring. ---------------------------------- I think he was just referring to and answering my question. I hope to see how these tools work in 'small' incidents as well as large-scale incidents. Knowing the tool's capabilities increases one's ability to assess the damage while troubleshooting. scott From todd at renesys.com Thu Nov 13 14:05:13 2008 From: todd at renesys.com (Todd Underwood) Date: Thu, 13 Nov 2008 20:05:13 +0000 Subject: Prefix Hijack Tool Comaprision In-Reply-To: <mmTWG8Tckr9z.JrvHRB1Z@smtp.gmail.com> References: <mmTWG8Tckr9z.JrvHRB1Z@smtp.gmail.com> Message-ID: <20081113200513.GW20914@renesys.com> alexander, all, On Thu, Nov 13, 2008 at 07:56:26PM +0000, Alexander Harrowell wrote: > It may be the North American NOG, but it's been said before that it > functions as a GNOG, G for Global. I don't think Brazil is > insignificant. I respect Todd's work greatly, but I think he's wrong > on this point. you misread me. i did not say that brazil was insignificant. it's not. it has some of the fastest growing internet in latin america. i said that *this* hijacking took place in an insignificant corner of the internet. i mean this AS-map wise rather than geographically. this hijacking didn't even spread beyond one or two ASes, one of whom just happened to be a RIPE RIS peer. real hijackings leak into dozens or hundreds or thousands of ASNs. they spread far and wide. that's why people carry them out, when they do. this one was stopped in its tracks in a very small portion of one corner of the AS graph. as such, i don't count it as a hijacking or leak of any great significance and wouldn't want to alert anyone about it. that's why i recommend that prefix hijacking detection systems do thresholding of peers to prevent a single, rogue, unrepresentative peer from reporting a hijacking when none is really happening. others may have a different approach, but without thresholding prefix alert systems can be noisy and more trouble than they are worth. sorry if it appears that i was denegrating .br . i was not. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd at renesys.com http://www.renesys.com/blog From a.harrowell at gmail.com Thu Nov 13 14:27:32 2008 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 13 Nov 2008 20:27:32 +0000 Subject: Prefix Hijack Tool Comaprision Message-ID: <bKF33HShRCRR.Hh1PmWm3@smtp.gmail.com> OK. This seems to be a flaw in RIPE RIS, a pity because BGPlay is great. - original message - Subject: Re: Prefix Hijack Tool Comaprision From: Todd Underwood <todd at renesys.com> Date: 13/11/2008 8:05 pm alexander, all, On Thu, Nov 13, 2008 at 07:56:26PM +0000, Alexander Harrowell wrote: > It may be the North American NOG, but it's been said before that it > functions as a GNOG, G for Global. I don't think Brazil is > insignificant. I respect Todd's work greatly, but I think he's wrong > on this point. you misread me. i did not say that brazil was insignificant. it's not. it has some of the fastest growing internet in latin america. i said that *this* hijacking took place in an insignificant corner of the internet. i mean this AS-map wise rather than geographically. this hijacking didn't even spread beyond one or two ASes, one of whom just happened to be a RIPE RIS peer. real hijackings leak into dozens or hundreds or thousands of ASNs. they spread far and wide. that's why people carry them out, when they do. this one was stopped in its tracks in a very small portion of one corner of the AS graph. as such, i don't count it as a hijacking or leak of any great significance and wouldn't want to alert anyone about it. that's why i recommend that prefix hijacking detection systems do thresholding of peers to prevent a single, rogue, unrepresentative peer from reporting a hijacking when none is really happening. others may have a different approach, but without thresholding prefix alert systems can be noisy and more trouble than they are worth. sorry if it appears that i was denegrating .br . i was not. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd at renesys.com http://www.renesys.com/blog From jbates at brightok.net Thu Nov 13 14:33:06 2008 From: jbates at brightok.net (Jack Bates) Date: Thu, 13 Nov 2008 14:33:06 -0600 Subject: Prefix Hijack Tool Comaprision In-Reply-To: <20081113200513.GW20914@renesys.com> References: <mmTWG8Tckr9z.JrvHRB1Z@smtp.gmail.com> <20081113200513.GW20914@renesys.com> Message-ID: <491C8F02.8040501@brightok.net> Todd Underwood wrote: > i said that *this* hijacking took place in an insignificant corner of > the internet. i mean this AS-map wise rather than geographically. > this hijacking didn't even spread beyond one or two ASes, one of whom > just happened to be a RIPE RIS peer. > Yet for someone monitoring from their own perspective, what matters to them is what their own AS is seeing. If a hijacking makes it to their AS, they want to be concerned. > real hijackings leak into dozens or hundreds or thousands of ASNs. > they spread far and wide. that's why people carry them out, when they > do. this one was stopped in its tracks in a very small portion of one > corner of the AS graph. > Wasn't there a dns hijack not long ago that only had the scope of one ISP (who just happened to be extremely large and carried a bunch of cell phones)? Just because a hijack only covers a small portion of the net doesn't make it any less effective. This is why we push to get as many access controls as far out to the edge as possible. If it only effects the person who tries it, then it has no bearing. > as such, i don't count it as a hijacking or leak of any great > significance and wouldn't want to alert anyone about it. that's why i > recommend that prefix hijacking detection systems do thresholding of > peers to prevent a single, rogue, unrepresentative peer from reporting > a hijacking when none is really happening. others may have a > different approach, but without thresholding prefix alert systems can > be noisy and more trouble than they are worth. Thresholds might be important, but different mileage, yada yada. Jack From martin at airwire.ie Thu Nov 13 15:06:54 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Thu, 13 Nov 2008 21:06:54 +0000 Subject: Prefix Hijack Tool Comaprision In-Reply-To: <bKF33HShRCRR.Hh1PmWm3@smtp.gmail.com> References: <bKF33HShRCRR.Hh1PmWm3@smtp.gmail.com> Message-ID: <491C96EE.2090001@airwire.ie> Alexander Harrowell wrote: > OK. This seems to be a flaw in RIPE RIS, a pity because BGPlay is great. > It is not a flaw in RIPE RIS. One of the RIPE RIS servers was just within the AS'es that where affected, so it will show up. What BGPplay og BGPmon do with that data afterwards is an entire different story. RIPE RIS just collects data from various viewpoints. It's the users, that have to create the threshoulds or to decide how significant that data is. Kind regards, Martin List-Petersen Airwire, Galway, Eire > - original message - > Subject: Re: Prefix Hijack Tool Comaprision > From: Todd Underwood <todd at renesys.com> > Date: 13/11/2008 8:05 pm > > alexander, all, > > On Thu, Nov 13, 2008 at 07:56:26PM +0000, Alexander Harrowell wrote: > >> It may be the North American NOG, but it's been said before that it >> functions as a GNOG, G for Global. I don't think Brazil is >> insignificant. I respect Todd's work greatly, but I think he's wrong >> on this point. >> > > you misread me. > > i did not say that brazil was insignificant. it's not. it has some of > the fastest growing internet in latin america. > > i said that *this* hijacking took place in an insignificant corner of > the internet. i mean this AS-map wise rather than geographically. > this hijacking didn't even spread beyond one or two ASes, one of whom > just happened to be a RIPE RIS peer. > > real hijackings leak into dozens or hundreds or thousands of ASNs. > they spread far and wide. that's why people carry them out, when they > do. this one was stopped in its tracks in a very small portion of one > corner of the AS graph. > > as such, i don't count it as a hijacking or leak of any great > significance and wouldn't want to alert anyone about it. that's why i > recommend that prefix hijacking detection systems do thresholding of > peers to prevent a single, rogue, unrepresentative peer from reporting > a hijacking when none is really happening. others may have a > different approach, but without thresholding prefix alert systems can > be noisy and more trouble than they are worth. > > sorry if it appears that i was denegrating .br . i was not. > > t. > > -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From danny at tcb.net Thu Nov 13 15:09:45 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 13 Nov 2008 14:09:45 -0700 Subject: Prefix Hijack Tool Comaprision In-Reply-To: <20081113200513.GW20914@renesys.com> References: <mmTWG8Tckr9z.JrvHRB1Z@smtp.gmail.com> <20081113200513.GW20914@renesys.com> Message-ID: <AB98543C-6075-4A6D-9F7A-C74F18E2F167@tcb.net> On Nov 13, 2008, at 1:05 PM, Todd Underwood wrote: > > as such, i don't count it as a hijacking or leak of any great > significance and wouldn't want to alert anyone about it. that's why i > recommend that prefix hijacking detection systems do thresholding of > peers to prevent a single, rogue, unrepresentative peer from reporting > a hijacking when none is really happening. others may have a > different approach, but without thresholding prefix alert systems can > be noisy and more trouble than they are worth. While I agree that this incident didn't appear to much impact anyone beyond CTBC and their customers (where we very clearly impacted considerably), I would contend that ANY time anyone asserts reachability of another ASNs address space the owner of that space should be alerted. IMO, if an actual intentional targeted attack were to be launched, versus, say, the slew of accidental leaks we mostly see, then it may very well be scoped to some insignificant corner of the Internet, as close to the targets as possible - that's precisely what I'd do if I were to launch such an attack.... Now, if the goal is denial of service or a leak, sure, it'll likely propagate much wider - and be detected much quicker. -danny From mohitlad at gmail.com Thu Nov 13 15:28:49 2008 From: mohitlad at gmail.com (Mohit Lad) Date: Thu, 13 Nov 2008 13:28:49 -0800 Subject: NANOG Digest, Vol 10, Issue 46 In-Reply-To: <mailman.77906.1226608062.43406.nanog@nanog.org> References: <mailman.77906.1226608062.43406.nanog@nanog.org> Message-ID: <eea785af0811131328x29cdd9cby34b78910f43a047c@mail.gmail.com> Since this thread started as comparison of the tools, there are two issues 1. Which BGP feeds the tools use? RIPE, RouteViews, other private feeds. 2. How they decide what to send and what not to send? In this case, BGPMon detected an event that was not detected by others, and there might be other hijacks that were local in scope where PHAS or Watchmy might catch something that BGPMon does not. But that does not make one tool better than the other, unless this pattern is repeated. Eventually all tools will catch up with each other on the feeds (or so is the hope), so the difference will then lie in "the decision of what to send and what to drop", and as Todd mentioned, thresholding is very critical here. Mohit Date: Thu, 13 Nov 2008 20:27:32 +0000 > From: "Alexander Harrowell" <a.harrowell at gmail.com> > Subject: Re: Prefix Hijack Tool Comaprision > To: Todd Underwood <todd at renesys.com> > Cc: nanog at nanog.org > > OK. This seems to be a flaw in RIPE RIS, a pity because BGPlay is great. > > - original message - > Subject: Re: Prefix Hijack Tool Comaprision > From: Todd Underwood <todd at renesys.com> > Date: 13/11/2008 8:05 pm > > alexander, all, > > On Thu, Nov 13, 2008 at 07:56:26PM +0000, Alexander Harrowell wrote: > > It may be the North American NOG, but it's been said before that it > > functions as a GNOG, G for Global. I don't think Brazil is > > insignificant. I respect Todd's work greatly, but I think he's wrong > > on this point. > > you misread me. > > i did not say that brazil was insignificant. it's not. it has some of > the fastest growing internet in latin america. > > i said that *this* hijacking took place in an insignificant corner of > the internet. i mean this AS-map wise rather than geographically. > this hijacking didn't even spread beyond one or two ASes, one of whom > just happened to be a RIPE RIS peer. > > real hijackings leak into dozens or hundreds or thousands of ASNs. > they spread far and wide. that's why people carry them out, when they > do. this one was stopped in its tracks in a very small portion of one > corner of the AS graph. > > as such, i don't count it as a hijacking or leak of any great > significance and wouldn't want to alert anyone about it. that's why i > recommend that prefix hijacking detection systems do thresholding of > peers to prevent a single, rogue, unrepresentative peer from reporting > a hijacking when none is really happening. others may have a > different approach, but without thresholding prefix alert systems can > be noisy and more trouble than they are worth. > > sorry if it appears that i was denegrating .br . i was not. > > t. > > -- > _____________________________________________________________________ > todd underwood +1 603 643 9300 x101 > renesys corporation > todd at renesys.com http://www.renesys.com/blog > > > > From mohitlad at gmail.com Thu Nov 13 15:31:30 2008 From: mohitlad at gmail.com (Mohit Lad) Date: Thu, 13 Nov 2008 13:31:30 -0800 Subject: Prefix Hijack Tool Comaprision Message-ID: <eea785af0811131331q6d639d15i2273fb77bf7d84d@mail.gmail.com> Sorry for the subject line in the previous message :-) Since this thread started as comparison of the tools, there are two issues 1. Which BGP feeds the tools use? RIPE, RouteViews, other private feeds. 2. How they decide what to send and what not to send? In this case, BGPMon detected an event that was not detected by others, and there might be other hijacks that were local in scope where PHAS or Watchmy might catch something that BGPMon does not. But that does not make one tool better than the other, unless this pattern is repeated. Eventually all tools will catch up with each other on the feeds (or so is the hope), so the difference will then lie in "the decision of what to send and what to drop". Mohit Date: Thu, 13 Nov 2008 20:27:32 +0000 > From: "Alexander Harrowell" <a.harrowell at gmail.com> > Subject: Re: Prefix Hijack Tool Comaprision > To: Todd Underwood <todd at renesys.com> > Cc: nanog at nanog.org > > OK. This seems to be a flaw in RIPE RIS, a pity because BGPlay is great. > > - original message - > Subject: Re: Prefix Hijack Tool Comaprision > From: Todd Underwood <todd at renesys.com> > Date: 13/11/2008 8:05 pm > > alexander, all, > > On Thu, Nov 13, 2008 at 07:56:26PM +0000, Alexander Harrowell wrote: > > It may be the North American NOG, but it's been said before that it > > functions as a GNOG, G for Global. I don't think Brazil is > > insignificant. I respect Todd's work greatly, but I think he's wrong > > on this point. > > you misread me. > > i did not say that brazil was insignificant. it's not. it has some of > the fastest growing internet in latin america. > > i said that *this* hijacking took place in an insignificant corner of > the internet. i mean this AS-map wise rather than geographically. > this hijacking didn't even spread beyond one or two ASes, one of whom > just happened to be a RIPE RIS peer. > > real hijackings leak into dozens or hundreds or thousands of ASNs. > they spread far and wide. that's why people carry them out, when they > do. this one was stopped in its tracks in a very small portion of one > corner of the AS graph. > > as such, i don't count it as a hijacking or leak of any great > significance and wouldn't want to alert anyone about it. that's why i > recommend that prefix hijacking detection systems do thresholding of > peers to prevent a single, rogue, unrepresentative peer from reporting > a hijacking when none is really happening. others may have a > different approach, but without thresholding prefix alert systems can > be noisy and more trouble than they are worth. > > sorry if it appears that i was denegrating .br . i was not. > > t. > > -- > _____________________________________________________________________ > todd underwood +1 603 643 9300 x101 > renesys corporation > todd at renesys.com http://www.renesys.com/blog > > > > From karlinjf at cs.unm.edu Thu Nov 13 18:21:25 2008 From: karlinjf at cs.unm.edu (Josh Karlin) Date: Thu, 13 Nov 2008 17:21:25 -0700 Subject: Prefix Hijack Tool Comaprision In-Reply-To: <eea785af0811131331q6d639d15i2273fb77bf7d84d@mail.gmail.com> References: <eea785af0811131331q6d639d15i2273fb77bf7d84d@mail.gmail.com> Message-ID: <71051fe20811131621o7680f6fsa964c43969f8565d@mail.gmail.com> Agreed. The Internet Alert Registry ( http://iar.cs.unm.edu ) has switched from monitoring RIPE and Routeviews to direct connections with our PGBGP enabled router. This means the IAR has less data, but immediate response times. Some of the prefixes were detected as hijacked by the IAR but most of the hijacked prefixes never reached the IAR's neighbors. If anyone would like to add their feed to the IAR we would appreciate it! Josh On Thu, Nov 13, 2008 at 2:31 PM, Mohit Lad <mohitlad at gmail.com> wrote: > Sorry for the subject line in the previous message :-) > > Since this thread started as comparison of the tools, there are two issues > 1. Which BGP feeds the tools use? RIPE, RouteViews, other private feeds. > 2. How they decide what to send and what not to send? > > In this case, BGPMon detected an event that was not detected by others, and > there might be other hijacks that were local in scope where PHAS or Watchmy > might catch something that BGPMon does not. But that does not make one tool > better than the other, unless this pattern is repeated. > Eventually all tools will catch up with each other on the feeds (or so is > the hope), so the difference will then lie in "the decision of what to send > and what to drop". > > Mohit > > Date: Thu, 13 Nov 2008 20:27:32 +0000 > > From: "Alexander Harrowell" <a.harrowell at gmail.com> > > Subject: Re: Prefix Hijack Tool Comaprision > > To: Todd Underwood <todd at renesys.com> > > Cc: nanog at nanog.org > > > > OK. This seems to be a flaw in RIPE RIS, a pity because BGPlay is great. > > > > - original message - > > Subject: Re: Prefix Hijack Tool Comaprision > > From: Todd Underwood <todd at renesys.com> > > Date: 13/11/2008 8:05 pm > > > > alexander, all, > > > > On Thu, Nov 13, 2008 at 07:56:26PM +0000, Alexander Harrowell wrote: > > > It may be the North American NOG, but it's been said before that it > > > functions as a GNOG, G for Global. I don't think Brazil is > > > insignificant. I respect Todd's work greatly, but I think he's wrong > > > on this point. > > > > you misread me. > > > > i did not say that brazil was insignificant. it's not. it has some of > > the fastest growing internet in latin america. > > > > i said that *this* hijacking took place in an insignificant corner of > > the internet. i mean this AS-map wise rather than geographically. > > this hijacking didn't even spread beyond one or two ASes, one of whom > > just happened to be a RIPE RIS peer. > > > > real hijackings leak into dozens or hundreds or thousands of ASNs. > > they spread far and wide. that's why people carry them out, when they > > do. this one was stopped in its tracks in a very small portion of one > > corner of the AS graph. > > > > as such, i don't count it as a hijacking or leak of any great > > significance and wouldn't want to alert anyone about it. that's why i > > recommend that prefix hijacking detection systems do thresholding of > > peers to prevent a single, rogue, unrepresentative peer from reporting > > a hijacking when none is really happening. others may have a > > different approach, but without thresholding prefix alert systems can > > be noisy and more trouble than they are worth. > > > > sorry if it appears that i was denegrating .br . i was not. > > > > t. > > > > -- > > _____________________________________________________________________ > > todd underwood +1 603 643 9300 x101 > > renesys corporation > > todd at renesys.com > http://www.renesys.com/blog > > > > > > > > > From cidr-report at potaroo.net Fri Nov 14 05:00:05 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Nov 2008 22:00:05 +1100 (EST) Subject: BGP Update Report Message-ID: <200811141100.mAEB05B5055838@wattle.apnic.net> BGP Update Report Interval: 13-Oct-08 -to- 13-Nov-08 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 192824 1.6% 169.3 -- SIFY-AS-IN Sify Limited 2 - AS4538 185313 1.5% 36.4 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS10396 153901 1.3% 2653.5 -- COQUI-NET - DATACOM CARIBE, INC. 4 - AS6389 130178 1.1% 29.5 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 5 - AS1803 89603 0.8% 63.6 -- ICMNET-5 - Sprint 6 - AS6629 85589 0.7% 1316.8 -- NOAA-AS - NOAA 7 - AS20115 66122 0.6% 29.6 -- CHARTER-NET-HKY-NC - Charter Communications 8 - AS23126 64323 0.5% 278.5 -- CENTURYTEL-SOLUTIONS-LLC - CenturyTel Solutions, LLC 9 - AS8151 62013 0.5% 43.1 -- Uninet S.A. de C.V. 10 - AS209 58003 0.5% 18.3 -- ASN-QWEST - Qwest Communications Corporation 11 - AS6298 56546 0.5% 26.7 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 12 - AS2386 52486 0.4% 31.8 -- INS-AS - AT&T Data Communications Services 13 - AS29282 47473 0.4% 15824.3 -- EMENTOR-AS Enfo Oyj 14 - AS9051 45081 0.4% 280.0 -- IDM Autonomous System 15 - AS34116 43926 0.4% 439.3 -- CYBER-AS Cyber Net AS 16 - AS7643 43390 0.4% 24.5 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 17 - AS1785 42164 0.3% 24.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. 18 - AS14106 41600 0.3% 20800.0 -- LEPMED01 - Leprechaun, LLC 19 - AS6458 41193 0.3% 97.2 -- Telgua 20 - AS17488 40525 0.3% 26.2 -- HATHWAY-NET-AP Hathway IP Over Cable Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14106 41600 0.3% 20800.0 -- LEPMED01 - Leprechaun, LLC 2 - AS29282 47473 0.4% 15824.3 -- EMENTOR-AS Enfo Oyj 3 - AS14593 14797 0.1% 14797.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 4 - AS43299 13760 0.1% 13760.0 -- TELECONTACT-AS Telecontact Ltd. 5 - AS22492 25284 0.2% 8428.0 -- 6 - AS37026 15335 0.1% 7667.5 -- SALT-ASN 7 - AS30287 5813 0.1% 5813.0 -- ALON-USA - ALON USA, LP 8 - AS40194 4229 0.0% 4229.0 -- INHOUSE-ASSOCIATES-LC - Inhouse Associates, L.C. 9 - AS14220 18062 0.1% 3612.4 -- I2A - I 20 Access 10 - AS4130 16410 0.1% 3282.0 -- UPITT-AS - University of Pittsburgh 11 - AS30969 26091 0.2% 3261.4 -- TAN-NET TransAfrica Networks 12 - AS41007 16046 0.1% 3209.2 -- CTCASTANA CTC ASTANA, KZ 13 - AS21603 30105 0.2% 3010.5 -- Universidad La Salle, AC 14 - AS25799 3001 0.0% 3001.0 -- HOLMAN - Holman Enterprises 15 - AS5691 38614 0.3% 2970.3 -- MITRE-AS-5 - The MITRE Corporation 16 - AS5033 25159 0.2% 2795.4 -- ISW - Internet Specialties West Inc. 17 - AS10396 153901 1.3% 2653.5 -- COQUI-NET - DATACOM CARIBE, INC. 18 - AS23917 2334 0.0% 2334.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 19 - AS22247 2036 0.0% 2036.0 -- LETOURNEAUUNIVERSITY - LeTourneau University 20 - AS48131 2020 0.0% 2020.0 -- VANGUARD-BG-AS Vanguard SA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 221.134.222.0/24 62636 0.5% AS9583 -- SIFY-AS-IN Sify Limited 2 - 210.214.151.0/24 59751 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 221.135.80.0/24 42657 0.3% AS9583 -- SIFY-AS-IN Sify Limited 4 - 192.12.120.0/24 38228 0.3% AS5691 -- MITRE-AS-5 - The MITRE Corporation 5 - 194.126.143.0/24 35011 0.3% AS9051 -- IDM Autonomous System 6 - 77.95.144.0/22 33245 0.3% AS29282 -- EMENTOR-AS Enfo Oyj 7 - 200.33.104.0/23 29597 0.2% AS21603 -- Universidad La Salle, AC 8 - 192.102.88.0/24 27198 0.2% AS6629 -- NOAA-AS - NOAA 9 - 192.35.129.0/24 26950 0.2% AS6629 -- NOAA-AS - NOAA 10 - 198.77.177.0/24 26932 0.2% AS6629 -- NOAA-AS - NOAA 11 - 12.2.46.0/24 25239 0.2% AS22492 -- 12 - 64.162.116.0/24 24935 0.2% AS5033 -- ISW - Internet Specialties West Inc. 13 - 221.128.192.0/18 23082 0.2% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 14 - 8.192.154.0/24 22681 0.2% AS14106 -- LEPMED01 - Leprechaun, LLC 15 - 65.44.76.0/24 18919 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 16 - 150.212.224.0/19 16291 0.1% AS4130 -- UPITT-AS - University of Pittsburgh 17 - 72.50.96.0/20 14905 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 18 - 196.42.0.0/20 14871 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 19 - 12.8.7.0/24 14797 0.1% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 20 - 217.69.48.0/20 14206 0.1% AS29282 -- EMENTOR-AS Enfo Oyj Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Nov 14 05:00:03 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Nov 2008 22:00:03 +1100 (EST) Subject: The Cidr Report Message-ID: <200811141100.mAEB03Kd055832@wattle.apnic.net> This report has been generated at Fri Nov 14 21:24:10 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 07-11-08 287743 177595 08-11-08 288027 178006 09-11-08 288049 176846 10-11-08 286254 177123 11-11-08 286541 175643 12-11-08 287066 175835 13-11-08 286772 176362 14-11-08 287463 175543 AS Summary 29973 Number of ASes in routing system 12681 Number of ASes announcing only one prefix 5058 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 89832448 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 14Nov08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 287942 175499 112443 39.1% All ASes AS4538 5058 875 4183 82.7% ERX-CERNET-BKB China Education and Research Network Center AS6389 4375 357 4018 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 3020 1356 1664 55.1% ASN-QWEST - Qwest Communications Corporation AS1785 1697 277 1420 83.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS6298 2101 743 1358 64.6% ASN-CXA-PH-6298-CBS - Cox Communications Inc. AS4323 1586 437 1149 72.4% TWTC - tw telecom holdings, inc. AS17488 1410 285 1125 79.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1196 191 1005 84.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS6478 1664 751 913 54.9% ATT-INTERNET3 - AT&T WorldNet Services AS8151 1402 566 836 59.6% Uninet S.A. de C.V. AS22773 1006 199 807 80.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS11492 1213 447 766 63.1% CABLEONE - CABLE ONE, INC. AS2386 1594 920 674 42.3% INS-AS - AT&T Data Communications Services AS19262 929 275 654 70.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 788 195 593 75.3% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS9498 691 113 578 83.6% BBIL-AP BHARTI Airtel Ltd. AS3356 1066 505 561 52.6% LEVEL3 Level 3 Communications AS18566 1059 549 510 48.2% COVAD - Covad Communications Co. AS4766 939 453 486 51.8% KIXS-AS-KR Korea Telecom AS7545 633 157 476 75.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS855 595 121 474 79.7% CANET-ASN-4 - Bell Aliant AS4808 625 154 471 75.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 608 163 445 73.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7011 923 480 443 48.0% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17676 522 79 443 84.9% GIGAINFRA BB TECHNOLOGY Corp. AS9443 524 83 441 84.2% INTERNETPRIMUS-AS-AP Primus Telecommunications AS22047 568 127 441 77.6% VTR BANDA ANCHA S.A. AS7018 1432 993 439 30.7% ATT-INTERNET4 - AT&T WorldNet Services AS4134 899 477 422 46.9% CHINANET-BACKBONE No.31,Jin-rong Street AS4668 688 275 413 60.0% LGNET-AS-KR LG CNS Total 40811 12603 28208 69.1% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 50.0.0.0/16 AS6858 COMLINK-AS Comlink ISP Autonomous System 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 91.207.222.0/23 AS9138 94.229.96.0/20 AS41546 INTRASTAR-AS CJSC "IntraStar" 95.52.0.0/14 AS8997 ASN-SPBNIT OJSC North-West Telecom Autonomous System 95.52.0.0/18 AS8997 ASN-SPBNIT OJSC North-West Telecom Autonomous System 95.52.64.0/18 AS8997 ASN-SPBNIT OJSC North-West Telecom Autonomous System 95.52.128.0/18 AS8997 ASN-SPBNIT OJSC North-West Telecom Autonomous System 95.53.0.0/18 AS8997 ASN-SPBNIT OJSC North-West Telecom Autonomous System 95.53.128.0/18 AS8997 ASN-SPBNIT OJSC North-West Telecom Autonomous System 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 119.31.232.0/21 AS38870 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 124.109.16.0/21 AS38137 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 169.254.0.0/16 AS13184 HANSENET HanseNet Telekommunikation GmbH 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.0.187.0/24 AS19132 200.5.32.0/21 AS19132 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/21 AS38205 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 202.191.8.0/21 AS10223 UECOMM-AU Uecomm Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From pauldotwall at gmail.com Fri Nov 14 05:30:32 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 14 Nov 2008 06:30:32 -0500 Subject: Router Choice In-Reply-To: <d0fea3580811120731n577d954cp46c376eb14e72bb9@mail.gmail.com> References: <ac036ce50811120440x8139b1fq170fd13b5d0a61ef@mail.gmail.com> <D0AA0B5D-9EE6-4B60-8043-89D3A017EB77@gmail.com> <d0fea3580811120731n577d954cp46c376eb14e72bb9@mail.gmail.com> Message-ID: <620fd17c0811140330s33792e68r94b12424d3d2be14@mail.gmail.com> Whoa, excessive use of "!"...this isn't IOS ICMP output. For those of you who want to have a chuckle, grep the word "exit" on any of these fine 7750/7450 router configurations. Seeing a router configuration that contains 10,000+ instances of the word "exit" makes me recall the fine book FINAL EXIT. Seems like a poor mans version of nesting with { }'s in JUNOS. Some of my gripes on the Timetra (whens the last time Alcatel built something themselves instead of acquire it?) box are that it really is catered to installs where Alcatel is running the design side of the network as well. The CLI is somewhat non-intuitive for IOS, IOS-XR or JUNOS operations staff. Here are some examples: Here in 2008, why are people buying boxes that do not support candidate configuration or commit/rollback? The only thing you can "commit" on the box is routing policy changes. I thought this was a service provider box? For years (this might not be the case anymore), any time you attempted to use the short-form of the "show" command by typing "sh", you received a syntax error. This is because there were two commands that began with sh: show and shell. The problem is that the shell command prompts you for a password that only Alcatel knows (and won't share with any customers that I'm aware of). So, if your own customers cant run the command, why give users a headache? Its a router, why do I have to do "show router route" to see a routing table entry? For years, you also had to suffix the command "exact" on the end of every command as well. Pricing wise...they're way above other boxes that you can find elsewhere that can do the jobs you need. Both the Cisco 7600 and the Juniper MX line both have a way better CLI and employ a knowledgeable staff of seasoned former service provider engineers. Alcatel seems to be comprised of failed router startup guys from Caspian or Chiaro. Feature wise, they're behind the curve when it comes to competing with Cisco and Juniper. I think this is also shown in how they name their software releases as "Feature Groups" (telco-speak, anyone?). The main thing I want to speak to is that this box is not made for your clueful IP operator. Alcatel is very insistent that the customer use their UNIX/Windows NMS (I believe they call the SAM) to interface with the routers. Sorry but...that might fly in telcoland where executives ooh and ahh over point-and-click network management, but I think most operators are going to find it a tad bit useless. Sure, they do have NSR, but so did Avici. Does NSR make up for the lack of features, high pricing and being stuck at 20Gbps per slot? Yes, they do have 40Gbps per slot on the way, but who doesn't support 40Gbps per slot today? Why bother stepping back a few years in development when if you want a solid P core box, Foundry MLX/XMR, Juniper MX, Cisco 7600s and CRS-1's are ready now and at prices that really aren't all that bad. Oh yeah, you wont scratch the hell out of your finger nails when removing the compact flash on those boxes. Drive slow, pinging 10(!!!!). On Wed, Nov 12, 2008 at 10:31 AM, devang patel <devangnp at gmail.com> wrote: > I guess they have good lab in Plano, TX also!!!I worked on the same routers > for IPTV deployment and really they are best!!! > > > regards > Devang Patel > > On Wed, Nov 12, 2008 at 8:43 AM, Dan Snyder <sliplever at gmail.com> wrote: > >> I think that the 7750SR routers are great and you won't be let down. We >> used to have an all Cisco network and I was skeptical at first but they have >> been great. >> >> As for nss and nsr when we tested this by failing a cpm we saw less than 50 >> ms of traffic loss. I would see if you could go to either California or >> Canada to one of ALUs labs and have it demonstrated for you. >> >> hth, >> Dan >> >> >> >> Sent from my iPhone >> >> >> On Nov 12, 2008, at 7:40 AM, "Raymond Macharia" <rmacharia at gmail.com> >> wrote: >> >> Hello fellow nanogers, >>> I am a long time user of Cisco gear and currently evaluating an >>> alternative >>> for my network expansion. currently the one that looks like it will be >>> able >>> to do the job iare Alcatel-Lucent 7710/7750 service routers. >>> I am looking for real life experience of those who have used it and what I >>> may need to watch out for (if anything) I have seen in some of their >>> documentation features like Non-stop Services (NSS) and Non-stop Routing >>> (NSR). are these features real world deployable. >>> oh, just to add I want to use the routers as P routers in my IP/MPLS core >>> >>> Regards >>> -- >>> Raymond Macharia >>> >> >> > From devangnp at gmail.com Fri Nov 14 08:55:40 2008 From: devangnp at gmail.com (devang patel) Date: Fri, 14 Nov 2008 08:55:40 -0600 Subject: OSPF with Multiple ABR & ASBR Message-ID: <d0fea3580811140655k5dcbee71tfa8af3b5096eb477@mail.gmail.com> Hi All, I am not sure is this the good place to ask this question or not!!! I am looking for feed back on having OSPF multi-area, lets say if you have multiple location in nonbackbone areas and those nonbackbone areas are connected with the one backbone area. For example: OSPF AREA1 has the connectivity to OSPF AREA0 using two ABR, so what is the optimum way to achieve the load balancing or load sharing for traffic entering or leaving the area, what are the possible way to configure it? regards Devang Patel From darden at armc.org Fri Nov 14 09:29:07 2008 From: darden at armc.org (Patrick Darden) Date: Fri, 14 Nov 2008 10:29:07 -0500 Subject: OSPF with Multiple ABR & ASBR In-Reply-To: <d0fea3580811140655k5dcbee71tfa8af3b5096eb477@mail.gmail.com> References: <d0fea3580811140655k5dcbee71tfa8af3b5096eb477@mail.gmail.com> Message-ID: <491D9943.30506@armc.org> First, without any details, it sounds like you might be better off with static routes than with OSPF. I'm not trying to be patronizing, but you don't mention many details, and some of the details you omit are the crucial ones for OSPF. 1. Do these remote areas have multiple paths to the central area for failover? E.g. a 10Mbps Metro Ethernet primary link, and a 1.5Mbps DSL secondary? 2. Does the central area have multiple routers for failover? E.g. a Cisco 7200 for the incoming Metro Ethernet primary connections, and a Cisco 3660 for the slower secondary connections? 3. Are there any tie-ins between the remote sites that bypass the central site? E.g. site1 and site2 both communicate to the central site via Metro Ethernet, and they also communicate to eachother via DSL. If none of the above are true, then static routes would be better for you (for the remote area/s in question). E.g. area1 has multiple paths, so ospf is warranted; however, area2 has just one path so a static approach would usually be better. Your language seems to indicate that OSPF is warranted (area0, area1, two ABRs). I am assuming you mean Area Border Router not Associative Based Routing (vs. OSPF). I am also assuming this is a non-public system (internal network, probably a MAN or WAN). If so, without any further details, I would set it up for bandwidth/failover. Weight the paths appropriately. Keep it as simple as you can. OSPF can become a morass. If you sketch your situation out more, we can be more helpful.... Campus? MAN? How public? Multi-pathed? Multi-homed? Multiple interlinks? Are there some lines with reliability problems where the lower bandwidth links are actually preferred? Do you have any decentralized concentration points that might have problems due to multiple remote sites shuttling traffic through it (due to multiple interlinks)? --p devang patel wrote: > Hi All, > > I am not sure is this the good place to ask this question or not!!! > > I am looking for feed back on having OSPF multi-area, lets say if you have > multiple location in nonbackbone areas and those nonbackbone areas are > connected with the one backbone area. For example: OSPF AREA1 has the > connectivity to OSPF AREA0 using two ABR, so what is the optimum way to > achieve the load balancing or load sharing for traffic entering or leaving > the area, what are the possible way to configure it? > > regards > Devang Patel > From devangnp at gmail.com Fri Nov 14 09:52:12 2008 From: devangnp at gmail.com (devang patel) Date: Fri, 14 Nov 2008 09:52:12 -0600 Subject: OSPF with Multiple ABR & ASBR In-Reply-To: <491D9943.30506@armc.org> References: <d0fea3580811140655k5dcbee71tfa8af3b5096eb477@mail.gmail.com> <491D9943.30506@armc.org> Message-ID: <d0fea3580811140752x12c4079an12728e4303f67949@mail.gmail.com> Sorry about that!!! 1. Do these remote areas have multiple paths to the central area for failover? E.g. a 10Mbps Metro Ethernet primary link, and a 1.5Mbps DSL secondary? 2. Does the central area have multiple routers for failover? E.g. a Cisco 7200 for the incoming Metro Ethernet primary connections, and a Cisco 3660 for the slower secondary connections? 3. Are there any tie-ins between the remote sites that bypass the central site? E.g. site1 and site2 both communicate to the central site via Metro Ethernet, and they also communicate to eachother via DSL. Answers: I have two T1 line to the non-backbone area and both T1s are terminated to the two different routers on non-backbone area as well as to backbone area, and I dont want to achieve primary and secondary role, I want to go for the load sharing kind of scenario. All sites are connected with the central site. ABR means Area border router only. I am attaching one generalized diagram, please look at that one. Now I want to achieve the load balancing between the traffic going from R1 to R8, I want to achieve some of the networks on R1 should be reachable via R2 and some of them via R3 for the traffic coming from the R8. assume all links are same. regards Devang Patel On Fri, Nov 14, 2008 at 9:29 AM, Patrick Darden <darden at armc.org> wrote: > > First, without any details, it sounds like you might be better off with > static routes than with OSPF. I'm not trying to be patronizing, but you > don't mention many details, and some of the details you omit are the crucial > ones for OSPF. > > 1. Do these remote areas have multiple paths to the central area for > failover? E.g. a 10Mbps Metro Ethernet primary link, and a 1.5Mbps DSL > secondary? > 2. Does the central area have multiple routers for failover? E.g. a Cisco > 7200 for the incoming Metro Ethernet primary connections, and a Cisco 3660 > for the slower secondary connections? > 3. Are there any tie-ins between the remote sites that bypass the central > site? E.g. site1 and site2 both communicate to the central site via Metro > Ethernet, and they also communicate to eachother via DSL. > > If none of the above are true, then static routes would be better for you > (for the remote area/s in question). E.g. area1 has multiple paths, so ospf > is warranted; however, area2 has just one path so a static approach would > usually be better. > > Your language seems to indicate that OSPF is warranted (area0, area1, two > ABRs). I am assuming you mean Area Border Router not Associative Based > Routing (vs. OSPF). I am also assuming this is a non-public system > (internal network, probably a MAN or WAN). > > If so, without any further details, I would set it up for > bandwidth/failover. Weight the paths appropriately. Keep it as simple as > you can. OSPF can become a morass. > > If you sketch your situation out more, we can be more helpful.... Campus? > MAN? How public? Multi-pathed? Multi-homed? Multiple interlinks? Are > there some lines with reliability problems where the lower bandwidth links > are actually preferred? Do you have any decentralized concentration points > that might have problems due to multiple remote sites shuttling traffic > through it (due to multiple interlinks)? > > --p > > > devang patel wrote: > >> Hi All, >> >> I am not sure is this the good place to ask this question or not!!! >> >> I am looking for feed back on having OSPF multi-area, lets say if you have >> multiple location in nonbackbone areas and those nonbackbone areas are >> connected with the one backbone area. For example: OSPF AREA1 has the >> connectivity to OSPF AREA0 using two ABR, so what is the optimum way to >> achieve the load balancing or load sharing for traffic entering or leaving >> the area, what are the possible way to configure it? >> >> regards >> Devang Patel >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: OSPF.jpg Type: image/jpeg Size: 51738 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081114/0f241be7/attachment.jpg> From black at csulb.edu Fri Nov 14 09:55:35 2008 From: black at csulb.edu (Matthew Black) Date: Fri, 14 Nov 2008 07:55:35 -0800 Subject: [funsec] McColo: Major Source of Online Scams andSpams KnockedOffline (fwd) In-Reply-To: <491C5845.6090500@nortel.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int> <355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> <491B42C4.7080805@wvi.com> <DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int> <491B58B4.5070906@thewybles.com> <491C1DEF.9070704@gmail.com> <491C5845.6090500@nortel.com> Message-ID: <web-21475173@remus.csulb.edu> Since McColo, et al., cutting off those miscreant customers on Wednesday, I've noticed a huge decline in connection attempts to our e-mail gateways. Even if their efforts are temporary, the change is quite noticeable. matthew black e-mail postmaster california state university, long beach From isabeldias1 at yahoo.com Fri Nov 14 10:06:30 2008 From: isabeldias1 at yahoo.com (isabel dias) Date: Fri, 14 Nov 2008 08:06:30 -0800 (PST) Subject: OSPF with Multiple ABR & ASBR In-Reply-To: <d0fea3580811140752x12c4079an12728e4303f67949@mail.gmail.com> Message-ID: <484544.42051.qm@web52609.mail.re2.yahoo.com> Patel, I would suggest you to read a few things about the path selection algoritm....as if i understand your words you are asking for an issue on LSA type 4 rather than multiple AS and therefore LSA type 5 /7-ASBR prefer backbone intra-area paths over inter-area paths.... Excerpted from RFC 16.4.1...- When multiple intra-AS paths are available to ASBRs/forwarding addresses some rules using different costs apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, while in the latter the paths terminate at separate ASBRs/forwarding addresses. http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080124c7d.shtml .//ID --- On Fri, 11/14/08, devang patel <devangnp at gmail.com> wrote: > From: devang patel <devangnp at gmail.com> > Subject: Re: OSPF with Multiple ABR & ASBR > To: "Patrick Darden" <darden at armc.org> > Cc: nanog at nanog.org > Date: Friday, November 14, 2008, 4:52 PM > Sorry about that!!! > > 1. Do these remote areas have multiple paths to the > central area for > failover? E.g. a 10Mbps Metro Ethernet primary link, and a > 1.5Mbps DSL > secondary? > 2. Does the central area have multiple routers for > failover? E.g. a Cisco > 7200 for the incoming Metro Ethernet primary connections, > and a Cisco 3660 > for the slower secondary connections? > 3. Are there any tie-ins between the remote sites that > bypass the central > site? E.g. site1 and site2 both communicate to the central > site via Metro > Ethernet, and they also communicate to eachother via DSL. > > > Answers: > I have two T1 line to the non-backbone area and both T1s > are terminated to > the two different routers on non-backbone area as well as > to backbone area, > and I dont want to achieve primary and secondary role, I > want to go for the > load sharing kind of scenario. All sites are connected with > the central > site. > > ABR means Area border router only. > > I am attaching one generalized diagram, please look at that > one. > Now I want to achieve the load balancing between the > traffic going from R1 > to R8, I want to achieve some of the networks on R1 should > be reachable via > R2 and some of them via R3 for the traffic coming from the > R8. assume all > links are same. > > regards > Devang Patel > > > On Fri, Nov 14, 2008 at 9:29 AM, Patrick Darden > <darden at armc.org> wrote: > > > > > First, without any details, it sounds like you might > be better off with > > static routes than with OSPF. I'm not trying to > be patronizing, but you > > don't mention many details, and some of the > details you omit are the crucial > > ones for OSPF. > > > > 1. Do these remote areas have multiple paths to the > central area for > > failover? E.g. a 10Mbps Metro Ethernet primary link, > and a 1.5Mbps DSL > > secondary? > > 2. Does the central area have multiple routers for > failover? E.g. a Cisco > > 7200 for the incoming Metro Ethernet primary > connections, and a Cisco 3660 > > for the slower secondary connections? > > 3. Are there any tie-ins between the remote sites > that bypass the central > > site? E.g. site1 and site2 both communicate to the > central site via Metro > > Ethernet, and they also communicate to eachother via > DSL. > > > > If none of the above are true, then static routes > would be better for you > > (for the remote area/s in question). E.g. area1 has > multiple paths, so ospf > > is warranted; however, area2 has just one path so a > static approach would > > usually be better. > > > > Your language seems to indicate that OSPF is warranted > (area0, area1, two > > ABRs). I am assuming you mean Area Border Router not > Associative Based > > Routing (vs. OSPF). I am also assuming this is a > non-public system > > (internal network, probably a MAN or WAN). > > > > If so, without any further details, I would set it up > for > > bandwidth/failover. Weight the paths appropriately. > Keep it as simple as > > you can. OSPF can become a morass. > > > > If you sketch your situation out more, we can be more > helpful.... Campus? > > MAN? How public? Multi-pathed? Multi-homed? > Multiple interlinks? Are > > there some lines with reliability problems where the > lower bandwidth links > > are actually preferred? Do you have any decentralized > concentration points > > that might have problems due to multiple remote sites > shuttling traffic > > through it (due to multiple interlinks)? > > > > --p > > > > > > devang patel wrote: > > > >> Hi All, > >> > >> I am not sure is this the good place to ask this > question or not!!! > >> > >> I am looking for feed back on having OSPF > multi-area, lets say if you have > >> multiple location in nonbackbone areas and those > nonbackbone areas are > >> connected with the one backbone area. For example: > OSPF AREA1 has the > >> connectivity to OSPF AREA0 using two ABR, so what > is the optimum way to > >> achieve the load balancing or load sharing for > traffic entering or leaving > >> the area, what are the possible way to configure > it? > >> > >> regards > >> Devang Patel > >> > >> > > From dave at stayonline.com Fri Nov 14 10:22:20 2008 From: dave at stayonline.com (Dave Larter) Date: Fri, 14 Nov 2008 11:22:20 -0500 Subject: [funsec] McColo: Major Source of Online Scams andSpamsKnockedOffline (fwd) In-Reply-To: <web-21475173@remus.csulb.edu> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org><02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com><6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com><DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int><355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com><491B42C4.7080805@wvi.com><DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int><491B58B4.5070906@thewybles.com> <491C1DEF.9070704@gmail.com><491C5845.6090500@nortel.com> <web-21475173@remus.csulb.edu> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB353390@MERCURY.socrdu.com> I would agree, a tedious drop. The image is from one of our gateways. -----Original Message----- From: Matthew Black [mailto:black at csulb.edu] Sent: Friday, November 14, 2008 10:56 AM To: NANOG list Subject: Re: [funsec] McColo: Major Source of Online Scams andSpamsKnockedOffline (fwd) Since McColo, et al., cutting off those miscreant customers on Wednesday, I've noticed a huge decline in connection attempts to our e-mail gateways. Even if their efforts are temporary, the change is quite noticeable. matthew black e-mail postmaster california state university, long beach -------------- next part -------------- A non-text attachment was scrubbed... Name: javachart_servletCA4OKYR0.png Type: image/png Size: 12564 bytes Desc: javachart_servletCA4OKYR0.png URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081114/82775dae/attachment.png> From michael.dillon at bt.com Fri Nov 14 11:07:40 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 14 Nov 2008 17:07:40 -0000 Subject: NAT66 and the subscriber prefix length Message-ID: <C0F2465B4F386241A58321C884AC7ECC0961B7FB@E03MVZ2-UKDY.domain1.systemhost.net> Not long ago, ARIN changed the IPv6 policy so that residential subscribers could be issued with a /56 instead of the normal /48 assignment. This was done so that ISPs with large numbers of subscriber sites would not exhaust their /32 (or larger) allocations too soon. Since these ISPs are allowed to assign a /56 to residential subscriber sites, their initial IPv6 allocation will last a lot longer and they won't have to apply for an additional allocation while everyone is getting up to speed with an IPv6 Internet. Now, however, the IETF is discussing a form of NAT for IPv6 called NAT66. See this draft for details <http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-01.txt> Part of this new NAT is that they are checksum neutral. They do this by modifying bits in the address that are not needed. Specifically, they assume that the end site has a /48 allocation, and that the next 16 bits up to the /64 boundary, are non-essential information outside the end-site boundary. These bits are then twiddled to preserve the IPv6 header checksum. Of course, these are the same bits that an ISP relies on for reducing the assignment size to /56. I see a potential conflict here. If we assume that NAT66 will be widely used by consumers, then it follows that consumer end-sites will need a /48 assignment in order for IPv6 to work. But some ISPs want to reduce the end site assignment to /56 meaning that NAT66 won't work for those consumers. Of course, it's not all set in stone yet which is why I am posting this to NANOG. If ISP's who intend to use /56 allocations could join in the discussions, then perhaps we could develop some form of NAT66 that works with /56 prefix lengths. Personally, I would be happy to just see every site consistently use a /48 assignment. Corporate campus or one-room studio apartment; it's all the same to me. --Michael Dillon From darden at armc.org Fri Nov 14 11:27:56 2008 From: darden at armc.org (Darden, Patrick S.) Date: Fri, 14 Nov 2008 12:27:56 -0500 Subject: OSPF with Multiple ABR & ASBR In-Reply-To: <d0fea3580811140752x12c4079an12728e4303f67949@mail.gmail.com> Message-ID: <CBE22E5FF427B149A272DD1DDE10752402368B0F@EX2K3.armc.org> It is my understanding of OSPF that, if you have paths with equal distance and cost to a destination, load balancing happens automatically for up to four (or is it 6 for OSPF?) clear paths. In your diagram R1 to R8 load balancing should happen naturally, unless you have weighted one of the paths. You have much more than 4 paths here, so you should weight the ones you want. E.g. 1-2-4-6-8, 1-3-5-7-8 would be the most straightforward, and barring some type of natural concentration of bandwidth (e.g. R3 having 10X the hosts connected that R2 has) it would be the easiest to implement. This only applies to coequal routing (e.g. all links are T1s). If you are doing unequal routing I think you are out of luck. I would stick to two paths if possible for simplicity's sake. OSPF can become a quagmire if you let it. So, first step is weight your chosen paths equally, and make sure they are preferred over other possible paths. Second step is to decide what kind of load balancing you want: per packet, or endpoint. If you set it up per packet, you get equal load balancing with the chance of out-of-order packets on the other end. It can also take up a lot of the router's cpu resources. If you decide on endpoint load balancing you will almost always have one path taking the majority of the traffic--e.g. all traffic to the file sharer will take path1 and all traffic to the ntp server will take path2, and path1 will definitely be more heavily loaded. To properly balance by endpoint takes some micromanagement. Depending on your router, you turn ip route cache on for endpoint balancing, and turn it off to enable per packet balancing. Cisco has something called CEF which I have never used, which supposedly enhances OSPF load balancing--uses special algorithms to speed it up. --p -----Original Message----- From: devang patel [mailto:devangnp at gmail.com] Sent: Friday, November 14, 2008 10:52 AM To: Darden, Patrick S. Cc: nanog at nanog.org Subject: Re: OSPF with Multiple ABR & ASBR Sorry about that!!! 1. Do these remote areas have multiple paths to the central area for failover? E.g. a 10Mbps Metro Ethernet primary link, and a 1.5Mbps DSL secondary? 2. Does the central area have multiple routers for failover? E.g. a Cisco 7200 for the incoming Metro Ethernet primary connections, and a Cisco 3660 for the slower secondary connections? 3. Are there any tie-ins between the remote sites that bypass the central site? E.g. site1 and site2 both communicate to the central site via Metro Ethernet, and they also communicate to eachother via DSL. Answers: I have two T1 line to the non-backbone area and both T1s are terminated to the two different routers on non-backbone area as well as to backbone area, and I dont want to achieve primary and secondary role, I want to go for the load sharing kind of scenario. All sites are connected with the central site. ABR means Area border router only. I am attaching one generalized diagram, please look at that one. Now I want to achieve the load balancing between the traffic going from R1 to R8, I want to achieve some of the networks on R1 should be reachable via R2 and some of them via R3 for the traffic coming from the R8. assume all links are same. regards Devang Patel On Fri, Nov 14, 2008 at 9:29 AM, Patrick Darden < darden at armc.org> wrote: First, without any details, it sounds like you might be better off with static routes than with OSPF. I'm not trying to be patronizing, but you don't mention many details, and some of the details you omit are the crucial ones for OSPF. 1. Do these remote areas have multiple paths to the central area for failover? E.g. a 10Mbps Metro Ethernet primary link, and a 1.5Mbps DSL secondary? 2. Does the central area have multiple routers for failover? E.g. a Cisco 7200 for the incoming Metro Ethernet primary connections, and a Cisco 3660 for the slower secondary connections? 3. Are there any tie-ins between the remote sites that bypass the central site? E.g. site1 and site2 both communicate to the central site via Metro Ethernet, and they also communicate to eachother via DSL. If none of the above are true, then static routes would be better for you (for the remote area/s in question). E.g. area1 has multiple paths, so ospf is warranted; however, area2 has just one path so a static approach would usually be better. Your language seems to indicate that OSPF is warranted (area0, area1, two ABRs). I am assuming you mean Area Border Router not Associative Based Routing (vs. OSPF). I am also assuming this is a non-public system (internal network, probably a MAN or WAN). If so, without any further details, I would set it up for bandwidth/failover. Weight the paths appropriately. Keep it as simple as you can. OSPF can become a morass. If you sketch your situation out more, we can be more helpful.... Campus? MAN? How public? Multi-pathed? Multi-homed? Multiple interlinks? Are there some lines with reliability problems where the lower bandwidth links are actually preferred? Do you have any decentralized concentration points that might have problems due to multiple remote sites shuttling traffic through it (due to multiple interlinks)? --p devang patel wrote: Hi All, I am not sure is this the good place to ask this question or not!!! I am looking for feed back on having OSPF multi-area, lets say if you have multiple location in nonbackbone areas and those nonbackbone areas are connected with the one backbone area. For example: OSPF AREA1 has the connectivity to OSPF AREA0 using two ABR, so what is the optimum way to achieve the load balancing or load sharing for traffic entering or leaving the area, what are the possible way to configure it? regards Devang Patel From aoxomoxoa at sunlightdata.com Fri Nov 14 11:44:12 2008 From: aoxomoxoa at sunlightdata.com (Fred Heutte) Date: Fri, 14 Nov 2008 09:44:12 -0800 Subject: McColo: Major Source of Online Scams and Spams Knocked Offline Message-ID: <200811141746.mAEHk5xD073520@broadway.hevanet.com> >p.s. McColo's upstream providers are completely within their rights to >terminate connectivity if they feel that they have violated their >contractual terms of service. Indeed. I also want to nominate fergdawg for the NANOG Order of Merit for getting the phrase "purge the badness" into the LA Times. "People thought the first community-source effort was a fluke," Ferguson said. "Now they see with McColo, it's not a fluke. The community can police its own backyard and purge the badness." http://www.latimes.com/business/la-fi-spam14-2008nov14,0,1012756.story cheers fh PS Spam counts on my own incoming mail are down about 70% right now. Enjoy the moment while we can ... ----------------- >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Wed, Nov 12, 2008 at 9:30 AM, Kee Hinckley <nazgul at somewhere.com> wrote: > >> After reading this, and the (Washington Post I believe--I'm away from my >> laptop right now) article on this, two things are bothering me. >> >> The article expressed a good deal of frustration with the (lack of) speed >> with which law enforcement has been tackling these issues. What wasn't >> clear was whether any attempt had been made to involve them prior to the >> shutdown. > >Don't assume what you don't know. :-) > >- - ferg > >p.s. McColo's upstream providers are completely within their rights to >terminate connectivity if they feel that they have violated their >contractual terms of service. > >-----BEGIN PGP SIGNATURE----- >Version: PGP Desktop 9.6.3 (Build 3017) > >wj8DBQFJGxggq1pz9mNUZTMRAsAwAKCUWdQAbTEZ+O5nWA/d1ED2fGSCQQCeJMUS >PmOiEoLms6r/V1IxJqcLMlk>=2xEG >-----END PGP SIGNATURE----- > > >-- >"Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > > From cscora at apnic.net Fri Nov 14 12:14:43 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Nov 2008 04:14:43 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200811141814.mAEIEhno005952@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <pfs at cisco.com>. Routing Table Report 04:00 +10GMT Sat 15 Nov, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 273747 Prefixes after maximum aggregation: 131698 Deaggregation factor: 2.08 Unique aggregates announced to Internet: 132906 Total ASes present in the Internet Routing Table: 29790 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25923 Origin ASes announcing only one prefix: 12618 Transit ASes present in the Internet Routing Table: 3867 Transit-only ASes present in the Internet Routing Table: 84 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 548 Unregistered ASNs in the Routing Table: 201 Number of 32-bit ASNs allocated by the RIRs: 63 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 210 Number of addresses announced to Internet: 1954643712 Equivalent to 116 /8s, 129 /16s and 127 /24s Percentage of available address space announced: 52.7 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 83.7 Percentage of address space in use by end-sites: 74.3 Total number of prefixes smaller than registry allocations: 134661 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62656 Total APNIC prefixes after maximum aggregation: 23339 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 59566 Unique aggregates announced from the APNIC address blocks: 26910 APNIC Region origin ASes present in the Internet Routing Table: 3459 APNIC Prefixes per ASN: 17.22 APNIC Region origin ASes announcing only one prefix: 932 APNIC Region transit ASes present in the Internet Routing Table: 534 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 381242016 Equivalent to 22 /8s, 185 /16s and 74 /24s Percentage of available APNIC address space announced: 75.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123986 Total ARIN prefixes after maximum aggregation: 64911 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 93363 Unique aggregates announced from the ARIN address blocks: 34747 ARIN Region origin ASes present in the Internet Routing Table: 12583 ARIN Prefixes per ASN: 7.42 ARIN Region origin ASes announcing only one prefix: 4862 ARIN Region transit ASes present in the Internet Routing Table: 1197 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 400498592 Equivalent to 23 /8s, 223 /16s and 31 /24s Percentage of available ARIN address space announced: 82.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 60086 Total RIPE prefixes after maximum aggregation: 36115 RIPE Deaggregation factor: 1.66 Prefixes being announced from the RIPE address blocks: 55709 Unique aggregates announced from the RIPE address blocks: 37297 RIPE Region origin ASes present in the Internet Routing Table: 12184 RIPE Prefixes per ASN: 4.57 RIPE Region origin ASes announcing only one prefix: 6406 RIPE Region transit ASes present in the Internet Routing Table: 1862 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 378515552 Equivalent to 22 /8s, 143 /16s and 176 /24s Percentage of available RIPE address space announced: 86.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22297 Total LACNIC prefixes after maximum aggregation: 5569 LACNIC Deaggregation factor: 4.00 Prefixes being announced from the LACNIC address blocks: 20335 Unique aggregates announced from the LACNIC address blocks: 11386 LACNIC Region origin ASes present in the Internet Routing Table: 1030 LACNIC Prefixes per ASN: 19.74 LACNIC Region origin ASes announcing only one prefix: 339 LACNIC Region transit ASes present in the Internet Routing Table: 170 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 58064256 Equivalent to 3 /8s, 117 /16s and 253 /24s Percentage of available LACNIC address space announced: 57.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4195 Total AfriNIC prefixes after maximum aggregation: 1334 AfriNIC Deaggregation factor: 3.14 Prefixes being announced from the AfriNIC address blocks: 4466 Unique aggregates announced from the AfriNIC address blocks: 2142 AfriNIC Region origin ASes present in the Internet Routing Table: 264 AfriNIC Prefixes per ASN: 16.92 AfriNIC Region origin ASes announcing only one prefix: 79 AfriNIC Region transit ASes present in the Internet Routing Table: 52 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC addresses announced to Internet: 12920064 Equivalent to 0 /8s, 197 /16s and 37 /24s Percentage of available AfriNIC address space announced: 25.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 17488 1409 99 106 Hathway IP Over Cable Interne 4755 1193 485 155 TATA Communications formerly 9583 1125 87 479 Sify Limited 4766 899 6409 363 Korea Telecom (KIX) 4134 898 13872 366 CHINANET-BACKBONE 23577 817 35 702 Korea Telecom (ATM-MPLS) 18101 786 167 31 Reliance Infocom Ltd Internet 4780 731 357 63 Digital United Inc. 9498 689 295 50 BHARTI BT INTERNET LTD. 4808 632 1172 143 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4370 3434 344 bellsouth.net, inc. 209 3019 4032 625 Qwest 6298 2094 327 691 Cox Communicatons 1785 1696 717 155 PaeTec Communications, Inc. 6478 1664 365 196 AT&T Worldnet Services 20115 1662 1452 726 Charter Communications 2386 1591 701 901 AT&T Data Communications Serv 4323 1589 1084 377 Time Warner Telecom 7018 1406 5869 974 AT&T WorldNet Services 11492 1214 166 16 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 429 1766 380 TDC Tele Danmark 12479 366 578 6 Uni2 Autonomous System 30890 366 95 189 SC Kappa Invexim SRL 3301 333 1429 303 TeliaNet Sweden 8866 331 111 23 Bulgarian Telecommunication C 3320 322 7062 271 Deutsche Telekom AG 3215 316 2788 99 France Telecom Transpac 5462 300 794 27 Telewest Broadband 8452 293 188 11 TEDATA 25233 289 44 24 Awalnet Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1400 2832 224 UniNet S.A. de C.V. 11830 670 299 9 Instituto Costarricense de El 10620 557 126 54 TVCABLE BOGOTA 22047 522 270 14 VTR PUNTO NET S.A. 7303 497 244 70 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 422 87 50 ENTEL CHILE S.A. 11172 406 118 72 Servicios Alestra S.A de C.V 28573 343 468 23 NET Servicos de Comunicao S.A 14117 331 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 560 72 45 LINKdotNET AS number 3741 271 857 227 The Internet Solution 20858 260 34 3 EgyNet 2018 238 215 140 Tertiary Education Network 29571 147 13 8 Ci Telecom Autonomous system 6713 144 135 11 Itissalat Al-MAGHRIB 33783 141 10 15 EEPAD TISP TELECOM & INTERNET 5536 119 7 22 Internet Egypt Network 33776 116 6 3 Starcomms Nigeria Limited 5713 114 555 63 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4370 3434 344 bellsouth.net, inc. 209 3019 4032 625 Qwest 6298 2094 327 691 Cox Communicatons 1785 1696 717 155 PaeTec Communications, Inc. 6478 1664 365 196 AT&T Worldnet Services 20115 1662 1452 726 Charter Communications 2386 1591 701 901 AT&T Data Communications Serv 4323 1589 1084 377 Time Warner Telecom 17488 1409 99 106 Hathway IP Over Cable Interne 7018 1406 5869 974 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 3019 2394 Qwest 1785 1696 1541 PaeTec Communications, Inc. 6478 1664 1468 AT&T Worldnet Services 6298 2094 1403 Cox Communicatons 17488 1409 1303 Hathway IP Over Cable Interne 4323 1589 1212 Time Warner Telecom 11492 1214 1198 Cable One 8151 1400 1176 UniNet S.A. de C.V. 18566 1059 1049 Covad Communications 4755 1193 1038 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.52.128.0/19 22561 Digital Teleport, Inc 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:19 /11:53 /12:159 /13:308 /14:547 /15:1077 /16:10156 /17:4457 /18:7687 /19:16553 /20:19396 /21:19150 /22:24122 /23:24829 /24:142451 /25:841 /26:1006 /27:798 /28:93 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2858 4370 bellsouth.net, inc. 6298 2068 2094 Cox Communicatons 209 1739 3019 Qwest 2386 1270 1591 AT&T Data Communications Serv 17488 1199 1409 Hathway IP Over Cable Interne 11492 1190 1214 Cable One 1785 1158 1696 PaeTec Communications, Inc. 6478 1106 1664 AT&T Worldnet Services 18566 1040 1059 Covad Communications 9583 992 1125 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 4:12 8:153 12:2181 13:2 15:21 16:3 17:5 20:35 24:1088 30:1 32:61 38:512 40:92 41:781 43:1 44:2 47:12 52:3 55:3 56:3 57:27 58:515 59:550 60:452 61:1032 62:1121 63:2012 64:3280 65:2433 66:3480 67:1326 68:818 69:2351 70:888 71:138 72:2067 73:2 74:1294 75:167 76:290 77:880 78:520 79:292 80:928 81:844 82:594 83:397 84:586 85:1040 86:505 87:705 88:347 89:1357 90:27 91:1670 92:300 93:980 94:395 95:38 96:88 97:132 98:387 99:15 113:40 114:127 115:150 116:1010 117:406 118:252 119:529 120:103 121:610 122:868 123:445 124:870 125:1229 128:353 129:217 130:137 131:408 132:72 133:9 134:186 135:31 136:223 137:106 138:144 139:85 140:413 141:111 142:392 143:321 144:302 145:51 146:372 147:140 148:601 149:210 150:130 151:210 152:148 153:137 154:10 155:275 156:174 157:301 158:168 159:301 160:272 161:140 162:249 163:135 164:517 165:508 166:363 167:341 168:631 169:154 170:452 171:40 172:10 173:138 174:17 187:18 188:1 189:318 190:2390 192:5825 193:4140 194:3288 195:2626 196:1021 198:3711 199:3309 200:5509 201:1471 202:7679 203:8044 204:3930 205:2180 206:2297 207:2773 208:3727 209:3445 210:2608 211:1093 212:1547 213:1633 214:68 215:25 216:4382 217:1249 218:351 219:426 220:1059 221:419 222:303 End of report From cscora at apnic.net Fri Nov 14 12:14:43 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Nov 2008 04:14:43 +1000 (EST) Subject: [SANOG] Weekly Routing Table Report Message-ID: <200811141814.mAEIEhno005952@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <pfs at cisco.com>. Routing Table Report 04:00 +10GMT Sat 15 Nov, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 273747 Prefixes after maximum aggregation: 131698 Deaggregation factor: 2.08 Unique aggregates announced to Internet: 132906 Total ASes present in the Internet Routing Table: 29790 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25923 Origin ASes announcing only one prefix: 12618 Transit ASes present in the Internet Routing Table: 3867 Transit-only ASes present in the Internet Routing Table: 84 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 548 Unregistered ASNs in the Routing Table: 201 Number of 32-bit ASNs allocated by the RIRs: 63 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 210 Number of addresses announced to Internet: 1954643712 Equivalent to 116 /8s, 129 /16s and 127 /24s Percentage of available address space announced: 52.7 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 83.7 Percentage of address space in use by end-sites: 74.3 Total number of prefixes smaller than registry allocations: 134661 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62656 Total APNIC prefixes after maximum aggregation: 23339 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 59566 Unique aggregates announced from the APNIC address blocks: 26910 APNIC Region origin ASes present in the Internet Routing Table: 3459 APNIC Prefixes per ASN: 17.22 APNIC Region origin ASes announcing only one prefix: 932 APNIC Region transit ASes present in the Internet Routing Table: 534 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 381242016 Equivalent to 22 /8s, 185 /16s and 74 /24s Percentage of available APNIC address space announced: 75.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123986 Total ARIN prefixes after maximum aggregation: 64911 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 93363 Unique aggregates announced from the ARIN address blocks: 34747 ARIN Region origin ASes present in the Internet Routing Table: 12583 ARIN Prefixes per ASN: 7.42 ARIN Region origin ASes announcing only one prefix: 4862 ARIN Region transit ASes present in the Internet Routing Table: 1197 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 400498592 Equivalent to 23 /8s, 223 /16s and 31 /24s Percentage of available ARIN address space announced: 82.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 60086 Total RIPE prefixes after maximum aggregation: 36115 RIPE Deaggregation factor: 1.66 Prefixes being announced from the RIPE address blocks: 55709 Unique aggregates announced from the RIPE address blocks: 37297 RIPE Region origin ASes present in the Internet Routing Table: 12184 RIPE Prefixes per ASN: 4.57 RIPE Region origin ASes announcing only one prefix: 6406 RIPE Region transit ASes present in the Internet Routing Table: 1862 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 378515552 Equivalent to 22 /8s, 143 /16s and 176 /24s Percentage of available RIPE address space announced: 86.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22297 Total LACNIC prefixes after maximum aggregation: 5569 LACNIC Deaggregation factor: 4.00 Prefixes being announced from the LACNIC address blocks: 20335 Unique aggregates announced from the LACNIC address blocks: 11386 LACNIC Region origin ASes present in the Internet Routing Table: 1030 LACNIC Prefixes per ASN: 19.74 LACNIC Region origin ASes announcing only one prefix: 339 LACNIC Region transit ASes present in the Internet Routing Table: 170 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 58064256 Equivalent to 3 /8s, 117 /16s and 253 /24s Percentage of available LACNIC address space announced: 57.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4195 Total AfriNIC prefixes after maximum aggregation: 1334 AfriNIC Deaggregation factor: 3.14 Prefixes being announced from the AfriNIC address blocks: 4466 Unique aggregates announced from the AfriNIC address blocks: 2142 AfriNIC Region origin ASes present in the Internet Routing Table: 264 AfriNIC Prefixes per ASN: 16.92 AfriNIC Region origin ASes announcing only one prefix: 79 AfriNIC Region transit ASes present in the Internet Routing Table: 52 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC addresses announced to Internet: 12920064 Equivalent to 0 /8s, 197 /16s and 37 /24s Percentage of available AfriNIC address space announced: 25.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 17488 1409 99 106 Hathway IP Over Cable Interne 4755 1193 485 155 TATA Communications formerly 9583 1125 87 479 Sify Limited 4766 899 6409 363 Korea Telecom (KIX) 4134 898 13872 366 CHINANET-BACKBONE 23577 817 35 702 Korea Telecom (ATM-MPLS) 18101 786 167 31 Reliance Infocom Ltd Internet 4780 731 357 63 Digital United Inc. 9498 689 295 50 BHARTI BT INTERNET LTD. 4808 632 1172 143 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4370 3434 344 bellsouth.net, inc. 209 3019 4032 625 Qwest 6298 2094 327 691 Cox Communicatons 1785 1696 717 155 PaeTec Communications, Inc. 6478 1664 365 196 AT&T Worldnet Services 20115 1662 1452 726 Charter Communications 2386 1591 701 901 AT&T Data Communications Serv 4323 1589 1084 377 Time Warner Telecom 7018 1406 5869 974 AT&T WorldNet Services 11492 1214 166 16 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 429 1766 380 TDC Tele Danmark 12479 366 578 6 Uni2 Autonomous System 30890 366 95 189 SC Kappa Invexim SRL 3301 333 1429 303 TeliaNet Sweden 8866 331 111 23 Bulgarian Telecommunication C 3320 322 7062 271 Deutsche Telekom AG 3215 316 2788 99 France Telecom Transpac 5462 300 794 27 Telewest Broadband 8452 293 188 11 TEDATA 25233 289 44 24 Awalnet Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1400 2832 224 UniNet S.A. de C.V. 11830 670 299 9 Instituto Costarricense de El 10620 557 126 54 TVCABLE BOGOTA 22047 522 270 14 VTR PUNTO NET S.A. 7303 497 244 70 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 422 87 50 ENTEL CHILE S.A. 11172 406 118 72 Servicios Alestra S.A de C.V 28573 343 468 23 NET Servicos de Comunicao S.A 14117 331 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 560 72 45 LINKdotNET AS number 3741 271 857 227 The Internet Solution 20858 260 34 3 EgyNet 2018 238 215 140 Tertiary Education Network 29571 147 13 8 Ci Telecom Autonomous system 6713 144 135 11 Itissalat Al-MAGHRIB 33783 141 10 15 EEPAD TISP TELECOM & INTERNET 5536 119 7 22 Internet Egypt Network 33776 116 6 3 Starcomms Nigeria Limited 5713 114 555 63 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4370 3434 344 bellsouth.net, inc. 209 3019 4032 625 Qwest 6298 2094 327 691 Cox Communicatons 1785 1696 717 155 PaeTec Communications, Inc. 6478 1664 365 196 AT&T Worldnet Services 20115 1662 1452 726 Charter Communications 2386 1591 701 901 AT&T Data Communications Serv 4323 1589 1084 377 Time Warner Telecom 17488 1409 99 106 Hathway IP Over Cable Interne 7018 1406 5869 974 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 3019 2394 Qwest 1785 1696 1541 PaeTec Communications, Inc. 6478 1664 1468 AT&T Worldnet Services 6298 2094 1403 Cox Communicatons 17488 1409 1303 Hathway IP Over Cable Interne 4323 1589 1212 Time Warner Telecom 11492 1214 1198 Cable One 8151 1400 1176 UniNet S.A. de C.V. 18566 1059 1049 Covad Communications 4755 1193 1038 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.52.128.0/19 22561 Digital Teleport, Inc 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:19 /11:53 /12:159 /13:308 /14:547 /15:1077 /16:10156 /17:4457 /18:7687 /19:16553 /20:19396 /21:19150 /22:24122 /23:24829 /24:142451 /25:841 /26:1006 /27:798 /28:93 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2858 4370 bellsouth.net, inc. 6298 2068 2094 Cox Communicatons 209 1739 3019 Qwest 2386 1270 1591 AT&T Data Communications Serv 17488 1199 1409 Hathway IP Over Cable Interne 11492 1190 1214 Cable One 1785 1158 1696 PaeTec Communications, Inc. 6478 1106 1664 AT&T Worldnet Services 18566 1040 1059 Covad Communications 9583 992 1125 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 4:12 8:153 12:2181 13:2 15:21 16:3 17:5 20:35 24:1088 30:1 32:61 38:512 40:92 41:781 43:1 44:2 47:12 52:3 55:3 56:3 57:27 58:515 59:550 60:452 61:1032 62:1121 63:2012 64:3280 65:2433 66:3480 67:1326 68:818 69:2351 70:888 71:138 72:2067 73:2 74:1294 75:167 76:290 77:880 78:520 79:292 80:928 81:844 82:594 83:397 84:586 85:1040 86:505 87:705 88:347 89:1357 90:27 91:1670 92:300 93:980 94:395 95:38 96:88 97:132 98:387 99:15 113:40 114:127 115:150 116:1010 117:406 118:252 119:529 120:103 121:610 122:868 123:445 124:870 125:1229 128:353 129:217 130:137 131:408 132:72 133:9 134:186 135:31 136:223 137:106 138:144 139:85 140:413 141:111 142:392 143:321 144:302 145:51 146:372 147:140 148:601 149:210 150:130 151:210 152:148 153:137 154:10 155:275 156:174 157:301 158:168 159:301 160:272 161:140 162:249 163:135 164:517 165:508 166:363 167:341 168:631 169:154 170:452 171:40 172:10 173:138 174:17 187:18 188:1 189:318 190:2390 192:5825 193:4140 194:3288 195:2626 196:1021 198:3711 199:3309 200:5509 201:1471 202:7679 203:8044 204:3930 205:2180 206:2297 207:2773 208:3727 209:3445 210:2608 211:1093 212:1547 213:1633 214:68 215:25 216:4382 217:1249 218:351 219:426 220:1059 221:419 222:303 End of report -- This is the SANOG (http://www.sanog.org/) mailing list. From sdalberg at marchex.com Fri Nov 14 12:46:44 2008 From: sdalberg at marchex.com (Steve Dalberg) Date: Fri, 14 Nov 2008 10:46:44 -0800 Subject: OSPF with Multiple ABR & ASBR In-Reply-To: <CBE22E5FF427B149A272DD1DDE10752402368B0F@EX2K3.armc.org> References: <d0fea3580811140752x12c4079an12728e4303f67949@mail.gmail.com> <CBE22E5FF427B149A272DD1DDE10752402368B0F@EX2K3.armc.org> Message-ID: <9B4191CF8F73B04BB4F437E1F7F86ED50AD4C266@exchbe1sea.windows.marchex.com> OSPF (on cisco anyway) will balance 6 paths automatically assuming you haven't messed with bandwidth or cost settings, and the paths have the same iftype. If not, setting the bandwidth equally will also do the trick. (I don't like messing with cost directly, just me) I would also point out that you would probably be better off not using a multi-area config for this solution. My rule of thumb, which may be a bit antiquated now, is create multiple areas when you have either more than 2000 routes, or more than 300 interfaces total, or 200 on a single router within a single area. This was just a general rule of thumb based on some problems with certain hardware scaling past that point and behaviors during reconvergence. If you can use a single area, go for it. If you are the type of company that might get acquired someday, or hopes to, you can save yourself time and select an AREA ID that is based on address space you own, that way there will be no AREA ID overlaps and you would have the possibility of connecting to someone else's area 0 (acquiring company). Also, don't use per packet load balancing. It may work in the short term, but it almost always screws with an applications performance. My $0.02. Steve -----Original Message----- From: Darden, Patrick S. [mailto:darden at armc.org] Sent: Friday, November 14, 2008 9:28 AM To: devang patel Cc: nanog at nanog.org Subject: RE: OSPF with Multiple ABR & ASBR It is my understanding of OSPF that, if you have paths with equal distance and cost to a destination, load balancing happens automatically for up to four (or is it 6 for OSPF?) clear paths. In your diagram R1 to R8 load balancing should happen naturally, unless you have weighted one of the paths. You have much more than 4 paths here, so you should weight the ones you want. E.g. 1-2-4-6-8, 1-3-5-7-8 would be the most straightforward, and barring some type of natural concentration of bandwidth (e.g. R3 having 10X the hosts connected that R2 has) it would be the easiest to implement. This only applies to coequal routing (e.g. all links are T1s). If you are doing unequal routing I think you are out of luck. I would stick to two paths if possible for simplicity's sake. OSPF can become a quagmire if you let it. So, first step is weight your chosen paths equally, and make sure they are preferred over other possible paths. Second step is to decide what kind of load balancing you want: per packet, or endpoint. If you set it up per packet, you get equal load balancing with the chance of out-of-order packets on the other end. It can also take up a lot of the router's cpu resources. If you decide on endpoint load balancing you will almost always have one path taking the majority of the traffic--e.g. all traffic to the file sharer will take path1 and all traffic to the ntp server will take path2, and path1 will definitely be more heavily loaded. To properly balance by endpoint takes some micromanagement. Depending on your router, you turn ip route cache on for endpoint balancing, and turn it off to enable per packet balancing. Cisco has something called CEF which I have never used, which supposedly enhances OSPF load balancing--uses special algorithms to speed it up. --p -----Original Message----- From: devang patel [mailto:devangnp at gmail.com] Sent: Friday, November 14, 2008 10:52 AM To: Darden, Patrick S. Cc: nanog at nanog.org Subject: Re: OSPF with Multiple ABR & ASBR Sorry about that!!! 1. Do these remote areas have multiple paths to the central area for failover? E.g. a 10Mbps Metro Ethernet primary link, and a 1.5Mbps DSL secondary? 2. Does the central area have multiple routers for failover? E.g. a Cisco 7200 for the incoming Metro Ethernet primary connections, and a Cisco 3660 for the slower secondary connections? 3. Are there any tie-ins between the remote sites that bypass the central site? E.g. site1 and site2 both communicate to the central site via Metro Ethernet, and they also communicate to eachother via DSL. Answers: I have two T1 line to the non-backbone area and both T1s are terminated to the two different routers on non-backbone area as well as to backbone area, and I dont want to achieve primary and secondary role, I want to go for the load sharing kind of scenario. All sites are connected with the central site. ABR means Area border router only. I am attaching one generalized diagram, please look at that one. Now I want to achieve the load balancing between the traffic going from R1 to R8, I want to achieve some of the networks on R1 should be reachable via R2 and some of them via R3 for the traffic coming from the R8. assume all links are same. regards Devang Patel On Fri, Nov 14, 2008 at 9:29 AM, Patrick Darden < darden at armc.org> wrote: First, without any details, it sounds like you might be better off with static routes than with OSPF. I'm not trying to be patronizing, but you don't mention many details, and some of the details you omit are the crucial ones for OSPF. 1. Do these remote areas have multiple paths to the central area for failover? E.g. a 10Mbps Metro Ethernet primary link, and a 1.5Mbps DSL secondary? 2. Does the central area have multiple routers for failover? E.g. a Cisco 7200 for the incoming Metro Ethernet primary connections, and a Cisco 3660 for the slower secondary connections? 3. Are there any tie-ins between the remote sites that bypass the central site? E.g. site1 and site2 both communicate to the central site via Metro Ethernet, and they also communicate to eachother via DSL. If none of the above are true, then static routes would be better for you (for the remote area/s in question). E.g. area1 has multiple paths, so ospf is warranted; however, area2 has just one path so a static approach would usually be better. Your language seems to indicate that OSPF is warranted (area0, area1, two ABRs). I am assuming you mean Area Border Router not Associative Based Routing (vs. OSPF). I am also assuming this is a non-public system (internal network, probably a MAN or WAN). If so, without any further details, I would set it up for bandwidth/failover. Weight the paths appropriately. Keep it as simple as you can. OSPF can become a morass. If you sketch your situation out more, we can be more helpful.... Campus? MAN? How public? Multi-pathed? Multi-homed? Multiple interlinks? Are there some lines with reliability problems where the lower bandwidth links are actually preferred? Do you have any decentralized concentration points that might have problems due to multiple remote sites shuttling traffic through it (due to multiple interlinks)? --p devang patel wrote: Hi All, I am not sure is this the good place to ask this question or not!!! I am looking for feed back on having OSPF multi-area, lets say if you have multiple location in nonbackbone areas and those nonbackbone areas are connected with the one backbone area. For example: OSPF AREA1 has the connectivity to OSPF AREA0 using two ABR, so what is the optimum way to achieve the load balancing or load sharing for traffic entering or leaving the area, what are the possible way to configure it? regards Devang Patel From cscora at apnic.net Fri Nov 14 12:14:43 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Nov 2008 04:14:43 +1000 (EST) Subject: [SANOG] Weekly Routing Table Report Message-ID: <200811141814.mAEIEhno005952@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <pfs at cisco.com>. Routing Table Report 04:00 +10GMT Sat 15 Nov, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 273747 Prefixes after maximum aggregation: 131698 Deaggregation factor: 2.08 Unique aggregates announced to Internet: 132906 Total ASes present in the Internet Routing Table: 29790 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25923 Origin ASes announcing only one prefix: 12618 Transit ASes present in the Internet Routing Table: 3867 Transit-only ASes present in the Internet Routing Table: 84 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 548 Unregistered ASNs in the Routing Table: 201 Number of 32-bit ASNs allocated by the RIRs: 63 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 210 Number of addresses announced to Internet: 1954643712 Equivalent to 116 /8s, 129 /16s and 127 /24s Percentage of available address space announced: 52.7 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 83.7 Percentage of address space in use by end-sites: 74.3 Total number of prefixes smaller than registry allocations: 134661 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62656 Total APNIC prefixes after maximum aggregation: 23339 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 59566 Unique aggregates announced from the APNIC address blocks: 26910 APNIC Region origin ASes present in the Internet Routing Table: 3459 APNIC Prefixes per ASN: 17.22 APNIC Region origin ASes announcing only one prefix: 932 APNIC Region transit ASes present in the Internet Routing Table: 534 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 381242016 Equivalent to 22 /8s, 185 /16s and 74 /24s Percentage of available APNIC address space announced: 75.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123986 Total ARIN prefixes after maximum aggregation: 64911 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 93363 Unique aggregates announced from the ARIN address blocks: 34747 ARIN Region origin ASes present in the Internet Routing Table: 12583 ARIN Prefixes per ASN: 7.42 ARIN Region origin ASes announcing only one prefix: 4862 ARIN Region transit ASes present in the Internet Routing Table: 1197 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 400498592 Equivalent to 23 /8s, 223 /16s and 31 /24s Percentage of available ARIN address space announced: 82.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 60086 Total RIPE prefixes after maximum aggregation: 36115 RIPE Deaggregation factor: 1.66 Prefixes being announced from the RIPE address blocks: 55709 Unique aggregates announced from the RIPE address blocks: 37297 RIPE Region origin ASes present in the Internet Routing Table: 12184 RIPE Prefixes per ASN: 4.57 RIPE Region origin ASes announcing only one prefix: 6406 RIPE Region transit ASes present in the Internet Routing Table: 1862 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 378515552 Equivalent to 22 /8s, 143 /16s and 176 /24s Percentage of available RIPE address space announced: 86.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22297 Total LACNIC prefixes after maximum aggregation: 5569 LACNIC Deaggregation factor: 4.00 Prefixes being announced from the LACNIC address blocks: 20335 Unique aggregates announced from the LACNIC address blocks: 11386 LACNIC Region origin ASes present in the Internet Routing Table: 1030 LACNIC Prefixes per ASN: 19.74 LACNIC Region origin ASes announcing only one prefix: 339 LACNIC Region transit ASes present in the Internet Routing Table: 170 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 58064256 Equivalent to 3 /8s, 117 /16s and 253 /24s Percentage of available LACNIC address space announced: 57.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4195 Total AfriNIC prefixes after maximum aggregation: 1334 AfriNIC Deaggregation factor: 3.14 Prefixes being announced from the AfriNIC address blocks: 4466 Unique aggregates announced from the AfriNIC address blocks: 2142 AfriNIC Region origin ASes present in the Internet Routing Table: 264 AfriNIC Prefixes per ASN: 16.92 AfriNIC Region origin ASes announcing only one prefix: 79 AfriNIC Region transit ASes present in the Internet Routing Table: 52 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC addresses announced to Internet: 12920064 Equivalent to 0 /8s, 197 /16s and 37 /24s Percentage of available AfriNIC address space announced: 25.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 17488 1409 99 106 Hathway IP Over Cable Interne 4755 1193 485 155 TATA Communications formerly 9583 1125 87 479 Sify Limited 4766 899 6409 363 Korea Telecom (KIX) 4134 898 13872 366 CHINANET-BACKBONE 23577 817 35 702 Korea Telecom (ATM-MPLS) 18101 786 167 31 Reliance Infocom Ltd Internet 4780 731 357 63 Digital United Inc. 9498 689 295 50 BHARTI BT INTERNET LTD. 4808 632 1172 143 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4370 3434 344 bellsouth.net, inc. 209 3019 4032 625 Qwest 6298 2094 327 691 Cox Communicatons 1785 1696 717 155 PaeTec Communications, Inc. 6478 1664 365 196 AT&T Worldnet Services 20115 1662 1452 726 Charter Communications 2386 1591 701 901 AT&T Data Communications Serv 4323 1589 1084 377 Time Warner Telecom 7018 1406 5869 974 AT&T WorldNet Services 11492 1214 166 16 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 429 1766 380 TDC Tele Danmark 12479 366 578 6 Uni2 Autonomous System 30890 366 95 189 SC Kappa Invexim SRL 3301 333 1429 303 TeliaNet Sweden 8866 331 111 23 Bulgarian Telecommunication C 3320 322 7062 271 Deutsche Telekom AG 3215 316 2788 99 France Telecom Transpac 5462 300 794 27 Telewest Broadband 8452 293 188 11 TEDATA 25233 289 44 24 Awalnet Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1400 2832 224 UniNet S.A. de C.V. 11830 670 299 9 Instituto Costarricense de El 10620 557 126 54 TVCABLE BOGOTA 22047 522 270 14 VTR PUNTO NET S.A. 7303 497 244 70 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 422 87 50 ENTEL CHILE S.A. 11172 406 118 72 Servicios Alestra S.A de C.V 28573 343 468 23 NET Servicos de Comunicao S.A 14117 331 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 560 72 45 LINKdotNET AS number 3741 271 857 227 The Internet Solution 20858 260 34 3 EgyNet 2018 238 215 140 Tertiary Education Network 29571 147 13 8 Ci Telecom Autonomous system 6713 144 135 11 Itissalat Al-MAGHRIB 33783 141 10 15 EEPAD TISP TELECOM & INTERNET 5536 119 7 22 Internet Egypt Network 33776 116 6 3 Starcomms Nigeria Limited 5713 114 555 63 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4370 3434 344 bellsouth.net, inc. 209 3019 4032 625 Qwest 6298 2094 327 691 Cox Communicatons 1785 1696 717 155 PaeTec Communications, Inc. 6478 1664 365 196 AT&T Worldnet Services 20115 1662 1452 726 Charter Communications 2386 1591 701 901 AT&T Data Communications Serv 4323 1589 1084 377 Time Warner Telecom 17488 1409 99 106 Hathway IP Over Cable Interne 7018 1406 5869 974 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 3019 2394 Qwest 1785 1696 1541 PaeTec Communications, Inc. 6478 1664 1468 AT&T Worldnet Services 6298 2094 1403 Cox Communicatons 17488 1409 1303 Hathway IP Over Cable Interne 4323 1589 1212 Time Warner Telecom 11492 1214 1198 Cable One 8151 1400 1176 UniNet S.A. de C.V. 18566 1059 1049 Covad Communications 4755 1193 1038 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.52.128.0/19 22561 Digital Teleport, Inc 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:19 /11:53 /12:159 /13:308 /14:547 /15:1077 /16:10156 /17:4457 /18:7687 /19:16553 /20:19396 /21:19150 /22:24122 /23:24829 /24:142451 /25:841 /26:1006 /27:798 /28:93 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2858 4370 bellsouth.net, inc. 6298 2068 2094 Cox Communicatons 209 1739 3019 Qwest 2386 1270 1591 AT&T Data Communications Serv 17488 1199 1409 Hathway IP Over Cable Interne 11492 1190 1214 Cable One 1785 1158 1696 PaeTec Communications, Inc. 6478 1106 1664 AT&T Worldnet Services 18566 1040 1059 Covad Communications 9583 992 1125 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 4:12 8:153 12:2181 13:2 15:21 16:3 17:5 20:35 24:1088 30:1 32:61 38:512 40:92 41:781 43:1 44:2 47:12 52:3 55:3 56:3 57:27 58:515 59:550 60:452 61:1032 62:1121 63:2012 64:3280 65:2433 66:3480 67:1326 68:818 69:2351 70:888 71:138 72:2067 73:2 74:1294 75:167 76:290 77:880 78:520 79:292 80:928 81:844 82:594 83:397 84:586 85:1040 86:505 87:705 88:347 89:1357 90:27 91:1670 92:300 93:980 94:395 95:38 96:88 97:132 98:387 99:15 113:40 114:127 115:150 116:1010 117:406 118:252 119:529 120:103 121:610 122:868 123:445 124:870 125:1229 128:353 129:217 130:137 131:408 132:72 133:9 134:186 135:31 136:223 137:106 138:144 139:85 140:413 141:111 142:392 143:321 144:302 145:51 146:372 147:140 148:601 149:210 150:130 151:210 152:148 153:137 154:10 155:275 156:174 157:301 158:168 159:301 160:272 161:140 162:249 163:135 164:517 165:508 166:363 167:341 168:631 169:154 170:452 171:40 172:10 173:138 174:17 187:18 188:1 189:318 190:2390 192:5825 193:4140 194:3288 195:2626 196:1021 198:3711 199:3309 200:5509 201:1471 202:7679 203:8044 204:3930 205:2180 206:2297 207:2773 208:3727 209:3445 210:2608 211:1093 212:1547 213:1633 214:68 215:25 216:4382 217:1249 218:351 219:426 220:1059 221:419 222:303 End of report -- This is the SANOG (http://www.sanog.org/) mailing list. From swmike at swm.pp.se Fri Nov 14 13:28:47 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 14 Nov 2008 20:28:47 +0100 (CET) Subject: NAT66 and the subscriber prefix length In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC0961B7FB@E03MVZ2-UKDY.domain1.systemhost.net> References: <C0F2465B4F386241A58321C884AC7ECC0961B7FB@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <alpine.DEB.1.10.0811142023410.10993@uplift.swm.pp.se> On Fri, 14 Nov 2008, michael.dillon at bt.com wrote: > Not long ago, ARIN changed the IPv6 policy so that > residential subscribers could be issued with a /56 > instead of the normal /48 assignment. This was done > so that ISPs with large numbers of subscriber sites > would not exhaust their /32 (or larger) allocations > too soon. Since these ISPs are allowed to assign > a /56 to residential subscriber sites, their initial > IPv6 allocation will last a lot longer and they won't > have to apply for an additional allocation while > everyone is getting up to speed with an IPv6 Internet. We returned our /32 for a /25 (with /22 being reserved) and current plan is to hand out /48s to everybody (unless they need even more space, then they'll have to apply). So, doing /56 to end users just because you happen to have a /32 right now sounds like a bad plan, it doesn't take that many hours to get a larger space if you can justify it (which wasn't that hard for us). We received our /32 (as a /35 I think) back in 2000 or so, policy has changed since then, with RIPE it's not that hard to get a much larger space with a long term growth plan. My hope is that we'll make do with this /22 space for at least 5-10 years (67 million customer /48s is quite a lot), unless something really big happens, and then we'll just have to get an even larger space. So message should be that /48 to end users is the way to go, and this should suit residential and SME market without any additional administrative overhead depending on customer size. -- Mikael Abrahamsson email: swmike at swm.pp.se From fred at cisco.com Fri Nov 14 14:55:55 2008 From: fred at cisco.com (Fred Baker) Date: Fri, 14 Nov 2008 12:55:55 -0800 Subject: NAT66 and the subscriber prefix length In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC0961B7FB@E03MVZ2-UKDY.domain1.systemhost.net> References: <C0F2465B4F386241A58321C884AC7ECC0961B7FB@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <51FA4D2B-0E8D-4C74-9420-EE2564E96BD9@cisco.com> Before we get too deeply exercised, let Margaret and I huddle on it. The issue you raised can be trivially solved by adding the checksum offset to a different 16 bits in the address, such as bits 96..127. In fact, the only reason to care which bits it is added to is to handle multi-DMZ sites - multihoming. I'm looking at GSE/NAT66, which may be a very interesting application of the technology... On Nov 14, 2008, at 9:07 AM, <michael.dillon at bt.com> <michael.dillon at bt.com > wrote: > Not long ago, ARIN changed the IPv6 policy so that > residential subscribers could be issued with a /56 > instead of the normal /48 assignment. This was done > so that ISPs with large numbers of subscriber sites > would not exhaust their /32 (or larger) allocations > too soon. Since these ISPs are allowed to assign > a /56 to residential subscriber sites, their initial > IPv6 allocation will last a lot longer and they won't > have to apply for an additional allocation while > everyone is getting up to speed with an IPv6 Internet. > > Now, however, the IETF is discussing a form of NAT > for IPv6 called NAT66. See this draft for details > <http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-01.txt> > Part of this new NAT is that they are checksum neutral. > They do this by modifying bits in the address that are > not needed. Specifically, they assume that the > end site has a /48 allocation, and that the next > 16 bits up to the /64 boundary, are non-essential > information outside the end-site boundary. These > bits are then twiddled to preserve the IPv6 header > checksum. Of course, these are the same bits that > an ISP relies on for reducing the assignment size > to /56. > > I see a potential conflict here. If we assume that NAT66 > will be widely used by consumers, then it follows that > consumer end-sites will need a /48 assignment in order > for IPv6 to work. But some ISPs want to reduce the end > site assignment to /56 meaning that NAT66 won't work for > those consumers. > > Of course, it's not all set in stone yet which is why I > am posting this to NANOG. If ISP's who intend to use > /56 allocations could join in the discussions, then perhaps > we could develop some form of NAT66 that works with /56 > prefix lengths. > > Personally, I would be happy to just see every site > consistently use a /48 assignment. Corporate campus or > one-room studio apartment; it's all the same to me. > > --Michael Dillon > From cscora at apnic.net Fri Nov 14 12:14:43 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Nov 2008 04:14:43 +1000 (EST) Subject: [SANOG] Weekly Routing Table Report Message-ID: <200811141814.mAEIEhno005952@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <pfs at cisco.com>. Routing Table Report 04:00 +10GMT Sat 15 Nov, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 273747 Prefixes after maximum aggregation: 131698 Deaggregation factor: 2.08 Unique aggregates announced to Internet: 132906 Total ASes present in the Internet Routing Table: 29790 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25923 Origin ASes announcing only one prefix: 12618 Transit ASes present in the Internet Routing Table: 3867 Transit-only ASes present in the Internet Routing Table: 84 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 548 Unregistered ASNs in the Routing Table: 201 Number of 32-bit ASNs allocated by the RIRs: 63 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 210 Number of addresses announced to Internet: 1954643712 Equivalent to 116 /8s, 129 /16s and 127 /24s Percentage of available address space announced: 52.7 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 83.7 Percentage of address space in use by end-sites: 74.3 Total number of prefixes smaller than registry allocations: 134661 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62656 Total APNIC prefixes after maximum aggregation: 23339 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 59566 Unique aggregates announced from the APNIC address blocks: 26910 APNIC Region origin ASes present in the Internet Routing Table: 3459 APNIC Prefixes per ASN: 17.22 APNIC Region origin ASes announcing only one prefix: 932 APNIC Region transit ASes present in the Internet Routing Table: 534 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 381242016 Equivalent to 22 /8s, 185 /16s and 74 /24s Percentage of available APNIC address space announced: 75.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123986 Total ARIN prefixes after maximum aggregation: 64911 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 93363 Unique aggregates announced from the ARIN address blocks: 34747 ARIN Region origin ASes present in the Internet Routing Table: 12583 ARIN Prefixes per ASN: 7.42 ARIN Region origin ASes announcing only one prefix: 4862 ARIN Region transit ASes present in the Internet Routing Table: 1197 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 400498592 Equivalent to 23 /8s, 223 /16s and 31 /24s Percentage of available ARIN address space announced: 82.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 60086 Total RIPE prefixes after maximum aggregation: 36115 RIPE Deaggregation factor: 1.66 Prefixes being announced from the RIPE address blocks: 55709 Unique aggregates announced from the RIPE address blocks: 37297 RIPE Region origin ASes present in the Internet Routing Table: 12184 RIPE Prefixes per ASN: 4.57 RIPE Region origin ASes announcing only one prefix: 6406 RIPE Region transit ASes present in the Internet Routing Table: 1862 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 378515552 Equivalent to 22 /8s, 143 /16s and 176 /24s Percentage of available RIPE address space announced: 86.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22297 Total LACNIC prefixes after maximum aggregation: 5569 LACNIC Deaggregation factor: 4.00 Prefixes being announced from the LACNIC address blocks: 20335 Unique aggregates announced from the LACNIC address blocks: 11386 LACNIC Region origin ASes present in the Internet Routing Table: 1030 LACNIC Prefixes per ASN: 19.74 LACNIC Region origin ASes announcing only one prefix: 339 LACNIC Region transit ASes present in the Internet Routing Table: 170 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 58064256 Equivalent to 3 /8s, 117 /16s and 253 /24s Percentage of available LACNIC address space announced: 57.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4195 Total AfriNIC prefixes after maximum aggregation: 1334 AfriNIC Deaggregation factor: 3.14 Prefixes being announced from the AfriNIC address blocks: 4466 Unique aggregates announced from the AfriNIC address blocks: 2142 AfriNIC Region origin ASes present in the Internet Routing Table: 264 AfriNIC Prefixes per ASN: 16.92 AfriNIC Region origin ASes announcing only one prefix: 79 AfriNIC Region transit ASes present in the Internet Routing Table: 52 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC addresses announced to Internet: 12920064 Equivalent to 0 /8s, 197 /16s and 37 /24s Percentage of available AfriNIC address space announced: 25.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 17488 1409 99 106 Hathway IP Over Cable Interne 4755 1193 485 155 TATA Communications formerly 9583 1125 87 479 Sify Limited 4766 899 6409 363 Korea Telecom (KIX) 4134 898 13872 366 CHINANET-BACKBONE 23577 817 35 702 Korea Telecom (ATM-MPLS) 18101 786 167 31 Reliance Infocom Ltd Internet 4780 731 357 63 Digital United Inc. 9498 689 295 50 BHARTI BT INTERNET LTD. 4808 632 1172 143 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4370 3434 344 bellsouth.net, inc. 209 3019 4032 625 Qwest 6298 2094 327 691 Cox Communicatons 1785 1696 717 155 PaeTec Communications, Inc. 6478 1664 365 196 AT&T Worldnet Services 20115 1662 1452 726 Charter Communications 2386 1591 701 901 AT&T Data Communications Serv 4323 1589 1084 377 Time Warner Telecom 7018 1406 5869 974 AT&T WorldNet Services 11492 1214 166 16 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 429 1766 380 TDC Tele Danmark 12479 366 578 6 Uni2 Autonomous System 30890 366 95 189 SC Kappa Invexim SRL 3301 333 1429 303 TeliaNet Sweden 8866 331 111 23 Bulgarian Telecommunication C 3320 322 7062 271 Deutsche Telekom AG 3215 316 2788 99 France Telecom Transpac 5462 300 794 27 Telewest Broadband 8452 293 188 11 TEDATA 25233 289 44 24 Awalnet Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1400 2832 224 UniNet S.A. de C.V. 11830 670 299 9 Instituto Costarricense de El 10620 557 126 54 TVCABLE BOGOTA 22047 522 270 14 VTR PUNTO NET S.A. 7303 497 244 70 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 422 87 50 ENTEL CHILE S.A. 11172 406 118 72 Servicios Alestra S.A de C.V 28573 343 468 23 NET Servicos de Comunicao S.A 14117 331 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 560 72 45 LINKdotNET AS number 3741 271 857 227 The Internet Solution 20858 260 34 3 EgyNet 2018 238 215 140 Tertiary Education Network 29571 147 13 8 Ci Telecom Autonomous system 6713 144 135 11 Itissalat Al-MAGHRIB 33783 141 10 15 EEPAD TISP TELECOM & INTERNET 5536 119 7 22 Internet Egypt Network 33776 116 6 3 Starcomms Nigeria Limited 5713 114 555 63 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4370 3434 344 bellsouth.net, inc. 209 3019 4032 625 Qwest 6298 2094 327 691 Cox Communicatons 1785 1696 717 155 PaeTec Communications, Inc. 6478 1664 365 196 AT&T Worldnet Services 20115 1662 1452 726 Charter Communications 2386 1591 701 901 AT&T Data Communications Serv 4323 1589 1084 377 Time Warner Telecom 17488 1409 99 106 Hathway IP Over Cable Interne 7018 1406 5869 974 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 3019 2394 Qwest 1785 1696 1541 PaeTec Communications, Inc. 6478 1664 1468 AT&T Worldnet Services 6298 2094 1403 Cox Communicatons 17488 1409 1303 Hathway IP Over Cable Interne 4323 1589 1212 Time Warner Telecom 11492 1214 1198 Cable One 8151 1400 1176 UniNet S.A. de C.V. 18566 1059 1049 Covad Communications 4755 1193 1038 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.52.128.0/19 22561 Digital Teleport, Inc 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:19 /11:53 /12:159 /13:308 /14:547 /15:1077 /16:10156 /17:4457 /18:7687 /19:16553 /20:19396 /21:19150 /22:24122 /23:24829 /24:142451 /25:841 /26:1006 /27:798 /28:93 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2858 4370 bellsouth.net, inc. 6298 2068 2094 Cox Communicatons 209 1739 3019 Qwest 2386 1270 1591 AT&T Data Communications Serv 17488 1199 1409 Hathway IP Over Cable Interne 11492 1190 1214 Cable One 1785 1158 1696 PaeTec Communications, Inc. 6478 1106 1664 AT&T Worldnet Services 18566 1040 1059 Covad Communications 9583 992 1125 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 4:12 8:153 12:2181 13:2 15:21 16:3 17:5 20:35 24:1088 30:1 32:61 38:512 40:92 41:781 43:1 44:2 47:12 52:3 55:3 56:3 57:27 58:515 59:550 60:452 61:1032 62:1121 63:2012 64:3280 65:2433 66:3480 67:1326 68:818 69:2351 70:888 71:138 72:2067 73:2 74:1294 75:167 76:290 77:880 78:520 79:292 80:928 81:844 82:594 83:397 84:586 85:1040 86:505 87:705 88:347 89:1357 90:27 91:1670 92:300 93:980 94:395 95:38 96:88 97:132 98:387 99:15 113:40 114:127 115:150 116:1010 117:406 118:252 119:529 120:103 121:610 122:868 123:445 124:870 125:1229 128:353 129:217 130:137 131:408 132:72 133:9 134:186 135:31 136:223 137:106 138:144 139:85 140:413 141:111 142:392 143:321 144:302 145:51 146:372 147:140 148:601 149:210 150:130 151:210 152:148 153:137 154:10 155:275 156:174 157:301 158:168 159:301 160:272 161:140 162:249 163:135 164:517 165:508 166:363 167:341 168:631 169:154 170:452 171:40 172:10 173:138 174:17 187:18 188:1 189:318 190:2390 192:5825 193:4140 194:3288 195:2626 196:1021 198:3711 199:3309 200:5509 201:1471 202:7679 203:8044 204:3930 205:2180 206:2297 207:2773 208:3727 209:3445 210:2608 211:1093 212:1547 213:1633 214:68 215:25 216:4382 217:1249 218:351 219:426 220:1059 221:419 222:303 End of report -- This is the SANOG (http://www.sanog.org/) mailing list. From ge at linuxbox.org Fri Nov 14 17:35:46 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 14 Nov 2008 17:35:46 -0600 (CST) Subject: [funsec] McColo: Major Source of Online Scams andSpamsKnockedOffline (fwd) In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB353390@MERCURY.socrdu.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org><02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com><6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com><DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int><355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com><491B42C4.7080805@wvi.com><DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int><491B58B4.5070906@thewybles.com> <491C1DEF.9070704@gmail.com><491C5845.6090500@nortel.com> <web-21475173@remus.csulb.edu> <8B79B73777E7D544A24BEB8FC50D35DB353390@MERCURY.socrdu.com> Message-ID: <alpine.DEB.0.999999.0811141734320.18346@linuxbox.org> On Fri, 14 Nov 2008, Dave Larter wrote: > I would agree, a tedious drop. The image is from one of our gateways. Spam will be back. The value is that we see networks no longer willing to accept bad apples among them. There are other pros and cons, but if nothing else, it's a moral victory and makes some of us feel good--finally. > -----Original Message----- > From: Matthew Black [mailto:black at csulb.edu] > Sent: Friday, November 14, 2008 10:56 AM > To: NANOG list > Subject: Re: [funsec] McColo: Major Source of Online Scams > andSpamsKnockedOffline (fwd) > > Since McColo, et al., cutting off those miscreant customers > on Wednesday, I've noticed a huge decline in connection > attempts to our e-mail gateways. Even if their efforts are > temporary, the change is quite noticeable. > > matthew black > e-mail postmaster > california state university, long beach > > From frnkblk at iname.com Fri Nov 14 17:41:55 2008 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 14 Nov 2008 17:41:55 -0600 Subject: [funsec] McColo: Major Source of Online Scams and Spams KnockedOffline (fwd) In-Reply-To: <355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org> <02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com> <6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com> <DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int> <355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com> Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAADJtOCiNvtSRYSN2TgHA7xMAQAAAAA=@iname.com> Don't confuse contract enforcement with law enforcement. The word "lynching" or "vigilante" suggests that the enforcer of "justice" is breaking the law. But there's no indication that the service providers who've cut their customers off have done anything but follow the provisions in their contracts. As said elsewhere, contract enforcement is generally more effective. Frank -----Original Message----- From: Jason Ross [mailto:algorythm at gmail.com] Sent: Wednesday, November 12, 2008 1:45 PM To: Nick Newman Cc: nanog at merit.edu; Kee Hinckley Subject: Re: [funsec] McColo: Major Source of Online Scams and Spams KnockedOffline (fwd) On Wed, Nov 12, 2008 at 14:16, Nick Newman <NNewman at nw3c.org> wrote: > How many cops does it take to throw a community lynching? > None. The question that remains is: Why is the community having to resort to lynching? Following the metaphor and using the US "Old West" as an example, lynchings were largely due to one of the following: * a lack of organized law enforcement * a lack of effective law enforcement * an outraged mob following the lead of a few with their own agenda in the heat of some moment I don't think the latter point applies (though some have argued it very much does). The former two points though very much do IMO, and I think this was the point Kee was making. To put it another way: How can we as network operators help law enforcement become more organized and effective such that lynchings are no longer needed? I'm not convinced there's an adequate answer to that question given the current structure of "the internet", and the nature of how things work. ( I suppose there's room in there for an argument that community lynchings are the most effective way to deal with the problems that arise, though I don't think such is the case. ) -- Jason From dave at stayonline.com Fri Nov 14 18:20:32 2008 From: dave at stayonline.com (Dave Larter) Date: Fri, 14 Nov 2008 19:20:32 -0500 Subject: [funsec] McColo: Major Source of Online Scams andSpamsKnockedOffline (fwd) In-Reply-To: <alpine.DEB.0.999999.0811141734320.18346@linuxbox.org> References: <alpine.DEB.0.999999.0811112036560.14483@linuxbox.org><02B4B914-536C-417C-B7A3-6A15894E9E21@somewhere.com><6cd462c00811120953r4eac33bid0c719e96062a168@mail.gmail.com><DF569A62D4A461488173EBE91C043224037C27BE@POSTOFFICE.nw3c.int><355c7d900811121144v77b23a55n41ed14dc2b54f1f@mail.gmail.com><491B42C4.7080805@wvi.com><DF569A62D4A461488173EBE91C043224037C27C1@POSTOFFICE.nw3c.int><491B58B4.5070906@thewybles.com> <491C1DEF.9070704@gmail.com><491C5845.6090500@nortel.com> <web-21475173@remus.csulb.edu> <8B79B73777E7D544A24BEB8FC50D35DB353390@MERCURY.socrdu.com> <alpine.DEB.0.999999.0811141734320.18346@linuxbox.org> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB35344D@MERCURY.socrdu.com> I agree, yes it will, but it was nice to see proven the ability to fight the trash out there. Actually, coincidently I was installing new AV SW on out pub DNS and SMTP gateways the same time they got there plug pulled, I thought I was breaking stuff on my end, but not as the news hit the list a short time after I started updating. And in my previous post I meant tremendous drop. -----Original Message----- From: Gadi Evron [mailto:ge at linuxbox.org] Sent: Friday, November 14, 2008 6:36 PM To: Dave Larter Cc: Matthew Black; NANOG list Subject: RE: [funsec] McColo: Major Source of Online Scams andSpamsKnockedOffline (fwd) On Fri, 14 Nov 2008, Dave Larter wrote: > I would agree, a tedious drop. The image is from one of our gateways. Spam will be back. The value is that we see networks no longer willing to accept bad apples among them. There are other pros and cons, but if nothing else, it's a moral victory and makes some of us feel good--finally. > -----Original Message----- > From: Matthew Black [mailto:black at csulb.edu] > Sent: Friday, November 14, 2008 10:56 AM > To: NANOG list > Subject: Re: [funsec] McColo: Major Source of Online Scams > andSpamsKnockedOffline (fwd) > > Since McColo, et al., cutting off those miscreant customers > on Wednesday, I've noticed a huge decline in connection > attempts to our e-mail gateways. Even if their efforts are > temporary, the change is quite noticeable. > > matthew black > e-mail postmaster > california state university, long beach > > From ask at develooper.com Sat Nov 15 03:25:08 2008 From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Sat, 15 Nov 2008 01:25:08 -0800 Subject: NTP Md5 or AutoKey? In-Reply-To: <92c950310811040311x3a9e4d4an1aaed0465c5cdd3e@mail.gmail.com> References: <92c950310811032215s6dd7710cnd737db17cda7dd8e@mail.gmail.com> <6cd462c00811032223m701e736i89684f8aceeba62@mail.gmail.com> <20081104103009.GA13379@vacation.karoshi.com.> <92c950310811040311x3a9e4d4an1aaed0465c5cdd3e@mail.gmail.com> Message-ID: <05F68E68-D41C-4CD4-AE66-664B80C8536E@develooper.com> On Nov 4, 2008, at 3:11 AM, Glen Kent wrote: > My original question got drowned amidst all this vibrant discussions! > > Do folks already use or plan to use Autokey for NTP? In my experience most people have a hard enough time remembering to run ntp at all (and with an even remotely sane configuration - this is why a sane default using the ntp pool is helpful as a baseline). Add authentication into the mix and many operations will almost certainly just have even more mis-configuration. :-) - ask -- http://develooper.com/ - http://askask.com/ From phil at mindfury.net Sat Nov 15 15:35:28 2008 From: phil at mindfury.net (Philip L.) Date: Sat, 15 Nov 2008 16:35:28 -0500 Subject: Catalyst 6500 High Switch Proc Message-ID: <491F40A0.5060302@mindfury.net> Hello. I've run into a bit of a snag and I hope some folks here may be able to enlighten. From time to time I check the 'sh platform hardware capacity' command on our Catalyst 6509s and have noticed this item: CPU Resources CPU utilization: Module 5 seconds 1 minute 5 minutes 5 RP 1% / 0% 3% 4% 5 SP 82% / 27% 62% 73% This is shown on two 6509 switches that we operate as Core layer devices. This value goes up to 85-90% during periods of peak traffic and I'm concerned that this may be a problem. Checking 'sh proc cpu' is usually 10% or less. I've gone over this document backwards and forwards and none of the situations outlined seem to apply here: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml One thing to note, is that our main ACL for ingress traffic is applied here due to historical reasons. It's roughly 5000 single host entries at present. We also use these devices for NDE. I'm probably missing some other key details, but what could influence the SP like this? Any insight would be appreciated. -- Philip L. From jlewis at lewis.org Sat Nov 15 15:57:38 2008 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 15 Nov 2008 16:57:38 -0500 (EST) Subject: Catalyst 6500 High Switch Proc In-Reply-To: <491F40A0.5060302@mindfury.net> References: <491F40A0.5060302@mindfury.net> Message-ID: <Pine.LNX.4.61.0811151654110.6312@soloth.lewis.org> On Sat, 15 Nov 2008, Philip L. wrote: > I've run into a bit of a snag and I hope some folks here may be able to > enlighten. From time to time I check the 'sh platform hardware capacity' > command on our Catalyst 6509s and have noticed this item: > > CPU Resources > CPU utilization: Module 5 seconds 1 minute 5 minutes > 5 RP 1% / 0% 3% 4% > 5 SP 82% / 27% 62% 73% > > This is shown on two 6509 switches that we operate as Core layer devices. > This value goes up to 85-90% during periods of peak traffic and I'm concerned > that this may be a problem. > > Checking 'sh proc cpu' is usually 10% or less. > > I've gone over this document backwards and forwards and none of the > situations outlined seem to apply here: > http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml > > One thing to note, is that our main ACL for ingress traffic is applied here > due to historical reasons. It's roughly 5000 single host entries at present. > We also use these devices for NDE. This should probably be on cisco-nsp rather than nanog, but... 5000 lines for ACL? I don't have any experience with ACLs of that size, but it sounds like a possible problem. If you're doing netflow export and not doing sampled netflow, I'm guessing this is where your problem is. sh mls netflow table-contention detailed might be able to confirm or rule this out. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From fw at deneb.enyo.de Sat Nov 15 16:05:38 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 15 Nov 2008 23:05:38 +0100 Subject: Catalyst 6500 High Switch Proc In-Reply-To: <Pine.LNX.4.61.0811151654110.6312@soloth.lewis.org> (Jon Lewis's message of "Sat, 15 Nov 2008 16:57:38 -0500 (EST)") References: <491F40A0.5060302@mindfury.net> <Pine.LNX.4.61.0811151654110.6312@soloth.lewis.org> Message-ID: <87od0gfxvx.fsf@mid.deneb.enyo.de> * Jon Lewis: >> I've run into a bit of a snag and I hope some folks here may be able >> to enlighten. From time to time I check the 'sh platform hardware >> capacity' command on our Catalyst 6509s and have noticed this item: MSFC/PFC version is also relevant. > 5000 lines for ACL? I don't have any experience with ACLs of that > size, but it sounds like a possible problem. Yes, but it should be doable. I don't know the commands for the current IOS releases, but "show tcam" (including "show tcam detail") and "show fm interface" were quite helpful for designing ACLs for efficient processing. From phil at mindfury.net Sat Nov 15 16:08:21 2008 From: phil at mindfury.net (Philip L.) Date: Sat, 15 Nov 2008 17:08:21 -0500 Subject: Catalyst 6500 High Switch Proc In-Reply-To: <Pine.LNX.4.61.0811151654110.6312@soloth.lewis.org> References: <491F40A0.5060302@mindfury.net> <Pine.LNX.4.61.0811151654110.6312@soloth.lewis.org> Message-ID: <491F4855.6090405@mindfury.net> This is on a Sup720-3BXL by the way: 'sh mls netflow table-con detailed:' Earl in Module 5 Detailed Netflow CAM (TCAM and ICAM) Utilization ================================================ TCAM Utilization : 100% ICAM Utilization : 6% Netflow TCAM count : 262024 Netflow ICAM count : 8 Netflow Creation Failures : 2085847 Netflow CAM aliases : 0 I had read about this earlier, along with 100% TCAM usage for the FIB, but that wouldn't be the case here, as we're only showing 25% of the FIB TCAM being used. -- Philip L. Jon Lewis wrote: > > This should probably be on cisco-nsp rather than nanog, but... > > 5000 lines for ACL? I don't have any experience with ACLs of that > size, but it sounds like a possible problem. > > If you're doing netflow export and not doing sampled netflow, I'm > guessing this is where your problem is. sh mls netflow > table-contention detailed > might be able to confirm or rule this out. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jgreco at ns.sol.net Sat Nov 15 16:18:47 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 15 Nov 2008 16:18:47 -0600 (CST) Subject: NTP Md5 or AutoKey? In-Reply-To: <05F68E68-D41C-4CD4-AE66-664B80C8536E@develooper.com> from "=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=" at Nov 15, 2008 01:25:08 AM Message-ID: <200811152218.mAFMIlRt090753@aurora.sol.net> > On Nov 4, 2008, at 3:11 AM, Glen Kent wrote: > > My original question got drowned amidst all this vibrant discussions! > > > > Do folks already use or plan to use Autokey for NTP? > > In my experience most people have a hard enough time remembering to > run ntp at all (and with an even remotely sane configuration - this is > why a sane default using the ntp pool is helpful as a baseline). Add > authentication into the mix and many operations will almost certainly > just have even more mis-configuration. :-) One of the things to lament is that it is so hard to find any reasonable examples of how to set up various configurations in a secure manner. There is voluminous documentation. Some of it is dated. Some of it is contradictory. Most of it assumes at least general familiarity with the topic. Accurate time/NTP is, on one hand, fundamentally important to a variety of needs, but on the other hand, is usually implemented just "well enough." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jlewis at lewis.org Sat Nov 15 16:23:23 2008 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 15 Nov 2008 17:23:23 -0500 (EST) Subject: Catalyst 6500 High Switch Proc In-Reply-To: <491F4855.6090405@mindfury.net> References: <491F40A0.5060302@mindfury.net> <Pine.LNX.4.61.0811151654110.6312@soloth.lewis.org> <491F4855.6090405@mindfury.net> Message-ID: <Pine.LNX.4.61.0811151717060.6312@soloth.lewis.org> On Sat, 15 Nov 2008, Philip L. wrote: > This is on a Sup720-3BXL by the way: > > 'sh mls netflow table-con detailed:' > Earl in Module 5 > Detailed Netflow CAM (TCAM and ICAM) Utilization > ================================================ > TCAM Utilization : 100% > ICAM Utilization : 6% > Netflow TCAM count : 262024 > Netflow ICAM count : 8 > Netflow Creation Failures : 2085847 > Netflow CAM aliases : 0 This looks like the same issue I ran into not long ago. Switch your netflow over from full to sampled...you lose lots of data, but your hardware can't handle full netflow for your traffic level. AFAIK, your only other options are to mess with the mls aging timers (shorten them) or buy cards with DFC and hope that gets you enough additional netflow capacity for the interfaces your collecting. http://www.gossamer-threads.com/lists/cisco/nsp/94953 ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From frnkblk at iname.com Sat Nov 15 16:49:16 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 15 Nov 2008 16:49:16 -0600 Subject: hosted PBX/VOIP thru VPN? In-Reply-To: <C3ED3B38-4299-4869-9A0D-443FBAFD31DA@daork.net> References: <041301c9446c$c6a33030$53e99090$@org> <e44ad6640811120339m5eb6a248j171d13c93549393d@mail.gmail.com> <C3ED3B38-4299-4869-9A0D-443FBAFD31DA@daork.net> Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACyDMOPfsERTqJsB9JZziIOAQAAAAA=@iname.com> Nathan hit the nail on the head in his first sentence. With a VPN, if the latency is low enough to allow retransmission of the UDP-based RTP packets before the ATA's jitter buffer is starved, there can definitely be an improvement in audio quality. This was documented in a VoIP testing review that Network Computing performed several years ago. Since most jitter buffers range from 20 to 80 msec (2 to 4 times the sampling size), it's unlikely a hosted PBX with service delivered over the internet would benefit from a VPN. Frank -----Original Message----- From: Nathan Ward [mailto:nanog at daork.net] Sent: Wednesday, November 12, 2008 6:01 AM To: nanog list Subject: Re: hosted PBX/VOIP thru VPN? On 13/11/2008, at 12:39 AM, Aaron Wolfe wrote: > Because the broadband connection was so fast, TCP was able to > repair the impairments without reducing voice quality. " That works fine if latency+window size is low, so that segments are retransmitted quickly. You really should also do the math and factor in the latency that comes from doing something like this, assuming you lose a packet. G. 114 recommends an end to end latency of no more than 150ms for voice applications, where over 400ms is unacceptable (between 150 and 400 you should indicate that performance is not ideal). Finally, some audio codecs work well with fairly high amounts of loss - I'd recommend doing something like that first. iLBC does this really well. G.729 etc. do not - they rely on context, so a single packet lost results in several packets of lost audio (and so, silence). iLBC doesn't rely on context, and quality degrades during packet loss before you get silence. The i stands for Internet - so no surprise it works great in typical Internet conditions. -- Nathan Ward From kloch at kl.net Sat Nov 15 20:53:43 2008 From: kloch at kl.net (Kevin Loch) Date: Sat, 15 Nov 2008 21:53:43 -0500 Subject: Catalyst 6500 High Switch Proc In-Reply-To: <Pine.LNX.4.61.0811151717060.6312@soloth.lewis.org> References: <491F40A0.5060302@mindfury.net> <Pine.LNX.4.61.0811151654110.6312@soloth.lewis.org> <491F4855.6090405@mindfury.net> <Pine.LNX.4.61.0811151717060.6312@soloth.lewis.org> Message-ID: <491F8B37.7070704@kl.net> Jon Lewis wrote: > On Sat, 15 Nov 2008, Philip L. wrote: > >> This is on a Sup720-3BXL by the way: >> >> 'sh mls netflow table-con detailed:' >> Earl in Module 5 >> Detailed Netflow CAM (TCAM and ICAM) Utilization >> ================================================ >> TCAM Utilization : 100% >> ICAM Utilization : 6% >> Netflow TCAM count : 262024 >> Netflow ICAM count : 8 >> Netflow Creation Failures : 2085847 >> Netflow CAM aliases : 0 > > This looks like the same issue I ran into not long ago. Switch your > netflow over from full to sampled...you lose lots of data, but your > hardware can't handle full netflow for your traffic level. > > AFAIK, your only other options are to mess with the mls aging timers > (shorten them) or buy cards with DFC and hope that gets you enough > additional netflow capacity for the interfaces your collecting. > > http://www.gossamer-threads.com/lists/cisco/nsp/94953 Hopefully he is not trying to use netflow for accounting/billing. I use: mls sampling packet-based 1024 8192 As it is a convenient factor of ~1000 from the real numbers. 1Gbit/s of traffic shows up as 1Mbit/s. This has been accurate enough for anything I have wanted to look at like per-AS traffic. - Kevin From fergdawgster at gmail.com Sat Nov 15 21:22:26 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 15 Nov 2008 19:22:26 -0800 Subject: McColo: Are the 'Lights On" at Telia? Message-ID: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If they are, then I sure wish that someone would explain reconnecting McColo: http://www.cidr-report.org/cgi-bin/as-report?as=as26780 With all of the evidence of criminal activity there, I would like to assume that this is just a case of ignorance. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJH5Hiq1pz9mNUZTMRAjJpAKCHaM0OofsH67j44SQPdZAo+3poPQCg4bK0 r32lLCsm//pcaPC91wTmuiA= =QjCr -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Sat Nov 15 22:10:36 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 15 Nov 2008 20:10:36 -0800 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> Message-ID: <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Nov 15, 2008 at 7:22 PM, Paul Ferguson <fergdawgster at gmail.com> wrote: > If they are, then I sure wish that someone would explain reconnecting > McColo: > > http://www.cidr-report.org/cgi-bin/as-report?as=as26780 > > With all of the evidence of criminal activity there, I would like to > assume that this is just a case of ignorance. > > - - ferg > Apparently, the badness is still located in the same SJ Data Center: %traceroute 208.66.194.22 Tracing route to 208.66.194.22 over a maximum of 30 hops 1 2 ms 5 ms 1 ms 208.66.194.22 [snip] 6 14 ms 14 ms 13 ms xe-11-1-0.edge1.sanjose1.level3.net [4.79.43.133 ] 7 14 ms 16 ms 16 ms vlan69.csw1.sanjose1.level3.net [4.68.18.62] 8 21 ms 36 ms 37 ms ae-63-63.ebr3.sanjose1.level3.net [4.69.134.225] 9 24 ms 21 ms 33 ms ae-2.ebr3.losangeles1.level3.net [4.69.132.10] 10 36 ms 21 ms 31 ms ae-73-73.csw2.losangeles1.level3.net [4.69.137.3 8] 11 * 22 ms 27 ms ae-23-79.car3.losangeles1.level3.net [4.68.20.69 ] 12 27 ms 26 ms 41 ms telia-level3-ge.losangeles1.level3.net [4.68.110 .222] 13 35 ms 39 ms 35 ms sjo-bb1-link.telia.net [213.248.80.18] 14 35 ms 36 ms 36 ms giglinx-ic-122068-sjo-bb1.c.telia.net [213.248.8 4.210] 15 35 ms 35 ms 35 ms vl-701.rt02.sjc.mccolo.com [208.66.192.26] 16 * * * Request timed out. 17 * ^C FYI, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJH501q1pz9mNUZTMRAm/xAKCV0zAnL3hQkgrT+i/UANCXGziz5gCfYJLd MXnaUIk8IXy1VBjXD+UDrXw= =+RoU -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From mmc at internode.com.au Sat Nov 15 22:30:18 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 16 Nov 2008 15:00:18 +1030 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> Message-ID: <491FA1DA.7010403@internode.com.au> Is the spam SMTP meant to be originating from the McColo ranges or is it being used to control other machines elsewhere? If they're originating the SPAM then is it sufficient for a transit provider to provide service but block tcp 25/465 etc and make then pass outbound email to something capable of cleaning it? Or are they doing more than just SMTP? Alternatively it seems a strategic advantage for a large amount of spam to originate from a single location with a small range of IP addresses. We could all just block tcp 25/465 at our borders for their ranges and/or just to our mail clusters. Although the last might leave customer mail servers vunerable, but at least no one could accuse us of filtering them (sore point in Oz at the moment!). MMC -- Matthew Moyle-Croft - Internode/Agile - Networks From nanog at daork.net Sat Nov 15 22:35:36 2008 From: nanog at daork.net (Nathan Ward) Date: Sun, 16 Nov 2008 17:35:36 +1300 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <491FA1DA.7010403@internode.com.au> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> <491FA1DA.7010403@internode.com.au> Message-ID: <054D45C4-9991-4805-B3BE-737A3EE40A2C@daork.net> On 16/11/2008, at 5:30 PM, Matthew Moyle-Croft wrote: > Is the spam SMTP meant to be originating from the McColo ranges or > is it being used to control other machines elsewhere? The latter. -- Nathan Ward From fergdawgster at gmail.com Sat Nov 15 22:37:23 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 15 Nov 2008 20:37:23 -0800 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <491FA1DA.7010403@internode.com.au> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> <491FA1DA.7010403@internode.com.au> Message-ID: <6cd462c00811152037v165cc28ar5620ce55eee62eb7@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Nov 15, 2008 at 8:30 PM, Matthew Moyle-Croft <mmc at internode.com.au> wrote: > Is the spam SMTP meant to be originating from the McColo ranges or is it > being used to control other machines elsewhere? > The latter. Also a host of other badness, not just spam: http://hostexploit.com/index.php?option=com_content&view=article&id=12&Item id=15 - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJH6N8q1pz9mNUZTMRAsnXAKClI4BUu8/qAQZ0tebwp0sPhFDWfQCfZV0/ LtUUpvA9GQVHIqs5whc5aQQ= =FG+e -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From jasper at unleash.co.nz Sat Nov 15 22:46:55 2008 From: jasper at unleash.co.nz (Jasper Bryant-Greene) Date: Sun, 16 Nov 2008 17:46:55 +1300 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <6cd462c00811152037v165cc28ar5620ce55eee62eb7@mail.gmail.com> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> <491FA1DA.7010403@internode.com.au> <6cd462c00811152037v165cc28ar5620ce55eee62eb7@mail.gmail.com> Message-ID: <5FF5635E-E537-4C43-9966-2F93FD591E6D@unleash.co.nz> Overall spam levels don't seem to have re-attained their previous lofty heights yet: http://www.spamcop.net/spamgraph.shtml?spamweek http://www.spamcop.net/spamgraph.shtml?spamstats -jasper On 16/11/2008, at 5:37 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, Nov 15, 2008 at 8:30 PM, Matthew Moyle-Croft <mmc at internode.com.au > > > wrote: > >> Is the spam SMTP meant to be originating from the McColo ranges or >> is it >> being used to control other machines elsewhere? >> > > The latter. > > Also a host of other badness, not just spam: > > http://hostexploit.com/index.php?option=com_content&view=article&id=12&Item > id=15 > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFJH6N8q1pz9mNUZTMRAsnXAKClI4BUu8/qAQZ0tebwp0sPhFDWfQCfZV0/ > LtUUpvA9GQVHIqs5whc5aQQ= > =FG+e > -----END PGP SIGNATURE----- > > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > -- Jasper Bryant-Greene Network Engineer, Unleash ddi: +64 3 978 1222 mob: +64 21 129 9458 From mmc at internode.com.au Sat Nov 15 22:52:11 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 16 Nov 2008 15:22:11 +1030 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <6cd462c00811152037v165cc28ar5620ce55eee62eb7@mail.gmail.com> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> <491FA1DA.7010403@internode.com.au> <6cd462c00811152037v165cc28ar5620ce55eee62eb7@mail.gmail.com> Message-ID: <491FA6FB.50309@internode.com.au> Thanks for that Paul, It's a pity - the slightly hazy Sunday afternoon brain was hoping, for once, for an easy fix! MMC Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, Nov 15, 2008 at 8:30 PM, Matthew Moyle-Croft <mmc at internode.com.au> > wrote: > > >> Is the spam SMTP meant to be originating from the McColo ranges or is it >> being used to control other machines elsewhere? >> >> > > The latter. > > Also a host of other badness, not just spam: > > http://hostexploit.com/index.php?option=com_content&view=article&id=12&Item > id=15 > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFJH6N8q1pz9mNUZTMRAsnXAKClI4BUu8/qAQZ0tebwp0sPhFDWfQCfZV0/ > LtUUpvA9GQVHIqs5whc5aQQ= > =FG+e > -----END PGP SIGNATURE----- > > > > -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From fergdawgster at gmail.com Sat Nov 15 22:57:26 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 15 Nov 2008 20:57:26 -0800 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <5FF5635E-E537-4C43-9966-2F93FD591E6D@unleash.co.nz> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> <491FA1DA.7010403@internode.com.au> <6cd462c00811152037v165cc28ar5620ce55eee62eb7@mail.gmail.com> <5FF5635E-E537-4C43-9966-2F93FD591E6D@unleash.co.nz> Message-ID: <6cd462c00811152057y2c88b991hc27bdfffddffe58f@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Nov 15, 2008 at 8:46 PM, Jasper Bryant-Greene <jasper at unleash.co.nz> wrote: > Overall spam levels don't seem to have re-attained their previous lofty > heights yet: > > http://www.spamcop.net/spamgraph.shtml?spamweek > http://www.spamcop.net/spamgraph.shtml?spamstats > Not yet, no -- I suspect they have priorities at the moment. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJH6gsq1pz9mNUZTMRAmDSAKDkozgJWasjUxGoU6znRtFrnP2j8gCgjaWa NCfHK92EsP9DPdnGn0hFozc= =TeXa -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From clewis at nortel.com Sat Nov 15 23:07:34 2008 From: clewis at nortel.com (Chris Lewis) Date: Sun, 16 Nov 2008 00:07:34 -0500 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <491FA1DA.7010403@internode.com.au> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> <491FA1DA.7010403@internode.com.au> Message-ID: <491FAA96.9020902@nortel.com> Matthew Moyle-Croft wrote: > Is the spam SMTP meant to be originating from the McColo ranges or is it > being used to control other machines elsewhere? On the spam front, it's mostly command and control connections inbound from infected machines to McColo-based controllers. Hence, unless you can "watch" an infected machine in your own netblock, you don't know that it is being controlled from McColo. A transit provider could port block the inbound traffic, if they knew the ports, but that would presume that the BOTs don't try to get around that. And we do know that some BOTs can get around that. Secondly, from the transit provider's perspective, an outright depeer is probably easier to defend than selective (and probably having to be "secret") firewalling. If they're connected again, at least some of the Botnets don't seem to be back in full operation yet. Ozdok/Mega-D and Rustock doesn't seem to have started recovery (well over 95% down). Srizbi showed some brief renewed activity 12-24 hours ago (perhaps 10% of its former glory), but seemingly nothing since. > Alternatively it seems a strategic advantage for a large amount of spam > to originate from a single location with a small range of IP > addresses. We could all just block tcp 25/465 at our borders for their > ranges and/or just to our mail clusters. Although the last might leave > customer mail servers vunerable, but at least no one could accuse us of > filtering them (sore point in Oz at the moment!). The difficulty is that local blocking is only useful to block C&C communications from infected machine in _your_ netblock. It doesn't at all stop inbound port 25 connections from infected machines elsewhere. In some limited cases, you might see a benefit to blocking DNS queries from their netblocks. Some "spam-by-compromised-machine" mechanisms have the C&C doing the MX lookups for the victims. Mostly because the "compromised machine" is merely a proxy, and _can't_ do the MXes. I doubt these BOTnet C&Cs do. More efficient to have the BOTs themselves doing it. From mmc at internode.com.au Sat Nov 15 23:15:17 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 16 Nov 2008 15:45:17 +1030 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <491FAA96.9020902@nortel.com> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> <491FA1DA.7010403@internode.com.au> <491FAA96.9020902@nortel.com> Message-ID: <491FAC65.4070108@internode.com.au> Chris Lewis wrote: > Matthew Moyle-Croft wrote: > > > The difficulty is that local blocking is only useful to block C&C > communications from infected machine in _your_ netblock. It doesn't at > all stop inbound port 25 connections from infected machines elsewhere. > Yeah - got it. It's Sunday afternoon here ... I got all hopeful it might be easy. > In some limited cases, you might see a benefit to blocking DNS queries > from their netblocks. Some "spam-by-compromised-machine" mechanisms > have the C&C doing the MX lookups for the victims. Mostly because the > "compromised machine" is merely a proxy, and _can't_ do the MXes. I > doubt these BOTnet C&Cs do. More efficient to have the BOTs themselves > doing it. > Actually, it's a pity the compromised machines don't do DNS - then you'd be able to do some interesting things with resolvers and looking for MX lookup abnormalities. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From justin at justinshore.com Sat Nov 15 23:18:43 2008 From: justin at justinshore.com (Justin Shore) Date: Sat, 15 Nov 2008 23:18:43 -0600 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> Message-ID: <491FAD33.5080902@justinshore.com> If we all dropped routes from 26780 at the edge, I wonder how long it would be before their prefixes popped up somewhere else. Justin Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, Nov 15, 2008 at 7:22 PM, Paul Ferguson <fergdawgster at gmail.com> > wrote: > >> If they are, then I sure wish that someone would explain reconnecting >> McColo: >> >> http://www.cidr-report.org/cgi-bin/as-report?as=as26780 >> >> With all of the evidence of criminal activity there, I would like to >> assume that this is just a case of ignorance. >> >> - - ferg >> > > Apparently, the badness is still located in the same SJ Data Center: > > %traceroute 208.66.194.22 > > Tracing route to 208.66.194.22 over a maximum of 30 hops > > 1 2 ms 5 ms 1 ms 208.66.194.22 > > [snip] > > 6 14 ms 14 ms 13 ms xe-11-1-0.edge1.sanjose1.level3.net > [4.79.43.133 > ] > 7 14 ms 16 ms 16 ms vlan69.csw1.sanjose1.level3.net > [4.68.18.62] > 8 21 ms 36 ms 37 ms ae-63-63.ebr3.sanjose1.level3.net > [4.69.134.225] > > 9 24 ms 21 ms 33 ms ae-2.ebr3.losangeles1.level3.net > [4.69.132.10] > 10 36 ms 21 ms 31 ms ae-73-73.csw2.losangeles1.level3.net > [4.69.137.3 > 8] > 11 * 22 ms 27 ms ae-23-79.car3.losangeles1.level3.net > [4.68.20.69 > ] > 12 27 ms 26 ms 41 ms telia-level3-ge.losangeles1.level3.net > [4.68.110 > .222] > 13 35 ms 39 ms 35 ms sjo-bb1-link.telia.net [213.248.80.18] > 14 35 ms 36 ms 36 ms giglinx-ic-122068-sjo-bb1.c.telia.net > [213.248.8 > 4.210] > 15 35 ms 35 ms 35 ms vl-701.rt02.sjc.mccolo.com [208.66.192.26] > 16 * * * Request timed out. > 17 * ^C > > FYI, > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFJH501q1pz9mNUZTMRAm/xAKCV0zAnL3hQkgrT+i/UANCXGziz5gCfYJLd > MXnaUIk8IXy1VBjXD+UDrXw= > =+RoU > -----END PGP SIGNATURE----- > > From hank at efes.iucc.ac.il Sun Nov 16 01:42:24 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 16 Nov 2008 09:42:24 +0200 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.co m> Message-ID: <5.1.0.14.2.20081116094048.00abd9f0@efes.iucc.ac.il> At 07:22 PM 15-11-08 -0800, Paul Ferguson wrote: >If they are, then I sure wish that someone would explain reconnecting >McColo: > >http://www.cidr-report.org/cgi-bin/as-report?as=as26780 > >With all of the evidence of criminal activity there, I would like to assume >that this is just a case of ignorance. Some West Coast Telia salesman just hit his 2008 quota and is sitting home happy on Sunday. What don't you understand here? :-) -Hank From fergdawgster at gmail.com Sun Nov 16 11:26:54 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sun, 16 Nov 2008 09:26:54 -0800 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> Message-ID: <6cd462c00811160926o32e62084uded670ea08b2a93b@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks to some good folks in Telia, McColo has been de-peered (again): 26780 MCCOLO - McColo Corporation Adjacency: 1 Upstream: 1 Downstream: 0 Upstream Adjacent AS list AS1299 TELIANET TeliaNet Global Network NOT Announced This AS is not currently used to announce prefixes in the global routing table, nor is it used as a visible transit AS. Prefixes added and withdrawn by this origin AS in the past 7 days. - 208.66.192.0/22 Withdrawn - 208.72.168.0/21 Withdrawn - 208.72.173.0/24 Withdrawn - - ferg On Sat, Nov 15, 2008 at 8:10 PM, Paul Ferguson <fergdawgster at gmail.com> wrote: > >> If they are, then I sure wish that someone would explain reconnecting >> McColo: >> >> http://www.cidr-report.org/cgi-bin/as-report?as=as26780 >> >> With all of the evidence of criminal activity there, I would like to >> assume that this is just a case of ignorance. >> >> - - ferg >> > > Apparently, the badness is still located in the same SJ Data Center: > > %traceroute 208.66.194.22 > > Tracing route to 208.66.194.22 over a maximum of 30 hops > > 1 2 ms 5 ms 1 ms 208.66.194.22 > > [snip] > > 6 14 ms 14 ms 13 ms xe-11-1-0.edge1.sanjose1.level3.net > [4.79.43.133 > ] > 7 14 ms 16 ms 16 ms vlan69.csw1.sanjose1.level3.net > [4.68.18.62] > 8 21 ms 36 ms 37 ms ae-63-63.ebr3.sanjose1.level3.net > [4.69.134.225] > > 9 24 ms 21 ms 33 ms ae-2.ebr3.losangeles1.level3.net > [4.69.132.10] > 10 36 ms 21 ms 31 ms ae-73-73.csw2.losangeles1.level3.net > [4.69.137.3 > 8] > 11 * 22 ms 27 ms ae-23-79.car3.losangeles1.level3.net > [4.68.20.69 > ] > 12 27 ms 26 ms 41 ms telia-level3-ge.losangeles1.level3.net > [4.68.110 > .222] > 13 35 ms 39 ms 35 ms sjo-bb1-link.telia.net [213.248.80.18] > 14 35 ms 36 ms 36 ms giglinx-ic-122068-sjo-bb1.c.telia.net > [213.248.8 > 4.210] > 15 35 ms 35 ms 35 ms vl-701.rt02.sjc.mccolo.com > [208.66.192.26] > 16 * * * Request timed out. > 17 * ^C > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJIFfVq1pz9mNUZTMRAgyNAKCt71zumjM7kMgrq2ibOWhdYIWINgCcCZWP 29hL6xxLNdyrwbPMh+JLN5E= =ARyx -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From mike-nanog at tiedyenetworks.com Sun Nov 16 12:10:20 2008 From: mike-nanog at tiedyenetworks.com (mike) Date: Sun, 16 Nov 2008 10:10:20 -0800 Subject: godaddy spam / abuse suspensions? Message-ID: <4920620C.1000304@tiedyenetworks.com> Hi gang, I am looking into a dns problem. My resolvers are attempting to resolve various hosts under "axonplatform.net", but it's nameservers aren't responding, resulting in many many many repeated queries that end up going nowhere. I dug around a bit and the nameservers for the domain are "ns1.suspended-for.spam-and-abuse.com." and so forth. The domain registrar is godaddy and it doesn't make a whole lot of sense for them to point the nameservers for any domain at non-functioning hosts, and these have been dead for at least a few days now that I know about. Can anyone enlighten me as to what the deal might be here? Thank you. rslv1:~# dig -t ns axonplatform.net. ; <<>> DiG 9.2.4 <<>> -t ns axonplatform.net. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42266 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;axonplatform.net. IN NS ;; ANSWER SECTION: axonplatform.net. 114343 IN NS ns1.suspended-for.spam-and-abuse.com. axonplatform.net. 114343 IN NS ns2.suspended-for.spam-and-abuse.com. ;; Query time: 0 msec ;; SERVER: 65.127.32.36#53(65.127.32.36) ;; WHEN: Sun Nov 16 18:12:00 2008 ;; MSG SIZE rcvd: 102 From rohan at rs3net.net Sun Nov 16 12:19:24 2008 From: rohan at rs3net.net (Rohan Sheth) Date: Sun, 16 Nov 2008 10:19:24 -0800 Subject: godaddy spam / abuse suspensions? In-Reply-To: <4920620C.1000304@tiedyenetworks.com> References: <4920620C.1000304@tiedyenetworks.com> Message-ID: <20081116101924.3db7bd1b@supernova> Name has been suspended for "supposed" abuse by the godaddy abuse team. I believe the only recourse is to email abuse at godaddy.com (cc president at godaddy.com) asking what they want to release the domain to you. I believe the usual charge is like $75 or so. --Rohan On Sun, 16 Nov 2008 10:10:20 -0800 mike <mike-nanog at tiedyenetworks.com> wrote: > Hi gang, > > I am looking into a dns problem. My resolvers are attempting to > resolve various hosts under "axonplatform.net", but it's nameservers > aren't responding, resulting in many many many repeated queries that > end up going nowhere. I dug around a bit and the nameservers for the > domain are "ns1.suspended-for.spam-and-abuse.com." and so forth. The > domain registrar is godaddy and it doesn't make a whole lot of sense > for them to point the nameservers for any domain at non-functioning > hosts, and these have been dead for at least a few days now that I > know about. > > Can anyone enlighten me as to what the deal might be here? > > Thank you. > > > rslv1:~# dig -t ns axonplatform.net. > > ; <<>> DiG 9.2.4 <<>> -t ns axonplatform.net. > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42266 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;axonplatform.net. IN NS > > ;; ANSWER SECTION: > axonplatform.net. 114343 IN NS > ns1.suspended-for.spam-and-abuse.com. > axonplatform.net. 114343 IN NS > ns2.suspended-for.spam-and-abuse.com. > > ;; Query time: 0 msec > ;; SERVER: 65.127.32.36#53(65.127.32.36) > ;; WHEN: Sun Nov 16 18:12:00 2008 > ;; MSG SIZE rcvd: 102 > > From kuenzler at init7.net Sun Nov 16 12:35:21 2008 From: kuenzler at init7.net (Fredy Kuenzler) Date: Sun, 16 Nov 2008 19:35:21 +0100 Subject: McColo: Are the 'Lights On" at Telia? In-Reply-To: <6cd462c00811160926o32e62084uded670ea08b2a93b@mail.gmail.com> References: <6cd462c00811151922i34beb371o9b7fa203cf2f4d60@mail.gmail.com> <6cd462c00811152010m41888fafq874a96679b4266ce@mail.gmail.com> <6cd462c00811160926o32e62084uded670ea08b2a93b@mail.gmail.com> Message-ID: <492067E9.1090903@init7.net> Paul Ferguson schrieb: > Thanks to some good folks in Telia, McColo has been de-peered > (again): > > 26780 MCCOLO - McColo Corporation > > Adjacency: 1 Upstream: 1 Downstream: 0 > Upstream Adjacent AS list > AS1299 TELIANET TeliaNet Global Network > > NOT Announced > > This AS is not currently used to announce prefixes in the global > routing table, nor is it used as a visible transit AS. > > Prefixes added and withdrawn by this origin AS in the past 7 days. > > - 208.66.192.0/22 Withdrawn > - 208.72.168.0/21 Withdrawn > - 208.72.173.0/24 Withdrawn I was wondering why I still saw routes from McColo AS26780, and I noticed that we picked up the routes via the Any2 LAX routeserver. They still seem to be connected to Any2 LAX, even though they are no longer listed. I applied now filters and set the community 19996:26780 to avoid the annoucement of our routes towards them. Maybe someone at CRG West could pull their plug, too. -- Fredy K?nzler Init Seven AG, AS13030 From mysidia at gmail.com Sun Nov 16 15:29:22 2008 From: mysidia at gmail.com (James Hess) Date: Sun, 16 Nov 2008 15:29:22 -0600 Subject: godaddy spam / abuse suspensions? In-Reply-To: <20081116101924.3db7bd1b@supernova> References: <4920620C.1000304@tiedyenetworks.com> <20081116101924.3db7bd1b@supernova> Message-ID: <6eb799ab0811161329y3123ffc3iebad0dd4e4d1d1d2@mail.gmail.com> I don't think he wants the domain. The problem is Godaddy listing NS records for some domains (for any reason) to only DNS servers that were all down or didn't exist. The entry of only lame DNS servers is an inconclusive situation and doesn't let a message be permanently rejected as spam; it's indistinguishable from a temporary failure of all that domain's DNS servers. It also causes (hopefully non-fatal) problems for hosts looking up the contacting host's ip, like wasteful repeated queries. This is not good behavior on the registrar's part; Godaddy would almost be better seving the internet community by ignoring spam and doing nothing, or forwarding reports to ISPs rather than introducing lame DNS zones. Registrars aren't really in a place to be able to stop spam; the spammer can simply use any domain or have their reverse zone changed accordingly, if they have custom reverse. But for a registrar to do their best.. by pulling domains where they have proof the owner has performed or authorized spam, they should pull the domain from the TLD zone entirely and let the response be NXDOMAIN. A NXDOMAIN response allows the mail server to definitively reject the message and move on. -- -J On Sun, Nov 16, 2008 at 12:19 PM, Rohan Sheth <rohan at rs3net.net> wrote: > Name has been suspended for "supposed" abuse by the godaddy abuse team. > > I believe the only recourse is to email abuse at godaddy.com (cc > president at godaddy.com) asking what they want to release the domain to > you. I believe the usual charge is like $75 or so. > > --Rohan > From andrew.fried at gmail.com Sun Nov 16 16:38:50 2008 From: andrew.fried at gmail.com (Andrew Fried) Date: Sun, 16 Nov 2008 17:38:50 -0500 Subject: godaddy spam / abuse suspensions? In-Reply-To: <6eb799ab0811161329y3123ffc3iebad0dd4e4d1d1d2@mail.gmail.com> References: <4920620C.1000304@tiedyenetworks.com> <20081116101924.3db7bd1b@supernova> <6eb799ab0811161329y3123ffc3iebad0dd4e4d1d1d2@mail.gmail.com> Message-ID: <4920A0FA.9070409@gmail.com> Chances are if the domain has been sandboxed, it was because it was involved in some kind of phishing scheme, not spam. This is the typicaly way of mitigating fast flux botnets. So I don't agree with the assessment that this is bad behavior on the part of GoDaddy - to the contrary, they are acting quite responsibly. AF James Hess wrote: > I don't think he wants the domain. The problem is Godaddy listing NS > records for some domains (for any reason) to only DNS servers that > were all down or didn't exist. The entry of only lame DNS servers is > an inconclusive situation and doesn't let a message be permanently > rejected as spam; it's indistinguishable from a temporary failure of > all that domain's DNS servers. > > It also causes (hopefully non-fatal) problems for hosts looking up the > contacting host's ip, > like wasteful repeated queries. > > This is not good behavior on the registrar's part; Godaddy would > almost be better seving > the internet community by ignoring spam and doing nothing, or > forwarding reports to ISPs rather than introducing lame DNS zones. > > > Registrars aren't really in a place to be able to stop spam; the > spammer can simply use any domain or have their reverse zone changed > accordingly, if they have custom reverse. > > But for a registrar to do their best.. by pulling domains where they > have proof the owner has performed or authorized spam, they should > pull the domain from the TLD zone entirely and let the response be > NXDOMAIN. > > A NXDOMAIN response allows the mail server to definitively reject the message > and move on. > > > -- > -J > > On Sun, Nov 16, 2008 at 12:19 PM, Rohan Sheth <rohan at rs3net.net> wrote: > >> Name has been suspended for "supposed" abuse by the godaddy abuse team. >> >> I believe the only recourse is to email abuse at godaddy.com (cc >> president at godaddy.com) asking what they want to release the domain to >> you. I believe the usual charge is like $75 or so. >> >> --Rohan >> >> > > > -- Andrew Fried andrew.fried at gmail.com From mysidia at gmail.com Sun Nov 16 16:50:27 2008 From: mysidia at gmail.com (James Hess) Date: Sun, 16 Nov 2008 16:50:27 -0600 Subject: godaddy spam / abuse suspensions? In-Reply-To: <4920A0FA.9070409@gmail.com> References: <4920620C.1000304@tiedyenetworks.com> <20081116101924.3db7bd1b@supernova> <6eb799ab0811161329y3123ffc3iebad0dd4e4d1d1d2@mail.gmail.com> <4920A0FA.9070409@gmail.com> Message-ID: <6eb799ab0811161450r3b4f6febga3054b45da76181b@mail.gmail.com> It's also not effective in various situations. The bad behavior is not disabling abused domains, it's the method used to do it (by giving no answer instead of actively giving a negative answer). When a http client asks recursive resolver A for an A RR, and no response is received, the client will then go to recursive resolver B and make the very same query again, and possibly on to recursive resolver C. One of the secondary/tertiary recursive resolvers may hand the client a cached response that had been obtained before the registrar took any action. If instead recursive resolver A returned a NXDOMAIN, that would be the end of it, no new queries, the answer has returned name does not exist. The impact of the additional queries can be significant as well. -- -J On Sun, Nov 16, 2008 at 4:38 PM, Andrew Fried <andrew.fried at gmail.com> wrote: > Chances are if the domain has been sandboxed, it was because it was > involved in some kind of phishing scheme, not spam. This is the > typicaly way of mitigating fast flux botnets. So I don't agree with the > assessment that this is bad behavior on the part of GoDaddy - to the > contrary, they are acting quite responsibly. > > AF > From ops.lists at gmail.com Sun Nov 16 17:45:14 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 17 Nov 2008 05:15:14 +0530 Subject: godaddy spam / abuse suspensions? In-Reply-To: <6eb799ab0811161450r3b4f6febga3054b45da76181b@mail.gmail.com> References: <4920620C.1000304@tiedyenetworks.com> <20081116101924.3db7bd1b@supernova> <6eb799ab0811161329y3123ffc3iebad0dd4e4d1d1d2@mail.gmail.com> <4920A0FA.9070409@gmail.com> <6eb799ab0811161450r3b4f6febga3054b45da76181b@mail.gmail.com> Message-ID: <bb0e440a0811161545w28dc089aj2a9d629b190dc80a@mail.gmail.com> On Mon, Nov 17, 2008 at 4:20 AM, James Hess <mysidia at gmail.com> wrote: > One of the secondary/tertiary recursive resolvers may hand the client > a cached response that had been obtained before the registrar took any > action. Yes, and that'd make a good case for the good old ops practice of dialing down the TTL for a while before any NS change is made. --srs From jerj at coplanar.net Sun Nov 16 18:02:49 2008 From: jerj at coplanar.net (Jeremy Jackson) Date: Sun, 16 Nov 2008 19:02:49 -0500 Subject: godaddy spam / abuse suspensions? In-Reply-To: <bb0e440a0811161545w28dc089aj2a9d629b190dc80a@mail.gmail.com> References: <4920620C.1000304@tiedyenetworks.com> <20081116101924.3db7bd1b@supernova> <6eb799ab0811161329y3123ffc3iebad0dd4e4d1d1d2@mail.gmail.com> <4920A0FA.9070409@gmail.com> <6eb799ab0811161450r3b4f6febga3054b45da76181b@mail.gmail.com> <bb0e440a0811161545w28dc089aj2a9d629b190dc80a@mail.gmail.com> Message-ID: <1226880169.6912.321.camel@ragnarok> or how about using an NS that returns ICMP errors instead of NXDOMAIN, perhaps using anycast for reducing network load? Would that stop the timeout errors? server is still lame, you just know faster? On Mon, 2008-11-17 at 05:15 +0530, Suresh Ramasubramanian wrote: > On Mon, Nov 17, 2008 at 4:20 AM, James Hess <mysidia at gmail.com> wrote: > > One of the secondary/tertiary recursive resolvers may hand the client > > a cached response that had been obtained before the registrar took any > > action. > > Yes, and that'd make a good case for the good old ops practice of > dialing down the TTL for a while before any NS change is made. > > --srs > -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net jerj at coplanar.net From Mark_Andrews at isc.org Sun Nov 16 21:12:30 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Mon, 17 Nov 2008 14:12:30 +1100 Subject: godaddy spam / abuse suspensions? In-Reply-To: Your message of "Sun, 16 Nov 2008 19:02:49 CDT." <1226880169.6912.321.camel@ragnarok> Message-ID: <200811170312.mAH3CUfg016387@drugs.dv.isc.org> In message <1226880169.6912.321.camel at ragnarok>, Jeremy Jackson writes: > or how about using an NS that returns ICMP errors instead of NXDOMAIN, > perhaps using anycast for reducing network load? ICMP is not particularly useful unless the nameserver uses connected sockets. Now that randomised ports are used this well may be true but there are still lots of nameservers that don't see the ICMP message even it makes it past the firewalls. > Would that stop the timeout errors? server is still lame, you just know > faster? > > On Mon, 2008-11-17 at 05:15 +0530, Suresh Ramasubramanian wrote: > > On Mon, Nov 17, 2008 at 4:20 AM, James Hess <mysidia at gmail.com> wrote: > > > One of the secondary/tertiary recursive resolvers may hand the client > > > a cached response that had been obtained before the registrar took any > > > action. > > > > Yes, and that'd make a good case for the good old ops practice of > > dialing down the TTL for a while before any NS change is made. > > > > --srs > > > -- > Jeremy Jackson > Coplanar Networks > (519)489-4903 > http://www.coplanar.net > jerj at coplanar.net > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From Skywing at valhallalegends.com Sun Nov 16 22:22:05 2008 From: Skywing at valhallalegends.com (Skywing) Date: Sun, 16 Nov 2008 22:22:05 -0600 Subject: godaddy spam / abuse suspensions? In-Reply-To: <1226880169.6912.321.camel@ragnarok> References: <4920620C.1000304@tiedyenetworks.com> <20081116101924.3db7bd1b@supernova> <6eb799ab0811161329y3123ffc3iebad0dd4e4d1d1d2@mail.gmail.com> <4920A0FA.9070409@gmail.com> <6eb799ab0811161450r3b4f6febga3054b45da76181b@mail.gmail.com> <bb0e440a0811161545w28dc089aj2a9d629b190dc80a@mail.gmail.com> <1226880169.6912.321.camel@ragnarok> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BEF9369138@caralain.haven.nynaeve.net> Why not just return NXDOMAIN if you are going to all of that trouble and be guaranteed that it'll work for standards-compliant caching resolvers? I don't see what would be available to gain by adding this extra complexity, and there's certainly a (much) lesser guarantee, or so I would tend to believe, that things will stop asking if they get an ICMP unreach as opposed to an NXDOMAIN. - S -----Original Message----- From: Jeremy Jackson [mailto:jerj at coplanar.net] Sent: Sunday, November 16, 2008 7:03 PM To: Suresh Ramasubramanian Cc: nanog at nanog.org Subject: Re: godaddy spam / abuse suspensions? or how about using an NS that returns ICMP errors instead of NXDOMAIN, perhaps using anycast for reducing network load? Would that stop the timeout errors? server is still lame, you just know faster? On Mon, 2008-11-17 at 05:15 +0530, Suresh Ramasubramanian wrote: > On Mon, Nov 17, 2008 at 4:20 AM, James Hess <mysidia at gmail.com> wrote: > > One of the secondary/tertiary recursive resolvers may hand the client > > a cached response that had been obtained before the registrar took any > > action. > > Yes, and that'd make a good case for the good old ops practice of > dialing down the TTL for a while before any NS change is made. > > --srs > -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net jerj at coplanar.net From lyndon at orthanc.ca Mon Nov 17 00:32:39 2008 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 16 Nov 2008 22:32:39 -0800 Subject: Rogers cluefuls Message-ID: <647F43DF-BDF7-49E4-A7FB-CA619FE7DEB7@orthanc.ca> Anyone from Rogers out there that can help me with port 587 proxy insanity? (Don't give me the 1-8xx numbers, thank you.) From jerj at coplanar.net Mon Nov 17 10:00:11 2008 From: jerj at coplanar.net (Jeremy Jackson) Date: Mon, 17 Nov 2008 11:00:11 -0500 Subject: godaddy spam / abuse suspensions? In-Reply-To: <bb0e440a0811161545w28dc089aj2a9d629b190dc80a@mail.gmail.com> References: <4920620C.1000304@tiedyenetworks.com> <20081116101924.3db7bd1b@supernova> <6eb799ab0811161329y3123ffc3iebad0dd4e4d1d1d2@mail.gmail.com> <4920A0FA.9070409@gmail.com> <6eb799ab0811161450r3b4f6febga3054b45da76181b@mail.gmail.com> <bb0e440a0811161545w28dc089aj2a9d629b190dc80a@mail.gmail.com> Message-ID: <1226937611.6912.332.camel@ragnarok> On Mon, 2008-11-17 at 05:15 +0530, Suresh Ramasubramanian wrote: > On Mon, Nov 17, 2008 at 4:20 AM, James Hess <mysidia at gmail.com> wrote: > > One of the secondary/tertiary recursive resolvers may hand the client > > a cached response that had been obtained before the registrar took any > > action. > > Yes, and that'd make a good case for the good old ops practice of > dialing down the TTL for a while before any NS change is made. That would work only if Godaddy was considering suspending it for greater than TTL time before actually suspending them...it takes the same time to dial-down TTL (old TTL time) then change it, as it does to just change it outright. -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net jerj at coplanar.net From andree+nanog at toonk.nl Mon Nov 17 10:31:17 2008 From: andree+nanog at toonk.nl (Andree Toonk) Date: Mon, 17 Nov 2008 17:31:17 +0100 Subject: Prefix Hijack Tool Comaprision In-Reply-To: <20081113200513.GW20914@renesys.com> References: <mmTWG8Tckr9z.JrvHRB1Z@smtp.gmail.com> <20081113200513.GW20914@renesys.com> Message-ID: <20081117163117.GA4408@toonk.nl> Hi all, .-- My secret spy satellite informs me that at Thu, 13 Nov 2008, Todd Underwood wrote: > that's why i recommend that prefix hijacking detection systems do thresholding of > peers to prevent a single, rogue, unrepresentative peer from reporting > a hijacking when none is really happening. others may have a > different approach, but without thresholding prefix alert systems can > be noisy and more trouble than they are worth. For those who like to use a peer threshold, BGPmon.net now has minimum peer threshold support. For more information see: http://bgpmon.net/blog/?p=88 Cheers, Andree From rmacharia at gmail.com Mon Nov 17 12:20:24 2008 From: rmacharia at gmail.com (Raymond Macharia) Date: Mon, 17 Nov 2008 21:20:24 +0300 Subject: Router Choice In-Reply-To: <620fd17c0811140330s33792e68r94b12424d3d2be14@mail.gmail.com> References: <ac036ce50811120440x8139b1fq170fd13b5d0a61ef@mail.gmail.com> <D0AA0B5D-9EE6-4B60-8043-89D3A017EB77@gmail.com> <d0fea3580811120731n577d954cp46c376eb14e72bb9@mail.gmail.com> <620fd17c0811140330s33792e68r94b12424d3d2be14@mail.gmail.com> Message-ID: <ac036ce50811171020s1ec9a444ib4bd3acabed29881@mail.gmail.com> Hello,I appreciate all your feedback. I have also recieved more research material from independent research institutes that give the products thumbs up. Best regards Raymond On Fri, Nov 14, 2008 at 2:30 PM, Paul Wall <pauldotwall at gmail.com> wrote: > Whoa, excessive use of "!"...this isn't IOS ICMP output. > > For those of you who want to have a chuckle, grep the word "exit" on > any of these fine 7750/7450 router configurations. Seeing a router > configuration that contains 10,000+ instances of the word "exit" makes > me recall the fine book FINAL EXIT. Seems like a poor mans version of > nesting with { }'s in JUNOS. > > Some of my gripes on the Timetra (whens the last time Alcatel built > something themselves instead of acquire it?) box are that it really is > catered to installs where Alcatel is running the design side of the > network as well. The CLI is somewhat non-intuitive for IOS, IOS-XR or > JUNOS operations staff. Here are some examples: > > Here in 2008, why are people buying boxes that do not support > candidate configuration or commit/rollback? The only thing you can > "commit" on the box is routing policy changes. I thought this was a > service provider box? > > For years (this might not be the case anymore), any time you attempted > to use the short-form of the "show" command by typing "sh", you > received a syntax error. This is because there were two commands that > began with sh: show and shell. The problem is that the shell command > prompts you for a password that only Alcatel knows (and won't share > with any customers that I'm aware of). So, if your own customers cant > run the command, why give users a headache? > > Its a router, why do I have to do "show router route" to see a routing > table entry? For years, you also had to suffix the command "exact" on > the end of every command as well. > > Pricing wise...they're way above other boxes that you can find > elsewhere that can do the jobs you need. Both the Cisco 7600 and the > Juniper MX line both have a way better CLI and employ a knowledgeable > staff of seasoned former service provider engineers. Alcatel seems to > be comprised of failed router startup guys from Caspian or Chiaro. > Feature wise, they're behind the curve when it comes to competing with > Cisco and Juniper. I think this is also shown in how they name their > software releases as "Feature Groups" (telco-speak, anyone?). > > The main thing I want to speak to is that this box is not made for > your clueful IP operator. Alcatel is very insistent that the customer > use their UNIX/Windows NMS (I believe they call the SAM) to interface > with the routers. Sorry but...that might fly in telcoland where > executives ooh and ahh over point-and-click network management, but I > think most operators are going to find it a tad bit useless. > > Sure, they do have NSR, but so did Avici. Does NSR make up for the > lack of features, high pricing and being stuck at 20Gbps per slot? > Yes, they do have 40Gbps per slot on the way, but who doesn't support > 40Gbps per slot today? > > Why bother stepping back a few years in development when if you want a > solid P core box, Foundry MLX/XMR, Juniper MX, Cisco 7600s and CRS-1's > are ready now and at prices that really aren't all that bad. Oh yeah, > you wont scratch the hell out of your finger nails when removing the > compact flash on those boxes. > > Drive slow, pinging 10(!!!!). > > On Wed, Nov 12, 2008 at 10:31 AM, devang patel <devangnp at gmail.com> wrote: > > I guess they have good lab in Plano, TX also!!!I worked on the same > routers > > for IPTV deployment and really they are best!!! > > > > > > regards > > Devang Patel > > > > On Wed, Nov 12, 2008 at 8:43 AM, Dan Snyder <sliplever at gmail.com> wrote: > > > >> I think that the 7750SR routers are great and you won't be let down. We > >> used to have an all Cisco network and I was skeptical at first but they > have > >> been great. > >> > >> As for nss and nsr when we tested this by failing a cpm we saw less than > 50 > >> ms of traffic loss. I would see if you could go to either California or > >> Canada to one of ALUs labs and have it demonstrated for you. > >> > >> hth, > >> Dan > >> > >> > >> > >> Sent from my iPhone > >> > >> > >> On Nov 12, 2008, at 7:40 AM, "Raymond Macharia" <rmacharia at gmail.com> > >> wrote: > >> > >> Hello fellow nanogers, > >>> I am a long time user of Cisco gear and currently evaluating an > >>> alternative > >>> for my network expansion. currently the one that looks like it will be > >>> able > >>> to do the job iare Alcatel-Lucent 7710/7750 service routers. > >>> I am looking for real life experience of those who have used it and > what I > >>> may need to watch out for (if anything) I have seen in some of their > >>> documentation features like Non-stop Services (NSS) and Non-stop > Routing > >>> (NSR). are these features real world deployable. > >>> oh, just to add I want to use the routers as P routers in my IP/MPLS > core > >>> > >>> Regards > >>> -- > >>> Raymond Macharia > >>> > >> > >> > > > -- Raymond Macharia From isabeldias1 at yahoo.com Mon Nov 17 13:07:05 2008 From: isabeldias1 at yahoo.com (isabel dias) Date: Mon, 17 Nov 2008 11:07:05 -0800 (PST) Subject: Router Choice In-Reply-To: <ac036ce50811171020s1ec9a444ib4bd3acabed29881@mail.gmail.com> Message-ID: <122334.3159.qm@web52605.mail.re2.yahoo.com> Raymondo ..... I guess you are bringing everyone together on the achieving resilience and "efficient" Load Balancing just in case the one path is temporarly unavailable ...... :-) *****commit/rollback CISCO IOS save a configuration to the NVRAM with the copy running-config startup -config command http://www-europe.cisco.com/en/US/docs/switches/wan/mgx/mgx_8850/software/mgx_r3/rpm/rpm_r1.1/configuration/guide/appc.html JUNIPER JUNOS You just have to send you syslog messages to /var/log/messages to a central point of management and avoid /dev/null :-) The best practice would be to follow the same in all Cisco devices Catos or IOS based ones. And again that is why management tools have their relevance and have cron jobs in place to keep the latest changes -accounting included) but yes you are right we can always "grep" something out and find what has changed. The commit concept is an interesting one and bring us back to the way they have compiled and allowed us "users" to fiddle around w/ the OS. Some versions not mentioned here require the word "comit" to be typed after a stop/start of some services-PID. Let us say a gracefull reestart of the process ...... And yes the "old batle" ethernet vs ATM interfaces ....gosh ATM just had a "credit crunch" for the past years and ETHERNET standard knocked it down big time! Yes, the argument still standands ....if we want to take this further to the QoS/reliability ....I bet a lot of consultants would love an payed argument on this :-) As far as I am aware there are still a few interopability issues going on w/ some vendors and Eth-IEEE P802.3ba 40Gb/s, specially w/ having features available such as 802.1q/vlans etc ...but the card is there and available for everyone to work on .... And the world is moving to the 100 Gb Eth .....and so does IPv4 to IPv6. .//ID --- On Mon, 11/17/08, Raymond Macharia <rmacharia at gmail.com> wrote: > From: Raymond Macharia <rmacharia at gmail.com> > Subject: Re: Router Choice > To: nanog at nanog.org > Date: Monday, November 17, 2008, 7:20 PM > Hello,I appreciate all your feedback. I have also recieved > more research > material from independent research institutes that give the > products thumbs > up. > > Best regards > > Raymond > > On Fri, Nov 14, 2008 at 2:30 PM, Paul Wall > <pauldotwall at gmail.com> wrote: > > > Whoa, excessive use of "!"...this isn't > IOS ICMP output. > > > > For those of you who want to have a chuckle, grep the > word "exit" on > > any of these fine 7750/7450 router configurations. > Seeing a router > > configuration that contains 10,000+ instances of the > word "exit" makes > > me recall the fine book FINAL EXIT. Seems like a poor > mans version of > > nesting with { }'s in JUNOS. > > > > Some of my gripes on the Timetra (whens the last time > Alcatel built > > something themselves instead of acquire it?) box are > that it really is > > catered to installs where Alcatel is running the > design side of the > > network as well. The CLI is somewhat non-intuitive for > IOS, IOS-XR or > > JUNOS operations staff. Here are some examples: > > > > Here in 2008, why are people buying boxes that do not > support > > candidate configuration or commit/rollback? The only > thing you can > > "commit" on the box is routing policy > changes. I thought this was a > > service provider box? > > > > For years (this might not be the case anymore), any > time you attempted > > to use the short-form of the "show" command > by typing "sh", you > > received a syntax error. This is because there were > two commands that > > began with sh: show and shell. The problem is that the > shell command > > prompts you for a password that only Alcatel knows > (and won't share > > with any customers that I'm aware of). So, if your > own customers cant > > run the command, why give users a headache? > > > > Its a router, why do I have to do "show router > route" to see a routing > > table entry? For years, you also had to suffix the > command "exact" on > > the end of every command as well. > > > > Pricing wise...they're way above other boxes that > you can find > > elsewhere that can do the jobs you need. Both the > Cisco 7600 and the > > Juniper MX line both have a way better CLI and employ > a knowledgeable > > staff of seasoned former service provider engineers. > Alcatel seems to > > be comprised of failed router startup guys from > Caspian or Chiaro. > > Feature wise, they're behind the curve when it > comes to competing with > > Cisco and Juniper. I think this is also shown in how > they name their > > software releases as "Feature Groups" > (telco-speak, anyone?). > > > > The main thing I want to speak to is that this box is > not made for > > your clueful IP operator. Alcatel is very insistent > that the customer > > use their UNIX/Windows NMS (I believe they call the > SAM) to interface > > with the routers. Sorry but...that might fly in > telcoland where > > executives ooh and ahh over point-and-click network > management, but I > > think most operators are going to find it a tad bit > useless. > > > > Sure, they do have NSR, but so did Avici. Does NSR > make up for the > > lack of features, high pricing and being stuck at > 20Gbps per slot? > > Yes, they do have 40Gbps per slot on the way, but who > doesn't support > > 40Gbps per slot today? > > > > Why bother stepping back a few years in development > when if you want a > > solid P core box, Foundry MLX/XMR, Juniper MX, Cisco > 7600s and CRS-1's > > are ready now and at prices that really aren't all > that bad. Oh yeah, > > you wont scratch the hell out of your finger nails > when removing the > > compact flash on those boxes. > > > > Drive slow, pinging 10(!!!!). > > > > On Wed, Nov 12, 2008 at 10:31 AM, devang patel > <devangnp at gmail.com> wrote: > > > I guess they have good lab in Plano, TX also!!!I > worked on the same > > routers > > > for IPTV deployment and really they are best!!! > > > > > > > > > regards > > > Devang Patel > > > > > > On Wed, Nov 12, 2008 at 8:43 AM, Dan Snyder > <sliplever at gmail.com> wrote: > > > > > >> I think that the 7750SR routers are great and > you won't be let down. We > > >> used to have an all Cisco network and I was > skeptical at first but they > > have > > >> been great. > > >> > > >> As for nss and nsr when we tested this by > failing a cpm we saw less than > > 50 > > >> ms of traffic loss. I would see if you could > go to either California or > > >> Canada to one of ALUs labs and have it > demonstrated for you. > > >> > > >> hth, > > >> Dan > > >> > > >> > > >> > > >> Sent from my iPhone > > >> > > >> > > >> On Nov 12, 2008, at 7:40 AM, "Raymond > Macharia" <rmacharia at gmail.com> > > >> wrote: > > >> > > >> Hello fellow nanogers, > > >>> I am a long time user of Cisco gear and > currently evaluating an > > >>> alternative > > >>> for my network expansion. currently the > one that looks like it will be > > >>> able > > >>> to do the job iare Alcatel-Lucent > 7710/7750 service routers. > > >>> I am looking for real life experience of > those who have used it and > > what I > > >>> may need to watch out for (if anything) I > have seen in some of their > > >>> documentation features like Non-stop > Services (NSS) and Non-stop > > Routing > > >>> (NSR). are these features real world > deployable. > > >>> oh, just to add I want to use the routers > as P routers in my IP/MPLS > > core > > >>> > > >>> Regards > > >>> -- > > >>> Raymond Macharia > > >>> > > >> > > >> > > > > > > > > > -- > Raymond Macharia From ross at kallisti.us Mon Nov 17 13:11:01 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Mon, 17 Nov 2008 14:11:01 -0500 Subject: Catalyst 6500 High Switch Proc In-Reply-To: <491F40A0.5060302@mindfury.net> References: <491F40A0.5060302@mindfury.net> Message-ID: <20081117191101.GD29082@kallisti.us> On Sat, Nov 15, 2008 at 04:35:28PM -0500, Philip L. wrote: > One thing to note, is that our main ACL for ingress traffic is applied > here due to historical reasons. It's roughly 5000 single host entries > at present. We also use these devices for NDE. On a SUP7203BXL, if your ACL TCAM utilization is fine, this shouldn't impact performance unless you're logging too much. Since you've been over the CPU utilization doc, I'm guessing you know that. "show platform hardware capacity acl" will give you a breakdown on your ACL TCAM usage. > I'm probably missing some other key details, but what could influence > the SP like this? Any insight would be appreciated. Cisco says that Netflow-based features always handle the first packet of a flow in software, but I don't know if this is the RP or the SP. It would make sense if a first-flow packet that didn't need punting hit the SP and not the RP. In that case, your traffic level with netflow enabled could explain your high SP utilization. -- Ross Vandegrift ross at kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie From jcurran at mail.com Mon Nov 17 13:26:42 2008 From: jcurran at mail.com (John Curran) Date: Mon, 17 Nov 2008 14:26:42 -0500 Subject: 134.17.0.0/16 Message-ID: <80D4143B-742C-4085-95F1-D8340B482AE0@mail.com> Media Breakaway and ARIN have cooperatively reached an agreement whereby Media Breakaway will be returning to ARIN the legacy address space 134.17.0.0/16 originally issued to San Francisco (SF) Bay Packet Radio. Media Breakaway will be returning this space upon completion of renumbering to a new IPv4 allocation made based on their qualification under existing policy. ARIN is grateful for Media Breakaway's cooperation in this matter. Regards, /John John Curran Chairman, ARIN Board of Trustees From Robert.E.VanOrmer at frb.gov Mon Nov 17 16:46:08 2008 From: Robert.E.VanOrmer at frb.gov (Robert.E.VanOrmer at frb.gov) Date: Mon, 17 Nov 2008 16:46:08 -0600 Subject: IPv6 routing /48s Message-ID: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> Are there any parties out there routing /48 IPv6 networks globally? I ran into a supposed Catch-22 with Verizon and IPv6 address space and was looking for clarification. We have been delegated a /48 by ARIN. We then went out to procure a native IPv6 T1 from Verizon (*mainly for testing*). We requested that Verizon route the /48 that we were provided by ARIN. Verizon's response was "they do not route network smaller than a /32". Fair enough... capacity planning for all the /48's would give a router a headache with today's hardware... so we requested address delegated from Verizon's larger block of addresses to be used for addressing. The response was that we could not receive new address space until we returned our ARIN provided address space... so in effect, go back and get a /32 from ARIN or give up on ever owning address space again. ARIN claims they are seeing /48s routed, at least in their route tables. I have seen some new momentum on the allocation of /32's, don't know if that is in response to rules like this?? Would be awefully difficult for our organization to come up with the rationale to need 65K /48s internally to justify a /32. revo From rrodriguez at ifbyphone.com Mon Nov 17 16:51:30 2008 From: rrodriguez at ifbyphone.com (Robin Rodriguez) Date: Mon, 17 Nov 2008 16:51:30 -0600 Subject: Clueful FIDO contacts Message-ID: <4921F572.70106@ifbyphone.com> It is not strictly netops but I am hoping someone in nanog-land can assist me. I am receiving bad callerID information (I get the BTN) from FIDO or FIDO's upstream. My SIP providers claim they are receiving the bad callerID from their upstreams. Though everyone I am a customer of agrees that it isn't their problem and that it's FIDO's they are all unwilling or unable to assist me in contacting FIDO. If anyone has a contact or a NOC number that you could contact me off-list i would greatly appreciate it. Thank you, Robin -- Robin D. Rodriguez Systems Engineer Ifbyphone, Inc. Phone: (866) 250-1663 Fax: (847) 676-6553 rrodriguez at ifbyphone.com http://www.ifbyphone.com From mtinka at globaltransit.net Mon Nov 17 17:02:18 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 18 Nov 2008 07:02:18 +0800 Subject: IPv6 routing /48s In-Reply-To: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> Message-ID: <200811180702.23498.mtinka@globaltransit.net> On Tuesday 18 November 2008 06:46:08 Robert.E.VanOrmer at frb.gov wrote: > Are there any parties out there routing /48 IPv6 networks > globally? We do. At present, our policy is to route up to /48. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081118/765455ce/attachment.bin> From nick at foobar.org Mon Nov 17 17:17:19 2008 From: nick at foobar.org (Nick Hilliard) Date: Mon, 17 Nov 2008 23:17:19 +0000 Subject: IPv6 routing /48s In-Reply-To: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> Message-ID: <4921FB7F.3040107@foobar.org> Robert.E.VanOrmer at frb.gov wrote: > Are there any parties out there routing /48 IPv6 networks globally? I ran > into a supposed Catch-22 with Verizon and IPv6 address space and was > looking for clarification. There are a bunch of IXPs around who have been announcing /48s for a some while. From a cursory glance around, it looks like Verizon is unreachable from these at least AS2128, which announces a single /48. This would seem to support your sales person's claim. It will be interesting to see how long this policy lasts - or at least it will be interesting to see at what stage carriers decide that the loss in sales revenues hurts more than the cost of carrying /48s from PI delegatin blocks. Nick From oberman at es.net Mon Nov 17 17:18:29 2008 From: oberman at es.net (Kevin Oberman) Date: Mon, 17 Nov 2008 15:18:29 -0800 Subject: IPv6 routing /48s In-Reply-To: Your message of "Mon, 17 Nov 2008 16:46:08 CST." <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> Message-ID: <20081117231829.8642D4501F@ptavv.es.net> > From: Robert.E.VanOrmer at frb.gov > Date: Mon, 17 Nov 2008 16:46:08 -0600 > > Are there any parties out there routing /48 IPv6 networks globally? I ran > into a supposed Catch-22 with Verizon and IPv6 address space and was > looking for clarification. > > We have been delegated a /48 by ARIN. We then went out to procure a > native IPv6 T1 from Verizon (*mainly for testing*). We requested that > Verizon route the /48 that we were provided by ARIN. Verizon's response > was "they do not route network smaller than a /32". Fair enough... > capacity planning for all the /48's would give a router a headache with > today's hardware... so we requested address delegated from Verizon's > larger block of addresses to be used for addressing. The response was > that we could not receive new address space until we returned our ARIN > provided address space... so in effect, go back and get a /32 from ARIN > or give up on ever owning address space again. > > ARIN claims they are seeing /48s routed, at least in their route tables. I > have seen some new momentum on the allocation of /32's, don't know if that > is in response to rules like this?? Would be awefully difficult for our > organization to come up with the rationale to need 65K /48s internally to > justify a /32. Lots of people have /48s from ARIN and many are routed. The global IPv6 table currently has about 200 of them. Among those using /48s are ARIN and at least three of the root name servers, so that policy would block access to rather important sites. :-) I'd say that someone at VZB is pretty clueless. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081117/3ea51d75/attachment.bin> From michael at rancid.berkeley.edu Mon Nov 17 17:20:56 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Mon, 17 Nov 2008 15:20:56 -0800 Subject: IPv6 routing /48s In-Reply-To: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> Message-ID: <4921FC58.2050507@rancid.berkeley.edu> On 11/17/08 14:46, Robert.E.VanOrmer at frb.gov wrote: > ARIN claims they are seeing /48s routed, at least in their route tables. I > have seen some new momentum on the allocation of /32's, don't know if that > is in response to rules like this?? Would be awefully difficult for our > organization to come up with the rationale to need 65K /48s internally to > justify a /32. You may want to post this issue to the ARIN PPML list (see http://www.arin.net/mailing_lists/index.html if you're not already subscribed), as that might be a useful venue for discussion as well. You're right in noting that this is a catch-22. ARIN and other RIRs are now giving out PI /48s, but there is still a notion that /32 is considered the maximum routable prefix length. However, UCB sees a lot of globally-routed /48s (and /35s, /40s, etc.) in our DFZ routing table. (I also see some /48s disaggregated from a /32 and announced in at least one non-ARIN region, but I am sure this is happening elsewhere. :-( ) So, I do think that /48 is beginning to be the new /32 when it comes to prefix filtering, but I can also understand those who want to hold to the more strict IPv6 filtering policies. I think in the end, we are going to end up generally accepting up to /48s. Basically, we're going to break the routing table anyway--the number of potential /32s is more than enough to do that, and forcing everyone who: a. needs to be multi-homed; and b. needs more than 1-2 subnets to get a /32 has to be a waste, no matter how big the potential address space is overall. One compromise would be to require that blocks that can be aggregated be aggregated, and then allow PI /48s. In theory, this could be enforced a number of ways, but I am sure we're all aware of how well that works... michael From jabley at hopcount.ca Mon Nov 17 17:47:44 2008 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 17 Nov 2008 18:47:44 -0500 Subject: IPv6 routing /48s In-Reply-To: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> Message-ID: <243835E0-5DB9-452E-89F2-6BC257F11951@hopcount.ca> On 2008-11-17, at 17:46, Robert.E.VanOrmer at frb.gov wrote: > Are there any parties out there routing /48 IPv6 networks globally? Yes. Some particularly visible examples are root and TLD server operators. There are some TLDs which are well-served by IPv6-capable nameservers, but which would be completely invisible to v6-only clients if their covering /48s were not accepted. ASes which refuse prefixes longer than 32 bits across the board as a matter of policy are broken. The last time I looked, the RIRs with v6 micro-assignment policies were all doing long-prefix assignments from an easy-to-identify range of addresses. Creating a general-purpose filter which lets through PI / 48s but drops PA/deaggregated /48s is not rocket science. > I ran > into a supposed Catch-22 with Verizon and IPv6 address space and was > looking for clarification. I was once told by another large carrier I was trying to buy from in Miami that "you are not allowed to announce your own addresses in IPv6; you have to use addresses from your upstream". While the goal of encouraging use of PA addresses and discouraging deaggregation may be noble and good, it seems more education is required in some areas. "There is such a thing as PI in IPv6", for example, and perhaps "just because it's a /48 doesn't mean it's not PI". Joe From owen at delong.com Mon Nov 17 18:21:15 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Nov 2008 16:21:15 -0800 Subject: IPv6 routing /48s In-Reply-To: <243835E0-5DB9-452E-89F2-6BC257F11951@hopcount.ca> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <243835E0-5DB9-452E-89F2-6BC257F11951@hopcount.ca> Message-ID: <6CA83294-65FB-4C5F-9150-29FDA6BCE755@delong.com> On Nov 17, 2008, at 3:47 PM, Joe Abley wrote: > > The last time I looked, the RIRs with v6 micro-assignment policies > were all doing long-prefix assignments from an easy-to-identify > range of addresses. Creating a general-purpose filter which lets > through PI /48s but drops PA/deaggregated /48s is not rocket science. > As of June, 2008, at least, AfriNIC was not using a distinct range for these. There was discussion of converting to this due to these problems. From hannigan at gmail.com Mon Nov 17 20:14:48 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 17 Nov 2008 21:14:48 -0500 Subject: Clueful FIDO contacts In-Reply-To: <4921F572.70106@ifbyphone.com> References: <4921F572.70106@ifbyphone.com> Message-ID: <2d106eb50811171814u65257610mc3165dd054321b3@mail.gmail.com> On Mon, Nov 17, 2008 at 5:51 PM, Robin Rodriguez <rrodriguez at ifbyphone.com> wrote: > It is not strictly netops but I am hoping someone in nanog-land can assist > me. I am receiving bad callerID information (I get the BTN) Why is the BTN (billing top number) bad? That's a legitimate answer. -M< From nanog at daork.net Mon Nov 17 20:02:41 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 18 Nov 2008 15:02:41 +1300 Subject: IPv6 routing /48s In-Reply-To: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> Message-ID: <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> On 18/11/2008, at 11:46 AM, [1]Robert.E.VanOrmer at frb.gov wrote: We have been delegated a /48 by ARIN. We then went out to procure a native IPv6 T1 from Verizon (*mainly for testing*). We requested that Verizon route the /48 that we were provided by ARIN. Verizon's response was "they do not route network smaller than a /32". I wish them good luck in reaching the DNS root servers. They are in "critical infrastructure" space, which is a single /32 with /48s assigned[1] from that - or something like that. IXP space was mentioned.. I'm not sure that needs to be globally reachable. Maybe to stop uRPF breaking ICMP messages if routers on the exchange respond from their interface address.. though.. I'd prefer to make my routers respond from loopback or something. -- Nathan Ward [1] Maybe I mean allocated, whatever. -- Nathan Ward References 1. mailto:Robert.E.VanOrmer at frb.gov From phil at mindfury.net Mon Nov 17 20:34:28 2008 From: phil at mindfury.net (Philip L.) Date: Mon, 17 Nov 2008 21:34:28 -0500 Subject: Catalyst 6500 High Switch Proc In-Reply-To: <20081117191101.GD29082@kallisti.us> References: <491F40A0.5060302@mindfury.net> <20081117191101.GD29082@kallisti.us> Message-ID: <492229B4.6050604@mindfury.net> Ross Vandegrift wrote: > On Sat, Nov 15, 2008 at 04:35:28PM -0500, Philip L. wrote: > >> One thing to note, is that our main ACL for ingress traffic is applied >> here due to historical reasons. It's roughly 5000 single host entries >> at present. We also use these devices for NDE. >> > > On a SUP7203BXL, if your ACL TCAM utilization is fine, this shouldn't > impact performance unless you're logging too much. Since you've been > over the CPU utilization doc, I'm guessing you know that. > > "show platform hardware capacity acl" will give you a breakdown on > your ACL TCAM usage. > > >> I'm probably missing some other key details, but what could influence >> the SP like this? Any insight would be appreciated. >> > > Cisco says that Netflow-based features always handle the first packet > of a flow in software, but I don't know if this is the RP or the SP. > It would make sense if a first-flow packet that didn't need punting > hit the SP and not the RP. In that case, your traffic level with > netflow enabled could explain your high SP utilization. > > It is a Sup720-3BXL. Based on the suggestions here, I went ahead and did 'no ip flow ingress' on all the interfaces just to see, and surely enough, the SP went down to about 10-15%. My colleague implemented packet count-based NetFlow sampling to attempt to reduce the 100% NetFlow TCAM usage, and it appears to be partially effective. It still fills up frequently, so we'll have to do some more tweaking. I appreciate all the replies, public and private. -- Philip L. From rrodriguez at ifbyphone.com Mon Nov 17 21:47:40 2008 From: rrodriguez at ifbyphone.com (Robin Rodriguez) Date: Mon, 17 Nov 2008 21:47:40 -0600 Subject: Clueful FIDO contacts In-Reply-To: <2d106eb50811171814u65257610mc3165dd054321b3@mail.gmail.com> References: <4921F572.70106@ifbyphone.com> <2d106eb50811171814u65257610mc3165dd054321b3@mail.gmail.com> Message-ID: <49223ADC.4060908@ifbyphone.com> Should have been more specific I suppose, I believe I'm receiving the BTN of the trunk FIDO is delivering the calls to other carriers on. No the BTN of the subscriber (this is a mobile phone network) Thanks! Martin Hannigan wrote: > On Mon, Nov 17, 2008 at 5:51 PM, Robin Rodriguez > <rrodriguez at ifbyphone.com> wrote: > >> It is not strictly netops but I am hoping someone in nanog-land can assist >> me. I am receiving bad callerID information (I get the BTN) >> > > Why is the BTN (billing top number) bad? That's a legitimate answer. > > -M< > > -- Robin D. Rodriguez Systems Engineer Ifbyphone, Inc. Phone: (866) 250-1663 Fax: (847) 676-6553 rrodriguez at ifbyphone.com http://www.ifbyphone.com From nanog at daork.net Tue Nov 18 01:06:19 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 18 Nov 2008 20:06:19 +1300 Subject: Router Choice In-Reply-To: <620fd17c0811140330s33792e68r94b12424d3d2be14@mail.gmail.com> References: <ac036ce50811120440x8139b1fq170fd13b5d0a61ef@mail.gmail.com> <D0AA0B5D-9EE6-4B60-8043-89D3A017EB77@gmail.com> <d0fea3580811120731n577d954cp46c376eb14e72bb9@mail.gmail.com> <620fd17c0811140330s33792e68r94b12424d3d2be14@mail.gmail.com> Message-ID: <6ECAADF0-ECDD-4685-B888-4CFC1307E84A@daork.net> On 15/11/2008, at 12:30 AM, Paul Wall wrote: > For those of you who want to have a chuckle, grep the word "exit" on > any of these fine 7750/7450 router configurations. Seeing a router > configuration that contains 10,000+ instances of the word "exit" makes > me recall the fine book FINAL EXIT. Seems like a poor mans version of > nesting with { }'s in JUNOS. > > ..stuff.. Try out the GUI thing. I know people will go "GUIs are for idiots!" and all that. Seriously, try it before you knock it, it's really very very good, and doesn't try and hide things from you like traditional GUIs do. You can do XML stuff in to it for automated service provisioning etc. etc. etc. with templates, and so on. I've done quite a lot of this for lawful intercept, automated debugging of VoIP stuff, service provisioning, etc. Switch out the hardware, and the GUI/mgmt system will give it the config it should have. This is all configurable, so it doesn't annoy you if you don't want it to. Make changes in the CLI, and the GUI knows about it within a second or so - it gets an SNMP trap or something and updates accordingly. None of this periodic scan rubbish that you get with Dorado RMC etc. The GUI product name is 5620SAM. Also, before you try 7x50, do a training course so you understand how things work - thinking is quite different to Cisco/Juniper. For example, in the 7450, VLANs: - VLANs are specific only to a physical port, they are not per-box like Cisco etc. - To build a L2 VLAN, you create a VLAN on each port that you want to hook up (numbers can be whatever you want, do not have to be the same on every port) and then create a L2 service[1], and add the VLANs on each port in to the L2 service. - L2VPNs Because of this, VLAN tag re-write is not an extra feature - it is a core component of how switching works across the platform. They really seem to have thrown away a whole bunch of conventional thinking, and the result is, in my opinion, really quite good. -- Nathan Ward [1] I believe that it's the same L2 service that you use when creating a VPLS. -- Nathan Ward From simon at darkmere.gen.nz Tue Nov 18 02:52:18 2008 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Tue, 18 Nov 2008 21:52:18 +1300 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: <E1L2MJn-0005kO-5d@orange.darkmere.gen.nz> This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also containers pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From frank at cats-net.com Tue Nov 18 03:47:50 2008 From: frank at cats-net.com (Frank Habicht) Date: Tue, 18 Nov 2008 12:47:50 +0300 Subject: IPv6 routing /48s In-Reply-To: <6CA83294-65FB-4C5F-9150-29FDA6BCE755@delong.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <243835E0-5DB9-452E-89F2-6BC257F11951@hopcount.ca> <6CA83294-65FB-4C5F-9150-29FDA6BCE755@delong.com> Message-ID: <49228F46.4080104@cats-net.com> Owen DeLong wrote: > As of June, 2008, at least, AfriNIC was not using a distinct range for > these. > There was discussion of converting to this due to these problems. > afrinic /48 are out of 2001:43f8::/29 http://www.afrinic.net/Registration/resources.htm grep -w ipv6 delegated-afrinic-20081118 | grep -w 48 afrinic|TZ|ipv6|2001:43f8::|48|20070711|assigned afrinic|KE|ipv6|2001:43f8:10::|48|20070713|assigned afrinic|ZA|ipv6|2001:43f8:20::|48|20070726|assigned afrinic|ZA|ipv6|2001:43f8:30::|48|20070730|assigned afrinic|ZA|ipv6|2001:43f8:40::|48|20070921|assigned afrinic|ZA|ipv6|2001:43f8:50::|48|20071029|assigned afrinic|KE|ipv6|2001:43f8:60::|48|20080411|assigned afrinic|NA|ipv6|2001:43f8:80::|48|20081107|assigned Frank From jmaimon at ttec.com Tue Nov 18 10:19:10 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 18 Nov 2008 11:19:10 -0500 Subject: IPv6 routing /48s In-Reply-To: <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> Message-ID: <4922EAFE.1000000@ttec.com> Nathan Ward wrote: > I'd prefer to > make my routers respond from loopback or something. Wouldnt we all...how is that done again? From jeroen at unfix.org Tue Nov 18 10:38:45 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 18 Nov 2008 17:38:45 +0100 Subject: IPv6 routing /48s In-Reply-To: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> Message-ID: <4922EF95.4040006@spaghetti.zurich.ibm.com> Robert.E.VanOrmer at frb.gov wrote: > Are there any parties out there routing /48 IPv6 networks globally? I ran > into a supposed Catch-22 with Verizon and IPv6 address space and was > looking for clarification. Let them signup to GRH (http://www.sixxs.net/tools/grh/) then it will be very easy to see which chunks of the IPv6 routing table they are not seeing. A /48 is perfectly fine. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081118/c2607176/attachment.bin> From jml at packetpimp.org Tue Nov 18 10:59:17 2008 From: jml at packetpimp.org (Jason LeBlanc) Date: Tue, 18 Nov 2008 11:59:17 -0500 Subject: hotmail contact? Message-ID: <4922F465.3080803@packetpimp.org> Having a mail issue looking for hotmail contact. Thanks, Jason From morrowc.lists at gmail.com Tue Nov 18 11:26:36 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Nov 2008 12:26:36 -0500 Subject: IPv6 routing /48s In-Reply-To: <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> Message-ID: <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog at daork.net> wrote: > I wish them good luck in reaching the DNS root servers. > They are in "critical infrastructure" space, which is a single /32 with traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside 701) oh, not working... traceroute6 to ipv6.google.com from inside 701, oh... not working either. vzb's v6 table is far from complete :( which is pretty painful. -chris From michael at rancid.berkeley.edu Tue Nov 18 11:39:30 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 18 Nov 2008 09:39:30 -0800 Subject: IPv6 routing /48s In-Reply-To: <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> Message-ID: <4922FDD2.1070707@rancid.berkeley.edu> On 11/18/08 9:26 AM, Christopher Morrow wrote: > On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog at daork.net> wrote: >> I wish them good luck in reaching the DNS root servers. >> They are in "critical infrastructure" space, which is a single /32 with > > traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside > 701) oh, not working... > traceroute6 to ipv6.google.com from inside 701, oh... not working either. > > vzb's v6 table is far from complete :( which is pretty painful. And it just reinforces the fear that people have against putting AAAA records in DNS for their publicly-accessible resources, especially www. michael From joelja at bogus.com Tue Nov 18 11:43:20 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 18 Nov 2008 09:43:20 -0800 Subject: IPv6 routing /48s In-Reply-To: <4922FDD2.1070707@rancid.berkeley.edu> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> Message-ID: <4922FEB8.704@bogus.com> Michael Sinatra wrote: > On 11/18/08 9:26 AM, Christopher Morrow wrote: >> On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog at daork.net> wrote: >>> I wish them good luck in reaching the DNS root servers. >>> They are in "critical infrastructure" space, which is a single /32 >>> with >> >> traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside >> 701) oh, not working... >> traceroute6 to ipv6.google.com from inside 701, oh... not working either. >> >> vzb's v6 table is far from complete :( which is pretty painful. > > And it just reinforces the fear that people have against putting AAAA > records in DNS for their publicly-accessible resources, especially www. oddly enough I kind of expect my settlement free upstream to have somewhat fewer routes than say those tier-2s that I also buy transit from. > michael > From morrowc.lists at gmail.com Tue Nov 18 11:47:11 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Nov 2008 12:47:11 -0500 Subject: IPv6 routing /48s In-Reply-To: <4922FDD2.1070707@rancid.berkeley.edu> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> Message-ID: <75cb24520811180947i5d5ee4e4n8f6db28e6e4a91df@mail.gmail.com> On Tue, Nov 18, 2008 at 12:39 PM, Michael Sinatra <michael at rancid.berkeley.edu> wrote: > On 11/18/08 9:26 AM, Christopher Morrow wrote: >> >> On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog at daork.net> wrote: >>> >>> I wish them good luck in reaching the DNS root servers. >>> They are in "critical infrastructure" space, which is a single /32 with >> >> traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside >> 701) oh, not working... >> traceroute6 to ipv6.google.com from inside 701, oh... not working either. >> >> vzb's v6 table is far from complete :( which is pretty painful. > > And it just reinforces the fear that people have against putting AAAA > records in DNS for their publicly-accessible resources, especially www. if you want v6 adoption... latency, path length, jitter, performance all should closely match v4 specs. Expecting a US customer to be 'ok' with 300ms to reach a US site 30 miles (as the crow flies) via Germany... not good. V6 so far doesn't have the same $$ and interest from the 'user' so it's not being optomized yet. Or so it seems. -chris From jbates at brightok.net Tue Nov 18 11:56:18 2008 From: jbates at brightok.net (Jack Bates) Date: Tue, 18 Nov 2008 11:56:18 -0600 Subject: IPv6 routing /48s In-Reply-To: <75cb24520811180947i5d5ee4e4n8f6db28e6e4a91df@mail.gmail.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> <75cb24520811180947i5d5ee4e4n8f6db28e6e4a91df@mail.gmail.com> Message-ID: <492301C2.2000707@brightok.net> Christopher Morrow wrote: > if you want v6 adoption... latency, path length, jitter, performance > all should closely match v4 specs. Expecting a US customer to be 'ok' > with 300ms to reach a US site 30 miles (as the crow flies) via > Germany... not good. > > V6 so far doesn't have the same $$ and interest from the 'user' so > it's not being optomized yet. Or so it seems. Until the peering topology of v6 matches v4, we will continue to see this issue. I expect to wait until the last minute when the NSP's suddenly realize that they need to switch, and as my dual stack peerings increase, so will the QOS. At that point, the content providers will add AAAA and the eyeball networks will have the worst of it. M$ seems to be coming along fine with IPv6, but the problem we'll see is all those modems/routers which do not support it and probably can't with the minimal flash space they have. I haven't even seen good alternatives yet to start pushing my customers into IPv6 routers. Jack From bicknell at ufp.org Tue Nov 18 11:58:07 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 18 Nov 2008 12:58:07 -0500 Subject: IPv6 routing /48s In-Reply-To: <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> Message-ID: <20081118175807.GA71023@ussenterprise.ufp.org> In a message written on Tue, Nov 18, 2008 at 12:26:36PM -0500, Christopher Morrow wrote: > traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside > 701) oh, not working... > traceroute6 to ipv6.google.com from inside 701, oh... not working either. > > vzb's v6 table is far from complete :( which is pretty painful. It's only "Critical Infrastructure", and there's only like 50 of them now (mostly root servers and CC-Tld's) in the ARIN region. http://www.arin.net/reference/micro_allocations.html Note too that they are not all /48's. A lot of people want to filter the range with le 47 ge 49, and that doesn't work either. F-Root's covering prefix is a /47, for example. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081118/17ee1f6e/attachment.bin> From jeroen at unfix.org Tue Nov 18 11:59:50 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 18 Nov 2008 18:59:50 +0100 Subject: IPv6 routing /48s In-Reply-To: <4922FDD2.1070707@rancid.berkeley.edu> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> Message-ID: <49230296.3080407@spaghetti.zurich.ibm.com> Michael Sinatra wrote: > On 11/18/08 9:26 AM, Christopher Morrow wrote: >> On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog at daork.net> wrote: >>> I wish them good luck in reaching the DNS root servers. >>> They are in "critical infrastructure" space, which is a single /32 >>> with >> >> traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside >> 701) oh, not working... >> traceroute6 to ipv6.google.com from inside 701, oh... not working either. >> >> vzb's v6 table is far from complete :( which is pretty painful. > > And it just reinforces the fear that people have against putting AAAA > records in DNS for their publicly-accessible resources, especially www. Having no route is not a problem, you should get a destination unreachable directly and all is fine because IPv4 should be used as a fallback. The biggest issue at the moment with IPv6 for endusers is broken DNS caches/forwarders that just drop AAAA queries and thus let the client timeout and then optionally fallback to IPv4. Wikimedia has also been doing tests like the Google one already for some while, their results are publicly available here: http://ipv6and4.labs.wikimedia.org/ Greets, Jeroen (notice my usage of 'should' here, because other issues will break things too ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081118/58a2116c/attachment.bin> From jeroen at unfix.org Tue Nov 18 12:04:45 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 18 Nov 2008 19:04:45 +0100 Subject: IPv6 routing /48s In-Reply-To: <20081118175807.GA71023@ussenterprise.ufp.org> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <20081118175807.GA71023@ussenterprise.ufp.org> Message-ID: <492303BD.7010500@spaghetti.zurich.ibm.com> Leo Bicknell wrote: > In a message written on Tue, Nov 18, 2008 at 12:26:36PM -0500, Christopher Morrow wrote: >> traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside >> 701) oh, not working... >> traceroute6 to ipv6.google.com from inside 701, oh... not working either. >> >> vzb's v6 table is far from complete :( which is pretty painful. > > It's only "Critical Infrastructure", and there's only like 50 of > them now (mostly root servers and CC-Tld's) in the ARIN region. And a LOT and LOT more, don't forget the rest of the world please, there is more than the ARIN region, even if this is the NA-nog list ;) Check: http://www.space.net/~gert/RIPE/ipv6-filters.html for a list of suggested filter expressions that cover all of these correctly. From http://www.sixxs.net/tools/grh/dfp/ * 1x /13 * 2x /19 * 6x /20 * 4x /21 * 5x /22 * 1x /23 * 2x /24, 13x returned, 45x reclaimed * 2x /25 * 5x /26 * 4x /27 * 9x /28, 14x returned, 42x reclaimed * 4x /29 * 5x /30 * 3x /31, 1x returned * 2112x /32, 45x returned, 22x reclaimed * 4x /35, 2x returned * 2x /40 * 5x /41 * 1x /42 * 2x /43 * 3x /44, 1x returned * 7x /45 * 7x /46 * 11x /47 * 376x /48, 3x returned * 5x /64 Not everything is a /32 ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081118/0ef4182f/attachment.bin> From neil at domino.org Tue Nov 18 12:38:31 2008 From: neil at domino.org (Neil J. McRae) Date: Tue, 18 Nov 2008 18:38:31 -0000 (GMT) Subject: Router Choice In-Reply-To: <6ECAADF0-ECDD-4685-B888-4CFC1307E84A@daork.net> References: <ac036ce50811120440x8139b1fq170fd13b5d0a61ef@mail.gmail.com> <D0AA0B5D-9EE6-4B60-8043-89D3A017EB77@gmail.com> <d0fea3580811120731n577d954cp46c376eb14e72bb9@mail.gmail.com> <620fd17c0811140330s33792e68r94b12424d3d2be14@mail.gmail.com> <6ECAADF0-ECDD-4685-B888-4CFC1307E84A@daork.net> Message-ID: <50589.217.169.55.138.1227033511.squirrel@webmail2.domino.org> > > Try out the GUI thing. > > I know people will go "GUIs are for idiots!" and all that. > Agree, the SAM is excellent, esp the XML interface to it. Regards, Neil. -- Neil J. McRae -- Alive and Kicking. neil at DOMINO.ORG From tdurack at gmail.com Tue Nov 18 13:03:11 2008 From: tdurack at gmail.com (Tim Durack) Date: Tue, 18 Nov 2008 14:03:11 -0500 Subject: NAT66 and the subscriber prefix length In-Reply-To: <alpine.DEB.1.10.0811142023410.10993@uplift.swm.pp.se> References: <C0F2465B4F386241A58321C884AC7ECC0961B7FB@E03MVZ2-UKDY.domain1.systemhost.net> <alpine.DEB.1.10.0811142023410.10993@uplift.swm.pp.se> Message-ID: <9e246b4d0811181103v3cd8570dw10059ad998e6a1a1@mail.gmail.com> On Fri, Nov 14, 2008 at 2:28 PM, Mikael Abrahamsson <swmike at swm.pp.se>wrote: > On Fri, 14 Nov 2008, michael.dillon at bt.com wrote: > > Not long ago, ARIN changed the IPv6 policy so that >> residential subscribers could be issued with a /56 >> instead of the normal /48 assignment. This was done >> so that ISPs with large numbers of subscriber sites >> would not exhaust their /32 (or larger) allocations >> too soon. Since these ISPs are allowed to assign >> a /56 to residential subscriber sites, their initial >> IPv6 allocation will last a lot longer and they won't >> have to apply for an additional allocation while >> everyone is getting up to speed with an IPv6 Internet. >> > > We returned our /32 for a /25 (with /22 being reserved) and current plan is > to hand out /48s to everybody (unless they need even more space, then > they'll have to apply). > > So, doing /56 to end users just because you happen to have a /32 right now > sounds like a bad plan, it doesn't take that many hours to get a larger > space if you can justify it (which wasn't that hard for us). > > We received our /32 (as a /35 I think) back in 2000 or so, policy has > changed since then, with RIPE it's not that hard to get a much larger space > with a long term growth plan. My hope is that we'll make do with this /22 > space for at least 5-10 years (67 million customer /48s is quite a lot), > unless something really big happens, and then we'll just have to get an even > larger space. > > So message should be that /48 to end users is the way to go, and this > should suit residential and SME market without any additional administrative > overhead depending on customer size. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > This raises questions for me: we are a mixed enterprise/campus environment. Recently got a /45 assigned, so we have a /48 per site (it was some work to convince ARIN that fancy subnetting to make a /46 stretch a little further made no sense.) We have also started offering residential Internet to those living on campus, which has been very popular (no suprise.) If I'm expected to assign a /48 per residential user, I'm already out of address space. Should I be requesting a /32? Is it acceptable to carve the /32 up a little for IPv4 style multi-homing? I'd rather come to terms with this now before I do any meaningful deployment. Tim:> From gih at apnic.net Tue Nov 18 13:27:12 2008 From: gih at apnic.net (Geoff Huston) Date: Wed, 19 Nov 2008 06:27:12 +1100 Subject: IPv6 routing /48s In-Reply-To: <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> Message-ID: <8BCEC3E2-A6BC-46F6-B13C-DE147C24EB8E@apnic.net> On 19/11/2008, at 4:26 AM, Christopher Morrow wrote: > On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog at daork.net> wrote: >> I wish them good luck in reaching the DNS root servers. >> They are in "critical infrastructure" space, which is a single /32 >> with > > traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside > 701) oh, not working... > traceroute6 to ipv6.google.com from inside 701, oh... not working > either. > > vzb's v6 table is far from complete :( which is pretty painful. > > -chris > of the 1494 entries in the Ipv6 inter-domain routing table that is seen at the Ipv6 route-views router there are 347 /48's (and 1 /56 and 12 /64s, I dunno why) More details at http://bgp.potaroo.net/v6/as6447/ if anyone is interested From Crist.Clark at globalstar.com Tue Nov 18 13:33:01 2008 From: Crist.Clark at globalstar.com (Crist Clark) Date: Tue, 18 Nov 2008 11:33:01 -0800 Subject: NAT66 and the subscriber prefix length In-Reply-To: <9e246b4d0811181103v3cd8570dw10059ad998e6a1a1@mail.gmail.com> References: <C0F2465B4F386241A58321C884AC7ECC0961B7FB@E03MVZ2-UKDY.domain1.systemhost.net> <alpine.DEB.1.10.0811142023410.10993@uplift.swm.pp.se> <9e246b4d0811181103v3cd8570dw10059ad998e6a1a1@mail.gmail.com> Message-ID: <4922A7EA.33E4.0097.0@globalstar.com> >>> On 11/18/2008 at 11:03 AM, "Tim Durack" <tdurack at gmail.com> wrote: > On Fri, Nov 14, 2008 at 2:28 PM, Mikael Abrahamsson <swmike at swm.pp.se>wrote: > >> On Fri, 14 Nov 2008, michael.dillon at bt.com wrote: >> >> Not long ago, ARIN changed the IPv6 policy so that >>> residential subscribers could be issued with a /56 >>> instead of the normal /48 assignment. This was done >>> so that ISPs with large numbers of subscriber sites >>> would not exhaust their /32 (or larger) allocations >>> too soon. Since these ISPs are allowed to assign >>> a /56 to residential subscriber sites, their initial >>> IPv6 allocation will last a lot longer and they won't >>> have to apply for an additional allocation while >>> everyone is getting up to speed with an IPv6 Internet. >>> >> >> We returned our /32 for a /25 (with /22 being reserved) and current plan is >> to hand out /48s to everybody (unless they need even more space, then >> they'll have to apply). >> >> So, doing /56 to end users just because you happen to have a /32 right now >> sounds like a bad plan, it doesn't take that many hours to get a larger >> space if you can justify it (which wasn't that hard for us). >> >> We received our /32 (as a /35 I think) back in 2000 or so, policy has >> changed since then, with RIPE it's not that hard to get a much larger space >> with a long term growth plan. My hope is that we'll make do with this /22 >> space for at least 5-10 years (67 million customer /48s is quite a lot), >> unless something really big happens, and then we'll just have to get an even >> larger space. >> >> So message should be that /48 to end users is the way to go, and this >> should suit residential and SME market without any additional administrative >> overhead depending on customer size. >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se >> >> > This raises questions for me: we are a mixed enterprise/campus environment. > Recently got a /45 assigned, so we have a /48 per site (it was some work to > convince ARIN that fancy subnetting to make a /46 stretch a little further > made no sense.) A /45? I thought all allocations were on nibble borders for IP6.ARPA considerations. From tdurack at gmail.com Tue Nov 18 13:59:53 2008 From: tdurack at gmail.com (Tim Durack) Date: Tue, 18 Nov 2008 14:59:53 -0500 Subject: NAT66 and the subscriber prefix length In-Reply-To: <4922A7EA.33E4.0097.0@globalstar.com> References: <C0F2465B4F386241A58321C884AC7ECC0961B7FB@E03MVZ2-UKDY.domain1.systemhost.net> <alpine.DEB.1.10.0811142023410.10993@uplift.swm.pp.se> <9e246b4d0811181103v3cd8570dw10059ad998e6a1a1@mail.gmail.com> <4922A7EA.33E4.0097.0@globalstar.com> Message-ID: <9e246b4d0811181159y7b8f12ddhfa58d7c692fbe0f6@mail.gmail.com> On Tue, Nov 18, 2008 at 2:33 PM, Crist Clark <Crist.Clark at globalstar.com>wrote: > >>> On 11/18/2008 at 11:03 AM, "Tim Durack" <tdurack at gmail.com> wrote: > > On Fri, Nov 14, 2008 at 2:28 PM, Mikael Abrahamsson <swmike at swm.pp.se > >wrote: > > > >> On Fri, 14 Nov 2008, michael.dillon at bt.com wrote: > >> > >> Not long ago, ARIN changed the IPv6 policy so that > >>> residential subscribers could be issued with a /56 > >>> instead of the normal /48 assignment. This was done > >>> so that ISPs with large numbers of subscriber sites > >>> would not exhaust their /32 (or larger) allocations > >>> too soon. Since these ISPs are allowed to assign > >>> a /56 to residential subscriber sites, their initial > >>> IPv6 allocation will last a lot longer and they won't > >>> have to apply for an additional allocation while > >>> everyone is getting up to speed with an IPv6 Internet. > >>> > >> > >> We returned our /32 for a /25 (with /22 being reserved) and current plan > is > >> to hand out /48s to everybody (unless they need even more space, then > >> they'll have to apply). > >> > >> So, doing /56 to end users just because you happen to have a /32 right > now > >> sounds like a bad plan, it doesn't take that many hours to get a larger > >> space if you can justify it (which wasn't that hard for us). > >> > >> We received our /32 (as a /35 I think) back in 2000 or so, policy has > >> changed since then, with RIPE it's not that hard to get a much larger > space > >> with a long term growth plan. My hope is that we'll make do with this > /22 > >> space for at least 5-10 years (67 million customer /48s is quite a lot), > >> unless something really big happens, and then we'll just have to get an > even > >> larger space. > >> > >> So message should be that /48 to end users is the way to go, and this > >> should suit residential and SME market without any additional > administrative > >> overhead depending on customer size. > >> > >> -- > >> Mikael Abrahamsson email: swmike at swm.pp.se > >> > >> > > This raises questions for me: we are a mixed enterprise/campus > environment. > > Recently got a /45 assigned, so we have a /48 per site (it was some work > to > > convince ARIN that fancy subnetting to make a /46 stretch a little > further > > made no sense.) > > A /45? I thought all allocations were on nibble borders for > IP6.ARPA considerations. > > 2620:0000:/23 is PI. ARIN makes assignments to end user sites of anywhere between /48 and /40, depending on your justification. ARIN wanted to give us a /46 for 5 sites, which made no sense. We pushed back for a /45, and that's what they gave us. Still not convinced it's going to be enough. Tim:> From tony at lava.net Tue Nov 18 14:05:51 2008 From: tony at lava.net (Antonio Querubin) Date: Tue, 18 Nov 2008 10:05:51 -1000 (HST) Subject: IPv6 routing /48s In-Reply-To: <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> Message-ID: <Pine.BSI.4.64.0811181001580.21019@malasada.lava.net> On Tue, 18 Nov 2008, Christopher Morrow wrote: > traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside > 701) oh, not working... > traceroute6 to ipv6.google.com from inside 701, oh... not working either. > > vzb's v6 table is far from complete :( which is pretty painful. That's not all that's broken at vzb. I've been trying to get them to troubleshoot/fix a possible PMTU problem for weeks now. Everytime I try turning up our tunnel with them we lose http connectivity to various web sites (you can still ping/traceroute the same sites) one of which is isc.org. Antonio Querubin whois: AQ7-ARIN From morrowc.lists at gmail.com Tue Nov 18 15:10:52 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Nov 2008 16:10:52 -0500 Subject: IPv6 routing /48s In-Reply-To: <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> Message-ID: <75cb24520811181310p1621d5dey7f73d6bbad8ed61a@mail.gmail.com> On Tue, Nov 18, 2008 at 12:26 PM, Christopher Morrow <morrowc.lists at gmail.com> wrote: > On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog at daork.net> wrote: >> I wish them good luck in reaching the DNS root servers. >> They are in "critical infrastructure" space, which is a single /32 with > > traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside > 701) oh, not working... oh hey! this is fixed now :) (Thanks anonymous 701 engineer in my AIM window!!) > traceroute6 to ipv6.google.com from inside 701, oh... not working either. > Oh, this is also fixed, I get there from virginia -> frankfurt -> 12702 -> someone -> ipv6.google.com! All in .. 225ms or so. > vzb's v6 table is far from complete :( which is pretty painful. > the current table seen on the v6 routeviews box (routeviews6 perhaps?) is: 1495 routes GRH is too slow to get me an answer on what it thinks the v6 table size should be :( Geoff says though: 1627 routes (http://bgp.potaroo.net/v6/as2.0/index.html) -chris From perry at coders.net Tue Nov 18 15:13:07 2008 From: perry at coders.net (Perry Lorier) Date: Wed, 19 Nov 2008 10:13:07 +1300 Subject: IPv6 routing /48s In-Reply-To: <49230296.3080407@spaghetti.zurich.ibm.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> <49230296.3080407@spaghetti.zurich.ibm.com> Message-ID: <49232FE3.5080306@coders.net> > Having no route is not a problem, you should get a destination > unreachable directly and all is fine because IPv4 should be used as a > fallback. > > The big problem is when you have a route to them, but they don't have a route back. You don't get destination unreachables, but instead get timeouts, and pain, and misery (btdt). :( From paul at telcodata.us Tue Nov 18 16:04:43 2008 From: paul at telcodata.us (Paul Timmins) Date: Tue, 18 Nov 2008 17:04:43 -0500 Subject: IPv6 routing /48s In-Reply-To: <Pine.BSI.4.64.0811181001580.21019@malasada.lava.net> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <Pine.BSI.4.64.0811181001580.21019@malasada.lava.net> Message-ID: <1227045883.24801.6.camel@ptimmins-d.corp.clearrate.net> You too, huh? On Tue, 2008-11-18 at 10:05 -1000, Antonio Querubin wrote: > On Tue, 18 Nov 2008, Christopher Morrow wrote: > > > traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside > > 701) oh, not working... > > traceroute6 to ipv6.google.com from inside 701, oh... not working either. > > > > vzb's v6 table is far from complete :( which is pretty painful. > > That's not all that's broken at vzb. I've been trying to get them to > troubleshoot/fix a possible PMTU problem for weeks now. Everytime I try > turning up our tunnel with them we lose http connectivity to various web > sites (you can still ping/traceroute the same sites) one of which is > isc.org. > > > Antonio Querubin > whois: AQ7-ARIN > From kloch at kl.net Tue Nov 18 16:05:49 2008 From: kloch at kl.net (Kevin Loch) Date: Tue, 18 Nov 2008 17:05:49 -0500 Subject: IPv6 routing /48s In-Reply-To: <75cb24520811181310p1621d5dey7f73d6bbad8ed61a@mail.gmail.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <75cb24520811181310p1621d5dey7f73d6bbad8ed61a@mail.gmail.com> Message-ID: <49233C3D.6020708@kl.net> Christopher Morrow wrote: > GRH is too slow to get me an answer on what it thinks the v6 table > size should be :( Geoff says though: > 1627 routes > (http://bgp.potaroo.net/v6/as2.0/index.html) route-views6 is another good place to look. 1481 is the max seen there. Perhaps there are some internal/customer routes in the feed Geoff is using? route-views6.routeviews.org> sh bgp sum (output snipped for brevity) - Kevin From michael at rancid.berkeley.edu Tue Nov 18 16:24:27 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 18 Nov 2008 14:24:27 -0800 Subject: IPv6 routing /48s In-Reply-To: <49230296.3080407@spaghetti.zurich.ibm.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> <49230296.3080407@spaghetti.zurich.ibm.com> Message-ID: <4923409B.5090909@rancid.berkeley.edu> On 11/18/08 9:59 AM, Jeroen Massar wrote: > Michael Sinatra wrote: >> On 11/18/08 9:26 AM, Christopher Morrow wrote: >>> On Mon, Nov 17, 2008 at 9:02 PM, Nathan Ward <nanog at daork.net> wrote: >>>> I wish them good luck in reaching the DNS root servers. >>>> They are in "critical infrastructure" space, which is a single /32 >>>> with >>> traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside >>> 701) oh, not working... >>> traceroute6 to ipv6.google.com from inside 701, oh... not working either. >>> >>> vzb's v6 table is far from complete :( which is pretty painful. >> And it just reinforces the fear that people have against putting AAAA >> records in DNS for their publicly-accessible resources, especially www. > > Having no route is not a problem, you should get a destination > unreachable directly and all is fine because IPv4 should be used as a > fallback. Not all routers send dest unreachable (yes they should). Not all firewalls pass it. And, worst of all, we have even seen OSes that don't pay any attention to dest unreachables and just wait for timeouts. :( Fortunately those latter edge cases seem to be getting fixed, but YMMV. michael From tony at lava.net Tue Nov 18 17:48:43 2008 From: tony at lava.net (Antonio Querubin) Date: Tue, 18 Nov 2008 13:48:43 -1000 (HST) Subject: IPv6 routing /48s In-Reply-To: <1227045883.24801.6.camel@ptimmins-d.corp.clearrate.net> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <Pine.BSI.4.64.0811181001580.21019@malasada.lava.net> <1227045883.24801.6.camel@ptimmins-d.corp.clearrate.net> Message-ID: <Pine.BSI.4.64.0811181345410.6400@malasada.lava.net> On Tue, 18 Nov 2008, Paul Timmins wrote: > You too, huh? Is your IPv6 tunnel with vzb using GRE or 6-in-4 encapsulation? Antonio Querubin whois: AQ7-ARIN From paul at telcodata.us Tue Nov 18 19:07:17 2008 From: paul at telcodata.us (Paul Timmins) Date: Tue, 18 Nov 2008 20:07:17 -0500 Subject: IPv6 routing /48s In-Reply-To: <Pine.BSI.4.64.0811181345410.6400@malasada.lava.net> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <Pine.BSI.4.64.0811181001580.21019@malasada.lava.net> <1227045883.24801.6.camel@ptimmins-d.corp.clearrate.net> <Pine.BSI.4.64.0811181345410.6400@malasada.lava.net> Message-ID: <1227056837.484.5.camel@pichu.internal.timminstechnologies.com> GRE. The problem we have (I think) is that the tunnel goes to something other than the direct router we have the DS3 on. The tunnel goes: vzb->ds3 router->ethernet->another router We aren't able to do more than a 1500 byte MTU, so when they send packets larger than 1380 or so, the packets never make it to my end. They get an IPv4 packet too large, and their router doesn't do anything to either lower the MTU of the tunnel (they have changed settings on their side but evidently not the right ones, because it's not changed anything at all) or translate that to an IPv6 packet too big somehow, so the packet just disappears into thin air. -Paul On Tue, 2008-11-18 at 13:48 -1000, Antonio Querubin wrote: > On Tue, 18 Nov 2008, Paul Timmins wrote: > > > You too, huh? > > Is your IPv6 tunnel with vzb using GRE or 6-in-4 encapsulation? > > Antonio Querubin > whois: AQ7-ARIN From pekkas at netcore.fi Wed Nov 19 01:28:06 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 19 Nov 2008 09:28:06 +0200 (EET) Subject: IPv6 routing /48s In-Reply-To: <492303BD.7010500@spaghetti.zurich.ibm.com> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <20081118175807.GA71023@ussenterprise.ufp.org> <492303BD.7010500@spaghetti.zurich.ibm.com> Message-ID: <alpine.LRH.2.00.0811190924020.22834@netcore.fi> On Tue, 18 Nov 2008, Jeroen Massar wrote: > Check: http://www.space.net/~gert/RIPE/ipv6-filters.html for a list of > suggested filter expressions that cover all of these correctly. Unfortunately, the JunOS version of the strict filter is blocking /32's from APNIC region as well. The offending lines are: route-filter 2001::/16 prefix-length-range /19-/32; ... route-filter 2001:0c00::/23 prefix-length-range /48-/48; This is because Juniper uses longest prefix matching in route filters (maybe this is different in cisco, I don't know): https://www.juniper.net/techpubs/software/junos/junos92/swconfig-policy/how-a-route-list-is-evaluated.html As a result, this will end up rejecting legitimate prefixes such as 2001:c00::/32 because then only /48's are accepted from that range. Unfortunately, I don't know which blocks APNIC has set aside from 2001:0c00::/23 for /48 assignments; based on their web pages, they have policies for at least multihoming, IXs and critical infrastructure. But I couldn't find info which block these are from. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From michael.dillon at bt.com Wed Nov 19 02:43:45 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 19 Nov 2008 08:43:45 -0000 Subject: NAT66 and the subscriber prefix length In-Reply-To: <9e246b4d0811181103v3cd8570dw10059ad998e6a1a1@mail.gmail.com> Message-ID: <C0F2465B4F386241A58321C884AC7ECC0978DE13@E03MVZ2-UKDY.domain1.systemhost.net> > We have also started offering residential Internet to those > living on campus, which has been very popular (no suprise.) You've started your own ISP. ISP's get a /32 from ARIN. Case closed. In fact, you are better off treating your non-ISP networks as a customer of your ISP and assigning a /48 to each of your non-ISP sites. This is an area where IPv4 and IPv6 differ. --Michael Dillon From eugen at imacandi.net Wed Nov 19 08:25:29 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 19 Nov 2008 16:25:29 +0200 Subject: NAT66 and the subscriber prefix length In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC0978DE13@E03MVZ2-UKDY.domain1.systemhost.net> References: <C0F2465B4F386241A58321C884AC7ECC0978DE13@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <492421D9.4070203@imacandi.net> michael.dillon at bt.com wrote: >> We have also started offering residential Internet to those >> living on campus, which has been very popular (no suprise.) > > You've started your own ISP. ISP's get a /32 from ARIN. > Case closed. > > In fact, you are better off treating your non-ISP networks > as a customer of your ISP and assigning a /48 to each of > your non-ISP sites. This is an area where IPv4 and IPv6 differ. Too bad in Europe RIPE wants 3000EUR per month membership fees to give you PI IPv6 if you're an end user. From jabley at hopcount.ca Wed Nov 19 08:51:54 2008 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 19 Nov 2008 09:51:54 -0500 Subject: NAT66 and the subscriber prefix length In-Reply-To: <492421D9.4070203@imacandi.net> References: <C0F2465B4F386241A58321C884AC7ECC0978DE13@E03MVZ2-UKDY.domain1.systemhost.net> <492421D9.4070203@imacandi.net> Message-ID: <A9BBB5D9-AE94-4DA9-9468-C0978097161E@hopcount.ca> On 2008-11-19, at 09:25, Eugeniu Patrascu wrote: > michael.dillon at bt.com wrote: >>> We have also started offering residential Internet to those living >>> on campus, which has been very popular (no suprise.) >> You've started your own ISP. ISP's get a /32 from ARIN. >> Case closed. >> In fact, you are better off treating your non-ISP networks >> as a customer of your ISP and assigning a /48 to each of >> your non-ISP sites. This is an area where IPv4 and IPv6 differ. > > Too bad in Europe RIPE wants 3000EUR per month membership fees to > give you PI IPv6 if you're an end user. But surely he's not an end-user. He's an ISP, which means he's (potentially) an LIR. Joe From fw at deneb.enyo.de Wed Nov 19 09:06:19 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 19 Nov 2008 16:06:19 +0100 Subject: IPv6 routing /48s In-Reply-To: <4922FDD2.1070707@rancid.berkeley.edu> (Michael Sinatra's message of "Tue, 18 Nov 2008 09:39:30 -0800") References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> Message-ID: <874p234uxg.fsf@mid.deneb.enyo.de> * Michael Sinatra: > And it just reinforces the fear that people have against putting AAAA > records in DNS for their publicly-accessible resources, especially > www. Won't current Windows clients work just fine in this case? I have no idea what a fix should look like for some of the non-Windows systems I care about, unfortunately. From eugen at imacandi.net Wed Nov 19 09:27:03 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 19 Nov 2008 17:27:03 +0200 Subject: NAT66 and the subscriber prefix length In-Reply-To: <A9BBB5D9-AE94-4DA9-9468-C0978097161E@hopcount.ca> References: <C0F2465B4F386241A58321C884AC7ECC0978DE13@E03MVZ2-UKDY.domain1.systemhost.net> <492421D9.4070203@imacandi.net> <A9BBB5D9-AE94-4DA9-9468-C0978097161E@hopcount.ca> Message-ID: <49243047.70204@imacandi.net> Joe Abley wrote: > But surely he's not an end-user. He's an ISP, which means he's > (potentially) an LIR. > My gripe was that I wanted to get an IPv6 allocation from RIPE to start testing how IPv6 would fit in the company that I work for and build a dual stack network so that when the time comes, just switch on IPv6 BGP neighbors and update the DNS. But at almost 10.000 EUR per year it's an experiment I can't afford. From iljitsch at muada.com Wed Nov 19 09:37:23 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 19 Nov 2008 09:37:23 -0600 Subject: NAT66 and the subscriber prefix length In-Reply-To: <49243047.70204@imacandi.net> References: <C0F2465B4F386241A58321C884AC7ECC0978DE13@E03MVZ2-UKDY.domain1.systemhost.net> <492421D9.4070203@imacandi.net> <A9BBB5D9-AE94-4DA9-9468-C0978097161E@hopcount.ca> <49243047.70204@imacandi.net> Message-ID: <3DF68620-0BFF-4048-B434-79EE34404DFB@muada.com> On 19 nov 2008, at 9:27, Eugeniu Patrascu wrote: > My gripe was that I wanted to get an IPv6 allocation from RIPE to > start testing how IPv6 would fit in the company that I work for and > build a dual stack network so that when the time comes, just switch > on IPv6 BGP neighbors and update the DNS. > But at almost 10.000 EUR per year it's an experiment I can't afford. You don't need PI for most things. You certainly don't need it to experiment. From michael.dillon at bt.com Wed Nov 19 09:39:00 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 19 Nov 2008 15:39:00 -0000 Subject: NAT66 and the subscriber prefix length In-Reply-To: <49243047.70204@imacandi.net> Message-ID: <C0F2465B4F386241A58321C884AC7ECC0978EA06@E03MVZ2-UKDY.domain1.systemhost.net> > My gripe was that I wanted to get an IPv6 allocation from > RIPE to start > testing how IPv6 would fit in the company that I work for and build a > dual stack network so that when the time comes, just switch > on IPv6 BGP > neighbors and update the DNS. > > But at almost 10.000 EUR per year it's an experiment I can't afford. That is not an experiment. An experiment is where you go to <https://www.sixxs.net/tools/grh/ula/>, generate your own unique RFC 4193 prefix, and then implement your IPv6 network using that. When you are ready to switch on BGP peering with the rest of the world, get a /32 from your RIR, and renumber the network leaving the interface IDs the same. If you are concerned that renumbering will be hard, go back and generate another ULA, and renumber your network as part of your experiment. --Michael Dillon From iljitsch at muada.com Wed Nov 19 09:46:05 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 19 Nov 2008 09:46:05 -0600 Subject: NAT66 and the subscriber prefix length In-Reply-To: <51FA4D2B-0E8D-4C74-9420-EE2564E96BD9@cisco.com> References: <C0F2465B4F386241A58321C884AC7ECC0961B7FB@E03MVZ2-UKDY.domain1.systemhost.net> <51FA4D2B-0E8D-4C74-9420-EE2564E96BD9@cisco.com> Message-ID: <25FA66EA-E412-4BEA-A5DB-FC2300AA6884@muada.com> On 14 nov 2008, at 14:55, Fred Baker wrote: > Before we get too deeply exercised, let Margaret and I huddle on it. > The issue you raised can be trivially solved by adding the checksum > offset to a different 16 bits in the address, such as bits 96..127. Being checksum-equivalent is important so all protocols that use the standard checksum keep working without the NAT66 specifically supporting those protocols. The trouble is that in one's complement math 0xFFFF is equivalent to 0x0000 which means that there is loss of information, so accommodating the difference in the lower bits means some nasty corner cases are possible, while if it's in the subnet bits you just lose one subnet. From nanog at jeffcalvert.com Wed Nov 19 11:18:22 2008 From: nanog at jeffcalvert.com (Jeff Calvert) Date: Wed, 19 Nov 2008 11:18:22 -0600 Subject: Adobe contact Message-ID: <466efcea0811190918w1f43b783k1f1efab4c13d651a@mail.gmail.com> Hello, Could someone from Adobe (AS1313) please contact me off list? I'm having some routing issues getting packets back from your network. Thanks, Jeff Calvert jeff at jeffcalvert.com jcalvert at cyrusone.com 713-821-1260 opt 2 (NOC) From Irwin.Lazar at nemertes.com Wed Nov 19 12:05:29 2008 From: Irwin.Lazar at nemertes.com (Irwin.Lazar at nemertes.com) Date: Wed, 19 Nov 2008 13:05:29 -0500 Subject: New Internet study released Message-ID: <OF5143818E.7F34F2D0-ON85257506.005C449E-85257506.0063613E@Nemertes.com> Hi All, Nemertes Research released a study on Internet Infrastructure this morning, this is an update to our 2007 study looking at Internet demand vs. growth of available bandwidth. This year's update also includes an examination of routing/addressing trends, IPv6 adoption, and potential of other solutions such as LISP and application-based addressing. It's freely available on our web site: http://www.nemertes.com/internet_interrupted_why_architectural_limitations_will_fracture_net thanks, irwin From leo.vegoda at icann.org Wed Nov 19 12:26:19 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 19 Nov 2008 10:26:19 -0800 Subject: NAT66 and the subscriber prefix length In-Reply-To: <49243047.70204@imacandi.net> Message-ID: <C54A18DB.21BDD%leo.vegoda@icann.org> On 19/11/2008 4:27, "Eugeniu Patrascu" <eugen at imacandi.net> wrote: [...] > My gripe was that I wanted to get an IPv6 allocation from RIPE to start > testing how IPv6 would fit in the company that I work for and build a > dual stack network so that when the time comes, just switch on IPv6 BGP > neighbors and update the DNS. > > But at almost 10.000 EUR per year it's an experiment I can't afford. Where did the 10k come from? According the the 2009 billing scheme (http://www.ripe.net/ripe/docs/ripe-437.html) the highest annual fee is ?5,500. The FAQ makes it clear that new members are automatically assigned to the Extra Small billing category (http://www.ripe.net/info/faq/membership/newlir-billing.html#2), putting membership and the sign-up fee at ?3,300. I don't remember the RIPE NCC trying to sell expensive extras like a car dealership. I'd be surprised if the prices quoted aren't the prices that everyone pays. Regards, Leo From sfischer1967 at gmail.com Wed Nov 19 13:53:48 2008 From: sfischer1967 at gmail.com (Steven Fischer) Date: Wed, 19 Nov 2008 14:53:48 -0500 Subject: Verizon outage between Baltimore and Washington Message-ID: <500ffb690811191153s6b07909dt1787a02872be6f5d@mail.gmail.com> Can someone on the list shed some more light on this? Verizon reports the 9 linear oc-48s are impacting 173 ds3s, 3 oc3cs, and 14 oc12cs. There is 1 unprotected oc192c down for TOT-A. OTDR readings from Baltimore place the break at 36.4 miles towards Washington. Additional OTDR readings from Laurel toward Washington indicate cut at 16.25 miles. Any additional info would be appreciated. -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From Valdis.Kletnieks at vt.edu Wed Nov 19 14:29:26 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 19 Nov 2008 15:29:26 -0500 Subject: Verizon outage between Baltimore and Washington In-Reply-To: Your message of "Wed, 19 Nov 2008 14:53:48 EST." <500ffb690811191153s6b07909dt1787a02872be6f5d@mail.gmail.com> References: <500ffb690811191153s6b07909dt1787a02872be6f5d@mail.gmail.com> Message-ID: <5546.1227126566@turing-police.cc.vt.edu> On Wed, 19 Nov 2008 14:53:48 EST, Steven Fischer said: > Can someone on the list shed some more light on this? Verizon reports the 9 > linear oc-48s are impacting 173 ds3s, 3 oc3cs, and 14 oc12cs. There is 1 > unprotected oc192c down for TOT-A. OTDR readings from Baltimore place the > break at 36.4 miles towards Washington. Additional OTDR readings from Laurel > toward Washington indicate cut at 16.25 miles. Are the two OTDR readings consistent with one break on a shared segment of the DC-Balt and DC-Laurel runs, or is some cable-splicer having a *really* long day ahead? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081119/8d358c00/attachment.bin> From sfischer1967 at gmail.com Wed Nov 19 14:41:54 2008 From: sfischer1967 at gmail.com (Steven Fischer) Date: Wed, 19 Nov 2008 15:41:54 -0500 Subject: Verizon outage between Baltimore and Washington In-Reply-To: <5546.1227126566@turing-police.cc.vt.edu> References: <500ffb690811191153s6b07909dt1787a02872be6f5d@mail.gmail.com> <5546.1227126566@turing-police.cc.vt.edu> Message-ID: <500ffb690811191241u6b8f40f1t88b58c94998046ff@mail.gmail.com> looks like a single break....Baltimore is about 36.4 miles north of Washington, and Laurel is about 16.25 miles north of Washington, with Baltimore being about 20 miles north of Laurel. All this makes sense. The part that doesn't really make sense is that our headquarters in right smack-dab along this run in Columbia, MD (about 5-7 miles north of Laruel), and has been unaffected...but a remote office in Hagerstown, about 50-60 miles west, north-west of here, is down hard. On Wed, Nov 19, 2008 at 3:29 PM, <Valdis.Kletnieks at vt.edu> wrote: > On Wed, 19 Nov 2008 14:53:48 EST, Steven Fischer said: > > Can someone on the list shed some more light on this? Verizon reports > the 9 > > linear oc-48s are impacting 173 ds3s, 3 oc3cs, and 14 oc12cs. There is 1 > > unprotected oc192c down for TOT-A. OTDR readings from Baltimore place the > > break at 36.4 miles towards Washington. Additional OTDR readings from > Laurel > > toward Washington indicate cut at 16.25 miles. > > Are the two OTDR readings consistent with one break on a shared segment > of the DC-Balt and DC-Laurel runs, or is some cable-splicer having a > *really* > long day ahead? > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From nanog at daork.net Wed Nov 19 15:02:29 2008 From: nanog at daork.net (Nathan Ward) Date: Thu, 20 Nov 2008 10:02:29 +1300 Subject: IPv6 routing /48s In-Reply-To: <874p234uxg.fsf@mid.deneb.enyo.de> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> <874p234uxg.fsf@mid.deneb.enyo.de> Message-ID: <FB540970-BE21-48E2-AACC-ACA5302FF2D2@daork.net> On 20/11/2008, at 4:06 AM, Florian Weimer wrote: > * Michael Sinatra: > >> And it just reinforces the fear that people have against putting AAAA >> records in DNS for their publicly-accessible resources, especially >> www. > > Won't current Windows clients work just fine in this case? > > I have no idea what a fix should look like for some of the non-Windows > systems I care about, unfortunately. No, unfortunately broken 6to4 auto-configuration (ie, in Vista, XPSP2, when on a non-RFC1918 IP address) breaks, and you get 90s timeouts before falling back to IPv4/A. Works fine most of the time, however when that non-RFC1918 address is behind NAT, or some sort of packet filter, then it doesn't work so well, and the client does not have a way to detect that reliably. -- Nathan Ward From trejrco at gmail.com Wed Nov 19 15:11:30 2008 From: trejrco at gmail.com (trejrco at gmail.com) Date: Wed, 19 Nov 2008 21:11:30 +0000 Subject: IPv6 routing /48s Message-ID: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> Ah yes, public-but-not-external IPv4 addresses ... I wish a stern note saying don't do that was feasible ... /TJ ------Original Message------ From: Nathan Ward To: nanog list Subject: Re: IPv6 routing /48s Sent: Nov 19, 2008 15:02 On 20/11/2008, at 4:06 AM, Florian Weimer wrote: > * Michael Sinatra: > >> And it just reinforces the fear that people have against putting AAAA >> records in DNS for their publicly-accessible resources, especially >> www. > > Won't current Windows clients work just fine in this case? > > I have no idea what a fix should look like for some of the non-Windows > systems I care about, unfortunately. No, unfortunately broken 6to4 auto-configuration (ie, in Vista, XPSP2, when on a non-RFC1918 IP address) breaks, and you get 90s timeouts before falling back to IPv4/A. Works fine most of the time, however when that non-RFC1918 address is behind NAT, or some sort of packet filter, then it doesn't work so well, and the client does not have a way to detect that reliably. -- Nathan Ward Sent from my Verizon Wireless BlackBerry From streiner at cluebyfour.org Wed Nov 19 15:19:19 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 19 Nov 2008 16:19:19 -0500 (EST) Subject: Verizon outage between Baltimore and Washington Message-ID: <Pine.LNX.4.64.0811191618580.29398@whammy.cluebyfour.org> On Wed, 19 Nov 2008, Steven Fischer wrote: > looks like a single break....Baltimore is about 36.4 miles north of > Washington, and Laurel is about 16.25 miles north of Washington, with > Baltimore being about 20 miles north of Laurel. All this makes sense. The > part that doesn't really make sense is that our headquarters in right > smack-dab along this run in Columbia, MD (about 5-7 miles north of Laruel), > and has been unaffected...but a remote office in Hagerstown, about 50-60 > miles west, north-west of here, is down hard. The circuit between you and your remote office could be DACS'd across several SONET rings between point A and B and if the cut took out one of those rings then you'd lose your circuit. Also, keep in mind that carriers love to call SONET rings redundant even when both the working and protect sides of it ride in the same conduit, or hell, even in the same buffer. That makes them a little more susceptible to backhoe fade. There are other possibilities as well, such as the protect side of the ring being down for maintenance when something hits the working side, the carrier screws up a re-groom, etc... jms From nanog at daork.net Wed Nov 19 15:34:28 2008 From: nanog at daork.net (Nathan Ward) Date: Thu, 20 Nov 2008 10:34:28 +1300 Subject: IPv6 routing /48s In-Reply-To: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> Message-ID: <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> On 20/11/2008, at 10:11 AM, trejrco at gmail.com wrote: > Ah yes, public-but-not-external IPv4 addresses ... I wish a stern > note saying don't do that was feasible ... What people do with their addresses is their business. The problem here is XPSP2/Vista assuming that non-RFC1918 = unfiltered/ unNATed for the purposes of 6to4. Well, deeper problem is that they're using 6to4 on an end host I suppose - it's supposed to be used on routers. I was going to write up a qualification mechanism for it so it could detect if 6to4 was OK or not, but code is already out there on umpteen million PCs that aren't going to do their patches. I still plan to.. hopefully I'll get around to it when I feel a bit less jaded :-) -- Nathan Ward From eslerj at gmail.com Wed Nov 19 15:39:59 2008 From: eslerj at gmail.com (Joel Esler) Date: Wed, 19 Nov 2008 16:39:59 -0500 Subject: Verizon outage between Baltimore and Washington In-Reply-To: <500ffb690811191241u6b8f40f1t88b58c94998046ff@mail.gmail.com> References: <500ffb690811191153s6b07909dt1787a02872be6f5d@mail.gmail.com> <5546.1227126566@turing-police.cc.vt.edu> <500ffb690811191241u6b8f40f1t88b58c94998046ff@mail.gmail.com> Message-ID: <C1CBAC6C-8644-4733-87A9-4C986C19ADA5@gmail.com> Just to agree, I am in Columbia, MD as well, and am unaffected. J On Nov 19, 2008, at 3:41 PM, Steven Fischer wrote: > looks like a single break....Baltimore is about 36.4 miles north of > Washington, and Laurel is about 16.25 miles north of Washington, with > Baltimore being about 20 miles north of Laurel. All this makes > sense. The > part that doesn't really make sense is that our headquarters in right > smack-dab along this run in Columbia, MD (about 5-7 miles north of > Laruel), > and has been unaffected...but a remote office in Hagerstown, about > 50-60 > miles west, north-west of here, is down hard. From trejrco at gmail.com Wed Nov 19 15:42:49 2008 From: trejrco at gmail.com (trejrco at gmail.com) Date: Wed, 19 Nov 2008 21:42:49 +0000 Subject: IPv6 routing /48s Message-ID: <1472914183-1227130848-cardhu_decombobulator_blackberry.rim.net-1917313859-@bxe324.bisx.prod.on.blackberry> Yeah, that's part of why it isn't feasible :) Also - a more generalized black-hole detection type mechanism (to also catch PMTUD failures, etc) would be mighty useful ... /TJ ------Original Message------ From: Nathan Ward To: nanog list Subject: Re: IPv6 routing /48s Sent: Nov 19, 2008 15:34 On 20/11/2008, at 10:11 AM, trejrco at gmail.com wrote: > Ah yes, public-but-not-external IPv4 addresses ... I wish a stern > note saying don't do that was feasible ... What people do with their addresses is their business. The problem here is XPSP2/Vista assuming that non-RFC1918 = unfiltered/ unNATed for the purposes of 6to4. Well, deeper problem is that they're using 6to4 on an end host I suppose - it's supposed to be used on routers. I was going to write up a qualification mechanism for it so it could detect if 6to4 was OK or not, but code is already out there on umpteen million PCs that aren't going to do their patches. I still plan to.. hopefully I'll get around to it when I feel a bit less jaded :-) -- Nathan Ward Sent from my Verizon Wireless BlackBerry From sfischer1967 at gmail.com Wed Nov 19 15:46:38 2008 From: sfischer1967 at gmail.com (Steven Fischer) Date: Wed, 19 Nov 2008 16:46:38 -0500 Subject: Verizon outage between Baltimore and Washington In-Reply-To: <C1CBAC6C-8644-4733-87A9-4C986C19ADA5@gmail.com> References: <500ffb690811191153s6b07909dt1787a02872be6f5d@mail.gmail.com> <5546.1227126566@turing-police.cc.vt.edu> <500ffb690811191241u6b8f40f1t88b58c94998046ff@mail.gmail.com> <C1CBAC6C-8644-4733-87A9-4C986C19ADA5@gmail.com> Message-ID: <500ffb690811191346k4339ce08xfc365c31e81d88f5@mail.gmail.com> Technician on site, and excavation has begun. Still no MTTR On Wed, Nov 19, 2008 at 4:39 PM, Joel Esler <eslerj at gmail.com> wrote: > Just to agree, I am in Columbia, MD as well, and am unaffected. > > J > > > On Nov 19, 2008, at 3:41 PM, Steven Fischer wrote: > > looks like a single break....Baltimore is about 36.4 miles north of >> Washington, and Laurel is about 16.25 miles north of Washington, with >> Baltimore being about 20 miles north of Laurel. All this makes sense. >> The >> part that doesn't really make sense is that our headquarters in right >> smack-dab along this run in Columbia, MD (about 5-7 miles north of >> Laruel), >> and has been unaffected...but a remote office in Hagerstown, about 50-60 >> miles west, north-west of here, is down hard. >> > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From jbates at brightok.net Wed Nov 19 16:05:20 2008 From: jbates at brightok.net (Jack Bates) Date: Wed, 19 Nov 2008 16:05:20 -0600 Subject: IPv6 routing /48s In-Reply-To: <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> Message-ID: <49248DA0.3070000@brightok.net> Nathan Ward wrote: > The problem here is XPSP2/Vista assuming that non-RFC1918 = > unfiltered/unNATed for the purposes of 6to4. > Well, deeper problem is that they're using 6to4 on an end host I suppose > - it's supposed to be used on routers. > While I don't doubt that the 6to4 is broken in such circumstances, how many IPv6 content providers are using 6to4 addressing and not 2001:: addressing? 6to4 by default on xp and vista, in my experience, is only used if a) talking to another 6to4 address or b) there is no IPv4 address available. 6to4 never seemed like a viable method for content providing, though its use at the eyeball layer is somewhat iffy given that it's primary use is for other 6to4 addresses. If prefix policies are altered to use it for 2001:: addressing, problems start arising quickly. A good example is that traceroutes through my he.net tunnel using 6to4 source addresses do not get replies through he.net's network, presumably due to their routers not being 6to4 aware and having no route to respond. Responses pick up again after picking up a network such as NTT that is 6to4 aware. My 2001:: addressing works just fine the entire route. I'm sure there's quite a few networks that aren't 6to4 aware, hindering 6to4 connectivity to non-6to4 addresses. Jack From dcurran at nuvox.com Wed Nov 19 14:46:57 2008 From: dcurran at nuvox.com (David Curran) Date: Wed, 19 Nov 2008 15:46:57 -0500 Subject: Quagga on Xen or VMWare etc Message-ID: <C549E571.27D00%dcurran@nuvox.com> Can anyone provide direction (anecdotal or otherwise) on the use of Quagga in a virtual environment for route servers? Thanks From michael at rancid.berkeley.edu Wed Nov 19 16:15:55 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 19 Nov 2008 14:15:55 -0800 Subject: IPv6 routing /48s In-Reply-To: <49248DA0.3070000@brightok.net> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> Message-ID: <4924901B.2060708@rancid.berkeley.edu> On 11/19/08 14:05, Jack Bates wrote: > Nathan Ward wrote: >> The problem here is XPSP2/Vista assuming that non-RFC1918 = >> unfiltered/unNATed for the purposes of 6to4. >> Well, deeper problem is that they're using 6to4 on an end host I >> suppose - it's supposed to be used on routers. >> > > While I don't doubt that the 6to4 is broken in such circumstances, how > many IPv6 content providers are using 6to4 addressing and not 2001:: > addressing? [other references to 2001:: addressing snipped] I hope I am not being toooo picky here, and I realize this is not part of your main point... If your reference to 2001:: addressing simply means "non-tunneled, globally routable IPv6 addressing," then I suppose it is okay. But please note that there is now a lot of native (non-tunneled), globally routable IPv6 addressing that is outside of 2001::/16. ARIN, for example, is allocating blocks out of 2607::/16 and there are quite a large number of prefixes elsewhere in the designated globally-routable 2000::/3 that are *not* 6to4 addresses. The reason I bring this up is that I have already seen certain applications, such as one for registering AAAA records for DNS servers in a certain TLD, that don't allow anything other than 2001::/16. (Fortunately that application was fixed quickly when those responsible were notified.) Just making sure others aren't careening toward making the same mistake. michael From trejrco at gmail.com Wed Nov 19 16:20:25 2008 From: trejrco at gmail.com (TJ) Date: Wed, 19 Nov 2008 16:20:25 -0600 Subject: IPv6 routing /48s In-Reply-To: <49248DA0.3070000@brightok.net> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> Message-ID: <012301c94a95$06b927f0$142b77d0$@com> Just for the record, I like my host being the degenerate case of "6to4 site + site router all in one". This makes my life much easier, as I frequently need IPv6 connectivity and frequently have a public IP(v4) address (EVDO, FTW). Having said that - what applies to me may well not be the common case. (Just wanted to state this in case MS is listening and was thinking about removing the functionality. I think the right approach is to detect the failure (s) when they occur, not to remove the functionality) /TJ >-----Original Message----- >From: Jack Bates [mailto:jbates at brightok.net] >Sent: Wednesday, November 19, 2008 4:05 PM >To: Nathan Ward >Cc: nanog list >Subject: Re: IPv6 routing /48s > >Nathan Ward wrote: >> The problem here is XPSP2/Vista assuming that non-RFC1918 = >> unfiltered/unNATed for the purposes of 6to4. >> Well, deeper problem is that they're using 6to4 on an end host I >> suppose >> - it's supposed to be used on routers. >> > >While I don't doubt that the 6to4 is broken in such circumstances, how many >IPv6 content providers are using 6to4 addressing and not 2001:: >addressing? 6to4 by default on xp and vista, in my experience, is only used >if a) talking to another 6to4 address or b) there is no IPv4 address >available. > >6to4 never seemed like a viable method for content providing, though its use >at the eyeball layer is somewhat iffy given that it's primary use is for >other 6to4 addresses. If prefix policies are altered to use it for >2001:: addressing, problems start arising quickly. > >A good example is that traceroutes through my he.net tunnel using 6to4 >source addresses do not get replies through he.net's network, presumably due >to their routers not being 6to4 aware and having no route to respond. >Responses pick up again after picking up a network such as NTT that is 6to4 >aware. My 2001:: addressing works just fine the entire route. > >I'm sure there's quite a few networks that aren't 6to4 aware, hindering >6to4 connectivity to non-6to4 addresses. > >Jack From joelja at bogus.com Wed Nov 19 16:27:01 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 19 Nov 2008 14:27:01 -0800 Subject: Quagga on Xen or VMWare etc In-Reply-To: <C549E571.27D00%dcurran@nuvox.com> References: <C549E571.27D00%dcurran@nuvox.com> Message-ID: <492492B5.2020908@bogus.com> David Curran wrote: > Can anyone provide direction (anecdotal or otherwise) on the use of Quagga > in a virtual environment for route servers? I run it in a real environment on a virtual machine (as a route reflector)... > Thanks > From trejrco at gmail.com Wed Nov 19 16:33:48 2008 From: trejrco at gmail.com (TJ) Date: Wed, 19 Nov 2008 16:33:48 -0600 Subject: IPv6 routing /48s In-Reply-To: <4924901B.2060708@rancid.berkeley.edu> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> <4924901B.2060708@rancid.berkeley.edu> Message-ID: <012401c94a96$e4f9dd60$aeed9820$@com> Yes, always worth reminding people: 2000::/3 is the currently active "Global Unicast" pool ... and that doesn't mean native IPv6 (2002::/16 = 6to4, 2001::/32 = Teredo ... ISATAP may be in play, and not discretely indicated in prefix side of address ... and non-auto tunnels cold be mentioned here as well, using global-scope prefixes ) Back to the topic at hand, and in the subject line, global routing of arbitrary /48s is far from guaranteed. /32 is the default cutoff (routing for /35s probably pretty reliable as well) Up to /48s for Critical Infra / Micro-Allocations and PI-designated blocks ... anything else AFAIK is quite possibly troublesome today. /TJ >-----Original Message----- >From: Michael Sinatra [mailto:michael at rancid.berkeley.edu] >Sent: Wednesday, November 19, 2008 4:16 PM >To: Jack Bates >Cc: nanog list >Subject: Re: IPv6 routing /48s > >On 11/19/08 14:05, Jack Bates wrote: >> Nathan Ward wrote: >>> The problem here is XPSP2/Vista assuming that non-RFC1918 = >>> unfiltered/unNATed for the purposes of 6to4. >>> Well, deeper problem is that they're using 6to4 on an end host I >>> suppose - it's supposed to be used on routers. >>> >> >> While I don't doubt that the 6to4 is broken in such circumstances, how >> many IPv6 content providers are using 6to4 addressing and not 2001:: >> addressing? > >[other references to 2001:: addressing snipped] > >I hope I am not being toooo picky here, and I realize this is not part of >your main point... > >If your reference to 2001:: addressing simply means "non-tunneled, globally >routable IPv6 addressing," then I suppose it is okay. But please note that >there is now a lot of native (non-tunneled), globally routable IPv6 >addressing that is outside of 2001::/16. ARIN, for example, is allocating >blocks out of 2607::/16 and there are quite a large number of prefixes >elsewhere in the designated globally-routable >2000::/3 that are *not* 6to4 addresses. > >The reason I bring this up is that I have already seen certain applications, >such as one for registering AAAA records for DNS servers in a certain TLD, >that don't allow anything other than 2001::/16. >(Fortunately that application was fixed quickly when those responsible were >notified.) Just making sure others aren't careening toward making the same >mistake. > >michael From morrowc.lists at gmail.com Wed Nov 19 16:37:53 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 19 Nov 2008 17:37:53 -0500 Subject: IPv6 routing /48s In-Reply-To: <49248DA0.3070000@brightok.net> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> Message-ID: <75cb24520811191437t171dd696rc46d554e4b751078@mail.gmail.com> On Wed, Nov 19, 2008 at 5:05 PM, Jack Bates <jbates at brightok.net> wrote: > Nathan Ward wrote: >> >> The problem here is XPSP2/Vista assuming that non-RFC1918 = >> unfiltered/unNATed for the purposes of 6to4. >> Well, deeper problem is that they're using 6to4 on an end host I suppose - >> it's supposed to be used on routers. >> > > While I don't doubt that the 6to4 is broken in such circumstances, how many > IPv6 content providers are using 6to4 addressing and not 2001:: addressing? 6to4 v6 addrs are just regular v6 addrs as far as the network is concerned. if you put a 6to4 addr on your server you are saying that you don't have native v6 transport to that host(s) and that you are reachable via the 6to4 tunnel your host presumably has configured. Content providers MIGHT put 6to4 addrs on their servers so that they appear to be 'closer' to their clients, or so they might better control the pathing between client/server... but that's really no different than a non-6to4 addr as far as the applications and network are concerned. > 6to4 never seemed like a viable method for content providing, though its use it doesn't seem clear that 6to4 buys the content provider much on their side of the pipe, sure. > at the eyeball layer is somewhat iffy given that it's primary use is for > other 6to4 addresses. If prefix policies are altered to use it for 2001:: > addressing, problems start arising quickly. 6to4 is just an ip, 128bits long, but an ip... no differentiation is made in the network for 6to4 vs 'normal v6'... unless someone's putting up acls, or blackholing 6to4's /16, of course. > A good example is that traceroutes through my he.net tunnel using 6to4 > source addresses do not get replies through he.net's network, presumably due > to their routers not being 6to4 aware and having no route to respond. can you explain this a little more? is it possible your v6 packets hit something like 6pe inside HE and exit to NTT without hitting a > Responses pick up again after picking up a network such as NTT that is 6to4 > aware. My 2001:: addressing works just fine the entire route. > '6to4 aware' doesn't compute... -chris From jbates at brightok.net Wed Nov 19 16:38:27 2008 From: jbates at brightok.net (Jack Bates) Date: Wed, 19 Nov 2008 16:38:27 -0600 Subject: IPv6 routing /48s In-Reply-To: <4924901B.2060708@rancid.berkeley.edu> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> <4924901B.2060708@rancid.berkeley.edu> Message-ID: <49249563.1010201@brightok.net> Michael Sinatra wrote: > If your reference to 2001:: addressing simply means "non-tunneled, > globally routable IPv6 addressing," then I suppose it is okay. But > please note that there is now a lot of native (non-tunneled), globally > routable IPv6 addressing that is outside of 2001::/16. ARIN, for > example, is allocating blocks out of 2607::/16 and there are quite a > large number of prefixes elsewhere in the designated globally-routable > 2000::/3 that are *not* 6to4 addresses. > heh, these days, lots of it is still tunneled, though through more conventional means. But yes, I should have been more clear. Just too used to seeing 2001::/16 and too lazy to figure out the proper terminology (The original topic is something I've been heavily testing lately while I figure out how closely I can get to customer edges and how they will react). > The reason I bring this up is that I have already seen certain > applications, such as one for registering AAAA records for DNS servers > in a certain TLD, that don't allow anything other than 2001::/16. > (Fortunately that application was fixed quickly when those responsible > were notified.) Just making sure others aren't careening toward making > the same mistake. Agreed, and thanks for correcting my post. Would hate for others to take my offhanded comments on addressing and use them in production apps. Jack From vicky at geeks.net.np Wed Nov 19 16:52:17 2008 From: vicky at geeks.net.np (Vicky Shrestha) Date: Thu, 20 Nov 2008 04:37:17 +0545 Subject: Quagga on Xen or VMWare etc In-Reply-To: <C549E571.27D00%dcurran@nuvox.com> References: <C549E571.27D00%dcurran@nuvox.com> Message-ID: <6BBF5114-E6F9-49DC-A5E7-B4940DE591D4@geeks.net.np> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 20, 2008, at 02:31 AM, David Curran wrote: > Can anyone provide direction (anecdotal or otherwise) on the use of > Quagga > in a virtual environment for route servers? We are running it as route collectors in a virtual environment. > > > Thanks > Regards, Vicky Shrestha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQEcBAEBAgAGBQJJJJihAAoJEGi4SIJCvhMLVbMIAI8J7Zmdmv8/sjVpoZqHpV/e X3AQrwTwgccEk/K/Z19akON3vavLHygu+SGuMvoE9bxONYi1aVrxdY5S98cnOFU/ B8GLZBRqjf/QlBEHfuFFYo/JaqM2bi0t+ml6Uchbzdzf/vDDdRv09cz6DsGoPKXr IRbQfQ90khgtmvlXq4CV1s1NKYh/KAwoAAo+ETEtK9worsfyngGV6Ovuerl/bbVJ d8CwtGyzwNKv+BrtWQ2WHK6JQXW6+WwYce6/ylspRciQOGxVzO0LQ3ZvnX1+LZM0 v4cD6CO0vWW2hIKDX+xG/IIpbNVIS54oWlRqZMC3LtUpoacePY0S+Q2VBgwWBos= =P0B3 -----END PGP SIGNATURE----- From nanog at daork.net Wed Nov 19 16:56:58 2008 From: nanog at daork.net (Nathan Ward) Date: Thu, 20 Nov 2008 11:56:58 +1300 Subject: IPv6 routing /48s In-Reply-To: <49248DA0.3070000@brightok.net> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> Message-ID: <AEBC2792-8C46-4DD8-AD21-9CD96525B83B@daork.net> On 20/11/2008, at 11:05 AM, Jack Bates wrote: > Nathan Ward wrote: >> The problem here is XPSP2/Vista assuming that non-RFC1918 = >> unfiltered/unNATed for the purposes of 6to4. >> Well, deeper problem is that they're using 6to4 on an end host I >> suppose - it's supposed to be used on routers. > > While I don't doubt that the 6to4 is broken in such circumstances, > how many IPv6 content providers are using 6to4 addressing and not > 2001:: addressing? 6to4 by default on xp and vista, in my > experience, is only used if a) talking to another 6to4 address or b) > there is no IPv4 address available. IPv6 will be used in preference to IPv4 if it is available. If 6to4 is the only IPv6 connectivity then it will be used. See RFC3484. Preference of IPv4 is 10, 6to4 is 30. Things are a bit different with Teredo.. In Vista, if Teredo is the only IPv6 connectivity available, WSAConnectByName will not send queries for AAAA - obviously Teredo can still be used if the application does its own name resolution and opens sockets by INET6 address, not name. This Teredo behaviour is not documented in an RFC anywhere I don't believe, it is Windows specific. > 6to4 never seemed like a viable method for content providing, though > its use at the eyeball layer is somewhat iffy given that it's > primary use is for other 6to4 addresses. If prefix policies are > altered to use it for 2001:: addressing, problems start arising > quickly. Right, so, because of how RFC3484 works the above is largely invalid. Because of RFC3484, putting 6to4 addresses on content is actually quite a good idea. It means that hosts with 6to4 connectivity only will not have to go via an RFC3068 (192.88.99.1) relay - they will go direct over an IPv4 best path between their 6to4 router and yours. This works best if RFC3484 is widely deployed - it is, however it does not exist on OS X. Because of this, if you do this you may find OS X clients visiting your content on a 6to4 address when they have native connectivity, or vice versa. So.. stuff to play with, and please go encourage Apple to do RFC3484 if you are a big customer of theirs. > A good example is that traceroutes through my he.net tunnel using > 6to4 source addresses do not get replies through he.net's network, > presumably due to their routers not being 6to4 aware and having no > route to respond. Responses pick up again after picking up a network > such as NTT that is 6to4 aware. My 2001:: addressing works just fine > the entire route. No, he.net does not have a 6to4 relay. If they did it would be used by a very large number of networks as he.net is fairly well peered. Because of that, the traffic would be quite high, and any relay deployment there would have to be managed quite carefully. > I'm sure there's quite a few networks that aren't 6to4 aware, > hindering 6to4 connectivity to non-6to4 addresses. 6to4 does not require networks to be 6to4 aware - the Internet has many public 6to4 relays available. Note though that most end user IPv6 hosts have a 6to4 relay within 3 IPv6 hops. This is easy to calculate - throw up an AAAA pointing only to a 2002::/16 address, and look at the HLIM of the IPv6 header (not the IPv4 header). You will see that it is generally between 124 and 128, or 60 and 64. (Some hosts start at 128, some 64. Few start at much else it seems.) I did some work looking at IPv6 adoption using Bittorrent DHT to talk to large numbers of peers without downloading any content, this was one of the interesting points that fell out of that work. Content providers wanting to put AAAA records on things should run 6to4 relays until IPv4-only networks are a thing of the past. If they don't, they'll have to rely on third party relays that might not work. -- Nathan Ward From jbates at brightok.net Wed Nov 19 17:03:44 2008 From: jbates at brightok.net (Jack Bates) Date: Wed, 19 Nov 2008 17:03:44 -0600 Subject: IPv6 routing /48s In-Reply-To: <75cb24520811191437t171dd696rc46d554e4b751078@mail.gmail.com> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> <75cb24520811191437t171dd696rc46d554e4b751078@mail.gmail.com> Message-ID: <49249B50.9060100@brightok.net> Christopher Morrow wrote: > 6to4 v6 addrs are just regular v6 addrs as far as the network is > concerned. if you put a 6to4 addr on your server you are saying that > you don't have native v6 transport to that host(s) and that you are > reachable via the 6to4 tunnel your host presumably has configured. > Sure it's just another address, except the anycast portion of it for dealing with tunnels. It's also usually set to a different label and priority in windows prefix policies (and at least some linux setups). I was referring to the matter of if a windows box will even choose to use 6to4. > 6to4 is just an ip, 128bits long, but an ip... no differentiation is > made in the network for 6to4 vs 'normal v6'... unless someone's > putting up acls, or blackholing 6to4's /16, of course. > Windows and several other end systems use prefix policies to determine if they use IPv6 or IPv4 and even when using IPv6, if they should use the 6to4 tunnel or not. > can you explain this a little more? is it possible your v6 packets hit > something like 6pe inside HE and exit to NTT without hitting a > If a router does not a) know how to encapsulate 6to4 and send it over ipv4 to the destination or b) know how to reach a 6to4 anycast address where the packet can be encapsulated into IPv4, the packet is going to get dropped. Of course, you could be right. he.net could be purposefully not sending icmp replies back to 6to4 addresses for other reasons while replying to my non-6to4 addresses. I hesitate to say filter, as it does push the 6to4 sourced packets on to other networks. Jack From mleber at he.net Wed Nov 19 17:16:26 2008 From: mleber at he.net (Mike Leber) Date: Wed, 19 Nov 2008 15:16:26 -0800 Subject: IPv6 routing /48s In-Reply-To: <75cb24520811191437t171dd696rc46d554e4b751078@mail.gmail.com> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> <75cb24520811191437t171dd696rc46d554e4b751078@mail.gmail.com> Message-ID: <49249E4A.4080708@he.net> Christopher Morrow wrote: >Jack Bates wrote: >> A good example is that traceroutes through my he.net tunnel using 6to4 >> source addresses do not get replies through he.net's network, presumably due >> to their routers not being 6to4 aware and having no route to respond. > > can you explain this a little more? is it possible your v6 packets hit > something like 6pe inside HE and exit to NTT without hitting a (Chris thank you for automatically going into customer service mode :) A bunch of background first, then some questions to help diagnose this specific case. We don't filter 6to4 in any way. We don't run 6PE. We don't operate any 6to4 gateways. We've been considering it carefully, and haven't taken the plunge. There is sort of a "routing the whole Internet for free" aspect that will occur as v6 takes off and it's not clear how one manages that (i.e. If you do it in the beginning until people depend on it and traffic grows to 100 Gbps and you no longer can afford to do it for free, do you stop? What about all the IPv4 traffic traveling directly between 6to4 gateways on IPv4? abuse, security, man in the middle by definition, etc). This means any 6to4 gateway action is happening on somebody's 6to4 gateway not operated by us. There are people that are using 6to4 on our network that works just fine. You can reach several 6to4 gateways on both IPv4 and IPv6 via our network. However, what is likely happening is a random 6to4 gateway operator may have seen fit to rate limit or filter ICMP. To properly diagnose 6to4 problems you potentially need as many as 4 traceroutes, IPv6 traceroutes from the source and destination endpoints and a IPv4 traceroutes to the 6to4 gateway addresses from the source and destination endpoint. There a few other tips I'm forgetting at the moment, however if you send us email (to ipv6 at he.net) we will make sure to research it thoroughly. Because 6to4 gateways are *anycast* the gateways you use in any part of the world in any part of a specific network may be different. This makes debugging it "interesting". >> Responses pick up again after picking up a network such as NTT that is 6to4 >> aware. My 2001:: addressing works just fine the entire route. > > '6to4 aware' doesn't compute... Jack, it seems you are saying traffic passes end to end just fine, you just don't get ICMP responses from some of the hops in the middle. Is this correct? If you would like, please send email to ipv6 at he.net with the detail regarding what you are seeing with all of the endpoint information and the traceroutes and we will work from our side to see where the "interesting" 6to4 gateway is that is affecting your traceroute. We will probably also need you to have access to the destination side as well. Mike. -- +---------------- H U R R I C A N E - E L E C T R I C ----------------+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric AS6939 | | mleber at he.net Internet Backbone & Colocation http://he.net | +---------------------------------------------------------------------+ From morrowc.lists at gmail.com Wed Nov 19 17:26:15 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 19 Nov 2008 18:26:15 -0500 Subject: IPv6 routing /48s In-Reply-To: <49249B50.9060100@brightok.net> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> <75cb24520811191437t171dd696rc46d554e4b751078@mail.gmail.com> <49249B50.9060100@brightok.net> Message-ID: <75cb24520811191526x7e211a9bg8a80e6643d49b203@mail.gmail.com> On Wed, Nov 19, 2008 at 6:03 PM, Jack Bates <jbates at brightok.net> wrote: > Christopher Morrow wrote: >> >> 6to4 v6 addrs are just regular v6 addrs as far as the network is >> concerned. if you put a 6to4 addr on your server you are saying that >> you don't have native v6 transport to that host(s) and that you are >> reachable via the 6to4 tunnel your host presumably has configured. >> > > Sure it's just another address, except the anycast portion of it for dealing > with tunnels. It's also usually set to a different label and priority in > windows prefix policies (and at least some linux setups). I was referring to > the matter of if a windows box will even choose to use 6to4. sure... address selection on new connections, standard ipv6 foo for end-hosts. routers in the middle don't care, they route to the /16 route for 2002::/16, or they route to 192.88.99.0/24 ... anycast'd on their respective sides of the version#. > >> 6to4 is just an ip, 128bits long, but an ip... no differentiation is >> made in the network for 6to4 vs 'normal v6'... unless someone's >> putting up acls, or blackholing 6to4's /16, of course. >> > > Windows and several other end systems use prefix policies to determine if > they use IPv6 or IPv4 and even when using IPv6, if they should use the 6to4 > tunnel or not. > right, normal address selection rules. >> can you explain this a little more? is it possible your v6 packets hit >> something like 6pe inside HE and exit to NTT without hitting a >> > > If a router does not a) know how to encapsulate 6to4 and send it over ipv4 routers in the middle shouldn't/won't do this.. once it's encap'd it rides (on v4) to the 192.88.99.1 device that does the 4->6 majics, then on to the v6 destination where it rides back to the 'local' 2002::/16 endpoint where 6->4 encap majics happen then over the v4 to you again. > to the destination or b) know how to reach a 6to4 anycast address where the > packet can be encapsulated into IPv4, the packet is going to get dropped. Of > course, you could be right. he.net could be purposefully not sending icmp > replies back to 6to4 addresses for other reasons while replying to my > non-6to4 addresses. I hesitate to say filter, as it does push the 6to4 > sourced packets on to other networks. hopefully mike's message gets it worked out :) -chris From jbates at brightok.net Wed Nov 19 17:54:36 2008 From: jbates at brightok.net (Jack Bates) Date: Wed, 19 Nov 2008 17:54:36 -0600 Subject: IPv6 routing /48s In-Reply-To: <49249E4A.4080708@he.net> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> <75cb24520811191437t171dd696rc46d554e4b751078@mail.gmail.com> <49249E4A.4080708@he.net> Message-ID: <4924A73C.1080304@brightok.net> Mike Leber wrote: > We don't operate any 6to4 gateways. This I suspected, and actually took as evidence based on the results from traceroutes. > However, what is likely happening is a random 6to4 gateway operator may > have seen fit to rate limit or filter ICMP. This may very well be true. I have nothing but love for he.net. However, the anycast nature of 6to4 does have it's issues. This was just a passing example that I noticed. Packets go through the network, but your network couldn't send ICMPv6 back. Actually not a concern for me, but I doubt it's the only 6to4 issue seen across the network. > To properly diagnose 6to4 problems you potentially need as many as 4 > traceroutes, IPv6 traceroutes from the source and destination endpoints > and a IPv4 traceroutes to the 6to4 gateway addresses from the source and > destination endpoint. There a few other tips I'm forgetting at the > moment, however if you send us email (to ipv6 at he.net) we will make sure > to research it thoroughly. Will do. Not that I care, but might be something you'll want to check into anyways. > Because 6to4 gateways are *anycast* the gateways you use in any part of > the world in any part of a specific network may be different. > > This makes debugging it "interesting". > Definitely, and another reason I am heavily against 6to4 except in cases where it's absolutely necessary. > Jack, it seems you are saying traffic passes end to end just fine, you > just don't get ICMP responses from some of the hops in the middle. Is > this correct? Correct, traceroute and ping find a void on the 2 routers I pass before I hit NTT's network in the test case I was doing. I haven't tested this in 1/2 a week, though. > If you would like, please send email to ipv6 at he.net with the detail > regarding what you are seeing with all of the endpoint information and > the traceroutes and we will work from our side to see where the > "interesting" 6to4 gateway is that is affecting your traceroute. We > will probably also need you to have access to the destination side as well. Will do. Be abit. The "interesting" part is primarily what it was mentioned. Though in another response I agreed that anyone using IPv6 from an end network should consider have 6to4 relays so as not to depend on someone else. In some cases, though, it's just not practical. FYI: Outside of testing, my link to he.net was to take what little 6to4 traffic I had on the network to non-6to4 addresses and give it a better chance. My nearest IPv4 anycast 6to4 was beyond horrid (major isolation). Heaviest traffic load appears to be p2p to teredo destinations. Jack From heather.schiller at verizonbusiness.com Wed Nov 19 18:16:43 2008 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Wed, 19 Nov 2008 19:16:43 -0500 Subject: Origin ASN seen vs Origin ASN in Whois Records Report? Message-ID: <4924AC6B.2030806@verizonbusiness.com> I don't know if a report like this already exists, but I haven't been able to find one. Can someone (CIDR Report? BGPMon? PCH?) offer a report that shows the discrepencies in Origin ASN according to the whois records, and routes in the [global/public] routing table? Publishing it on some regular interval would be even better. ARIN makes available a list of prefixes with OriginAS. I don't know if other RIR's do. ftp://ftp.arin.net/pub/originAS/ To be clear. I want a list of the prefixes where the actual origin ASN seen does not match the one in the whois record. Inconsistent Origin is fair game here. As a transit provider I'm interested in seeing what prefixes I am transiting for my customers that have this discrepancy, so something that shows the full path as part of the results would be most helpful. Thanks, --Heather -- ==================================================== Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management help4u at verizonbusiness.com ===================================================== From woody at pch.net Wed Nov 19 18:16:33 2008 From: woody at pch.net (Bill Woodcock) Date: Wed, 19 Nov 2008 16:16:33 -0800 (PST) Subject: Origin ASN seen vs Origin ASN in Whois Records Report? In-Reply-To: <4924AC6B.2030806@verizonbusiness.com> References: <4924AC6B.2030806@verizonbusiness.com> Message-ID: <Pine.SOC.4.61.0811191615110.13567@paixhost.pch.net> On Wed, 19 Nov 2008, Heather Schiller wrote: > I don't know if a report like this already exists, but I haven't been able > to find one. Can someone (CIDR Report? BGPMon? PCH?) offer a report that > shows the discrepencies in Origin ASN according to the whois records, and > routes in the [global/public] routing table? I'm pretty sure that we don't already generate that, though I'm checking to make sure. We do have all the necessary data sources already in our database and updated in real-time, so no problem to generate it. May take a day or two. -Bill From ops.lists at gmail.com Wed Nov 19 20:33:35 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 20 Nov 2008 08:03:35 +0530 Subject: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end Message-ID: <bb0e440a0811191833m6a7f20f9m8a6198945bfad592@mail.gmail.com> Hi We blocked some prefixes belonging to AS14037 (rackvibe llc) due to their hosting spammers. Rackvibe decided to nullroute us back in reply - thats up to them I guess Only they're dumb enough to inject these blackhole announcements into the cloud, and various other networks are picking up on these announcements TIA for filtering these out at your end Our IPs are below - at least 208.36.123/24 seems to be announced as a blackhole route by rackvibe - 205.158.62.0/24 208.36.123.0/24 203.86.166.0/24 65.49.50.0/24 65.49.50.0/24 64.71.166.192/27 64.62.181.80/28 srs Paths: (7 available, best #7, table Default-IP-Routing-Table) Not advertised to any peer 16150 6939 19318 14037 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 16150:63392 16150:65320 16150:65426 3333 1103 1273 19318 14037 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin IGP, localpref 100, valid, external Community: 1103:1000 1273:21000 1273:21971 14037:6855 19318:999 19318:4000 19318:6855 19318:40012 21698:999 21698:4000 21698:6855 3277 3216 1273 19318 14037 194.85.4.55 from 194.85.4.55 (194.85.4.16) Origin IGP, localpref 100, valid, external Community: 1273:21000 1273:21971 3216:3000 3216:3001 3277:3216 14037:6855 19318:999 19318:4000 19318:6855 19318:40012 21698:999 21698:4000 21698:6855 812 19318 14037 From mtinka at globaltransit.net Wed Nov 19 21:06:59 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 20 Nov 2008 11:06:59 +0800 Subject: Google/Yahoo - Geo-Location Issues Message-ID: <200811201107.04476.mtinka@globaltransit.net> Hi all. Grateful if someone from Google and Yahoo can contact me off-list re: some geo-location issues with their web sites, our side of the world. E-mail to the 'noc@' addresses seem to have > /dev/null'ed. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081120/4eb3fa7f/attachment.bin> From jasper at unleash.co.nz Wed Nov 19 21:10:50 2008 From: jasper at unleash.co.nz (Jasper Bryant-Greene) Date: Thu, 20 Nov 2008 16:10:50 +1300 Subject: Google/Yahoo - Geo-Location Issues In-Reply-To: <200811201107.04476.mtinka@globaltransit.net> References: <200811201107.04476.mtinka@globaltransit.net> Message-ID: <0F015002-D37E-49B0-A6CA-27792E814760@unleash.co.nz> Ditto for Google to me please, we are also having geo-location issues with various google.* domains. Thanks, Jasper On 20/11/2008, at 4:06 PM, Mark Tinka wrote: > Hi all. > > Grateful if someone from Google and Yahoo can contact me > off-list re: some geo-location issues with their web sites, > our side of the world. > > E-mail to the 'noc@' addresses seem to have > /dev/null'ed. > > Cheers, > > Mark. -- Jasper Bryant-Greene Network Engineer, Unleash ddi: +64 3 978 1222 mob: +64 21 129 9458 From ops.lists at gmail.com Wed Nov 19 22:08:40 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 20 Nov 2008 09:38:40 +0530 Subject: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end In-Reply-To: <bb0e440a0811191833m6a7f20f9m8a6198945bfad592@mail.gmail.com> References: <bb0e440a0811191833m6a7f20f9m8a6198945bfad592@mail.gmail.com> Message-ID: <bb0e440a0811192008g18e27cedq86b2282d19b02355@mail.gmail.com> These routes are also being injected by another AS belonging to Rackvibe - AS19318 This is the guy from rackvibe who said he'd blackhole us because we blocked him for hosting spammers. RNOCHandle: GC373-ARIN RNOCName: Czupryna, Gregg RNOCPhone: +1-201-605-1425 RNOCEmail: gregg at njiix.net RTechHandle: GC373-ARIN RTechName: Czupryna, Gregg RTechPhone: +1-201-605-1425 RTechEmail: gregg at njiix.net Network Next Hop Metric LocPrf Weight Path *>i 208.36.123.0 209.123.44.153 100 0 8001 19318 14037 i telnet route-server.quagga.net port 2605 shows various ASNs exclusively getting blackhole routes from AS19318 On Thu, Nov 20, 2008 at 8:03 AM, Suresh Ramasubramanian <ops.lists at gmail.com> wrote: > Hi > > We blocked some prefixes belonging to AS14037 (rackvibe llc) due to > their hosting spammers. > > Rackvibe decided to nullroute us back in reply - thats up to them I guess > > Only they're dumb enough to inject these blackhole announcements into > the cloud, and various other networks are picking up on these > announcements > > TIA for filtering these out at your end > > Our IPs are below - at least 208.36.123/24 seems to be announced as a > blackhole route by rackvibe - > > 205.158.62.0/24 > 208.36.123.0/24 > 203.86.166.0/24 > 65.49.50.0/24 > 65.49.50.0/24 > 64.71.166.192/27 > 64.62.181.80/28 > > srs > > Paths: (7 available, best #7, table Default-IP-Routing-Table) > Not advertised to any peer > 16150 6939 19318 14037 > 217.75.96.60 from 217.75.96.60 (217.75.96.60) > Origin IGP, metric 0, localpref 100, valid, external > Community: 16150:63392 16150:65320 16150:65426 > 3333 1103 1273 19318 14037 > 193.0.0.56 from 193.0.0.56 (193.0.0.56) > Origin IGP, localpref 100, valid, external > Community: 1103:1000 1273:21000 1273:21971 14037:6855 19318:999 > 19318:4000 19318:6855 19318:40012 21698:999 21698:4000 21698:6855 > 3277 3216 1273 19318 14037 > 194.85.4.55 from 194.85.4.55 (194.85.4.16) > Origin IGP, localpref 100, valid, external > Community: 1273:21000 1273:21971 3216:3000 3216:3001 3277:3216 > 14037:6855 19318:999 19318:4000 19318:6855 19318:40012 21698:999 > 21698:4000 21698:6855 > 812 19318 14037 > -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Wed Nov 19 22:43:12 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 20 Nov 2008 10:13:12 +0530 Subject: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end In-Reply-To: <bb0e440a0811192008g18e27cedq86b2282d19b02355@mail.gmail.com> References: <bb0e440a0811191833m6a7f20f9m8a6198945bfad592@mail.gmail.com> <bb0e440a0811192008g18e27cedq86b2282d19b02355@mail.gmail.com> Message-ID: <bb0e440a0811192043p756ef656u167b9387210aca20@mail.gmail.com> If you see 208.36.123.0/24 being announced from any other prefix than XO (2828 I guess) please ignore it. Especially if you see it announced from 19318 or 14037. On Thu, Nov 20, 2008 at 9:38 AM, Suresh Ramasubramanian <ops.lists at gmail.com> wrote: > These routes are also being injected by another AS belonging to > Rackvibe - AS19318 > > This is the guy from rackvibe who said he'd blackhole us because we > blocked him for hosting spammers. > > RNOCHandle: GC373-ARIN > RNOCName: Czupryna, Gregg > RNOCPhone: +1-201-605-1425 > RNOCEmail: gregg at njiix.net > > RTechHandle: GC373-ARIN > RTechName: Czupryna, Gregg > RTechPhone: +1-201-605-1425 > RTechEmail: gregg at njiix.net > > Network Next Hop Metric LocPrf Weight Path > *>i 208.36.123.0 209.123.44.153 100 0 8001 19318 > 14037 i > > telnet route-server.quagga.net port 2605 shows various ASNs > exclusively getting blackhole routes from AS19318 > > > > On Thu, Nov 20, 2008 at 8:03 AM, Suresh Ramasubramanian > <ops.lists at gmail.com> wrote: >> Hi >> >> We blocked some prefixes belonging to AS14037 (rackvibe llc) due to >> their hosting spammers. >> >> Rackvibe decided to nullroute us back in reply - thats up to them I guess >> >> Only they're dumb enough to inject these blackhole announcements into >> the cloud, and various other networks are picking up on these >> announcements >> >> TIA for filtering these out at your end >> >> Our IPs are below - at least 208.36.123/24 seems to be announced as a >> blackhole route by rackvibe - >> >> 205.158.62.0/24 >> 208.36.123.0/24 >> 203.86.166.0/24 >> 65.49.50.0/24 >> 65.49.50.0/24 >> 64.71.166.192/27 >> 64.62.181.80/28 >> >> srs >> >> Paths: (7 available, best #7, table Default-IP-Routing-Table) >> Not advertised to any peer >> 16150 6939 19318 14037 >> 217.75.96.60 from 217.75.96.60 (217.75.96.60) >> Origin IGP, metric 0, localpref 100, valid, external >> Community: 16150:63392 16150:65320 16150:65426 >> 3333 1103 1273 19318 14037 >> 193.0.0.56 from 193.0.0.56 (193.0.0.56) >> Origin IGP, localpref 100, valid, external >> Community: 1103:1000 1273:21000 1273:21971 14037:6855 19318:999 >> 19318:4000 19318:6855 19318:40012 21698:999 21698:4000 21698:6855 >> 3277 3216 1273 19318 14037 >> 194.85.4.55 from 194.85.4.55 (194.85.4.16) >> Origin IGP, localpref 100, valid, external >> Community: 1273:21000 1273:21971 3216:3000 3216:3001 3277:3216 >> 14037:6855 19318:999 19318:4000 19318:6855 19318:40012 21698:999 >> 21698:4000 21698:6855 >> 812 19318 14037 >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > -- Suresh Ramasubramanian (ops.lists at gmail.com) From kris.foster at gmail.com Wed Nov 19 23:11:05 2008 From: kris.foster at gmail.com (kris foster) Date: Wed, 19 Nov 2008 21:11:05 -0800 Subject: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end In-Reply-To: <bb0e440a0811192043p756ef656u167b9387210aca20@mail.gmail.com> References: <bb0e440a0811191833m6a7f20f9m8a6198945bfad592@mail.gmail.com> <bb0e440a0811192008g18e27cedq86b2282d19b02355@mail.gmail.com> <bb0e440a0811192043p756ef656u167b9387210aca20@mail.gmail.com> Message-ID: <D8B561CA-B1E1-454E-AB41-D24D42D5A8EF@gmail.com> On Nov 19, 2008, at 8:43 PM, Suresh Ramasubramanian wrote: > If you see 208.36.123.0/24 being announced from any other prefix than > XO (2828 I guess) please ignore it. Especially if you see it > announced from 19318 or 14037. > You're unlikely to get any reasonable response or action here. The best course of action is to work through XO. You are their customer, and it is their address space, right? For what it's worth 208.36.123.0/24 was advertised recently but as a community we have no way of knowing the validity of it, or the operational impact. Kris (not speaking as MLC) From ops.lists at gmail.com Wed Nov 19 23:19:27 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 20 Nov 2008 10:49:27 +0530 Subject: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end In-Reply-To: <D8B561CA-B1E1-454E-AB41-D24D42D5A8EF@gmail.com> References: <bb0e440a0811191833m6a7f20f9m8a6198945bfad592@mail.gmail.com> <bb0e440a0811192008g18e27cedq86b2282d19b02355@mail.gmail.com> <bb0e440a0811192043p756ef656u167b9387210aca20@mail.gmail.com> <D8B561CA-B1E1-454E-AB41-D24D42D5A8EF@gmail.com> Message-ID: <bb0e440a0811192119r5dbc1ec2n7710e09139e3c494@mail.gmail.com> Hi Yes we are on the phone with xo - but meanwhile several other operators have been picking it up. As for operational impact - we're Outblaze.com - thats mail.com, register.com hosted domains etc, email for 40 million users or so. That makes us, lemme see, quite a bit larger than people like Comcast, in terms of userbase for email. I hope that helps the community decide whether or not to accept these bogus blackhole prefixes thanks srs On Thu, Nov 20, 2008 at 10:41 AM, kris foster <kris.foster at gmail.com> wrote: > On Nov 19, 2008, at 8:43 PM, Suresh Ramasubramanian wrote: > >> If you see 208.36.123.0/24 being announced from any other prefix than >> XO (2828 I guess) please ignore it. Especially if you see it >> announced from 19318 or 14037. >> > > You're unlikely to get any reasonable response or action here. The best > course of action is to work through XO. You are their customer, and it is > their address space, right? > > For what it's worth 208.36.123.0/24 was advertised recently but as a > community we have no way of knowing the validity of it, or the operational > impact. > > Kris > (not speaking as MLC) > -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Wed Nov 19 23:20:30 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 20 Nov 2008 10:50:30 +0530 Subject: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end In-Reply-To: <bb0e440a0811192119r5dbc1ec2n7710e09139e3c494@mail.gmail.com> References: <bb0e440a0811191833m6a7f20f9m8a6198945bfad592@mail.gmail.com> <bb0e440a0811192008g18e27cedq86b2282d19b02355@mail.gmail.com> <bb0e440a0811192043p756ef656u167b9387210aca20@mail.gmail.com> <D8B561CA-B1E1-454E-AB41-D24D42D5A8EF@gmail.com> <bb0e440a0811192119r5dbc1ec2n7710e09139e3c494@mail.gmail.com> Message-ID: <bb0e440a0811192120n2e3f510eq7e50eda74e16ac73@mail.gmail.com> And the guy who is doing this is also an XO downstream as I see.. and I have a feeling he wont like the consequences of what he did .. but meanwhile, operationally speaking, my 40 million ++ users would be glad if these fake announcements could get cut off at the knees srs Head, Antispam Operations Outblaze Limited http://www.outblaze.com On Thu, Nov 20, 2008 at 10:49 AM, Suresh Ramasubramanian <ops.lists at gmail.com> wrote: > Hi > > Yes we are on the phone with xo - but meanwhile several other > operators have been picking it up. > > As for operational impact - we're Outblaze.com - thats mail.com, > register.com hosted domains etc, email for 40 million users or so. > That makes us, lemme see, quite a bit larger than people like Comcast, > in terms of userbase for email. > > I hope that helps the community decide whether or not to accept these > bogus blackhole prefixes > > thanks > srs > > On Thu, Nov 20, 2008 at 10:41 AM, kris foster <kris.foster at gmail.com> wrote: >> On Nov 19, 2008, at 8:43 PM, Suresh Ramasubramanian wrote: >> >>> If you see 208.36.123.0/24 being announced from any other prefix than >>> XO (2828 I guess) please ignore it. Especially if you see it >>> announced from 19318 or 14037. >>> >> >> You're unlikely to get any reasonable response or action here. The best >> course of action is to work through XO. You are their customer, and it is >> their address space, right? >> >> For what it's worth 208.36.123.0/24 was advertised recently but as a >> community we have no way of knowing the validity of it, or the operational >> impact. >> >> Kris >> (not speaking as MLC) >> > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > -- Suresh Ramasubramanian (ops.lists at gmail.com) From mhuff at ox.com Wed Nov 19 23:45:25 2008 From: mhuff at ox.com (Matthew Huff) Date: Thu, 20 Nov 2008 00:45:25 -0500 Subject: Level 3 OC-12 cut in SanFran/Hayw In-Reply-To: <bb0e440a0811192008g18e27cedq86b2282d19b02355@mail.gmail.com> References: <bb0e440a0811191833m6a7f20f9m8a6198945bfad592@mail.gmail.com> <bb0e440a0811192008g18e27cedq86b2282d19b02355@mail.gmail.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F91432284A74@PUR-EXCH07.ox.com> We lost a DS3 out of our downtown SF office around 4 hours ago. The Level 3 master ticket for OC-12 outage is #3020259 and is out of Hayworth. Anyone know anything more about this? Getting any info out of level 3 let alone an ETR has been challenging. From mohacsi at niif.hu Thu Nov 20 02:22:30 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 20 Nov 2008 09:22:30 +0100 (CET) Subject: IPv6 routing /48s In-Reply-To: <FB540970-BE21-48E2-AACC-ACA5302FF2D2@daork.net> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> <874p234uxg.fsf@mid.deneb.enyo.de> <FB540970-BE21-48E2-AACC-ACA5302FF2D2@daork.net> Message-ID: <alpine.BSF.2.00.0811200912550.60025@mignon.ki.iif.hu> On Thu, 20 Nov 2008, Nathan Ward wrote: > On 20/11/2008, at 4:06 AM, Florian Weimer wrote: > >> * Michael Sinatra: >> >>> And it just reinforces the fear that people have against putting AAAA >>> records in DNS for their publicly-accessible resources, especially >>> www. >> >> Won't current Windows clients work just fine in this case? >> >> I have no idea what a fix should look like for some of the non-Windows >> systems I care about, unfortunately. > > > No, unfortunately broken 6to4 auto-configuration (ie, in Vista, XPSP2, when > on a non-RFC1918 IP address) breaks, and you get 90s timeouts before falling > back to IPv4/A. This must be a broken RFC 3484 implementation: - 6to4 should be less prerefed than IPv4 if the service has both AAAA and A record. Regards, Janos Mohacsi From pekkas at netcore.fi Thu Nov 20 05:32:30 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 20 Nov 2008 13:32:30 +0200 (EET) Subject: IPv6 routing /48s In-Reply-To: <AEBC2792-8C46-4DD8-AD21-9CD96525B83B@daork.net> References: <1468069929-1227128970-cardhu_decombobulator_blackberry.rim.net-702252608-@bxe324.bisx.prod.on.blackberry> <48193722-778E-4027-B945-DDBA9F56B70F@daork.net> <49248DA0.3070000@brightok.net> <AEBC2792-8C46-4DD8-AD21-9CD96525B83B@daork.net> Message-ID: <alpine.LRH.2.00.0811201330210.22185@netcore.fi> On Thu, 20 Nov 2008, Nathan Ward wrote: > IPv6 will be used in preference to IPv4 if it is available. If 6to4 is the > only IPv6 connectivity then it will be used. See RFC3484. Preference of IPv4 > is 10, 6to4 is 30. However, in destination address selection "prefer matching scope" (comes up when v4 address is rfc1918) and "prefer matching label" is checked before preference. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From sven at cyberbunker.com Thu Nov 20 05:58:20 2008 From: sven at cyberbunker.com (HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP) Date: Thu, 20 Nov 2008 11:58:20 +0000 (GMT) Subject: Google/Yahoo - Geo-Location Issues In-Reply-To: <0F015002-D37E-49B0-A6CA-27792E814760@unleash.co.nz> References: <200811201107.04476.mtinka@globaltransit.net> <0F015002-D37E-49B0-A6CA-27792E814760@unleash.co.nz> Message-ID: <Pine.LNX.4.58.0811201148250.6558@scott.cb3rob.net> plenty of problems with that over here too. funnily enough google seems to completely ignore the coutry code in assigned PA/PI and only take the one in the PA -allocation- for the LIR itself (or more precisely, whichever the fuck stupid little country the LIR happened to be registered in at the moment the company was founded decades ago, as this is not easily updated, ending up with workstations in venezuela getting google in some obsolete crappy wannabe german dialect (dutch), which btw is considered completely obsolete for use on anything serious even in the netherlands itself. (maybe for ordering beer but that's about it) ;) they should just forget about this geolocation crap and just do it in english, unless specificed otherwise (for example, by going to www.google.de instead of google.com), provide an interface for the network administrator to set the default language for individual netblocks (which is something entirely different than the country code in whois, plently of offices in let's say dubai where people speak let's say french all day for example) or at the very minimum take the country code from the ASSIGNMENTS rather than the ALLOCATIONS (or just accept that countries and other languages are an obsolete concept and just force everyone to use english only, problem solved.) getting google in klingon is not much use, even if it would be the "local" klingon version of the country surrounding our building (which in most cases isn't much use either), it should still be network-block-owner definable On Thu, 20 Nov 2008, Jasper Bryant-Greene wrote: > Ditto for Google to me please, we are also having geo-location issues > with various google.* domains. > > Thanks, > Jasper > > On 20/11/2008, at 4:06 PM, Mark Tinka wrote: > > > Hi all. > > > > Grateful if someone from Google and Yahoo can contact me > > off-list re: some geo-location issues with their web sites, > > our side of the world. > > > > E-mail to the 'noc@' addresses seem to have > /dev/null'ed. > > > > Cheers, > > > > Mark. > > -- > Jasper Bryant-Greene > Network Engineer, Unleash > > ddi: +64 3 978 1222 > mob: +64 21 129 9458 > > > > X-CONTACT-FILTER-MATCH: "google" > X-CONTACT-FILTER-MATCH: "nanog" > From mhuff at ox.com Thu Nov 20 08:32:45 2008 From: mhuff at ox.com (Matthew Huff) Date: Thu, 20 Nov 2008 09:32:45 -0500 Subject: Level 3 OC-12 cut in SanFran/Hayw In-Reply-To: <08b301c94b19$2d22f0e0$4401a8c0@cerento.com> References: <bb0e440a0811191833m6a7f20f9m8a6198945bfad592@mail.gmail.com><bb0e440a0811192008g18e27cedq86b2282d19b02355@mail.gmail.com> <483E6B0272B0284BA86D7596C40D29F91432284A74@PUR-EXCH07.ox.com> <08b301c94b19$2d22f0e0$4401a8c0@cerento.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F91432284A86@PUR-EXCH07.ox.com> Keep waiting. I've been yet unsuccessful on getting a call back from anyone. They keep saying the same thing "it's part of a oc12 issue, field techs have been dispatch, please wait, no etr". Since that's now over 12 hours, I don't find it acceptable (not the down part, if it's part of a large cut, outage etc, I understand that), but rather their lack of information. I've escalated it to a "level 4 escalation" and they promised a callback within 15 minutes (which was 30 minutes ago). By any chance, were you originally a Broadwing customer? I have a feeling that the oc-12 that was disconnected was a mistake in their db caused by the acquisition, and since they may have lost the original info, they may have no choice but to re-engineer the circuits. -----Original Message----- From: Brandon Shiers [mailto:brandon.shiers at wyoming.com] Sent: Thursday, November 20, 2008 9:06 AM To: Matthew Huff; 'NANOG list' Subject: RE: Level 3 OC-12 cut in SanFran/Hayw I can tell you I have a DS3 here in Wyoming down because of this outage as well. 14 hours now it's been out and we haven't received anything from L3 unless I call and beat it out of them. I am waiting on a CB from a supervisor right now. -----Original Message----- From: nanog-bounces at nanog.org [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Huff Sent: Wednesday, November 19, 2008 10:45 PM To: NANOG list Subject: Level 3 OC-12 cut in SanFran/Hayw We lost a DS3 out of our downtown SF office around 4 hours ago. The Level 3 master ticket for OC-12 outage is #3020259 and is out of Hayworth. Anyone know anything more about this? Getting any info out of level 3 let alone an ETR has been challenging. From cidr-report at potaroo.net Fri Nov 21 05:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Nov 2008 22:00:02 +1100 (EST) Subject: BGP Update Report Message-ID: <200811211100.mALB02PS090658@wattle.apnic.net> BGP Update Report Interval: 20-Oct-08 -to- 20-Nov-08 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 193657 1.6% 38.1 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS9583 193365 1.6% 162.9 -- SIFY-AS-IN Sify Limited 3 - AS10396 143531 1.2% 2474.7 -- COQUI-NET - DATACOM CARIBE, INC. 4 - AS6389 130827 1.1% 29.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 5 - AS1803 85966 0.7% 60.6 -- ICMNET-5 - Sprint 6 - AS6629 84544 0.7% 1300.7 -- NOAA-AS - NOAA 7 - AS209 73219 0.6% 23.3 -- ASN-QWEST - Qwest Communications Corporation 8 - AS29282 69396 0.6% 23132.0 -- EMENTOR-AS Enfo Oyj 9 - AS20115 67855 0.6% 29.0 -- CHARTER-NET-HKY-NC - Charter Communications 10 - AS23126 64248 0.6% 275.7 -- CENTURYTEL-SOLUTIONS-LLC - CenturyTel Solutions, LLC 11 - AS8151 55648 0.5% 39.3 -- Uninet S.A. de C.V. 12 - AS6298 52709 0.5% 24.6 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 13 - AS2386 50591 0.4% 30.5 -- INS-AS - AT&T Data Communications Services 14 - AS1785 48678 0.4% 28.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 15 - AS34116 47022 0.4% 470.2 -- CYBER-AS Cyber Net AS 16 - AS6458 46003 0.4% 114.2 -- Telgua 17 - AS14106 45697 0.4% 22848.5 -- LEPMED01 - Leprechaun, LLC 18 - AS6478 45085 0.4% 26.7 -- ATT-INTERNET3 - AT&T WorldNet Services 19 - AS7018 44569 0.4% 30.2 -- ATT-INTERNET4 - AT&T WorldNet Services 20 - AS7643 42615 0.4% 27.9 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29282 69396 0.6% 23132.0 -- EMENTOR-AS Enfo Oyj 2 - AS14106 45697 0.4% 22848.5 -- LEPMED01 - Leprechaun, LLC 3 - AS43299 9709 0.1% 9709.0 -- TELECONTACT-AS Telecontact Ltd. 4 - AS30287 6429 0.1% 6429.0 -- ALON-USA - ALON USA, LP 5 - AS22492 13574 0.1% 4524.7 -- 6 - AS40194 4209 0.0% 4209.0 -- INHOUSE-ASSOCIATES-LC - Inhouse Associates, L.C. 7 - AS37026 7700 0.1% 3850.0 -- SALT-ASN 8 - AS14220 17992 0.1% 3598.4 -- I2A - I 20 Access 9 - AS14593 3497 0.0% 3497.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 10 - AS4130 16261 0.1% 3252.2 -- UPITT-AS - University of Pittsburgh 11 - AS25799 3250 0.0% 3250.0 -- HOLMAN - Holman Enterprises 12 - AS41007 15591 0.1% 3118.2 -- CTCASTANA CTC ASTANA, KZ 13 - AS5033 26266 0.2% 2918.4 -- ISW - Internet Specialties West Inc. 14 - AS28194 14074 0.1% 2814.8 -- 15 - AS30969 21480 0.2% 2685.0 -- TAN-NET TransAfrica Networks 16 - AS10396 143531 1.2% 2474.7 -- COQUI-NET - DATACOM CARIBE, INC. 17 - AS47731 2468 0.0% 2468.0 -- ISDC-AS SC ISDC ROMANIA SRL 18 - AS23917 2319 0.0% 2319.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 19 - AS48131 2059 0.0% 2059.0 -- VANGUARD-BG-AS Vanguard SA 20 - AS22247 2005 0.0% 2005.0 -- LETOURNEAUUNIVERSITY - LeTourneau University TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 221.134.222.0/24 61640 0.5% AS9583 -- SIFY-AS-IN Sify Limited 2 - 210.214.151.0/24 57932 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 77.95.144.0/22 47824 0.4% AS29282 -- EMENTOR-AS Enfo Oyj 4 - 221.135.80.0/24 40588 0.3% AS9583 -- SIFY-AS-IN Sify Limited 5 - 192.102.88.0/24 26905 0.2% AS6629 -- NOAA-AS - NOAA 6 - 198.77.177.0/24 26549 0.2% AS6629 -- NOAA-AS - NOAA 7 - 192.35.129.0/24 26543 0.2% AS6629 -- NOAA-AS - NOAA 8 - 64.162.116.0/24 26051 0.2% AS5033 -- ISW - Internet Specialties West Inc. 9 - 8.192.154.0/24 24907 0.2% AS14106 -- LEPMED01 - Leprechaun, LLC 10 - 194.126.143.0/24 24674 0.2% AS9051 -- IDM Autonomous System 11 - 192.12.120.0/24 24632 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 12 - 217.69.48.0/20 21553 0.2% AS29282 -- EMENTOR-AS Enfo Oyj 13 - 65.44.76.0/24 20790 0.2% AS14106 -- LEPMED01 - Leprechaun, LLC 14 - 221.128.192.0/18 18168 0.1% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 15 - 150.212.224.0/19 16152 0.1% AS4130 -- UPITT-AS - University of Pittsburgh 16 - 200.33.104.0/23 13714 0.1% AS21603 -- Universidad La Salle, AC 17 - 12.2.46.0/24 13530 0.1% AS22492 -- 18 - 89.4.131.0/24 12531 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 19 - 203.63.26.0/24 11031 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 20 - 196.27.104.0/21 10409 0.1% AS30969 -- TAN-NET TransAfrica Networks Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Nov 21 05:00:00 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Nov 2008 22:00:00 +1100 (EST) Subject: The Cidr Report Message-ID: <200811211100.mALB00kj090651@wattle.apnic.net> This report has been generated at Fri Nov 21 21:25:56 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 14-11-08 287463 175819 15-11-08 288017 176099 16-11-08 288342 1 17-11-08 1 176622 18-11-08 288552 177404 19-11-08 288990 177113 20-11-08 290680 178437 21-11-08 291693 179577 AS Summary 30068 Number of ASes in routing system 12708 Number of ASes announcing only one prefix 5063 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 89764864 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 21Nov08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 291934 179551 112383 38.5% All ASes AS4538 5063 877 4186 82.7% ERX-CERNET-BKB China Education and Research Network Center AS6389 4380 361 4019 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 3009 1336 1673 55.6% ASN-QWEST - Qwest Communications Corporation AS6298 2158 900 1258 58.3% ASN-CXA-PH-6298-CBS - Cox Communications Inc. AS17488 1428 299 1129 79.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1702 606 1096 64.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS4323 1592 516 1076 67.6% TWTC - tw telecom holdings, inc. AS4755 1207 214 993 82.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1013 85 928 91.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS6478 1677 760 917 54.7% ATT-INTERNET3 - AT&T WorldNet Services AS8151 1401 570 831 59.3% Uninet S.A. de C.V. AS11492 1217 470 747 61.4% CABLEONE - CABLE ONE, INC. AS2386 1604 923 681 42.5% INS-AS - AT&T Data Communications Services AS19262 930 256 674 72.5% VZGNI-TRANSIT - Verizon Internet Services Inc. AS4766 1150 495 655 57.0% KIXS-AS-KR Korea Telecom AS18101 788 177 611 77.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS9498 690 116 574 83.2% BBIL-AP BHARTI Airtel Ltd. AS3356 1089 516 573 52.6% LEVEL3 Level 3 Communications AS18566 1059 552 507 47.9% COVAD - Covad Communications Co. AS7545 663 168 495 74.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS4808 634 158 476 75.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 597 134 463 77.6% CANET-ASN-4 - Bell Aliant AS24560 623 173 450 72.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 522 79 443 84.9% GIGAINFRA BB TECHNOLOGY Corp. AS7018 1439 998 441 30.6% ATT-INTERNET4 - AT&T WorldNet Services AS9443 525 84 441 84.0% INTERNETPRIMUS-AS-AP Primus Telecommunications AS22047 568 154 414 72.9% VTR BANDA ANCHA S.A. AS4668 695 282 413 59.4% LGNET-AS-KR LG CNS AS4780 735 330 405 55.1% SEEDNET Digital United Inc. AS4804 501 100 401 80.0% MPX-AS Microplex PTY LTD Total 40659 12689 27970 68.8% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.187.0.0/16 AS20928 NOOR-AS 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.212.32.0/19 AS34797 EGRISI-AS Egrisi JSC. 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 91.207.236.0/23 AS3329 Hellas Online SA 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 100.10.10.0/24 AS14000 AXTEL, S.A. de C.V. 119.31.232.0/21 AS38870 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 124.109.16.0/21 AS38137 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 169.254.0.0/16 AS13184 HANSENET HanseNet Telekommunikation GmbH 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 193.9.24.0/24 AS6746 ASTRAL ASTRAL Telecom SA, Romania 193.178.118.0/24 AS30836 NET23-AS 23VNET Ltd. 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.0.187.0/24 AS19132 200.5.32.0/21 AS19132 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/21 AS38205 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.67.64.0/20 AS43554 CDS-AS Cifrovye Dispetcherskie Sistemy 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From fw at deneb.enyo.de Fri Nov 21 09:55:42 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 21 Nov 2008 16:55:42 +0100 Subject: IPv6 routing /48s In-Reply-To: <alpine.BSF.2.00.0811200912550.60025@mignon.ki.iif.hu> (Mohacsi Janos's message of "Thu, 20 Nov 2008 09:22:30 +0100 (CET)") References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> <874p234uxg.fsf@mid.deneb.enyo.de> <FB540970-BE21-48E2-AACC-ACA5302FF2D2@daork.net> <alpine.BSF.2.00.0811200912550.60025@mignon.ki.iif.hu> Message-ID: <878wrdrs3l.fsf@mid.deneb.enyo.de> * Mohacsi Janos: > On Thu, 20 Nov 2008, Nathan Ward wrote: > >> On 20/11/2008, at 4:06 AM, Florian Weimer wrote: >> >>> * Michael Sinatra: >>> >>>> And it just reinforces the fear that people have against putting AAAA >>>> records in DNS for their publicly-accessible resources, especially >>>> www. >>> >>> Won't current Windows clients work just fine in this case? >>> >>> I have no idea what a fix should look like for some of the non-Windows >>> systems I care about, unfortunately. Do you mean that the client tries to enable 6to4 unsuccessfully? >> No, unfortunately broken 6to4 auto-configuration (ie, in Vista, >> XPSP2, when on a non-RFC1918 IP address) breaks, and you get 90s >> timeouts before falling back to IPv4/A. > > This must be a broken RFC 3484 implementation: > - 6to4 should be less prerefed than IPv4 if the service has both AAAA > and A record. RFC 3848 generally prefers IPv6 over IPv4 and fails if the host running its algorithm has neither IPv6 connectivity nore mean to detect that efficiently. I think Windows does something in the second area. From jbates at brightok.net Fri Nov 21 10:16:11 2008 From: jbates at brightok.net (Jack Bates) Date: Fri, 21 Nov 2008 10:16:11 -0600 Subject: IPv6 routing /48s In-Reply-To: <878wrdrs3l.fsf@mid.deneb.enyo.de> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> <874p234uxg.fsf@mid.deneb.enyo.de> <FB540970-BE21-48E2-AACC-ACA5302FF2D2@daork.net> <alpine.BSF.2.00.0811200912550.60025@mignon.ki.iif.hu> <878wrdrs3l.fsf@mid.deneb.enyo.de> Message-ID: <4926DECB.5050501@brightok.net> Florian Weimer wrote: >>> No, unfortunately broken 6to4 auto-configuration (ie, in Vista, >>> XPSP2, when on a non-RFC1918 IP address) breaks, and you get 90s >>> timeouts before falling back to IPv4/A. >> This must be a broken RFC 3484 implementation: >> - 6to4 should be less prerefed than IPv4 if the service has both AAAA >> and A record. > > RFC 3848 generally prefers IPv6 over IPv4 and fails if the host > running its algorithm has neither IPv6 connectivity nore mean to > detect that efficiently. I think Windows does something in the second > area. Yes and no. The test that was being run used 6to4 addresses, so every 6to4 capable device did try to reach it via 6to4, since that is preferred over IPv4. If it had used non-6to4 addressing, then IPv4 would had been preferred on those hosts that didn't have non-6to4 addresses. This is one reason why I believe using 6to4 addresses to be an issue for content providers. If they use non-6to4 addressing for the content, then most people will prefer IPv4 except for those who have configured non-6to4 addresses or altered the labels to force 6to4 to work with non-6to4 addressing. Gads, is it appropriate to just say Native when referring to non-6to4? lol Jack From cscora at apnic.net Fri Nov 21 12:12:16 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Nov 2008 04:12:16 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200811211812.mALICGj7003246@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <pfs at cisco.com>. Routing Table Report 04:00 +10GMT Sat 22 Nov, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 274832 Prefixes after maximum aggregation: 131770 Deaggregation factor: 2.09 Unique aggregates announced to Internet: 133162 Total ASes present in the Internet Routing Table: 29863 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 26014 Origin ASes announcing only one prefix: 12666 Transit ASes present in the Internet Routing Table: 3849 Transit-only ASes present in the Internet Routing Table: 85 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 19 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 539 Unregistered ASNs in the Routing Table: 195 Number of 32-bit ASNs allocated by the RIRs: 65 Prefixes from 32-bit ASNs in the Routing Table: 9 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 200 Number of addresses announced to Internet: 1960189952 Equivalent to 116 /8s, 214 /16s and 32 /24s Percentage of available address space announced: 52.9 Percentage of allocated address space announced: 63.2 Percentage of available address space allocated: 83.7 Percentage of address space in use by end-sites: 74.4 Total number of prefixes smaller than registry allocations: 135548 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62781 Total APNIC prefixes after maximum aggregation: 23297 APNIC Deaggregation factor: 2.69 Prefixes being announced from the APNIC address blocks: 59732 Unique aggregates announced from the APNIC address blocks: 26968 APNIC Region origin ASes present in the Internet Routing Table: 3467 APNIC Prefixes per ASN: 17.23 APNIC Region origin ASes announcing only one prefix: 939 APNIC Region transit ASes present in the Internet Routing Table: 535 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 385251744 Equivalent to 22 /8s, 246 /16s and 121 /24s Percentage of available APNIC address space announced: 76.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124396 Total ARIN prefixes after maximum aggregation: 64922 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 93713 Unique aggregates announced from the ARIN address blocks: 34784 ARIN Region origin ASes present in the Internet Routing Table: 12613 ARIN Prefixes per ASN: 7.43 ARIN Region origin ASes announcing only one prefix: 4877 ARIN Region transit ASes present in the Internet Routing Table: 1193 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 401255584 Equivalent to 23 /8s, 234 /16s and 172 /24s Percentage of available ARIN address space announced: 82.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 60483 Total RIPE prefixes after maximum aggregation: 36191 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 56086 Unique aggregates announced from the RIPE address blocks: 37394 RIPE Region origin ASes present in the Internet Routing Table: 12213 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 6430 RIPE Region transit ASes present in the Internet Routing Table: 1854 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 379496800 Equivalent to 22 /8s, 158 /16s and 169 /24s Percentage of available RIPE address space announced: 87.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22382 Total LACNIC prefixes after maximum aggregation: 5571 LACNIC Deaggregation factor: 4.02 Prefixes being announced from the LACNIC address blocks: 20411 Unique aggregates announced from the LACNIC address blocks: 11400 LACNIC Region origin ASes present in the Internet Routing Table: 1030 LACNIC Prefixes per ASN: 19.82 LACNIC Region origin ASes announcing only one prefix: 338 LACNIC Region transit ASes present in the Internet Routing Table: 168 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 58127616 Equivalent to 3 /8s, 118 /16s and 245 /24s Percentage of available LACNIC address space announced: 57.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4273 Total AfriNIC prefixes after maximum aggregation: 1359 AfriNIC Deaggregation factor: 3.14 Prefixes being announced from the AfriNIC address blocks: 4575 Unique aggregates announced from the AfriNIC address blocks: 2171 AfriNIC Region origin ASes present in the Internet Routing Table: 270 AfriNIC Prefixes per ASN: 16.94 AfriNIC Region origin ASes announcing only one prefix: 82 AfriNIC Region transit ASes present in the Internet Routing Table: 56 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12953856 Equivalent to 0 /8s, 197 /16s and 169 /24s Percentage of available AfriNIC address space announced: 25.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 17488 1425 100 114 Hathway IP Over Cable Interne 4755 1182 474 155 TATA Communications formerly 9583 1149 87 480 Sify Limited 4766 1092 6409 364 Korea Telecom (KIX) 4134 905 14768 370 CHINANET-BACKBONE 23577 809 35 696 Korea Telecom (ATM-MPLS) 18101 786 167 31 Reliance Infocom Ltd Internet 4780 731 357 63 Digital United Inc. 9498 689 295 50 BHARTI BT INTERNET LTD. 7545 642 152 80 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4370 3434 344 bellsouth.net, inc. 209 3000 4032 619 Qwest 6298 2151 333 633 Cox Communicatons 20115 1840 1461 735 Charter Communications 1785 1701 717 155 PaeTec Communications, Inc. 6478 1677 369 200 AT&T Worldnet Services 2386 1592 701 901 AT&T Data Communications Serv 4323 1586 1068 376 Time Warner Telecom 7018 1411 5869 974 AT&T WorldNet Services 11492 1217 192 12 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 429 1766 380 TDC Tele Danmark 12479 370 578 6 Uni2 Autonomous System 30890 366 95 188 SC Kappa Invexim SRL 3301 338 1429 307 TeliaNet Sweden 29049 338 26 3 AzerSat LLC. 8866 336 111 23 Bulgarian Telecommunication C 3320 323 7062 272 Deutsche Telekom AG 8452 323 188 11 TEDATA 3215 316 2788 99 France Telecom Transpac 8551 303 286 36 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1400 2832 221 UniNet S.A. de C.V. 11830 671 299 9 Instituto Costarricense de El 10620 563 128 55 TVCABLE BOGOTA 22047 533 270 14 VTR PUNTO NET S.A. 7303 496 244 71 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 425 88 50 ENTEL CHILE S.A. 11172 402 118 72 Servicios Alestra S.A de C.V 28573 347 469 24 NET Servicos de Comunicao S.A 14117 331 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 562 71 46 LINKdotNET AS number 3741 271 857 227 The Internet Solution 20858 261 34 3 EgyNet 2018 238 215 138 Tertiary Education Network 29571 147 13 8 Ci Telecom Autonomous system 6713 144 135 11 Itissalat Al-MAGHRIB 33783 141 10 15 EEPAD TISP TELECOM & INTERNET 5713 121 555 70 Telkom SA Ltd 5536 120 8 17 Internet Egypt Network 33776 116 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4370 3434 344 bellsouth.net, inc. 209 3000 4032 619 Qwest 6298 2151 333 633 Cox Communicatons 20115 1840 1461 735 Charter Communications 1785 1701 717 155 PaeTec Communications, Inc. 6478 1677 369 200 AT&T Worldnet Services 2386 1592 701 901 AT&T Data Communications Serv 4323 1586 1068 376 Time Warner Telecom 17488 1425 100 114 Hathway IP Over Cable Interne 7018 1411 5869 974 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 3000 2381 Qwest 1785 1701 1546 PaeTec Communications, Inc. 6298 2151 1518 Cox Communicatons 6478 1677 1477 AT&T Worldnet Services 17488 1425 1311 Hathway IP Over Cable Interne 4323 1586 1210 Time Warner Telecom 11492 1217 1205 Cable One 8151 1400 1179 UniNet S.A. de C.V. 20115 1840 1105 Charter Communications 18566 1059 1049 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.187.0.0/16 20928 Noor Advanced Technologies AS 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 62.212.32.0/19 34797 Egrisi JSC. Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:19 /11:54 /12:157 /13:307 /14:546 /15:1078 /16:10163 /17:4466 /18:7697 /19:16573 /20:19448 /21:19173 /22:24314 /23:24952 /24:143111 /25:843 /26:1009 /27:789 /28:88 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2856 4370 bellsouth.net, inc. 6298 2125 2151 Cox Communicatons 209 1720 3000 Qwest 2386 1271 1592 AT&T Data Communications Serv 17488 1215 1425 Hathway IP Over Cable Interne 11492 1192 1217 Cable One 1785 1161 1701 PaeTec Communications, Inc. 6478 1106 1677 AT&T Worldnet Services 18566 1040 1059 Covad Communications 9583 1015 1149 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 4:12 8:157 12:2178 13:2 15:21 16:3 17:5 20:36 24:1124 30:1 32:54 38:517 40:93 41:811 43:1 44:2 47:12 52:3 55:3 56:3 57:27 58:497 59:551 60:455 61:1041 62:1131 63:2015 64:3286 65:2436 66:3532 67:1332 68:845 69:2356 70:897 71:170 72:2087 73:7 74:1304 75:169 76:288 77:891 78:518 79:291 80:936 81:864 82:583 83:409 84:587 85:1047 86:507 87:656 88:348 89:1367 90:29 91:1684 92:309 93:975 94:676 95:29 96:91 97:137 98:394 99:15 100:1 113:39 114:128 115:153 116:1035 117:407 118:291 119:551 120:106 121:645 122:819 123:455 124:832 125:1186 128:359 129:219 130:136 131:406 132:72 133:9 134:187 135:31 136:224 137:118 138:144 139:85 140:417 141:111 142:393 143:315 144:301 145:53 146:373 147:143 148:600 149:209 150:143 151:210 152:140 153:131 154:10 155:276 156:175 157:301 158:168 159:297 160:274 161:132 162:249 163:135 164:517 165:509 166:361 167:339 168:628 169:155 170:455 171:40 172:10 173:140 174:5 187:18 188:1 189:321 190:2392 192:5825 193:4131 194:3288 195:2626 196:1026 198:3714 199:3299 200:5523 201:1474 202:7637 203:8069 204:3936 205:2179 206:2298 207:2772 208:3734 209:3440 210:2622 211:1122 212:1547 213:1649 214:69 215:25 216:4390 217:1241 218:352 219:412 220:1073 221:437 222:308 End of report From michael.holstein at csuohio.edu Fri Nov 21 12:44:22 2008 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Fri, 21 Nov 2008 13:44:22 -0500 Subject: Google/Yahoo - Geo-Location Issues In-Reply-To: <Pine.LNX.4.58.0811201148250.6558@scott.cb3rob.net> References: <200811201107.04476.mtinka@globaltransit.net> <0F015002-D37E-49B0-A6CA-27792E814760@unleash.co.nz> <Pine.LNX.4.58.0811201148250.6558@scott.cb3rob.net> Message-ID: <49270186.8080301@csuohio.edu> > they should just forget about this geolocation crap and just do it in > english, unless specificed otherwise (for example, by going to > www.google.de instead of google.com), They do, albeit not directly ... www.google.com/ncr Regards, Michael Holstein Cleveland State University From jml at packetpimp.org Fri Nov 21 14:29:48 2008 From: jml at packetpimp.org (Jason LeBlanc) Date: Fri, 21 Nov 2008 15:29:48 -0500 Subject: US <-> UK connectivity recommendations Message-ID: <49271A3C.6050708@packetpimp.org> Hi all, Looking for experiences with different carriers for layer 2 connectivity between US and UK. I have not received the bandwidth needs as yet but I am assuming 100mb/s. I am already in talks with a few. Thanks, Jason From peter.serwe at gmail.com Fri Nov 21 15:01:12 2008 From: peter.serwe at gmail.com (Peter Serwe) Date: Fri, 21 Nov 2008 13:01:12 -0800 Subject: NANOG Digest, Vol 10, Issue 71 In-Reply-To: <mailman.78416.1227265226.43406.nanog@nanog.org> References: <mailman.78416.1227265226.43406.nanog@nanog.org> Message-ID: <d3d177bd0811211301q41180e35p52508386446d7bf9@mail.gmail.com> > > Message: 1 > Date: Thu, 20 Nov 2008 09:32:45 -0500 > From: Matthew Huff <mhuff at ox.com> > Subject: RE: Level 3 OC-12 cut in SanFran/Hayw > To: Brandon Shiers <brandon.shiers at wyoming.com> > Cc: "nanog at nanog.org" <nanog at nanog.org> > Message-ID: > <483E6B0272B0284BA86D7596C40D29F91432284A86 at PUR-EXCH07.ox.com> > Content-Type: text/plain; charset="us-ascii" > > Keep waiting. I've been yet unsuccessful on getting a call back from anyone. They keep saying the same thing "it's part of a oc12 issue, field techs have been dispatch, please wait, no etr". Since that's now over 12 hours, I don't find it acceptable (not the down part, if it's part of a large cut, outage etc, I understand that), but rather their lack of information. I've escalated it to a "level 4 escalation" and they promised a callback within 15 minutes (which was 30 minutes ago). > > By any chance, were you originally a Broadwing customer? I have a feeling that the oc-12 that was disconnected was a mistake in their db caused by the acquisition, and since they may have lost the original info, they may have no choice but to re-engineer the circuits. > > > > -----Original Message----- > From: Brandon Shiers [mailto:brandon.shiers at wyoming.com] > Sent: Thursday, November 20, 2008 9:06 AM > To: Matthew Huff; 'NANOG list' > Subject: RE: Level 3 OC-12 cut in SanFran/Hayw > > I can tell you I have a DS3 here in Wyoming down because of this outage as > well. 14 hours now it's been out and we haven't received anything from L3 > unless I call and beat it out of them. I am waiting on a CB from a > supervisor right now. > > > > -----Original Message----- > From: nanog-bounces at nanog.org [mailto:nanog-bounces at nanog.org] On Behalf Of > Matthew Huff > Sent: Wednesday, November 19, 2008 10:45 PM > To: NANOG list > Subject: Level 3 OC-12 cut in SanFran/Hayw > > We lost a DS3 out of our downtown SF office around 4 hours ago. The Level 3 > master ticket for OC-12 outage is #3020259 and is out of Hayworth. Anyone > know anything more about this? Getting any info out of level 3 let alone an > ETR has been challenging. Level 3's customer service in general, and trouble resolution is the worst I have ever experienced in the industry. On several occasions, I have had to call them repeatedly (on average 6 times) to get any meaningful response at all. Even then, it has taken weeks to resolve very simple issues. Were I to be making the choice, I would never do business with Level 3 because of it. I also have it directly from Level 3 field engineers that they experience the exact same loss of productivity and level of frustration working with their own organization, and have no direct access to the backline support organization. As long as I don't have any problems I need to call them for, they are reasonably decent otherwise. One additional note: Based on prior experience with them, when they tell you they have escalated it, often they have not, if you do not demand to wait on the phone to speak with someone who can address your issue, getting a callback pretty much will never happen. Peter -- ???? From mhuff at ox.com Fri Nov 21 15:06:09 2008 From: mhuff at ox.com (Matthew Huff) Date: Fri, 21 Nov 2008 16:06:09 -0500 Subject: NANOG Digest, Vol 10, Issue 71 In-Reply-To: <d3d177bd0811211301q41180e35p52508386446d7bf9@mail.gmail.com> References: <mailman.78416.1227265226.43406.nanog@nanog.org> <d3d177bd0811211301q41180e35p52508386446d7bf9@mail.gmail.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F91432284AD1@PUR-EXCH07.ox.com> >Based on prior experience with them, when they tell you they have escalated it, often they have not, if you do not demand to wait on the phone to >speak with someone who can address your issue, getting a callback pretty much will never happen. I agree with this 100%. They are anxious to tell you they will call you right back, but never do. You cannot let them try that if you want to get anything accomplished. I got lucky. A backline engineer was reading my message on the outages list with his iPhone and accidently hit reply. Once he was outed, he was tremendously helpful and got us fixed within 30 minutes. He agreed that their support system was abysmal. He claimed that senior management was aware of the issues and were working to redo the entire support system, but who knows. We are already looking at other providers. -----Original Message----- From: Peter Serwe [mailto:peter.serwe at gmail.com] Sent: Friday, November 21, 2008 4:01 PM To: Matthew Huff Cc: nanog at nanog.org Subject: Re: NANOG Digest, Vol 10, Issue 71 > > Message: 1 > Date: Thu, 20 Nov 2008 09:32:45 -0500 > From: Matthew Huff <mhuff at ox.com> > Subject: RE: Level 3 OC-12 cut in SanFran/Hayw > To: Brandon Shiers <brandon.shiers at wyoming.com> > Cc: "nanog at nanog.org" <nanog at nanog.org> > Message-ID: > <483E6B0272B0284BA86D7596C40D29F91432284A86 at PUR-EXCH07.ox.com> > Content-Type: text/plain; charset="us-ascii" > > Keep waiting. I've been yet unsuccessful on getting a call back from anyone. They keep saying the same thing "it's part of a oc12 issue, field techs have been dispatch, please wait, no etr". Since that's now over 12 hours, I don't find it acceptable (not the down part, if it's part of a large cut, outage etc, I understand that), but rather their lack of information. I've escalated it to a "level 4 escalation" and they promised a callback within 15 minutes (which was 30 minutes ago). > > By any chance, were you originally a Broadwing customer? I have a feeling that the oc-12 that was disconnected was a mistake in their db caused by the acquisition, and since they may have lost the original info, they may have no choice but to re-engineer the circuits. > > > > -----Original Message----- > From: Brandon Shiers [mailto:brandon.shiers at wyoming.com] > Sent: Thursday, November 20, 2008 9:06 AM > To: Matthew Huff; 'NANOG list' > Subject: RE: Level 3 OC-12 cut in SanFran/Hayw > > I can tell you I have a DS3 here in Wyoming down because of this outage as > well. 14 hours now it's been out and we haven't received anything from L3 > unless I call and beat it out of them. I am waiting on a CB from a > supervisor right now. > > > > -----Original Message----- > From: nanog-bounces at nanog.org [mailto:nanog-bounces at nanog.org] On Behalf Of > Matthew Huff > Sent: Wednesday, November 19, 2008 10:45 PM > To: NANOG list > Subject: Level 3 OC-12 cut in SanFran/Hayw > > We lost a DS3 out of our downtown SF office around 4 hours ago. The Level 3 > master ticket for OC-12 outage is #3020259 and is out of Hayworth. Anyone > know anything more about this? Getting any info out of level 3 let alone an > ETR has been challenging. Level 3's customer service in general, and trouble resolution is the worst I have ever experienced in the industry. On several occasions, I have had to call them repeatedly (on average 6 times) to get any meaningful response at all. Even then, it has taken weeks to resolve very simple issues. Were I to be making the choice, I would never do business with Level 3 because of it. I also have it directly from Level 3 field engineers that they experience the exact same loss of productivity and level of frustration working with their own organization, and have no direct access to the backline support organization. As long as I don't have any problems I need to call them for, they are reasonably decent otherwise. One additional note: Based on prior experience with them, when they tell you they have escalated it, often they have not, if you do not demand to wait on the phone to speak with someone who can address your issue, getting a callback pretty much will never happen. Peter -- ???? From woody at pch.net Fri Nov 21 20:35:41 2008 From: woody at pch.net (Bill Woodcock) Date: Fri, 21 Nov 2008 18:35:41 -0800 Subject: Origin ASN seen vs Origin ASN in Whois Records Report? In-Reply-To: <4924AC6B.2030806@verizonbusiness.com> References: <4924AC6B.2030806@verizonbusiness.com> Message-ID: <4794A528-4DCC-480C-8A11-212746FF97D7@pch.net> On Nov 19, 2008, at 4:16 PM, Heather Schiller wrote: > I don't know if a report like this already exists, but I haven't > been able to find one. Can someone (CIDR Report? BGPMon? PCH?) > offer a report that shows the discrepencies in Origin ASN according > to the whois records, and routes in the [global/public] routing table? http://www.pch.net/routing-origin-inconsistency/ From the help page: "This tool identifies inconsistencies between the autonomous systems which the Regional Internet Registries believe are authoritative origins for routing announcements of each IP address prefix, and those which are actually announcing the prefixes to PCH's global network of looking glasses. The tool produces two lists of inconsistent origins: the list at the top of the page, which contains prefixes that are being announced by ASNs apparently unrelated to the putatively-authoritative ones; and the list at the bottom of the page, which contains prefixes with minor or apparently harmless inconsistencies, mainly subsets of large authoritative sets, and different ASNs operated by the same organization." > Publishing it on some regular interval would be even better. It's updated daily at midnight UTC. We don't presently spam any lists with our various reports and analyses. I guess we could add a subscription feature, though. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081121/df61ba87/attachment.bin> From woody at pch.net Fri Nov 21 22:01:53 2008 From: woody at pch.net (Bill Woodcock) Date: Fri, 21 Nov 2008 20:01:53 -0800 Subject: Origin ASN seen vs Origin ASN in Whois Records Report? In-Reply-To: <4794A528-4DCC-480C-8A11-212746FF97D7@pch.net> References: <4924AC6B.2030806@verizonbusiness.com> <4794A528-4DCC-480C-8A11-212746FF97D7@pch.net> Message-ID: <9D5020D9-D50E-4D47-A862-AC4757ACF129@pch.net> > http://www.pch.net/routing-origin-inconsistency/ Andrew Partan just pointed out to me that this is somewhat less useful than it might be if the way we do our web apps were a little more fully documented. There are tool-tips on organization names, which show the actual AS numbers. And you can sort on any column by clicking on the column-heading. Click again to reverse the sort order. We'll add drill-down to show the actual AS-paths in the next day or two. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081121/bfda1ad1/attachment.bin> From eugen at imacandi.net Sat Nov 22 13:36:21 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sat, 22 Nov 2008 21:36:21 +0200 Subject: NAT66 and the subscriber prefix length In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC0978EA06@E03MVZ2-UKDY.domain1.systemhost.net> References: <C0F2465B4F386241A58321C884AC7ECC0978EA06@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <49285F35.9040205@imacandi.net> michael.dillon at bt.com wrote: >> My gripe was that I wanted to get an IPv6 allocation from >> RIPE to start >> testing how IPv6 would fit in the company that I work for and build a >> dual stack network so that when the time comes, just switch >> on IPv6 BGP >> neighbors and update the DNS. >> >> But at almost 10.000 EUR per year it's an experiment I can't afford. > > That is not an experiment. I was hoping to do it in one step with my own IPv6 PI space and do the allocation and routing on the servers/routers/firewalls, see how that goes and when the time was right, just announce my prefix to the world :) > An experiment is where you go to <https://www.sixxs.net/tools/grh/ula/>, > generate your own unique RFC 4193 prefix, and then implement your IPv6 > network using that. When you are ready to switch on BGP peering with the > rest of the world, get a /32 from your RIR, and renumber the network > leaving > the interface IDs the same. Thanks for the URL, I was not aware of it. I guess I'll have to experiment with prefixes from that and see hot it goes. > > If you are concerned that renumbering will be hard, go back and generate > another ULA, and renumber your network as part of your experiment. > I'll probably do that also. Thanks. From fw at deneb.enyo.de Sun Nov 23 08:28:13 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 23 Nov 2008 15:28:13 +0100 Subject: Google/Yahoo - Geo-Location Issues In-Reply-To: <49270186.8080301@csuohio.edu> (Michael Holstein's message of "Fri, 21 Nov 2008 13:44:22 -0500") References: <200811201107.04476.mtinka@globaltransit.net> <0F015002-D37E-49B0-A6CA-27792E814760@unleash.co.nz> <Pine.LNX.4.58.0811201148250.6558@scott.cb3rob.net> <49270186.8080301@csuohio.edu> Message-ID: <87y6za5xfm.fsf@mid.deneb.enyo.de> * Michael Holstein: >> they should just forget about this geolocation crap and just do it in >> english, unless specificed otherwise (for example, by going to >> www.google.de instead of google.com), > > They do, albeit not directly ... www.google.com/ncr This doesn't work anymore, AFAICT. I get a redirect to the German homepage, serving results for the German market. From niels=nanog at bakker.net Sun Nov 23 11:07:25 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Sun, 23 Nov 2008 18:07:25 +0100 Subject: Google/Yahoo - Geo-Location Issues In-Reply-To: <87y6za5xfm.fsf@mid.deneb.enyo.de> References: <200811201107.04476.mtinka@globaltransit.net> <0F015002-D37E-49B0-A6CA-27792E814760@unleash.co.nz> <Pine.LNX.4.58.0811201148250.6558@scott.cb3rob.net> <49270186.8080301@csuohio.edu> <87y6za5xfm.fsf@mid.deneb.enyo.de> Message-ID: <20081123170725.GG78345@burnout.tpb.net> * fw at deneb.enyo.de (Florian Weimer) [Sun 23 Nov 2008, 15:28 CET]: >* Michael Holstein: >> They do, albeit not directly ... www.google.com/ncr > This doesn't work anymore, AFAICT. I get a redirect to the German > homepage, serving results for the German market. http://www.google.com/intl/en/ has continued to work for me -- Niels. -- "We humans get marks for consistency. We always opt for civilization after exhausting the alternatives." -- Carl Guderian From jabley at hopcount.ca Sun Nov 23 13:52:06 2008 From: jabley at hopcount.ca (Joe Abley) Date: Sun, 23 Nov 2008 14:52:06 -0500 Subject: Origin ASN seen vs Origin ASN in Whois Records Report? In-Reply-To: <4924AC6B.2030806@verizonbusiness.com> References: <4924AC6B.2030806@verizonbusiness.com> Message-ID: <004D0474-1D21-4D63-BE49-D48369C02AC7@hopcount.ca> On 19 Nov 2008, at 19:16, Heather Schiller wrote: > ARIN makes available a list of prefixes with OriginAS. I don't know > if other RIR's do. How is that list generated? I'm not aware of any tight coupling between address assignment and AS assignment that binds anybody to advertise particular routes with particular origins, at least at the time that either is assigned/ allocated by an RIR/LIR. Without such a coupling, would a report along the lines that you suggest implicate the advertisement, or the "whois record" (whatever that means)? Joe From roll at Stupi.SE Sun Nov 23 21:06:32 2008 From: roll at Stupi.SE (Peter Lothberg) Date: Sun, 23 Nov 2008 21:06:32 CET Subject: First Transatlantic 40G IP-Router--(optics only)--IP-Router link Message-ID: <CMM.0.90.0.1227470792.roll@avfall.stupi.se> Just want to announce for the history record that last week we did OC768/STM256 NY/USA-Lulea/SE using routers with integrated optics all the way. Longest hopp was SeaGirt to Blabjerg at some 7500km using RX-DPSK modulation on the underwather cable. Interface facing submarine cable in Denmark when link came up.. POS0/5/0/0 is up, line protocol is up Interface state transitions: 235948 Hardware is Packet over SONET/SDH Description: "TAT14 Chan 14, fiber 2 to SeaGirt" Internet address is 192.108.195.29/30 MTU 4474 bytes, BW 39813120 Kbit reliability 255/255, txload 14/255, rxload 0/255 Encapsulation HDLC, crc 32, controller loopback not set, keepalive not set Last clearing of "show interface" counters 00:20:14 30 second input rate 145190000 bits/sec, 33312 packets/sec 30 second output rate 2277465000 bits/sec, 333788 packets/sec 38828898 packets input, 20633312397 bytes, 10 total input drops 0 drops for unrecognized upper-level protocol Received 0 runts, 0 giants, 0 throttles, 0 parity 10 input errors, 10 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 325196864 packets output, 276372852009 bytes, 0 total output drops 0 output errors, 0 underruns, 0 applique, 0 resets 0 output buffer failures, 0 output buffers swapped out --Peter From roll at Stupi.SE Sun Nov 23 21:13:33 2008 From: roll at Stupi.SE (Peter Lothberg) Date: Sun, 23 Nov 2008 21:13:33 CET Subject: First Transatlantic 40G IP-Router--(optics only)--IP-Router link In-Reply-To: Your message of Sun, 23 Nov 2008 21:06:32 CET Message-ID: <CMM.0.90.0.1227471213.roll@avfall.stupi.se> Sorry, I made a typo. > RX-DPSK modulation on the underwather cable. Should be "RZ-DPSK modulation...." - Peter From stephen at sprunk.org Sun Nov 23 20:17:32 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 23 Nov 2008 20:17:32 -0600 Subject: Origin ASN seen vs Origin ASN in Whois Records Report? In-Reply-To: <004D0474-1D21-4D63-BE49-D48369C02AC7@hopcount.ca> References: <4924AC6B.2030806@verizonbusiness.com> <004D0474-1D21-4D63-BE49-D48369C02AC7@hopcount.ca> Message-ID: <492A0EBC.9030402@sprunk.org> Joe Abley wrote: > On 19 Nov 2008, at 19:16, Heather Schiller wrote: >> ARIN makes available a list of prefixes with OriginAS. I don't know >> if other RIR's do. > > How is that list generated? > > I'm not aware of any tight coupling between address assignment and AS > assignment that binds anybody to advertise particular routes with > particular origins, at least at the time that either is > assigned/allocated by an RIR/LIR. > Presumably it's from the "Origin AS" field in WHOIS: http://www.arin.net/registration/templates/netmod.txt Template: ARIN-NET-MOD-4.1 ** As of February 2007 ** Detailed instructions are located below the template. 01. Registration Action (M or R): 02. IP Address and Prefix or Range: 03. Network Name: 04. Origin AS: ... 04. List all AS numbers from which the network may originate. You can list as many AS numbers as necessary. You must separate multiple AS numbers with a comma. You may not list AS number ranges; only list individual AS numbers. Interesting is how accurate the field actually is. Slide 6 at: http://www.arin.net/meetings/minutes/ARIN_XXII/PDF/friday/engineering_report.pdf says that 91% of the routes they checked had a correct Origin AS in WHOIS, compared to 64% in the ARIN IRR database. S -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081123/b347c28c/attachment.bin> From jabley at hopcount.ca Sun Nov 23 20:21:00 2008 From: jabley at hopcount.ca (Joe Abley) Date: Sun, 23 Nov 2008 21:21:00 -0500 Subject: Origin ASN seen vs Origin ASN in Whois Records Report? In-Reply-To: <492A0EBC.9030402@sprunk.org> References: <4924AC6B.2030806@verizonbusiness.com> <004D0474-1D21-4D63-BE49-D48369C02AC7@hopcount.ca> <492A0EBC.9030402@sprunk.org> Message-ID: <4A6ED636-C162-438C-AB33-63426B0D0623@hopcount.ca> On 23 Nov 2008, at 21:17, Stephen Sprunk wrote: > Presumably it's from the "Origin AS" field in WHOIS: Ah, thanks (and also thanks to others who pointed that out off-list). That seems like a weird anachronism, to be honest. Perhaps it's only because nobody has ever tried to use it for anything that there's never been any reason for the ARIN community to propose that the collection of such information be stopped. Joe From johnmusbach1 at gmail.com Mon Nov 24 01:14:54 2008 From: johnmusbach1 at gmail.com (John Musbach) Date: Mon, 24 Nov 2008 02:14:54 -0500 Subject: How do dialup ISPs allow multiple clients under one access number? Message-ID: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> I'm interested in figuring out how dialup ISPs work and have found plenty of info on dialin server setup but not much on how ISPs allow multiple clients under one access number, how do they do it? -- Best Regards, John Musbach From mike.lyon at gmail.com Mon Nov 24 02:26:43 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 24 Nov 2008 00:26:43 -0800 Subject: How do dialup ISPs allow multiple clients under one access number? In-Reply-To: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> References: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> Message-ID: <1b5c1c150811240026k61623489ycf17e263113655e0@mail.gmail.com> Google "hunt-groups" and that should explain it. Cheers, Mike On Sun, Nov 23, 2008 at 11:14 PM, John Musbach <johnmusbach1 at gmail.com> wrote: > I'm interested in figuring out how dialup ISPs work and have found > plenty of info on dialin server setup but not much on how ISPs allow > multiple clients under one access number, how do they do it? > > -- > Best Regards, > > John Musbach > > From choprboy at dakotacom.net Mon Nov 24 04:03:41 2008 From: choprboy at dakotacom.net (Choprboy) Date: Mon, 24 Nov 2008 03:03:41 -0700 Subject: How do dialup ISPs allow multiple clients under one access number? In-Reply-To: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> References: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> Message-ID: <200811240303.42106.choprboy@dakotacom.net> On Monday 24 November 2008 00:14, John Musbach wrote: > I'm interested in figuring out how dialup ISPs work and have found > plenty of info on dialin server setup but not much on how ISPs allow > multiple clients under one access number, how do they do it? One phone number != one phone line. Each phone circuit has a single associated billing/account number. Notice I say circuit, not line, which is 1 or more channels over some medium. It may be a single line POTS, a 2 channel ISDN, a 23/24 channel T1, a 600+ channel T3, etc. In addition to the account number, one or more additional phone numbers can be directed at that account or agroup of accounts, either as a direct routing to a particular channel(s) or a roll-over between groups of various accounts. A call to a phone number is therefore is directed at a particular account number which, if all channels are busy, may roll on to other account numbers in the group. Adrian From darden at armc.org Mon Nov 24 07:06:58 2008 From: darden at armc.org (Darden, Patrick S.) Date: Mon, 24 Nov 2008 08:06:58 -0500 Subject: How do dialup ISPs allow multiple clients under one access number? In-Reply-To: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> Message-ID: <CBE22E5FF427B149A272DD1DDE10752402368B36@EX2K3.armc.org> You can do it multiple ways: 1. old fashioned hunt groups for multiple analog lines. 2. getting a PRI with one outward facing number. 3. talk to your local Bell about what would best suit your needs (digital calls? 56K? 64k? 128K? ISDN? Analog? dialout capability, or just dialin? etc. etc.) --Patrick Darden -----Original Message----- From: John Musbach [mailto:johnmusbach1 at gmail.com] Sent: Monday, November 24, 2008 2:15 AM To: nanog at nanog.org Subject: How do dialup ISPs allow multiple clients under one access number? I'm interested in figuring out how dialup ISPs work and have found plenty of info on dialin server setup but not much on how ISPs allow multiple clients under one access number, how do they do it? -- Best Regards, John Musbach From cayle.spandon at gmail.com Mon Nov 24 09:20:16 2008 From: cayle.spandon at gmail.com (cayle.spandon at gmail.com) Date: Mon, 24 Nov 2008 15:20:16 +0000 Subject: TRIP deployment? Message-ID: <00163630ee1d9c1ea3045c70ee1c@google.com> I'm not sure if this is the right mailing list for this question: how widely is TRIP (Telephone Routing over IP [RFC3219]) deployed / used in current networks? From toddunder at gmail.com Mon Nov 24 09:37:38 2008 From: toddunder at gmail.com (Todd Underwood) Date: Mon, 24 Nov 2008 10:37:38 -0500 Subject: NANOG 45 Preliminary Agenda and Conference Registration Message-ID: <65b1fd2e0811240737y466d7092o6d41dce7ffd7534e@mail.gmail.com> NANOG 45 is fast approaching. Today we have a preliminary agenda to announce that should assist people who need supplementary material for travel justifications. There are a number of presentation slots still available. The Program Committee will continue to accept presentations this week (if you plan to submit something, Friday was the deadline, but we will try to review presentations that arrive during the week this week. Please contact me if you have a talk in progress and need information on how to submit it, but in general: http://www.nanogpc.org/ Please note that conference registration is open and the early bird discount expires in under two weeks: https://nanog.merit.edu/registration/ Hotel registration is open as well, although to get the discount rate you may have to call the hotel. They are working on the automated registration issue and should have it resolved soon. Be aware: the hotel is outrageously cheap for very nice rooms (part of what should make your travel justification easier), so be sure to register soon. Also, consider booking travel soon. A number of airlines have substantially discounted flights at the moment, but one never knows when they might expire. The following talks were submitted early and have already been accepted by the Program Committee: Tutorials: ===================================================================== Introduction to LISP Dave Meyer, Cisco Dino Farinacci, Cisco Small Network Operator - Lessons Learned Pete Templin, Nextlink BGP 102: Scaling the Network Avi Freedman, Akamai DNSSEC at Comcast Srini Avirneni, Comcast Cable Accurate and Advanced Traceroute for Troubleshooting Richard Steenbergen Peering 101 William Norton and Kevin Oberman Plenary Presentations: ===================================================================== Tutorial on using the Malware Hash Registry Stephen Gill, Team Cymru Practical Reverse Traceroute Ethan Katz-Bassett, University of Washington DNSSEC at Comcast Srini Avirneni, Comcast Cable BFD - Is it worth it and does it work in production networks? Tom Scholl, AT&T Labs It's The End Of The World As We Know It (aka "The New Internet Architecture") David Meyer, Cisco/Univ of Oregon 4-byte ASNs Greg Hankins, Force10 Networks Birds of a Feather Sessions (BOFs): ===================================================================== ISP Security Danny McPherson, Arbor Networks Warren Kumari, Google Peering (including welcome, peering personals, peering survey results contact aaronh at bind.com to present) Aaron Hughes, Cariden Technologies, LMCO, UnitedLayer Research Forum: ===================================================================== A Comparative Analysis of BGP Anomaly Detection and Robustness Algorithms Kotikapaludi Sriram, Patrick Gleichmann, and Doug Montgomery 100Gbps for NexGen Content Distribution Networks Martin Zirngibl, Alcatel-Lucent I Look forward to seeing all of you in Santo Domingo, t. -- -------------------------------------------------------------- Todd Underwood, Chair, NANOG Program Committee toddunder at gmail.com From streiner at cluebyfour.org Mon Nov 24 09:52:17 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 24 Nov 2008 10:52:17 -0500 (EST) Subject: How do dialup ISPs allow multiple clients under one access number? In-Reply-To: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> References: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> Message-ID: <Pine.LNX.4.64.0811241044350.16392@whammy.cluebyfour.org> On Mon, 24 Nov 2008, John Musbach wrote: > I'm interested in figuring out how dialup ISPs work and have found > plenty of info on dialin server setup but not much on how ISPs allow > multiple clients under one access number, how do they do it? That depends on what you mean by multiple clients. If you mean multiple customers of a single ISP, you would provision serveral PRIs through a telco, and assign a phone number that will hunt down through all of PRIs to find an open port. If you mean multiple clients in the sense that you're a dial wholesaler and you're providing service to multiple ISPs, you'd still do hunt groups as mentioned by other posters, plus you could also assign each wholesale client a unique RADIUS domain to allow for client-specific attributes to be applied to dialin sessions. For example, this could be used to control the IP addresses that are assigned a given ISP's customers. jms From jerj at coplanar.net Mon Nov 24 09:55:12 2008 From: jerj at coplanar.net (Jeremy Jackson) Date: Mon, 24 Nov 2008 10:55:12 -0500 Subject: TRIP deployment? In-Reply-To: <00163630ee1d9c1ea3045c70ee1c@google.com> References: <00163630ee1d9c1ea3045c70ee1c@google.com> Message-ID: <1227542112.782.50.camel@ragnarok> http://xconnect.net/ is the big ENUM provider, I think that's the method that has gained popularity for VoIP Peering on the signaling end. TRIP sounds like it would be useful for finding QoS routes for media streams. On Mon, 2008-11-24 at 15:20 +0000, cayle.spandon at gmail.com wrote: > I'm not sure if this is the right mailing list for this question: how > widely is TRIP (Telephone Routing over IP [RFC3219]) deployed / used in > current networks? -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net jerj at coplanar.net From tglassey at earthlink.net Mon Nov 24 10:12:18 2008 From: tglassey at earthlink.net (TSG) Date: Mon, 24 Nov 2008 08:12:18 -0800 Subject: How do dialup ISPs allow multiple clients under one access number? In-Reply-To: <Pine.LNX.4.64.0811241044350.16392@whammy.cluebyfour.org> References: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> <Pine.LNX.4.64.0811241044350.16392@whammy.cluebyfour.org> Message-ID: <492AD262.1040409@earthlink.net> OK - great timing on this - So I need to hire a consultant who knows PATTON 2900 series RAS systems and managing them - i.e. someone with RADIUS experience. Anyone here with that ability who wants to help setup a set of access points. One in NYC and one in SJ California? Contact me offlist TGlassey at Certichron.com Todd Glassey Justin M. Streiner wrote: > On Mon, 24 Nov 2008, John Musbach wrote: > >> I'm interested in figuring out how dialup ISPs work and have found >> plenty of info on dialin server setup but not much on how ISPs allow >> multiple clients under one access number, how do they do it? > > That depends on what you mean by multiple clients. If you mean > multiple customers of a single ISP, you would provision serveral PRIs > through a telco, and assign a phone number that will hunt down through > all of PRIs to find an open port. > > If you mean multiple clients in the sense that you're a dial > wholesaler and you're providing service to multiple ISPs, you'd still > do hunt groups as mentioned by other posters, plus you could also > assign each wholesale client a unique RADIUS domain to allow for > client-specific attributes to be applied to dialin sessions. For > example, this could be used to control the IP addresses that are > assigned a given ISP's customers. > > jms > ------------------------------------------------------------------------ > > > Internal Virus Database is out of date. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.9.8/1800 - Release Date: 11/19/2008 6:55 PM > > From mtinka at globaltransit.net Mon Nov 24 10:34:11 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 25 Nov 2008 00:34:11 +0800 Subject: How do dialup ISPs allow multiple clients under one access number? In-Reply-To: <492AD262.1040409@earthlink.net> References: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> <Pine.LNX.4.64.0811241044350.16392@whammy.cluebyfour.org> <492AD262.1040409@earthlink.net> Message-ID: <200811250034.12071.mtinka@globaltransit.net> On Tuesday 25 November 2008 00:12:18 TSG wrote: > So I need to hire a consultant who knows PATTON 2900 > series RAS systems and managing them - i.e. someone with > RADIUS experience. It's been a while since I ran Patton's, but the last time I did, we had serious issues where the DSP's were gradually went from good to being hang in a "bad" state. It was likely a code issue, which I'm sure has been fixed. But you probably want to be sure. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081125/762eaf4e/attachment.bin> From peter at peter-dambier.de Mon Nov 24 10:55:59 2008 From: peter at peter-dambier.de (Peter Dambier) Date: Mon, 24 Nov 2008 17:55:59 +0100 Subject: How do dialup ISPs allow multiple clients under one access number? In-Reply-To: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> References: <17c8e29e0811232314x144f0103m493d452b59d1c348@mail.gmail.com> Message-ID: <492ADC9F.7060808@peter-dambier.de> e.g. DTAG.DE aDSL, PPPoE, it is flatrate mostly, but they use PPP for accounting data. You are connected via a DSL modem, that is kind of ATM. Your telephone number does not matter. You can terminate your DSL modem with a switch and connect five hosts each with its own user and password and even different providers. And you can move from the north of germany down south, connect with your same account. You cannot connect more than one with your account, except when you pay for a subuser but that is like yet another account. Kind regards Peter John Musbach wrote: > I'm interested in figuring out how dialup ISPs work and have found > plenty of info on dialin server setup but not much on how ISPs allow > multiple clients under one access number, how do they do it? > -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ From mike-nanog at tiedyenetworks.com Mon Nov 24 11:02:30 2008 From: mike-nanog at tiedyenetworks.com (mike) Date: Mon, 24 Nov 2008 09:02:30 -0800 Subject: BCP for Private OUI / address assignments? Message-ID: <492ADE26.3040608@tiedyenetworks.com> With the increasing use of virtual machines in my environment, I am needing more and more unique mac addresses to assign to the many virtual Ethernet devices I have attached and visible to my non-virtual physical network. The problem of course is that I don't have an IEEE OUI and therefore can't generate guaranteed to be unique addresses, and while the possible address space is quite large, it occurs to me that there should be something - ala rfc 1918 - for this kind of situation. For now however, I just want to know if anyones got something better than 'pick an oui out of the air' or 'pick an old dead manufacturer oui', or worse, 'pick old 10base2 network cards and destroy them, saving the mac'. In the future however, I think there's going to need to be some sort of extension or modification to dhcp to accomodate virtual machines in this regard (of not having a manufacturer assigned addresses for the virtual ethernets). Mike- From dwcarder at wisc.edu Mon Nov 24 11:13:55 2008 From: dwcarder at wisc.edu (Dale W. Carder) Date: Mon, 24 Nov 2008 11:13:55 -0600 Subject: BCP for Private OUI / address assignments? In-Reply-To: <492ADE26.3040608@tiedyenetworks.com> References: <492ADE26.3040608@tiedyenetworks.com> Message-ID: <0F35B944-50C3-4D63-AAD4-7DD469745735@wisc.edu> On Nov 24, 2008, at 11:02 AM, mike wrote: > I am needing more and more unique mac addresses ... > it occurs to me that there should be something - ala rfc 1918 You can probably find examples online, but in a nutshell this does exist. Set bit b2 to 1, "locally assigned". Default is 0, "globally unique" (OUI assigned). Cheers, Dale -- Dale W. Carder - Network Engineer University of Wisconsin / WiscNet http://net.doit.wisc.edu/~dwcarder From vish.yelsangikar at rea-group.com Mon Nov 24 11:27:11 2008 From: vish.yelsangikar at rea-group.com (Vish Yelsangikar) Date: Tue, 25 Nov 2008 04:27:11 +1100 Subject: Point to Point Bet AU and Amsterdam. In-Reply-To: <6FA6124E9378214883CA93A54AED601D0E72FEA4@EMAIL.win.int.realestate.com.au> References: <CMM.0.90.0.1227470792.roll@avfall.stupi.se> <6FA6124E9378214883CA93A54AED601D0E72FEA4@EMAIL.win.int.realestate.com.au> Message-ID: <6FA6124E9378214883CA93A54AED601D0E7301E0@EMAIL.win.int.realestate.com.au> Hi I am looking for point to point/MPLS/whatever links between Melbourne and Amsterdam. Any recommendations as to where (mailing list) I can post for a request for quote for this kind of service? Or who are the usual suspects I should ask for a quote? Reply off list. If this is off-topic for this list, my apologies. Thanks. Vish From heather.schiller at verizonbusiness.com Mon Nov 24 12:10:35 2008 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Mon, 24 Nov 2008 13:10:35 -0500 Subject: Origin ASN seen vs Origin ASN in Whois Records Report? In-Reply-To: <4A6ED636-C162-438C-AB33-63426B0D0623@hopcount.ca> References: <4924AC6B.2030806@verizonbusiness.com> <004D0474-1D21-4D63-BE49-D48369C02AC7@hopcount.ca> <492A0EBC.9030402@sprunk.org> <4A6ED636-C162-438C-AB33-63426B0D0623@hopcount.ca> Message-ID: <492AEE1B.6000602@verizonbusiness.com> Joe Abley wrote: > > On 23 Nov 2008, at 21:17, Stephen Sprunk wrote: > >> Presumably it's from the "Origin AS" field in WHOIS: > > Ah, thanks (and also thanks to others who pointed that out off-list). > > That seems like a weird anachronism, to be honest. Perhaps it's only > because nobody has ever tried to use it for anything that there's never > been any reason for the ARIN community to propose that the collection of > such information be stopped. > > > Joe > The policy is relatively new.. (Spring 2007) and adopted by the ARIN community after vetting at 2 meetings.. It's optional, so I can't imagine why anyone would propose that ARIN stop collecting this information. http://www.arin.net/policy/proposals/2006_3.html It may be that it's "newness" helps w/ the accuracy.. only time will tell. --heather ==================================================== Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management help4u at verizonbusiness.com ===================================================== From jabley at hopcount.ca Mon Nov 24 12:14:03 2008 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 24 Nov 2008 13:14:03 -0500 Subject: Origin ASN seen vs Origin ASN in Whois Records Report? In-Reply-To: <492AEE1B.6000602@verizonbusiness.com> References: <4924AC6B.2030806@verizonbusiness.com> <004D0474-1D21-4D63-BE49-D48369C02AC7@hopcount.ca> <492A0EBC.9030402@sprunk.org> <4A6ED636-C162-438C-AB33-63426B0D0623@hopcount.ca> <492AEE1B.6000602@verizonbusiness.com> Message-ID: <C672FECB-322C-4010-A652-FBFF757A144D@hopcount.ca> On 2008-11-24, at 13:10, Heather Schiller wrote: > Joe Abley wrote: >> On 23 Nov 2008, at 21:17, Stephen Sprunk wrote: >>> Presumably it's from the "Origin AS" field in WHOIS: >> Ah, thanks (and also thanks to others who pointed that out off-list). >> That seems like a weird anachronism, to be honest. Perhaps it's >> only because nobody has ever tried to use it for anything that >> there's never been any reason for the ARIN community to propose >> that the collection of such information be stopped. >> Joe > > The policy is relatively new.. Yep, thanks to you and the others who pointed that out privately. I think it's of limited utility, but this is not a policy list so I'm very happy to keep further reflections on that to myself :-) Joe From peter at peter-dambier.de Mon Nov 24 12:35:07 2008 From: peter at peter-dambier.de (Peter Dambier) Date: Mon, 24 Nov 2008 19:35:07 +0100 Subject: BCP for Private OUI / address assignments? In-Reply-To: <0F35B944-50C3-4D63-AAD4-7DD469745735@wisc.edu> References: <492ADE26.3040608@tiedyenetworks.com> <0F35B944-50C3-4D63-AAD4-7DD469745735@wisc.edu> Message-ID: <492AF3DB.9020609@peter-dambier.de> I also found this one helpful http://www.iana.org/assignments/ethernet-numbers === The CFxxxx Series RFC 2153 describes a method of usings a "pseudo OUI" for certain purposes when there is no appropriate regular OUI assigned. These are listed here. CF0001 Data Comm for Business [McCain] === I remember we had IBM Token-Ring equipment and they suggested to always use "CF..." and never rely on the programmed MAC for SNA. Kind regards Peter Dale W. Carder wrote: > > On Nov 24, 2008, at 11:02 AM, mike wrote: >> I am needing more and more unique mac addresses > ... >> it occurs to me that there should be something - ala rfc 1918 > > > You can probably find examples online, but in a nutshell this > does exist. > > Set bit b2 to 1, "locally assigned". > Default is 0, "globally unique" (OUI assigned). > > Cheers, > Dale > > -- > Dale W. Carder - Network Engineer > University of Wisconsin / WiscNet > http://net.doit.wisc.edu/~dwcarder > -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Nov 24 15:01:52 2008 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 25 Nov 2008 07:31:52 +1030 Subject: BCP for Private OUI / address assignments? In-Reply-To: <492AF3DB.9020609@peter-dambier.de> References: <492ADE26.3040608@tiedyenetworks.com> <0F35B944-50C3-4D63-AAD4-7DD469745735@wisc.edu> <492AF3DB.9020609@peter-dambier.de> Message-ID: <20081125073152.834c7f29.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Hi, On Mon, 24 Nov 2008 19:35:07 +0100 Peter Dambier <peter at peter-dambier.de> wrote: > I also found this one helpful > > http://www.iana.org/assignments/ethernet-numbers > > === > The CFxxxx Series > > RFC 2153 describes a method of usings a "pseudo OUI" for certain > purposes when there is no appropriate regular OUI assigned. These are > listed here. > > CF0001 Data Comm for Business [McCain] > === > > I remember we had IBM Token-Ring equipment and they suggested > to always use "CF..." and never rely on the programmed MAC for SNA. > On an ethernet network, CF is a multicast destination address, or, as a source, I'm pretty sure it indicates that the frame contains a source route for use with translational bridging. The locally assigned 0x02 bit would be better to use. Be aware that Microsoft have decided to "reserve" some locally assigned addresses in the range 02-BF, and 02-01 through 02-20 for use with their load balancing / high availability product, rather than use one of their proper OUIs. Apparently you're not supposed to be using these address ranges because the locally assigned address space is so large, before you use this Microsoft product, so if you are, too bad. You'll have to change your previous local assignments, or somehow change Microsoft's software. Within Wireshark it shows it as used by Microsoft, which implies official assignment to Microsoft. The Wireshark people won't change it, so that gives it a level of legitimacy. I think that's a slippery slope. (It's a pet hate of mine that certain organisations force their private address space assignments (RFC1918 or IEEE locally assigned) on outsiders. It's supposed to be private so outsiders don't see it or don't have to work around it!) Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear" From cmills at accessdc.com Mon Nov 24 15:26:27 2008 From: cmills at accessdc.com (Mills, Charles) Date: Mon, 24 Nov 2008 16:26:27 -0500 Subject: Sprint Problems? Message-ID: <58E0B21FC367B24485855A1DBD96B0BB11C050EC@adc-prd-exch1.internal.accessdc.com> Anyone seeing or have an insight as to what is going on with Sprint? Connectivity very sporadic. Very high latency. Found some corroborating evidence here: http://www.internetpulse.net/ Chuck This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. From deepak at ai.net Mon Nov 24 15:31:22 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 24 Nov 2008 16:31:22 -0500 Subject: BCP for Private OUI / address assignments? In-Reply-To: <20081125073152.834c7f29.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <492ADE26.3040608@tiedyenetworks.com> <0F35B944-50C3-4D63-AAD4-7DD469745735@wisc.edu> <492AF3DB.9020609@peter-dambier.de> <20081125073152.834c7f29.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <492B1D2A.1040101@ai.net> Realistically, OUI space is pretty large for each L2 domain... Once it hits an L3 domain, you can repeat OUIs all you want... Pick some prefix set of bits that include "locally assigned" that is unique to your organization and you will operationally be fine. Or the last 8 bits of your host server's base MAC (hardware) address -- plenty of entropy there. Even when two or 10 organizations merge, unless you are merging them into the same tributary L3 domain, its not a problem... And if it is a problem for more than 1 or 2 virtual machines, I'm sure your organization is big enough to split that into another domain/vlan/what have you. Yes, its a nice idea to have a BCP that works without conflicts, but I don't see how this is legitimately going to affect anyone more than theoretically... unless someone's device is really bad at generating OUIs; all of this based on the cheap prevalence of L3 devices at the edge. Deepak From streiner at cluebyfour.org Mon Nov 24 15:41:35 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 24 Nov 2008 16:41:35 -0500 (EST) Subject: Sprint Problems? In-Reply-To: <58E0B21FC367B24485855A1DBD96B0BB11C050EC@adc-prd-exch1.internal.accessdc.com> References: <58E0B21FC367B24485855A1DBD96B0BB11C050EC@adc-prd-exch1.internal.accessdc.com> Message-ID: <Pine.LNX.4.64.0811241639170.16392@whammy.cluebyfour.org> On Mon, 24 Nov 2008, Mills, Charles wrote: > Anyone seeing or have an insight as to what is going on with Sprint? > Connectivity very sporadic. Very high latency. Yeah, I'm seeing it here too. Looks like Sprint is advertising routes that they don't actually have reachability for... Perhaps someone fat-fingered an access-list? jms From RWerber at epiknetworks.com Mon Nov 24 15:47:24 2008 From: RWerber at epiknetworks.com (Ryan Werber) Date: Mon, 24 Nov 2008 16:47:24 -0500 Subject: Sprint Problems? References: <58E0B21FC367B24485855A1DBD96B0BB11C050EC@adc-prd-exch1.internal.accessdc.com> <Pine.LNX.4.64.0811241639170.16392@whammy.cluebyfour.org> Message-ID: <4D58C7B4943F874BA4CB5D68A79240605FC3FA@Epikserver2.Epik.local> Hello, >-----Original Message----- >From: Justin M. Streiner [mailto:streiner at cluebyfour.org] >Sent: Monday, November 24, 2008 1:42 PM >On Mon, 24 Nov 2008, Mills, Charles wrote: >> Anyone seeing or have an insight as to what is going on with Sprint? >> Connectivity very sporadic. Very high latency. >Yeah, I'm seeing it here too. Looks like Sprint is advertising routes >that they don't actually have reachability for... Perhaps someone >fat-fingered an access-list? We had a customer of ours last night complain of unreachability to a PEER1 (AS13768) route but for some reason Sprint was advertising it. That route had nothing to do with sprint originally. Packets were getting thrown around in the Atlanta area until the TTL finally expired. It seemed to clear it self up last night, but I think we are seeing some residual damage here. Ryan Werber Sr. Network Engineer Epik Networks (AS 21513) From cmills at accessdc.com Mon Nov 24 15:48:36 2008 From: cmills at accessdc.com (Mills, Charles) Date: Mon, 24 Nov 2008 16:48:36 -0500 Subject: Sprint Problems? In-Reply-To: <4D58C7B4943F874BA4CB5D68A79240605FC3FA@Epikserver2.Epik.local> References: <58E0B21FC367B24485855A1DBD96B0BB11C050EC@adc-prd-exch1.internal.accessdc.com> <Pine.LNX.4.64.0811241639170.16392@whammy.cluebyfour.org> <4D58C7B4943F874BA4CB5D68A79240605FC3FA@Epikserver2.Epik.local> Message-ID: <58E0B21FC367B24485855A1DBD96B0BB11C050F3@adc-prd-exch1.internal.accessdc.com> Well...our connectivity problems out of Pittsburgh have went from sporadic, skipped bad and worse and are at critical. -----Original Message----- From: Ryan Werber [mailto:RWerber at epiknetworks.com] Sent: Monday, November 24, 2008 4:47 PM To: Justin M. Streiner; Mills, Charles Cc: nanog at merit.edu Subject: RE: Sprint Problems? Hello, >-----Original Message----- >From: Justin M. Streiner [mailto:streiner at cluebyfour.org] >Sent: Monday, November 24, 2008 1:42 PM >On Mon, 24 Nov 2008, Mills, Charles wrote: >> Anyone seeing or have an insight as to what is going on with Sprint? >> Connectivity very sporadic. Very high latency. >Yeah, I'm seeing it here too. Looks like Sprint is advertising routes >that they don't actually have reachability for... Perhaps someone >fat-fingered an access-list? We had a customer of ours last night complain of unreachability to a PEER1 (AS13768) route but for some reason Sprint was advertising it. That route had nothing to do with sprint originally. Packets were getting thrown around in the Atlanta area until the TTL finally expired. It seemed to clear it self up last night, but I think we are seeing some residual damage here. Ryan Werber Sr. Network Engineer Epik Networks (AS 21513) This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. From cmills at accessdc.com Mon Nov 24 15:51:56 2008 From: cmills at accessdc.com (Mills, Charles) Date: Mon, 24 Nov 2008 16:51:56 -0500 Subject: Sprint Problems? In-Reply-To: <4D58C7B4943F874BA4CB5D68A79240605FC3FA@Epikserver2.Epik.local> References: <58E0B21FC367B24485855A1DBD96B0BB11C050EC@adc-prd-exch1.internal.accessdc.com> <Pine.LNX.4.64.0811241639170.16392@whammy.cluebyfour.org> <4D58C7B4943F874BA4CB5D68A79240605FC3FA@Epikserver2.Epik.local> Message-ID: <58E0B21FC367B24485855A1DBD96B0BB11C050F4@adc-prd-exch1.internal.accessdc.com> Found out from an upstream provider that Sprint might be having some major backbone issues right now. A number of their backbone routers are down. This is third hand information but would seem to make sense considering what we're seeing here. We dropped our sprint connection until this clears up but reachability to any site that is on their network or uses them for transit is iffy at best. Chuck -----Original Message----- From: Ryan Werber [mailto:RWerber at epiknetworks.com] Sent: Monday, November 24, 2008 4:47 PM To: Justin M. Streiner; Mills, Charles Cc: nanog at merit.edu Subject: RE: Sprint Problems? Hello, >-----Original Message----- >From: Justin M. Streiner [mailto:streiner at cluebyfour.org] >Sent: Monday, November 24, 2008 1:42 PM >On Mon, 24 Nov 2008, Mills, Charles wrote: >> Anyone seeing or have an insight as to what is going on with Sprint? >> Connectivity very sporadic. Very high latency. >Yeah, I'm seeing it here too. Looks like Sprint is advertising routes >that they don't actually have reachability for... Perhaps someone >fat-fingered an access-list? We had a customer of ours last night complain of unreachability to a PEER1 (AS13768) route but for some reason Sprint was advertising it. That route had nothing to do with sprint originally. Packets were getting thrown around in the Atlanta area until the TTL finally expired. It seemed to clear it self up last night, but I think we are seeing some residual damage here. Ryan Werber Sr. Network Engineer Epik Networks (AS 21513) This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. From bogus@does.not.exist.com Mon Nov 24 16:00:27 2008 From: bogus@does.not.exist.com () Date: Mon, 24 Nov 2008 22:00:27 -0000 Subject: Qwest Issues? Message-ID: <mailman.4.1315709018.76161.nanog@nanog.org> Anyone else seeing Qwest issues? Lost routing at about 2:09PM CST Route back dies at cer-core-01.inet.qwest.net From streiner at cluebyfour.org Mon Nov 24 16:07:22 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 24 Nov 2008 17:07:22 -0500 (EST) Subject: Sprint Problems? In-Reply-To: <58E0B21FC367B24485855A1DBD96B0BB11C050F4@adc-prd-exch1.internal.accessdc.com> References: <58E0B21FC367B24485855A1DBD96B0BB11C050EC@adc-prd-exch1.internal.accessdc.com> <Pine.LNX.4.64.0811241639170.16392@whammy.cluebyfour.org> <4D58C7B4943F874BA4CB5D68A79240605FC3FA@Epikserver2.Epik.local> <58E0B21FC367B24485855A1DBD96B0BB11C050F4@adc-prd-exch1.internal.accessdc.com> Message-ID: <Pine.LNX.4.64.0811241705410.16392@whammy.cluebyfour.org> On Mon, 24 Nov 2008, Mills, Charles wrote: > Found out from an upstream provider that Sprint might be having some > major backbone issues right now. > > A number of their backbone routers are down. This is third hand > information but would seem to make sense considering what we're seeing > here. We dropped our sprint connection until this clears up but > reachability to any site that is on their network or uses them for > transit is iffy at best. Our Sprint-connected transit provider just killed their BGP session to Sprint, so things are more stable now, but access to any single-homed Sprint sites is still DOA. jms From nanog at mattelmore.com Mon Nov 24 16:06:56 2008 From: nanog at mattelmore.com (Matthew Elmore) Date: Mon, 24 Nov 2008 16:06:56 -0600 Subject: Qwest Issues? In-Reply-To: <E1L4jUk-000OqS-Bx@s0.nanog.org> References: <E1L4jUk-000OqS-Bx@s0.nanog.org> Message-ID: <85939B82-5689-4E7A-801A-A2CA43456DB9@mattelmore.com> No problems here On Nov 24, 2008, at 4:01 PM, nanog-bounces at nanog.org wrote: > Anyone else seeing Qwest issues? Lost routing at about 2:09PM CST > > Route back dies at cer-core-01.inet.qwest.net > > From surfer at mauigateway.com Mon Nov 24 16:11:17 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 24 Nov 2008 14:11:17 -0800 Subject: Sprint Problems? Message-ID: <20081124141117.B46627D7@resin09.mta.everyone.net> --- streiner at cluebyfour.org wrote: Yeah, I'm seeing it here too. Looks like Sprint is advertising routes that they don't actually have reachability for... Perhaps someone fat-fingered an access-list? --------------------------------------- We recently dumped Sprint because of this and the fact that they claimed nothing happened. But it did to the tune of 600Mbps over 4 OC-12s at peak load for me two times. It's ok to make a mistake, but to deny it happened is not ok. scott From bpfankuch at cpgreeley.com Mon Nov 24 16:17:33 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Mon, 24 Nov 2008 15:17:33 -0700 Subject: Qwest Issues? In-Reply-To: <85939B82-5689-4E7A-801A-A2CA43456DB9@mattelmore.com> References: <E1L4jUk-000OqS-Bx@s0.nanog.org> <85939B82-5689-4E7A-801A-A2CA43456DB9@mattelmore.com> Message-ID: <01759D50DC387C45A018FE1817CE27D75403657AB9@CPExchange1.cpgreeley.com> Anything that might narrow down the region? Perhaps a state? Im seeing sprint issues (who isn't) but nothing with my qwest t's in Colorado, or the link to a datacenter in seattle. -----Original Message----- From: Matthew Elmore [mailto:nanog at mattelmore.com] Sent: Monday, November 24, 2008 3:07 PM To: nanog Subject: Re: Qwest Issues? No problems here On Nov 24, 2008, at 4:01 PM, nanog-bounces at nanog.org wrote: > Anyone else seeing Qwest issues? Lost routing at about 2:09PM CST > > Route back dies at cer-core-01.inet.qwest.net > > From bogus@does.not.exist.com Mon Nov 24 16:22:39 2008 From: bogus@does.not.exist.com () Date: Mon, 24 Nov 2008 22:22:39 -0000 Subject: No subject Message-ID: <mailman.5.1315709018.76161.nanog@nanog.org> DATA Subject: RE: Qwest Issues? Sorry, yes..Plano/Dallas, TX > Anything that might narrow down the region? Perhaps a state? Im seeing sprint issues (who isn't) but nothing with my qwest t's in Colorado, or the link to a datacenter in seattle. From jbates at brightok.net Mon Nov 24 16:41:48 2008 From: jbates at brightok.net (Jack Bates) Date: Mon, 24 Nov 2008 16:41:48 -0600 Subject: Qwest Issues? In-Reply-To: <01759D50DC387C45A018FE1817CE27D75403657AB9@CPExchange1.cpgreeley.com> References: <E1L4jUk-000OqS-Bx@s0.nanog.org> <85939B82-5689-4E7A-801A-A2CA43456DB9@mattelmore.com> <01759D50DC387C45A018FE1817CE27D75403657AB9@CPExchange1.cpgreeley.com> Message-ID: <492B2DAC.30005@brightok.net> Based on the response of Dallas: Dallas edge 14 is doing just fine for me. cer-core-01 is reachable. Noticing that traceroutes are blind through the network, but other than that, everything is routing. I have full visibility of the outside world and it of me. Jack Blake Pfankuch wrote: > Anything that might narrow down the region? Perhaps a state? Im seeing sprint issues (who isn't) but nothing with my qwest t's in Colorado, or the link to a datacenter in seattle. > > -----Original Message----- > From: Matthew Elmore [mailto:nanog at mattelmore.com] > Sent: Monday, November 24, 2008 3:07 PM > To: nanog > Subject: Re: Qwest Issues? > > No problems here > > On Nov 24, 2008, at 4:01 PM, nanog-bounces at nanog.org wrote: > >> Anyone else seeing Qwest issues? Lost routing at about 2:09PM CST >> >> Route back dies at cer-core-01.inet.qwest.net >> >> > > > From billf at mu.org Mon Nov 24 17:33:09 2008 From: billf at mu.org (bill fumerola) Date: Mon, 24 Nov 2008 15:33:09 -0800 Subject: IPv6 routing /48s In-Reply-To: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> Message-ID: <20081124233309.GV29895@elvis.mu.org> On Mon, Nov 17, 2008 at 04:46:08PM -0600, Robert.E.VanOrmer at frb.gov wrote: > ARIN claims they are seeing /48s routed, at least in their route tables. I > have seen some new momentum on the allocation of /32's, don't know if that > is in response to rules like this?? Would be awefully difficult for our > organization to come up with the rationale to need 65K /48s internally to > justify a /32. i can verify this. Verizon refused to route $employer's /44. any complaints were met with "just because ARIN gives you space doesn't mean we have to route it". -- bill From andy at nosignal.org Tue Nov 25 02:21:33 2008 From: andy at nosignal.org (Andy Davidson) Date: Tue, 25 Nov 2008 08:21:33 +0000 Subject: TRIP deployment? In-Reply-To: <1227542112.782.50.camel@ragnarok> References: <00163630ee1d9c1ea3045c70ee1c@google.com> <1227542112.782.50.camel@ragnarok> Message-ID: <3EF93529-6682-4F47-B20B-E8E0B14FA1CD@nosignal.org> On 24 Nov 2008, at 15:55, Jeremy Jackson wrote: > On Mon, 2008-11-24 at 15:20 +0000, cayle.spandon at gmail.com wrote: >> I'm not sure if this is the right mailing list for this question: >> how widely is TRIP (Telephone Routing over IP [RFC3219]) deployed / >> used in current networks? > http://xconnect.net/ is the big ENUM provider, I think that's the > method that has gained popularity for VoIP Peering on the signaling > end. TRIP sounds like it would be useful for finding QoS routes for > media streams. Hi, Jeremy, Cayle, All -- I am regularly involved with SIP interconnect. There are a number of providers of similar Federated/All-call-query-ENUM Multilateral Islands, but they do not befit the bilateral interconnect model which most people involved with voice interconnect need to follow, so that they can manage quality and the commercial properties of individual prefixes. *Some* of the island methods I have seen, perform signaling arbitration and media transcoding so that all parties on the island can communicate with all other parties, which is worrying to me as one of the benefits of end-to-end VoIP is the preservation of wideband audio codecs and new signaling features across the call path, compared with lowest-common-denominator call routing (just like TDM paths in the middle). I discussed this with Richard Shockey last year and proposed to him an out-of-band, trip-like gateway protocol that could express prefixes along with all relevant technical and commercial properties between telecoms peers. If the commercial and technical properties fit the requirements of the peer, then the prefix is appended to the dialplan of the peer (be it via a local ENUM zone or some other prefix/call routing method). The point is that the protocol to communicate prefixes and attributes needs to be call routing agnostic. I did some work on this protocol, but don't feel ready to take the document to the relevant working groups at this stage, but would welcome feedback on it from anyone here who is involved with voice interconnect. This is a bit layer 7ish, so the thread is possibly reaching a conclusion on list, but I really hope it continues off-list. best wishes Andy From jlloret at dcom.upv.es Tue Nov 25 03:53:23 2008 From: jlloret at dcom.upv.es (LMPCNA Advisory Committee) Date: Tue, 25 Nov 2008 10:53:23 +0100 Subject: Last 3 days: 1st Workshop LMPCNA in ICNS 2009 | April 21-25, 2009 - Valencia, Spain Message-ID: <200811250953.mAP9rMDw015622@smtp.upv.es> INVITATION Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific or educational results. ============== LMPCNAP 2009 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS The first International Workshop on Learning Methodologies and Platforms used in the Cisco Networking Academy (CNA), LMPCNA 2009 will be held during ICNS 2009 in April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/LMPCNAP.html Submission deadline: November 28, 2008 Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Workshop Special Areas, but not limited to, are (details in the CfP on site): New learning methodologies Blended learning Online laboratories Virtual laboratories Remote laboratories Learning strategies to enhance online courses Learning content adaptation for blended learning Learning platforms and their compatibility with cisco.netacad.net ================= LMPCNA Advisory Committee Emma Bluck, Cisco Systems, Inc./Cisco Networking Academy, Europe Giuseppe Cinque, Consorzio Elis, Italy Marco Cobb, Cisco Systems, Inc., Switzerland Petre Dini, Cisco Systems, Inc., USA / Concordia University, Canada Dennis C. Frezzo, Network Academy Learning Systems Development / Cisco Systems, Inc., USA Elaine Lawrence, University of Technology - Sydney, Australia Bernardo Leal, Universidad Sim?n Bol?var, Venezuela Jaime Lloret Mauri, Polytechnic University of Valencia, Spain Kerry-Lynn Thomson, Cisco Academy Training Centre/Nelson Mandela Metropolitan University, South Africa Donna Wright, Cisco Systems, Inc./Cisco Networking Academy, USA LMPCNA 2009 General Chair Rafael Tomas, Cisco Academy Training Center (CATC), Spain LMPCNA 2009 Technical Program Committee Chair: Tomeu Serra, Universitat de les Illes Balears, Spain Carlos Alves, Instituto Politecnico de Castelo Branco, Portugal Joan Arnedo, Universitat Oberta de Catalunya, Spain Emma Bluck, Cisco Systems, Inc./Cisco Networking Academy, Europe Doina Bucur, University of Aarhus, Denmark Giuseppe Cinque, Consorzio Elis, Italy Marco Cobb, Cisco Systems, Inc., Switzerland Kristen Dicerbo, Cisco Learning Institute, USA Dennis C. Frezzo, Network Academy Learning Systems Development / Cisco Systems, Inc., USA Michael Furminger, Cisco Networking Academy, Cisco Systems, Inc., UK Gabriel Fuster, Cisco Networking Academy Program, Spain Feher Gyula, Budapest Polytechnic, Hungary Kevin Johnston, Cisco Networking Academy Program, USA Elaine Lawrence, University of Technology - Sydney, Australia Bernardo Leal, Universidad Sim?n Bol?var, Venezuela Thomas Meuser, IT-Bildungsnetz e.V., Germany Josep Prieto, Universitat Oberta de Catalunya, Spain Osama Saleh, National Telecommunication Institute, Egypt Mihai Stanciu, Cisco Networking Academy Program / UPB, Romania Edward Swenson, Cisco Systems, Inc., USA Kerry-Lynn Thomson, Cisco Academy Training Centre/Nelson Mandela Metropolitan University, South Africa Donna Wright, Cisco Systems, Inc./Cisco Networking Academy, USA ================== From jlloret at dcom.upv.es Tue Nov 25 03:53:23 2008 From: jlloret at dcom.upv.es (LMPCNA Advisory Committee) Date: Tue, 25 Nov 2008 10:53:23 +0100 Subject: Last 3 days: 1st Workshop LMPCNA in ICNS 2009 | April 21-25, 2009 - Valencia, Spain Message-ID: <200811250953.mAP9rNI4015635@smtp.upv.es> INVITATION Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific or educational results. ============== LMPCNAP 2009 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS The first International Workshop on Learning Methodologies and Platforms used in the Cisco Networking Academy (CNA), LMPCNA 2009 will be held during ICNS 2009 in April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/LMPCNAP.html Submission deadline: November 28, 2008 Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Workshop Special Areas, but not limited to, are (details in the CfP on site): New learning methodologies Blended learning Online laboratories Virtual laboratories Remote laboratories Learning strategies to enhance online courses Learning content adaptation for blended learning Learning platforms and their compatibility with cisco.netacad.net ================= LMPCNA Advisory Committee Emma Bluck, Cisco Systems, Inc./Cisco Networking Academy, Europe Giuseppe Cinque, Consorzio Elis, Italy Marco Cobb, Cisco Systems, Inc., Switzerland Petre Dini, Cisco Systems, Inc., USA / Concordia University, Canada Dennis C. Frezzo, Network Academy Learning Systems Development / Cisco Systems, Inc., USA Elaine Lawrence, University of Technology - Sydney, Australia Bernardo Leal, Universidad Sim?n Bol?var, Venezuela Jaime Lloret Mauri, Polytechnic University of Valencia, Spain Kerry-Lynn Thomson, Cisco Academy Training Centre/Nelson Mandela Metropolitan University, South Africa Donna Wright, Cisco Systems, Inc./Cisco Networking Academy, USA LMPCNA 2009 General Chair Rafael Tomas, Cisco Academy Training Center (CATC), Spain LMPCNA 2009 Technical Program Committee Chair: Tomeu Serra, Universitat de les Illes Balears, Spain Carlos Alves, Instituto Politecnico de Castelo Branco, Portugal Joan Arnedo, Universitat Oberta de Catalunya, Spain Emma Bluck, Cisco Systems, Inc./Cisco Networking Academy, Europe Doina Bucur, University of Aarhus, Denmark Giuseppe Cinque, Consorzio Elis, Italy Marco Cobb, Cisco Systems, Inc., Switzerland Kristen Dicerbo, Cisco Learning Institute, USA Dennis C. Frezzo, Network Academy Learning Systems Development / Cisco Systems, Inc., USA Michael Furminger, Cisco Networking Academy, Cisco Systems, Inc., UK Gabriel Fuster, Cisco Networking Academy Program, Spain Feher Gyula, Budapest Polytechnic, Hungary Kevin Johnston, Cisco Networking Academy Program, USA Elaine Lawrence, University of Technology - Sydney, Australia Bernardo Leal, Universidad Sim?n Bol?var, Venezuela Thomas Meuser, IT-Bildungsnetz e.V., Germany Josep Prieto, Universitat Oberta de Catalunya, Spain Osama Saleh, National Telecommunication Institute, Egypt Mihai Stanciu, Cisco Networking Academy Program / UPB, Romania Edward Swenson, Cisco Systems, Inc., USA Kerry-Lynn Thomson, Cisco Academy Training Centre/Nelson Mandela Metropolitan University, South Africa Donna Wright, Cisco Systems, Inc./Cisco Networking Academy, USA ================== From bmanning at vacation.karoshi.com Tue Nov 25 09:51:32 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 25 Nov 2008 15:51:32 +0000 Subject: Public Assertions In-Reply-To: <Pine.LNX.4.44.0810161554250.25104-100000@citation2.av8.net> References: <200810152339.m9FNdmpb038566@himinbjorg.tucs-beachin-obx-house.com> <Pine.LNX.4.44.0810161554250.25104-100000@citation2.av8.net> Message-ID: <20081125155132.GA4950@vacation.karoshi.com.> On Thu, Oct 16, 2008 at 10:31:21PM -0400, Dean Anderson wrote: > (Manning and Woodcock have so far refused to > accept the certified letters) and then sometime in the past 5 days, you posted a comment to DoC here; http://www.ntia.doc.gov/dns/dnssec.html that states: " Bill Manning refused to accept certified mail" If I may... I am in possesion of your certified letter -AND- the signed acknowledgement that you received notice that I have taken posession of said certified mail. please get your facts straight, esp. when making formal replies to government inqueries. it can only strengthen your case if you tell the truth. --bill From woody at pch.net Tue Nov 25 10:56:43 2008 From: woody at pch.net (Bill Woodcock) Date: Tue, 25 Nov 2008 08:56:43 -0800 (PST) Subject: Public Assertions In-Reply-To: <20081125155132.GA4950@vacation.karoshi.com.> References: <200810152339.m9FNdmpb038566@himinbjorg.tucs-beachin-obx-house.com> <Pine.LNX.4.44.0810161554250.25104-100000@citation2.av8.net> <20081125155132.GA4950@vacation.karoshi.com.> Message-ID: <Pine.SOC.4.61.0811250854480.6611@paixhost.pch.net> On Tue, 25 Nov 2008 bmanning at vacation.karoshi.com wrote: > If I may... I am in possesion of your certified letter > -AND- the signed acknowledgement that you received notice > that I have taken posession of said certified mail. > > please get your facts straight, esp. when making formal > replies to government inqueries. it can only strengthen > your case if you tell the truth. Equally but differently untruthful in my case. Myself, I don't sit around my house all day, breathlessly anticipating a new missive from Dean. -Bill From isabeldias1 at yahoo.com Tue Nov 25 11:09:43 2008 From: isabeldias1 at yahoo.com (isabel dias) Date: Tue, 25 Nov 2008 09:09:43 -0800 (PST) Subject: BCP for Private OUI / address assignments? In-Reply-To: <20081125073152.834c7f29.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <914985.377.qm@web52609.mail.re2.yahoo.com> Someone is basicly "twicking the mail headers" by sending messages like "nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org"-who is? OUI...yes, great topic! Now mind me asking but why would you need a "private" OUI if the well-known (registed) list is quite public and everyone has a reserved allocation? (vendors have) and yes as far as i am aware all can be spoofed...up to the available anti-spoofing rules, plenty of google literature........just to check the theory points of failure ..... Now the question is do mac adresses change w/ IPv6? Is there a relation w/ IPv4/6 format type and OUI format type ? we might have heard of the IPv6 source address spoofing ..... http://www.cuba.ipv6-taskforce.org/pdf/isatap.pdf ...and w/ the translation to the OUI w/ v6 ...... http://tools.ietf.org/html/draft-eastlake-ethernet-iana-considerations-08 --- On Mon, 11/24/08, Mark Smith <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote: > From: Mark Smith <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> > Subject: Re: BCP for Private OUI / address assignments? > To: peter at peter-dambier.de > Cc: nanog at nanog.org > Date: Monday, November 24, 2008, 10:01 PM > Hi, > > On Mon, 24 Nov 2008 19:35:07 +0100 > Peter Dambier <peter at peter-dambier.de> wrote: > > > I also found this one helpful > > > > http://www.iana.org/assignments/ethernet-numbers > > > > === > > The CFxxxx Series > > > > RFC 2153 describes a method of usings a "pseudo > OUI" for certain > > purposes when there is no appropriate regular OUI > assigned. These are > > listed here. > > > > CF0001 Data Comm for Business > [McCain] > > === > > > > I remember we had IBM Token-Ring equipment and they > suggested > > to always use "CF..." and never rely on the > programmed MAC for SNA. > > > > On an ethernet network, CF is a multicast destination > address, or, as a > source, I'm pretty sure it indicates that the frame > contains a source > route for use with translational bridging. > > The locally assigned 0x02 bit would be better to use. Be > aware that > Microsoft have decided to "reserve" some locally > assigned addresses > in the range 02-BF, and 02-01 through 02-20 for use with > their load > balancing / high availability product, rather than use one > of their > proper OUIs. Apparently you're not supposed to be using > these > address ranges because the locally assigned address space > is so large, > before you use this Microsoft product, so if you are, too > bad. You'll > have to change your previous local assignments, or somehow > change > Microsoft's software. Within Wireshark it shows it as > used by > Microsoft, which implies official assignment to Microsoft. > The > Wireshark people won't change it, so that gives it a > level of > legitimacy. I think that's a slippery slope. > > (It's a pet hate of mine that certain organisations > force their private > address space assignments (RFC1918 or IEEE locally > assigned) on > outsiders. It's supposed to be private so outsiders > don't see it or > don't have to work around it!) > > Regards, > Mark. > > -- > > "Sheep are slow and tasty, and therefore must > remain constantly > alert." > - Bruce Schneier, > "Beyond Fear" From bmanning at vacation.karoshi.com Tue Nov 25 12:45:57 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 25 Nov 2008 18:45:57 +0000 Subject: Public Assertions In-Reply-To: <Pine.SOC.4.61.0811250854480.6611@paixhost.pch.net> References: <200810152339.m9FNdmpb038566@himinbjorg.tucs-beachin-obx-house.com> <Pine.LNX.4.44.0810161554250.25104-100000@citation2.av8.net> <20081125155132.GA4950@vacation.karoshi.com.> <Pine.SOC.4.61.0811250854480.6611@paixhost.pch.net> Message-ID: <20081125184557.GA6252@vacation.karoshi.com.> On Tue, Nov 25, 2008 at 08:56:43AM -0800, Bill Woodcock wrote: > On Tue, 25 Nov 2008 bmanning at vacation.karoshi.com wrote: > > If I may... I am in possesion of your certified letter > > -AND- the signed acknowledgement that you received notice > > that I have taken posession of said certified mail. > > > > please get your facts straight, esp. when making formal > > replies to government inqueries. it can only strengthen > > your case if you tell the truth. > > Equally but differently untruthful in my case. Myself, I don't sit around > my house all day, breathlessly anticipating a new missive from Dean. > > -Bill then what, pray tell, do you do to while away the hours? knit? route IP datagrams? carve elaborate totems from ancient redwoods? myself, I have taken up Portugese... such an expressive language. my instruction in the email above was derived from reading the submitted comments to the DoC/NOI on securing the DNS. telling us lies is one thing, factual mis-statements to the goverment is something else and i fail to see how doing so helps ones cause. in the event that anyone has doubts, I will be glad to scan and post the evidence. Dean, care to amend your statements? --bill From jeffshultz at wvi.com Tue Nov 25 14:13:54 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Tue, 25 Nov 2008 12:13:54 -0800 Subject: Public Assertions In-Reply-To: <20081125184557.GA6252@vacation.karoshi.com.> References: <200810152339.m9FNdmpb038566@himinbjorg.tucs-beachin-obx-house.com> <Pine.LNX.4.44.0810161554250.25104-100000@citation2.av8.net> <20081125155132.GA4950@vacation.karoshi.com.> <Pine.SOC.4.61.0811250854480.6611@paixhost.pch.net> <20081125184557.GA6252@vacation.karoshi.com.> Message-ID: <492C5C82.6000400@wvi.com> Can anyone explain why we are being exposed to this? From either side? bmanning at vacation.karoshi.com wrote: > On Tue, Nov 25, 2008 at 08:56:43AM -0800, Bill Woodcock wrote: >> On Tue, 25 Nov 2008 bmanning at vacation.karoshi.com wrote: >> > If I may... I am in possesion of your certified letter >> > -AND- the signed acknowledgement that you received notice >> > that I have taken posession of said certified mail. >> > >> > please get your facts straight, esp. when making formal >> > replies to government inqueries. it can only strengthen >> > your case if you tell the truth. >> >> Equally but differently untruthful in my case. Myself, I don't sit around >> my house all day, breathlessly anticipating a new missive from Dean. >> >> -Bill > > then what, pray tell, do you do to while away the hours? > knit? route IP datagrams? carve elaborate totems from ancient redwoods? > myself, I have taken up Portugese... such an expressive language. > > my instruction in the email above was derived from reading the submitted > comments to the DoC/NOI on securing the DNS. telling us lies is one thing, > factual mis-statements to the goverment is something else and i > fail to see how doing so helps ones cause. > > in the event that anyone has doubts, I will be glad to scan and post > the evidence. Dean, care to amend your statements? > > > --bill > -- Jeff Shultz From sethm at rollernet.us Tue Nov 25 15:33:35 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 25 Nov 2008 13:33:35 -0800 Subject: AS34012 Contact Message-ID: <492C6F2F.50807@rollernet.us> I'm looking for a contact within AS34012 (Parc Productions Webdesign) in regards to reachability issues from AS11170. The problem feels like 34012 is not seeing a route back to me. I can see 217.195.112.0/20, but as soon as any of my traffic hits 34012, it goes into a black hole. ~Seth From randy at psg.com Tue Nov 25 17:50:05 2008 From: randy at psg.com (Randy Bush) Date: Wed, 26 Nov 2008 08:50:05 +0900 Subject: Public Assertions In-Reply-To: <20081125184557.GA6252@vacation.karoshi.com.> References: <200810152339.m9FNdmpb038566@himinbjorg.tucs-beachin-obx-house.com> <Pine.LNX.4.44.0810161554250.25104-100000@citation2.av8.net> <20081125155132.GA4950@vacation.karoshi.com.> <Pine.SOC.4.61.0811250854480.6611@paixhost.pch.net> <20081125184557.GA6252@vacation.karoshi.com.> Message-ID: <492C8F2D.5020407@psg.com> the bills having a war with dean. how droll. can you maybe take it elsewhere? randy From woody at pch.net Tue Nov 25 17:52:31 2008 From: woody at pch.net (Bill Woodcock) Date: Tue, 25 Nov 2008 15:52:31 -0800 (PST) Subject: Public Assertions In-Reply-To: <Pine.LNX.4.44.0811251732190.12034-100000@citation2.av8.net> References: <Pine.LNX.4.44.0811251732190.12034-100000@citation2.av8.net> Message-ID: <Pine.SOC.4.61.0811251550420.6504@paixhost.pch.net> On Tue, 25 Nov 2008, Dean Anderson wrote: > A photo of Bill Woodcock's refused letter is at > http://www.av8.net/BillWoodcock.jpg Oh my god... What _is_ that sitting on? Is your desk upholstered with the hides of your victims? Also, I suggest you consult a dictionary. The word "refused" does not mean what you think it does. Amusing as this may be, I'm not sure that you need to bother the vast herd of NANOG co-conspirators with it. -Bill From woody at pch.net Tue Nov 25 17:52:31 2008 From: woody at pch.net (Bill Woodcock) Date: Tue, 25 Nov 2008 15:52:31 -0800 (PST) Subject: Public Assertions In-Reply-To: <Pine.LNX.4.44.0811251732190.12034-100000@citation2.av8.net> References: <Pine.LNX.4.44.0811251732190.12034-100000@citation2.av8.net> Message-ID: <Pine.SOC.4.61.0811251550420.6504@paixhost.pch.net> On Tue, 25 Nov 2008, Dean Anderson wrote: > A photo of Bill Woodcock's refused letter is at > http://www.av8.net/BillWoodcock.jpg Oh my god... What _is_ that sitting on? Is your desk upholstered with the hides of your victims? Also, I suggest you consult a dictionary. The word "refused" does not mean what you think it does. Amusing as this may be, I'm not sure that you need to bother the vast herd of NANOG co-conspirators with it. -Bill From alh-ietf at tndh.net Tue Nov 25 18:02:22 2008 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 25 Nov 2008 16:02:22 -0800 Subject: IPv6 routing /48s In-Reply-To: <4926DECB.5050501@brightok.net> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> <874p234uxg.fsf@mid.deneb.enyo.de> <FB540970-BE21-48E2-AACC-ACA5302FF2D2@daork.net> <alpine.BSF.2.00.0811200912550.60025@mignon.ki.iif.hu> <878wrdrs3l.fsf@mid.deneb.enyo.de> <4926DECB.5050501@brightok.net> Message-ID: <05e301c94f5a$41e11210$c5a33630$@net> Jack Bates wrote: > ..... > Yes and no. The test that was being run used 6to4 addresses, so every > 6to4 capable device did try to reach it via 6to4, since that is > preferred over IPv4. If it had used non-6to4 addressing, then IPv4 > would > had been preferred on those hosts that didn't have non-6to4 addresses. > > This is one reason why I believe using 6to4 addresses to be an issue > for > content providers. If they use non-6to4 addressing for the content, > then > most people will prefer IPv4 except for those who have configured > non-6to4 addresses or altered the labels to force 6to4 to work with > non-6to4 addressing. > > Gads, is it appropriate to just say Native when referring to non-6to4? > lol Terminology is a mess, because 2001:: could be tunneled directly from the end system, and 2002:: might be received in an RA by an end system so it doesn't know the difference between that and any other prefix. In any case, content providers can avoid the confusion if they simply put up a local 6to4 router alongside their 2001:: prefix, and populate DNS with both. Longest match will cause 2001:: connected systems to chose that dst, while 6to4 connected systems will chose 2002:: as the dst. There is no need to offer transit service to the entire world, and the latency/path selection for 6to4 to their demark will be exactly the same as the IPv4 service. Access providers could offer a localized 6to4 relay by ignoring the comment in the RFC that says 'must advertize 2002::/16', and send the appropriate ~32-40 into the IPv6 routing system that corresponds just to the customers being served by that relay. Yes the IPv6 routing system gets bigger, but there aren't enough people that would consider deploying a 6to4 relay to create a --real-- problem. FUD mongers will scream, but be pragmatic and only announce what is necessary to get some stable service to your customers. Running this service also provides a way to document how many people are using IPv6 despite the lack of availability on the distribution media. Now we get constant reports of no-traffic, because it is bypassing the local ISP monitoring system. On a recent torrent ~ 1/3 of the peers were connecting via IPv6, and most of the content my client exchanged was via those peers rather than the IPv4 ones. Clearly there is traffic, it is just going over the top to work around the lack of the service that is required ... Tony From niels=nanog at bakker.net Tue Nov 25 18:24:25 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 26 Nov 2008 01:24:25 +0100 Subject: IPv6 routing /48s In-Reply-To: <05e301c94f5a$41e11210$c5a33630$@net> References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> <874p234uxg.fsf@mid.deneb.enyo.de> <FB540970-BE21-48E2-AACC-ACA5302FF2D2@daork.net> <alpine.BSF.2.00.0811200912550.60025@mignon.ki.iif.hu> <878wrdrs3l.fsf@mid.deneb.enyo.de> <4926DECB.5050501@brightok.net> <05e301c94f5a$41e11210$c5a33630$@net> Message-ID: <20081126002425.GO78345@burnout.tpb.net> * alh-ietf at tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]: > In any case, content providers can avoid the confusion if they simply put up > a local 6to4 router alongside their 2001:: prefix, and populate DNS with > both. Longest match will cause 2001:: connected systems to chose that dst, > while 6to4 connected systems will chose 2002:: as the dst. There is no need Huh? Longest match done by web browsers and other applications? Since when? -- Niels. -- "We humans get marks for consistency. We always opt for civilization after exhausting the alternatives." -- Carl Guderian From Mark_Andrews at isc.org Tue Nov 25 18:55:02 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 26 Nov 2008 11:55:02 +1100 Subject: IPv6 routing /48s In-Reply-To: Your message of "Wed, 26 Nov 2008 01:24:25 BST." <20081126002425.GO78345@burnout.tpb.net> Message-ID: <200811260055.mAQ0t2ug016562@drugs.dv.isc.org> In message <20081126002425.GO78345 at burnout.tpb.net>, Niels Bakker writes: > * alh-ietf at tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]: > > In any case, content providers can avoid the confusion if they simply put u > p > > a local 6to4 router alongside their 2001:: prefix, and populate DNS with > > both. Longest match will cause 2001:: connected systems to chose that dst, > > while 6to4 connected systems will chose 2002:: as the dst. There is no need > > Huh? Longest match done by web browsers and other applications? Since > when? FreeBSD 6 has is as part of the standard getaddrinfo() implementation. % grep -r in6_addrpolicy /usr/src/lib/libc /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy pc_policy; /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy *pol, *ep; /usr/src/lib/libc/net/getaddrinfo.c: ep = (struct in6_addrpolicy *)(buf + l); /usr/src/lib/libc/net/getaddrinfo.c: for (pol = (struct in6_addrpolicy *)buf; pol + 1 <= ep; pol++) { /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy *pol; /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy pc_policy; /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol, *ep; /usr/src/lib/libc/net/name6.c: ep = (struct in6_addrpolicy *)(buf + l); /usr/src/lib/libc/net/name6.c: for (pol = (struct in6_addrpolicy *)buf; pol + 1 <= ep; pol++) { /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol; % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From Mark_Andrews at isc.org Tue Nov 25 19:00:49 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 26 Nov 2008 12:00:49 +1100 Subject: IPv6 routing /48s In-Reply-To: Your message of "Wed, 26 Nov 2008 11:55:02 +1100." Message-ID: <200811260100.mAQ10nAK016632@drugs.dv.isc.org> Mark Andrews writes: > > In message <20081126002425.GO78345 at burnout.tpb.net>, Niels Bakker writes: > > * alh-ietf at tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]: > > > In any case, content providers can avoid the confusion if they simply put > u > > p > > > a local 6to4 router alongside their 2001:: prefix, and populate DNS with > > > both. Longest match will cause 2001:: connected systems to chose that dst > , > > > while 6to4 connected systems will chose 2002:: as the dst. There is no ne > ed > > > > Huh? Longest match done by web browsers and other applications? Since > > when? > > FreeBSD 6 has is as part of the standard getaddrinfo() implementation. > > % grep -r in6_addrpolicy /usr/src/lib/libc > /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy pc_policy; > /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy *pol, *ep; > /usr/src/lib/libc/net/getaddrinfo.c: ep = (struct in6_addrpolicy *)(buf + > l); > /usr/src/lib/libc/net/getaddrinfo.c: for (pol = (struct in6_addrpolicy *)b > uf; pol + 1 <= ep; pol++) { > /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy *pol; > /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy pc_policy; > /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol, *ep; > /usr/src/lib/libc/net/name6.c: ep = (struct in6_addrpolicy *)(buf + l); > /usr/src/lib/libc/net/name6.c: for (pol = (struct in6_addrpolicy *)buf; pol > + 1 <= ep; pol++) { > /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol; > % And it was added on 30-Oct-03 according to CVS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From yahoo at jimpop.com Tue Nov 25 19:18:49 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Tue, 25 Nov 2008 20:18:49 -0500 Subject: Public Assertions In-Reply-To: <Pine.SOC.4.61.0811251550420.6504@paixhost.pch.net> References: <Pine.LNX.4.44.0811251732190.12034-100000@citation2.av8.net> <Pine.SOC.4.61.0811251550420.6504@paixhost.pch.net> Message-ID: <7ff145960811251718l466eb3f7s49015f00b3e2d4d8@mail.gmail.com> On Tue, Nov 25, 2008 at 18:52, Bill Woodcock <woody at pch.net> wrote: > On Tue, 25 Nov 2008, Dean Anderson wrote: > > A photo of Bill Woodcock's refused letter is at > > http://www.av8.net/BillWoodcock.jpg That's not a refused letter, that's a certified letter that hasn't yet been mailed. When refused, the item is signed and stamped (in red ink) by the postal delivery agent. It would be very interesting to see the image of the other side of the envelope (where postage stamp/payment info would appear). That said... this whole thing has an air of childishness associated with it. -Jim P. From yahoo at jimpop.com Tue Nov 25 19:18:49 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Tue, 25 Nov 2008 20:18:49 -0500 Subject: Public Assertions In-Reply-To: <Pine.SOC.4.61.0811251550420.6504@paixhost.pch.net> References: <Pine.LNX.4.44.0811251732190.12034-100000@citation2.av8.net> <Pine.SOC.4.61.0811251550420.6504@paixhost.pch.net> Message-ID: <7ff145960811251718l466eb3f7s49015f00b3e2d4d8@mail.gmail.com> On Tue, Nov 25, 2008 at 18:52, Bill Woodcock <woody at pch.net> wrote: > On Tue, 25 Nov 2008, Dean Anderson wrote: > > A photo of Bill Woodcock's refused letter is at > > http://www.av8.net/BillWoodcock.jpg That's not a refused letter, that's a certified letter that hasn't yet been mailed. When refused, the item is signed and stamped (in red ink) by the postal delivery agent. It would be very interesting to see the image of the other side of the envelope (where postage stamp/payment info would appear). That said... this whole thing has an air of childishness associated with it. -Jim P. From niels=nanog at bakker.net Tue Nov 25 19:23:26 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 26 Nov 2008 02:23:26 +0100 Subject: IPv6 routing /48s In-Reply-To: <200811260055.mAQ0t2ug016562@drugs.dv.isc.org> References: <20081126002425.GO78345@burnout.tpb.net> <200811260055.mAQ0t2ug016562@drugs.dv.isc.org> Message-ID: <20081126012326.GR78345@burnout.tpb.net> * Mark_Andrews at isc.org (Mark Andrews) [Wed 26 Nov 2008, 01:55 CET]: > In message <20081126002425.GO78345 at burnout.tpb.net>, Niels Bakker writes: >> * alh-ietf at tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]: >>> In any case, content providers can avoid the confusion if they simply put up >>> a local 6to4 router alongside their 2001:: prefix, and populate DNS with >>> both. Longest match will cause 2001:: connected systems to chose that dst, >>> while 6to4 connected systems will chose 2002:: as the dst. There is no need >> Huh? Longest match done by web browsers and other applications? Since >> when? > FreeBSD 6 has is as part of the standard getaddrinfo() implementation. I don't see that do any differentiation between 2001::/32, 2002::/16 and 2000::/8; only between IPv6-mapped IPv4 addresses and various interface/link/site-local addresses. And even that function has a big * XXX: we should standardize the functions and link them as standard * library. warning stuck on top of it -- Niels. From Mark_Andrews at isc.org Tue Nov 25 19:57:21 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 26 Nov 2008 12:57:21 +1100 Subject: IPv6 routing /48s In-Reply-To: Your message of "Wed, 26 Nov 2008 02:23:26 BST." <20081126012326.GR78345@burnout.tpb.net> Message-ID: <200811260157.mAQ1vL1t016895@drugs.dv.isc.org> In message <20081126012326.GR78345 at burnout.tpb.net>, Niels Bakker writes: > * Mark_Andrews at isc.org (Mark Andrews) [Wed 26 Nov 2008, 01:55 CET]: > > In message <20081126002425.GO78345 at burnout.tpb.net>, Niels Bakker writes: > >> * alh-ietf at tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]: > >>> In any case, content providers can avoid the confusion if they simply put > up > >>> a local 6to4 router alongside their 2001:: prefix, and populate DNS with > >>> both. Longest match will cause 2001:: connected systems to chose that dst > , > >>> while 6to4 connected systems will chose 2002:: as the dst. There is no ne > ed > >> Huh? Longest match done by web browsers and other applications? Since > >> when? > > FreeBSD 6 has is as part of the standard getaddrinfo() implementation. > > I don't see that do any differentiation between 2001::/32, 2002::/16 > and 2000::/8; only between IPv6-mapped IPv4 addresses and various > interface/link/site-local addresses. And even that function has a big > * XXX: we should standardize the functions and link them as standard > * library. > warning stuck on top of it 2002::/16 vs non 2002::/16 should be in the policy table. This is the default prefer ipv6 policy table for FreeBSD 6.4-PRERELEASE. There is also a alternate prefer ipv4 policy table that will be set if IPv6 is disabled. Prefix Prec Label Use ::1/128 50 0 0 ::/0 40 1 4997 2002::/16 30 2 0 ::/96 20 3 0 ::ffff:0.0.0.0/96 10 4 0 Mark > -- Niels. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From niels=nanog at bakker.net Tue Nov 25 20:15:19 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 26 Nov 2008 03:15:19 +0100 Subject: IPv6 routing /48s In-Reply-To: <200811260157.mAQ1vL1t016895@drugs.dv.isc.org> References: <20081126012326.GR78345@burnout.tpb.net> <200811260157.mAQ1vL1t016895@drugs.dv.isc.org> Message-ID: <20081126021519.GT78345@burnout.tpb.net> * Mark_Andrews at isc.org (Mark Andrews) [Wed 26 Nov 2008, 02:57 CET]: > 2002::/16 vs non 2002::/16 should be in the policy table. This is the > default prefer ipv6 policy table for FreeBSD 6.4-PRERELEASE. There is > also a alternate prefer ipv4 policy table that will be set if IPv6 is > disabled. > > Prefix Prec Label Use > ::1/128 50 0 0 > ::/0 40 1 4997 > 2002::/16 30 2 0 > ::/96 20 3 0 > ::ffff:0.0.0.0/96 10 4 0 I believe that is used for local address selection, not for sorting DNS replies. -- Niels. From niels=nanog at bakker.net Tue Nov 25 20:18:22 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 26 Nov 2008 03:18:22 +0100 Subject: IPv6 routing /48s In-Reply-To: <20081126021519.GT78345@burnout.tpb.net> References: <20081126012326.GR78345@burnout.tpb.net> <200811260157.mAQ1vL1t016895@drugs.dv.isc.org> <20081126021519.GT78345@burnout.tpb.net> Message-ID: <20081126021822.GU78345@burnout.tpb.net> Wie? Ik, zei de gek schreef: > I believe that is used for local address selection, not for sorting DNS > replies. I was too quick - getaddrinfo() indeed uses that policy list to reorder addresses. -- Niels. From Mark_Andrews at isc.org Tue Nov 25 20:18:26 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 26 Nov 2008 13:18:26 +1100 Subject: IPv6 routing /48s In-Reply-To: Your message of "Wed, 26 Nov 2008 03:15:19 BST." <20081126021519.GT78345@burnout.tpb.net> Message-ID: <200811260218.mAQ2IQBU017165@drugs.dv.isc.org> In message <20081126021519.GT78345 at burnout.tpb.net>, Niels Bakker writes: > * Mark_Andrews at isc.org (Mark Andrews) [Wed 26 Nov 2008, 02:57 CET]: > > 2002::/16 vs non 2002::/16 should be in the policy table. This is the > > default prefer ipv6 policy table for FreeBSD 6.4-PRERELEASE. There is > > also a alternate prefer ipv4 policy table that will be set if IPv6 is > > disabled. > > > > Prefix Prec Label Use > > ::1/128 50 0 0 > > ::/0 40 1 4997 > > 2002::/16 30 2 0 > > ::/96 20 3 0 > > ::ffff:0.0.0.0/96 10 4 0 > > I believe that is used for local address selection, not for sorting DNS > replies. It's used for both. > -- Niels. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From j at arpa.com Wed Nov 26 01:14:54 2008 From: j at arpa.com (jamie rishaw) Date: Wed, 26 Nov 2008 01:14:54 -0600 Subject: ip access-list e no-nanog-bs (Was Re: Public Assertions) Message-ID: <e6e9128b0811252314m218d94agf7e669be88fca8d7@mail.gmail.com> These guys need to get a room already. It's clear that the two bills have forgotten that "No U r !!!1" arguments happen on efnet; nanog@ is reserved strictly for "Are any engineers from [insert_company_who_blacklisted_my_company_here] around?" pages. All three of these boys are acting like drama queens[1] : dash-bill, dash-dash-bill and macgyver too for taking a picture of a piece of snail mail so you could post it on a nerdlist. | Bill Woodcock / 5:52 PM | On Tue, 25 Nov 2008, Dean Anderson wrote: | > A photo of Bill Woodcock's refused letter is at [irrelevant] | | Oh my god... What _is_ that sitting on? Is your desk upholstered with the hides of your victims? Soo.. How do I configure my rooter for that? gw(config)#ip drama enable ^ % Invalid input detected at '^' marker. Computer says no........... -j [1] professional history and credentials upon request On Tue, Nov 25, 2008 at 7:18 PM, Jim Popovitch <yahoo at jimpop.com> wrote: > On Tue, Nov 25, 2008 at 18:52, Bill Woodcock <woody at pch.net> wrote: > > On Tue, 25 Nov 2008, Dean Anderson wrote: > > > A photo of Bill Woodcock's refused letter is at > > > http://www.av8.net/BillWoodcock.jpg > > That's not a refused letter, that's a certified letter that hasn't yet > been mailed. When refused, the item is signed and stamped (in red > ink) by the postal delivery agent. It would be very interesting to > see the image of the other side of the envelope (where postage > stamp/payment info would appear). > > That said... this whole thing has an air of childishness associated with > it. > > -Jim P. > > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From j at arpa.com Wed Nov 26 01:14:54 2008 From: j at arpa.com (jamie rishaw) Date: Wed, 26 Nov 2008 01:14:54 -0600 Subject: ip access-list e no-nanog-bs (Was Re: Public Assertions) Message-ID: <e6e9128b0811252314m218d94agf7e669be88fca8d7@mail.gmail.com> These guys need to get a room already. It's clear that the two bills have forgotten that "No U r !!!1" arguments happen on efnet; nanog@ is reserved strictly for "Are any engineers from [insert_company_who_blacklisted_my_company_here] around?" pages. All three of these boys are acting like drama queens[1] : dash-bill, dash-dash-bill and macgyver too for taking a picture of a piece of snail mail so you could post it on a nerdlist. | Bill Woodcock / 5:52 PM | On Tue, 25 Nov 2008, Dean Anderson wrote: | > A photo of Bill Woodcock's refused letter is at [irrelevant] | | Oh my god... What _is_ that sitting on? Is your desk upholstered with the hides of your victims? Soo.. How do I configure my rooter for that? gw(config)#ip drama enable ^ % Invalid input detected at '^' marker. Computer says no........... -j [1] professional history and credentials upon request On Tue, Nov 25, 2008 at 7:18 PM, Jim Popovitch <yahoo at jimpop.com> wrote: > On Tue, Nov 25, 2008 at 18:52, Bill Woodcock <woody at pch.net> wrote: > > On Tue, 25 Nov 2008, Dean Anderson wrote: > > > A photo of Bill Woodcock's refused letter is at > > > http://www.av8.net/BillWoodcock.jpg > > That's not a refused letter, that's a certified letter that hasn't yet > been mailed. When refused, the item is signed and stamped (in red > ink) by the postal delivery agent. It would be very interesting to > see the image of the other side of the envelope (where postage > stamp/payment info would appear). > > That said... this whole thing has an air of childishness associated with > it. > > -Jim P. > > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From petelists at templin.org Wed Nov 26 04:37:59 2008 From: petelists at templin.org (Pete Templin) Date: Wed, 26 Nov 2008 05:37:59 -0500 Subject: DOS attack assistance? Message-ID: <492D2707.5090505@templin.org> One of my customers, a host at 64.8.105.15, is feeling a "bonus" ~130kpps from 88.191.63.28. I've null-routed the source, though our Engine2 GE cards don't seem to be doing a proper job of that, unfortunately. The attack is a solid 300% more pps than our aggregate traffic levels. It's coming in via 6461, but they don't appear to have any ability to backtrack it. Their only offer is to blackhole the destination until the attack subsides. BGP tells me the source is in AS 12322, a RIPE AS that has little if any information publicly visible. Any pointers on what to do next? Thanks, Pete From swmike at swm.pp.se Wed Nov 26 04:47:17 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 26 Nov 2008 11:47:17 +0100 (CET) Subject: DOS attack assistance? In-Reply-To: <492D2707.5090505@templin.org> References: <492D2707.5090505@templin.org> Message-ID: <alpine.DEB.1.10.0811261146260.10993@uplift.swm.pp.se> On Wed, 26 Nov 2008, Pete Templin wrote: > It's coming in via 6461, but they don't appear to have any ability to > backtrack it. Their only offer is to blackhole the destination until > the attack subsides. BGP tells me the source is in AS 12322, a RIPE AS > that has little if any information publicly visible. >From ripe whois database: role: Technical Contact for ProXad address: Free SAS / ProXad address: 8, rue de la Ville L'Eveque address: 75008 Paris phone: +33 1 73 50 20 00 fax-no: +33 1 73 92 25 69 remarks: trouble: Information: http://www.proxad.net/ remarks: trouble: Spam/Abuse requests: mailto:abuse at proxad.net admin-c: RA999-RIPE tech-c: FG4214-RIPE nic-hdl: TCP8-RIPE mnt-by: PROXAD-MNT source: RIPE # Filtered abuse-mailbox: abuse at proxad.net Do you really call this "little if any information publically visible"? -- Mikael Abrahamsson email: swmike at swm.pp.se From j at jcoley.net Wed Nov 26 04:50:39 2008 From: j at jcoley.net (Jay Coley) Date: Wed, 26 Nov 2008 10:50:39 +0000 Subject: DOS attack assistance? In-Reply-To: <492D2707.5090505@templin.org> References: <492D2707.5090505@templin.org> Message-ID: <492D29FF.9030102@jcoley.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pete Templin wrote: > One of my customers, a host at 64.8.105.15, is feeling a "bonus" > ~130kpps from 88.191.63.28. I've null-routed the source, though our > Engine2 GE cards don't seem to be doing a proper job of that, > unfortunately. The attack is a solid 300% more pps than our aggregate > traffic levels. > > It's coming in via 6461, but they don't appear to have any ability to > backtrack it. Their only offer is to blackhole the destination until > the attack subsides. BGP tells me the source is in AS 12322, a RIPE AS > that has little if any information publicly visible. > > Any pointers on what to do next? If it's all coming from that single IP 88.191.63.28, just request that your upstream block it. Usually if you explain the situation to them they'll oblige. Otherwise you'll want to look at mitigation gear (Toplayer, Cisco, etc) there are loads out there or you can look into a DDoS mitigation service. The Contacts I can see for that ASN are role: Technical Contact for ProXad address: Free SAS / ProXad address: 8, rue de la Ville L'Eveque address: 75008 Paris phone: +33 1 73 50 20 00 fax-no: +33 1 73 92 25 69 remarks: trouble: Information: http://www.proxad.net/ remarks: trouble: Spam/Abuse requests: mailto:abuse at proxad.net admin-c: RA999-RIPE tech-c: FG4214-RIPE nic-hdl: TCP8-RIPE mnt-by: PROXAD-MNT source: RIPE # Filtered abuse-mailbox: abuse at proxad.net Hope that helps! - --J -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkktKf8ACgkQETh+0NgvOtF+IgCdFE4TD885Ot9d97b+Dhenmrn8 oVYAniR3qua8mG3D7escGxv+td458jUK =BwvQ -----END PGP SIGNATURE----- From rol at witbe.net Wed Nov 26 05:14:18 2008 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Wed, 26 Nov 2008 12:14:18 +0100 Subject: DOS attack assistance? In-Reply-To: <492D2707.5090505@templin.org> References: <492D2707.5090505@templin.org> Message-ID: <20081126121418.53a6754a@tux.DEF.witbe.net> Hello, On Wed, 26 Nov 2008 05:37:59 -0500 Pete Templin <petelists at templin.org> wrote: > One of my customers, a host at 64.8.105.15, is feeling a "bonus" > ~130kpps from 88.191.63.28. I've null-routed the source, though our > Engine2 GE cards don't seem to be doing a proper job of that, > unfortunately. The attack is a solid 300% more pps than our aggregate > traffic levels. > > It's coming in via 6461, but they don't appear to have any ability to > backtrack it. Their only offer is to blackhole the destination until > the attack subsides. BGP tells me the source is in AS 12322, a RIPE AS > that has little if any information publicly visible. > 12322 is Free, a DSL (and now FTTH) provider in France. They also have a dedicated server hosting service. 88.191.63.28 is one of these dedicated server that is hosted in one of their DC : traceroute to 88.191.63.28 (88.191.63.28), 30 hops max, 60 byte packets ... 7 10ge-1-50.bzn-swr5.dedibox.fr (88.191.2.37) 353.946 ms 334.180 ms 336.400 ms 8 sd-11899.dedibox.fr (88.191.63.28) 338.403 ms 374.956 ms 376.837 ms I thought these were supposed to be connected at 100MBps, but if you see more than that, then it is possible that they are now connected thru a GBps port. You can try to contact the dedibox NOC, and Free : noc at free.fr can be a nice place to start... Paul > Any pointers on what to do next? > > Thanks, > > Pete > -- Paul Rolland E-Mail : rol(at)witbe.net CTO - Witbe.net SA Tel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La Defense RIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" All I need to have a good time, Is a reefer, a woman and a bottle of wine. With those three things I don't need no sunshine, A reefer, a woman and a bottle of wine. All I want is to never grow old, I want to wash in a bathtub of gold. I want 97 kilos already rolled, I want to wash in a bathtub of gold. I want to light my cigars with 10 dollar bills, I like to have a cattle ranch in Beverly Hills. I want a bottle of Red Eye that's always filled, I like to have a cattle ranch in Beverly Hills. -- Country Joe and the Fish, "Zachariah" From petelists at templin.org Wed Nov 26 05:16:01 2008 From: petelists at templin.org (Pete Templin) Date: Wed, 26 Nov 2008 06:16:01 -0500 Subject: DOS attack assistance? In-Reply-To: <alpine.DEB.1.10.0811261146260.10993@uplift.swm.pp.se> References: <492D2707.5090505@templin.org> <alpine.DEB.1.10.0811261146260.10993@uplift.swm.pp.se> Message-ID: <492D2FF1.7090403@templin.org> Mikael Abrahamsson wrote: > Do you really call this "little if any information publically visible"? Nope, I was wrong about that. My search-fu on RIPE isn't up to snuff, apparently; hence the request for assistance. pt From DHyde at HostMySite.com Wed Nov 26 05:53:11 2008 From: DHyde at HostMySite.com (Darrell Hyde) Date: Wed, 26 Nov 2008 06:53:11 -0500 Subject: DOS attack assistance? In-Reply-To: <492D2707.5090505@templin.org> References: <492D2707.5090505@templin.org> Message-ID: <A020FB4C57CEE249BD8F80C96590AC962CBAE6B584@MBX01.corp.safesecureweb.com> >One of my customers, a host at 64.8.105.15, is feeling a "bonus" >~130kpps from 88.191.63.28. I've null-routed the source, though our >Engine2 GE cards don't seem to be doing a proper job of that, >unfortunately. The attack is a solid 300% more pps than our aggregate >traffic levels. Null routing the source isn't going to stop the inbound packets from reaching the target of the attack. All that's going to do is blackhole packets back to the attacker from anyone hopping through the router carrying the null route. - Darrell From maxlarson.henry at mtptc.gouv.ht Wed Nov 26 07:53:16 2008 From: maxlarson.henry at mtptc.gouv.ht (Max Larson Henry) Date: Wed, 26 Nov 2008 08:53:16 -0500 Subject: DOS attack assistance? In-Reply-To: <492D2707.5090505@templin.org> References: <492D2707.5090505@templin.org> Message-ID: <90155a1e0811260553g391a12b5pe24d012bf9e069f8@mail.gmail.com> Hi, Please look for proxad.fr <-- Free Free is an ADSL provider based in France and proxad is a hosting company (please give a look at the "dig -x" below) dig -x 88.191.63.28 ; <<>> DiG 9.5.0b2 <<>> -x 88.191.63.28 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 131 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;28.63.191.88.in-addr.arpa. IN PTR ;; ANSWER SECTION: 28.63.191.88.in-addr.arpa. 86400 IN PTR sd-11899.dedibox.fr. ;; AUTHORITY SECTION: 63.191.88.in-addr.arpa. 86400 IN NS dns2.dedibox.fr. 63.191.88.in-addr.arpa. 86400 IN NS dns1.dedibox.fr. ;; Query time: 390 msec ;; SERVER: 200.80.96.100#53(200.80.96.100) ;; WHEN: Wed Nov 26 08:46:38 2008 ;; MSG SIZE rcvd: 114 ========================== dig -x 88.191.63.28 +trace ; <<>> DiG 9.5.0b2 <<>> -x 88.191.63.28 +trace ;; global options: printcmd . 17574 IN NS d.root-servers.net. . 17574 IN NS e.root-servers.net. . 17574 IN NS f.root-servers.net. . 17574 IN NS g.root-servers.net. . 17574 IN NS h.root-servers.net. . 17574 IN NS i.root-servers.net. . 17574 IN NS j.root-servers.net. . 17574 IN NS k.root-servers.net. . 17574 IN NS l.root-servers.net. . 17574 IN NS m.root-servers.net. . 17574 IN NS a.root-servers.net. . 17574 IN NS b.root-servers.net. . 17574 IN NS c.root-servers.net. ;; Received 488 bytes from 200.80.96.100#53(200.80.96.100) in 31 ms 88.in-addr.arpa. 86400 IN NS ns.lacnic.net. 88.in-addr.arpa. 86400 IN NS ns3.nic.fr. 88.in-addr.arpa. 86400 IN NS sec1.apnic.net. 88.in-addr.arpa. 86400 IN NS sec3.apnic.net. 88.in-addr.arpa. 86400 IN NS sunic.sunet.se. 88.in-addr.arpa. 86400 IN NS ns-pri.ripe.net. 88.in-addr.arpa. 86400 IN NS tinnie.arin.net. ;; Received 218 bytes from 199.7.83.42#53(l.root-servers.net) in 78 ms 191.88.in-addr.arpa. 172800 IN NS ns.ripe.net. 191.88.in-addr.arpa. 172800 IN NS ns0.proxad.net. 191.88.in-addr.arpa. 172800 IN NS ns1.proxad.net. ;; Received 111 bytes from 193.0.0.195#53(ns-pri.ripe.net) in 187 ms 63.191.88.in-addr.arpa. 86400 IN NS dns1.dedibox.fr. 63.191.88.in-addr.arpa. 86400 IN NS dns2.dedibox.fr. ;; Received 123 bytes from 212.27.32.2#53(ns0.proxad.net) in 187 ms 28.63.191.88.in-addr.arpa. 86400 IN PTR sd-11899.dedibox.fr. 191.88.in-addr.arpa. 7200 IN NS dns1.dedibox.fr. 191.88.in-addr.arpa. 7200 IN NS dns2.dedibox.fr. ;; Received 146 bytes from 88.191.254.6#53(dns1.dedibox.fr) in 187 ms -Max 2008/11/26 Pete Templin <petelists at templin.org>: > One of my customers, a host at 64.8.105.15, is feeling a "bonus" ~130kpps > from 88.191.63.28. I've null-routed the source, though our Engine2 GE cards > don't seem to be doing a proper job of that, unfortunately. The attack is a > solid 300% more pps than our aggregate traffic levels. > > It's coming in via 6461, but they don't appear to have any ability to > backtrack it. Their only offer is to blackhole the destination until the > attack subsides. BGP tells me the source is in AS 12322, a RIPE AS that has > little if any information publicly visible. > > Any pointers on what to do next? > > Thanks, > > Pete > > From SFisher at Bresnan.com Wed Nov 26 08:26:00 2008 From: SFisher at Bresnan.com (Fisher, Shawn) Date: Wed, 26 Nov 2008 09:26:00 -0500 Subject: Black Friday or Cyber Monday Message-ID: <21352038E7719F43A6D65B2D90B5256C021F7CED@fossil.bresnan.com> To all the service providers out there, do you historically see a significant uptick in internet traffic on "Black Friday" <http://en.wikipedia.org/wiki/Black_Friday_(shopping)> (the Friday after the US Holiday of Thanksgiving, named supposedly due to retail companies going from in the "red" all year to "black", bottom-line, "normally" lots of shopping occurs both online and traditional) and Cyber Monday <http://en.wikipedia.org/wiki/Cyber_Monday> ? I am curious what percentages of change are typically seen? TIA, Shawn Fisher From mohacsi at niif.hu Wed Nov 26 09:22:12 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 26 Nov 2008 16:22:12 +0100 (CET) Subject: IPv6 routing /48s In-Reply-To: <200811260100.mAQ10nAK016632@drugs.dv.isc.org> References: <200811260100.mAQ10nAK016632@drugs.dv.isc.org> Message-ID: <alpine.BSF.2.00.0811261621100.67780@mignon.ki.iif.hu> On Wed, 26 Nov 2008, Mark Andrews wrote: > > Mark Andrews writes: >> >> In message <20081126002425.GO78345 at burnout.tpb.net>, Niels Bakker writes: >>> * alh-ietf at tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]: >>>> In any case, content providers can avoid the confusion if they simply put >> u >>> p >>>> a local 6to4 router alongside their 2001:: prefix, and populate DNS with >>>> both. Longest match will cause 2001:: connected systems to chose that dst >> , >>>> while 6to4 connected systems will chose 2002:: as the dst. There is no ne >> ed >>> >>> Huh? Longest match done by web browsers and other applications? Since >>> when? >> >> FreeBSD 6 has is as part of the standard getaddrinfo() implementation. >> >> % grep -r in6_addrpolicy /usr/src/lib/libc >> /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy pc_policy; >> /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy *pol, *ep; >> /usr/src/lib/libc/net/getaddrinfo.c: ep = (struct in6_addrpolicy *)(buf + >> l); >> /usr/src/lib/libc/net/getaddrinfo.c: for (pol = (struct in6_addrpolicy *)b >> uf; pol + 1 <= ep; pol++) { >> /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy *pol; >> /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy pc_policy; >> /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol, *ep; >> /usr/src/lib/libc/net/name6.c: ep = (struct in6_addrpolicy *)(buf + l); >> /usr/src/lib/libc/net/name6.c: for (pol = (struct in6_addrpolicy *)buf; pol >> + 1 <= ep; pol++) { >> /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol; >> % > > And it was added on 30-Oct-03 according to CVS. And it was not imported to any MacOS X yet.... Regards, Janos From fw at deneb.enyo.de Wed Nov 26 15:00:55 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 26 Nov 2008 22:00:55 +0100 Subject: IPv6 routing /48s In-Reply-To: <20081126002425.GO78345@burnout.tpb.net> (Niels Bakker's message of "Wed, 26 Nov 2008 01:24:25 +0100") References: <OFC96626CF.8E97CCDC-ON85257504.007C3F42-86257504.007D12F7@frbog.frb.gov> <D2D2E6DE-A60F-43E0-B62F-7177B2EC532E@daork.net> <75cb24520811180926q3760a78jb21f32d044e31b84@mail.gmail.com> <4922FDD2.1070707@rancid.berkeley.edu> <874p234uxg.fsf@mid.deneb.enyo.de> <FB540970-BE21-48E2-AACC-ACA5302FF2D2@daork.net> <alpine.BSF.2.00.0811200912550.60025@mignon.ki.iif.hu> <878wrdrs3l.fsf@mid.deneb.enyo.de> <4926DECB.5050501@brightok.net> <05e301c94f5a$41e11210$c5a33630$@net> <20081126002425.GO78345@burnout.tpb.net> Message-ID: <87hc5urym0.fsf@mid.deneb.enyo.de> * Niels Bakker: > * alh-ietf at tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]: >> In any case, content providers can avoid the confusion if they simply put up >> a local 6to4 router alongside their 2001:: prefix, and populate DNS with >> both. Longest match will cause 2001:: connected systems to chose that dst, >> while 6to4 connected systems will chose 2002:: as the dst. There is no need > > Huh? Longest match done by web browsers and other applications? > Since when? It's been part of GNU libc for a while, but it has been disabled by several distributions. Usually, random selection leads to better results. At they very least, it makes renumbering much simpler because all addresses are equal, independently of where your clients are located. It's been a PITA to get this resolved (both in the IETF and in implementations), and it's still not done AFAIK. From Mark_Andrews at isc.org Wed Nov 26 16:08:26 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 27 Nov 2008 09:08:26 +1100 Subject: IPv6 routing /48s In-Reply-To: Your message of "Wed, 26 Nov 2008 16:22:12 BST." <alpine.BSF.2.00.0811261621100.67780@mignon.ki.iif.hu> Message-ID: <200811262208.mAQM8QdG045183@drugs.dv.isc.org> In message <alpine.BSF.2.00.0811261621100.67780 at mignon.ki.iif.hu>, Mohacsi Jano s writes: > > > > On Wed, 26 Nov 2008, Mark Andrews wrote: > > > > > Mark Andrews writes: > >> > >> In message <20081126002425.GO78345 at burnout.tpb.net>, Niels Bakker writes: > >>> * alh-ietf at tndh.net (Tony Hain) [Wed 26 Nov 2008, 01:03 CET]: > >>>> In any case, content providers can avoid the confusion if they simply pu > t > >> u > >>> p > >>>> a local 6to4 router alongside their 2001:: prefix, and populate DNS with > >>>> both. Longest match will cause 2001:: connected systems to chose that ds > t > >> , > >>>> while 6to4 connected systems will chose 2002:: as the dst. There is no n > e > >> ed > >>> > >>> Huh? Longest match done by web browsers and other applications? Since > >>> when? > >> > >> FreeBSD 6 has is as part of the standard getaddrinfo() implementation. > >> > >> % grep -r in6_addrpolicy /usr/src/lib/libc > >> /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy pc_policy; > >> /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy *pol, *ep; > >> /usr/src/lib/libc/net/getaddrinfo.c: ep = (struct in6_addrpolicy *)(buf > + > >> l); > >> /usr/src/lib/libc/net/getaddrinfo.c: for (pol = (struct in6_addrpolicy > *)b > >> uf; pol + 1 <= ep; pol++) { > >> /usr/src/lib/libc/net/getaddrinfo.c: struct in6_addrpolicy *pol; > >> /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy pc_policy; > >> /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol, *ep; > >> /usr/src/lib/libc/net/name6.c: ep = (struct in6_addrpolicy *)(buf + l); > >> /usr/src/lib/libc/net/name6.c: for (pol = (struct in6_addrpolicy *)buf; p > ol > >> + 1 <= ep; pol++) { > >> /usr/src/lib/libc/net/name6.c: struct in6_addrpolicy *pol; > >> % > > > > And it was added on 30-Oct-03 according to CVS. > > And it was not imported to any MacOS X yet.... Well complain to Apple. > Regards, > Janos -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From Todd_Young at unigroupinc.com Thu Nov 27 06:03:03 2008 From: Todd_Young at unigroupinc.com (Todd_Young at unigroupinc.com) Date: Thu, 27 Nov 2008 06:03:03 -0600 Subject: Todd Young is out of the office. Message-ID: <OFBEDE9F1B.9AA81ABB-ON8625750E.004232CC-8625750E.004232CC@unigroupinc.com> I will be out of the office starting 11/26/2008 and will not return until 12/01/2008. I will respond to your message when I return. If you are having a network issue, please contact Network Operations at 1-800-825-9585, option 3. ######################################################################## The information contained in this message, and any attachments thereto, is intended solely for the use of the addressee(s) and may contain confidential and/or privileged material. Any review, retransmission, dissemination, copying, or other use of the transmitted information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. UNIGROUPINC.COM ######################################################################## From david.freedman at uk.clara.net Thu Nov 27 07:39:13 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Thu, 27 Nov 2008 13:39:13 +0000 Subject: DOS attack assistance? In-Reply-To: <A020FB4C57CEE249BD8F80C96590AC962CBAE6B584@MBX01.corp.safesecureweb.com> References: <492D2707.5090505@templin.org> <A020FB4C57CEE249BD8F80C96590AC962CBAE6B584@MBX01.corp.safesecureweb.com> Message-ID: <ggm7u1$4rg$1@ger.gmane.org> > Null routing the source isn't going to stop <snip> Except when doing source based blackholing, see http://tools.ietf.org/html/draft-kumari-blackhole-urpf-02 section #4 Dave. From cidr-report at potaroo.net Fri Nov 28 05:00:05 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Nov 2008 22:00:05 +1100 (EST) Subject: BGP Update Report Message-ID: <200811281100.mASB054c047429@wattle.apnic.net> BGP Update Report Interval: 27-Oct-08 -to- 27-Nov-08 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 252085 1.8% 49.7 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS9583 214247 1.6% 178.7 -- SIFY-AS-IN Sify Limited 3 - AS6389 149692 1.1% 33.8 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 4 - AS10396 133984 1.0% 2310.1 -- COQUI-NET - DATACOM CARIBE, INC. 5 - AS1803 92457 0.7% 65.0 -- ICMNET-5 - Sprint 6 - AS24863 87976 0.6% 130.1 -- LINKdotNET-AS 7 - AS209 87816 0.6% 28.0 -- ASN-QWEST - Qwest Communications Corporation 8 - AS29282 84487 0.6% 28162.3 -- EMENTOR-AS Enfo Oyj 9 - AS6629 82966 0.6% 1276.4 -- NOAA-AS - NOAA 10 - AS6298 78393 0.6% 35.8 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 11 - AS8151 77243 0.6% 35.1 -- Uninet S.A. de C.V. 12 - AS20115 73975 0.5% 35.6 -- CHARTER-NET-HKY-NC - Charter Communications 13 - AS23126 61169 0.5% 262.5 -- CENTURYTEL-SOLUTIONS-LLC - CenturyTel Solutions, LLC 14 - AS1785 57403 0.4% 33.4 -- AS-PAETEC-NET - PaeTec Communications, Inc. 15 - AS2386 57115 0.4% 35.0 -- INS-AS - AT&T Data Communications Services 16 - AS17488 54430 0.4% 37.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 17 - AS3462 51294 0.4% 250.2 -- HINET Data Communication Business Group 18 - AS6478 50954 0.4% 30.0 -- ATT-INTERNET3 - AT&T WorldNet Services 19 - AS7018 50053 0.4% 33.6 -- ATT-INTERNET4 - AT&T WorldNet Services 20 - AS4323 49971 0.4% 31.0 -- TWTC - tw telecom holdings, inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29282 84487 0.6% 28162.3 -- EMENTOR-AS Enfo Oyj 2 - AS14106 45703 0.3% 22851.5 -- LEPMED01 - Leprechaun, LLC 3 - AS30287 4758 0.0% 4758.0 -- ALON-USA - ALON USA, LP 4 - AS40194 3900 0.0% 3900.0 -- INHOUSE-ASSOCIATES-LC - Inhouse Associates, L.C. 5 - AS28194 17903 0.1% 3580.6 -- 6 - AS14220 17184 0.1% 3436.8 -- I2A - I 20 Access 7 - AS41007 16674 0.1% 3334.8 -- CTCASTANA CTC ASTANA, KZ 8 - AS4130 16562 0.1% 3312.4 -- UPITT-AS - University of Pittsburgh 9 - AS5033 27181 0.2% 3020.1 -- ISW - Internet Specialties West Inc. 10 - AS25799 2923 0.0% 2923.0 -- HOLMAN - Holman Enterprises 11 - AS47731 2628 0.0% 2628.0 -- ISDC-AS SC ISDC ROMANIA SRL 12 - AS30969 20782 0.1% 2597.8 -- TAN-NET TransAfrica Networks 13 - AS23917 2503 0.0% 2503.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 14 - AS10396 133984 1.0% 2310.1 -- COQUI-NET - DATACOM CARIBE, INC. 15 - AS48131 2072 0.0% 2072.0 -- VANGUARD-BG-AS Vanguard SA 16 - AS8266 1909 0.0% 1909.0 -- NEXUSTEL Nexus Telecommunications 17 - AS21764 3427 0.0% 1713.5 -- ESOFTINC-NET - eSoft, Inc. 18 - AS43299 1590 0.0% 1590.0 -- TELECONTACT-AS Telecontact Ltd. 19 - AS14620 1576 0.0% 1576.0 -- ITALK - iTalk Global Communications, Inc. 20 - AS22247 1533 0.0% 1533.0 -- LETOURNEAUUNIVERSITY - LeTourneau University TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 77.95.144.0/22 64151 0.5% AS29282 -- EMENTOR-AS Enfo Oyj 2 - 221.134.222.0/24 62147 0.4% AS9583 -- SIFY-AS-IN Sify Limited 3 - 210.214.151.0/24 57883 0.4% AS9583 -- SIFY-AS-IN Sify Limited 4 - 221.135.80.0/24 39274 0.3% AS9583 -- SIFY-AS-IN Sify Limited 5 - 64.162.116.0/24 26905 0.2% AS5033 -- ISW - Internet Specialties West Inc. 6 - 192.102.88.0/24 26330 0.2% AS6629 -- NOAA-AS - NOAA 7 - 198.77.177.0/24 26015 0.2% AS6629 -- NOAA-AS - NOAA 8 - 192.35.129.0/24 25952 0.2% AS6629 -- NOAA-AS - NOAA 9 - 8.192.154.0/24 24903 0.2% AS14106 -- LEPMED01 - Leprechaun, LLC 10 - 65.44.76.0/24 20800 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 11 - 217.69.48.0/20 20308 0.1% AS29282 -- EMENTOR-AS Enfo Oyj 12 - 124.7.201.0/24 18082 0.1% AS9583 -- SIFY-AS-IN Sify Limited 13 - 150.212.224.0/19 16415 0.1% AS4130 -- UPITT-AS - University of Pittsburgh 14 - 192.12.120.0/24 16401 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 15 - 194.126.143.0/24 14659 0.1% AS9051 -- IDM Autonomous System 16 - 221.128.192.0/18 12978 0.1% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 17 - 89.4.131.0/24 12120 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 18 - 41.204.2.0/24 11416 0.1% AS32398 -- REALNET-ASN-1 19 - 203.63.26.0/24 10764 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 20 - 196.27.104.0/21 10030 0.1% AS30969 -- TAN-NET TransAfrica Networks Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Nov 28 05:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Nov 2008 22:00:02 +1100 (EST) Subject: The Cidr Report Message-ID: <200811281100.mASB02vE047424@wattle.apnic.net> This report has been generated at Fri Nov 28 21:24:45 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 21-11-08 291693 179552 22-11-08 292056 179242 23-11-08 292318 178139 24-11-08 292375 179063 25-11-08 292506 179813 26-11-08 292651 178174 27-11-08 292308 176215 28-11-08 288778 176644 AS Summary 30082 Number of ASes in routing system 12755 Number of ASes announcing only one prefix 5069 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 89820928 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 28Nov08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 289048 176623 112425 38.9% All ASes AS4538 5069 877 4192 82.7% ERX-CERNET-BKB China Education and Research Network Center AS6389 4379 356 4023 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2991 1319 1672 55.9% ASN-QWEST - Qwest Communications Corporation AS1785 1701 205 1496 87.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS6298 2168 681 1487 68.6% ASN-CXA-PH-6298-CBS - Cox Communications Inc. AS17488 1442 293 1149 79.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1589 458 1131 71.2% TWTC - tw telecom holdings, inc. AS4755 1175 202 973 82.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS6478 1608 760 848 52.7% ATT-INTERNET3 - AT&T WorldNet Services AS8151 1395 559 836 59.9% Uninet S.A. de C.V. AS18566 1059 242 817 77.1% COVAD - Covad Communications Co. AS11492 1219 451 768 63.0% CABLEONE - CABLE ONE, INC. AS2386 1597 917 680 42.6% INS-AS - AT&T Data Communications Services AS19262 932 255 677 72.6% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 787 183 604 76.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1106 524 582 52.6% LEVEL3 Level 3 Communications AS9498 692 115 577 83.4% BBIL-AP BHARTI Airtel Ltd. AS7545 660 154 506 76.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS4808 624 157 467 74.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS22773 1003 545 458 45.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS20115 1840 1386 454 24.7% CHARTER-NET-HKY-NC - Charter Communications AS24560 625 172 453 72.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1442 999 443 30.7% ATT-INTERNET4 - AT&T WorldNet Services AS17676 522 79 443 84.9% GIGAINFRA BB TECHNOLOGY Corp. AS855 560 119 441 78.8% CANET-ASN-4 - Bell Aliant AS9443 523 84 439 83.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4766 1331 896 435 32.7% KIXS-AS-KR Korea Telecom AS22047 552 121 431 78.1% VTR BANDA ANCHA S.A. AS4134 907 477 430 47.4% CHINANET-BACKBONE No.31,Jin-rong Street AS4668 691 276 415 60.1% LGNET-AS-KR LG CNS Total 42189 13862 28327 67.1% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 100.10.10.0/24 AS14000 AXTEL, S.A. de C.V. 119.31.232.0/21 AS38870 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 124.109.16.0/21 AS38137 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 169.254.0.0/16 AS13184 HANSENET HanseNet Telekommunikation GmbH 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.0.187.0/24 AS19132 200.5.32.0/21 AS19132 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/21 AS38205 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From smb at cs.columbia.edu Fri Nov 28 07:34:33 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 28 Nov 2008 08:34:33 -0500 Subject: an over-the-top data center Message-ID: <20081128083433.0e18c7e2@cs.columbia.edu> http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-center-fit-for-a-james-bond-villain/ (No, I don't know if it's real or not.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From mansaxel at besserwisser.org Fri Nov 28 08:52:59 2008 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Fri, 28 Nov 2008 15:52:59 +0100 Subject: an over-the-top data center In-Reply-To: <20081128083433.0e18c7e2@cs.columbia.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: <E001516945FF5475C33B7345@rasmus.kthnoc.net> --On fredag, fredag 28 nov 2008 08.34.33 -0500 "Steven M. Bellovin" <smb at cs.columbia.edu> wrote: > http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-c > enter-fit-for-a-james-bond-villain/ (No, I don't know if it's real or > not.) It is. The server space is outside the blastproof area. Go figure. -- M?ns Nilsson M A C H I N A I'm into SOFTWARE! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081128/252454ee/attachment.bin> From r.bhatia at ipax.at Fri Nov 28 08:54:16 2008 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Fri, 28 Nov 2008 15:54:16 +0100 Subject: an over-the-top data center In-Reply-To: <20081128083433.0e18c7e2@cs.columbia.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: <49300618.2050406@ipax.at> Steven M. Bellovin wrote: > http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-center-fit-for-a-james-bond-villain/ > (No, I don't know if it's real or not.) more images: http://www.archdaily.com/9257/pionen-%E2%80%93-white-mountain-albert-france-lanord-architects/ cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From grinch at panix.com Fri Nov 28 10:41:45 2008 From: grinch at panix.com (Craig Holland) Date: Fri, 28 Nov 2008 16:41:45 +0000 Subject: an over-the-top data center Message-ID: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> Just me, or is showing the floorplan not the typical behavior of a super-secure anything? ------Original Message------ From: M?ns Nilsson To: Steven M. Bellovin To: NANOG Sent: Nov 28, 2008 6:52 AM Subject: Re: an over-the-top data center --On fredag, fredag 28 nov 2008 08.34.33 -0500 "Steven M. Bellovin" <smb at cs.columbia.edu> wrote: > http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-c > enter-fit-for-a-james-bond-villain/ (No, I don't know if it's real or > not.) It is. The server space is outside the blastproof area. Go figure. -- M?ns Nilsson M A C H I N A I'm into SOFTWARE! From patrick at zill.net Fri Nov 28 10:55:27 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Fri, 28 Nov 2008 11:55:27 -0500 Subject: an over-the-top data center In-Reply-To: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> Message-ID: <4930227F.9080009@zill.net> Craig Holland wrote: > Just me, or is showing the floorplan not the typical behavior of a super-secure anything? > You mean, security through obscurity? --Patrick From swm at emanon.com Fri Nov 28 10:57:05 2008 From: swm at emanon.com (Scott Morris) Date: Fri, 28 Nov 2008 11:57:05 -0500 Subject: an over-the-top data center In-Reply-To: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> Message-ID: <F428733F9CCA4A459649264C3A3C1DE1@scott66ed7b03d> It's the "double-dog-dare". :) Scott -----Original Message----- From: Craig Holland [mailto:grinch at panix.com] Sent: Friday, November 28, 2008 11:42 AM To: M?ns Nilsson; Steven M. Bellovin; NANOG Subject: Re: an over-the-top data center Just me, or is showing the floorplan not the typical behavior of a super-secure anything? ------Original Message------ From: M?ns Nilsson To: Steven M. Bellovin To: NANOG Sent: Nov 28, 2008 6:52 AM Subject: Re: an over-the-top data center --On fredag, fredag 28 nov 2008 08.34.33 -0500 "Steven M. Bellovin" <smb at cs.columbia.edu> wrote: > http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-dat > a-c enter-fit-for-a-james-bond-villain/ (No, I don't know if it's real > or > not.) It is. The server space is outside the blastproof area. Go figure. -- M?ns Nilsson M A C H I N A I'm into SOFTWARE! From simonw at zynet.net Fri Nov 28 11:10:14 2008 From: simonw at zynet.net (Simon Waters) Date: Fri, 28 Nov 2008 17:10:14 +0000 Subject: an over-the-top data center In-Reply-To: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> Message-ID: <200811281710.14397.simonw@zynet.net> On Friday 28 November 2008 16:41:45 Craig Holland wrote: > Just me, or is showing the floorplan not the typical behavior of a > super-secure anything? I'm not sure anyone but the press are claiming anything is super secure there. I can't imagine being in a bunker makes physical security worse (although it could make cooling, and working diesel backup generators more interesting). Having had to visit data centres so secure they don't list their name on the front of the building, which is great for security till you need an engineer in a hurry and he is driving around looking for the building. I'm thinking physical security is over done in some data centers. Sure it is a great idea to make sure no one steals the hardware, but much beyond that and allowing in expected personnel only, it soon gets to being counter productive. I was once back-up for a facility so "secure" I never got to visit it?! I'm not saying I might not have been that useful if I was ever called on to provide support - guess we'll never know. Although for that one I did at least happen to know where it was despite it not being sign posted. From cscora at apnic.net Fri Nov 28 12:12:28 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Nov 2008 04:12:28 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200811281812.mASICS8M020782@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <pfs at cisco.com>. Routing Table Report 04:00 +10GMT Sat 29 Nov, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 275422 Prefixes after maximum aggregation: 131996 Deaggregation factor: 2.09 Unique aggregates announced to Internet: 133443 Total ASes present in the Internet Routing Table: 29927 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 26053 Origin ASes announcing only one prefix: 12687 Transit ASes present in the Internet Routing Table: 3874 Transit-only ASes present in the Internet Routing Table: 91 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 542 Unregistered ASNs in the Routing Table: 198 Number of 32-bit ASNs allocated by the RIRs: 65 Prefixes from 32-bit ASNs in the Routing Table: 9 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 197 Number of addresses announced to Internet: 1965542656 Equivalent to 117 /8s, 39 /16s and 205 /24s Percentage of available address space announced: 53.0 Percentage of allocated address space announced: 63.4 Percentage of available address space allocated: 83.7 Percentage of address space in use by end-sites: 74.5 Total number of prefixes smaller than registry allocations: 136040 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 63222 Total APNIC prefixes after maximum aggregation: 23413 APNIC Deaggregation factor: 2.70 Prefixes being announced from the APNIC address blocks: 60136 Unique aggregates announced from the APNIC address blocks: 27076 APNIC Region origin ASes present in the Internet Routing Table: 3473 APNIC Prefixes per ASN: 17.32 APNIC Region origin ASes announcing only one prefix: 937 APNIC Region transit ASes present in the Internet Routing Table: 532 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 388651936 Equivalent to 23 /8s, 42 /16s and 91 /24s Percentage of available APNIC address space announced: 77.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124408 Total ARIN prefixes after maximum aggregation: 64946 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 93756 Unique aggregates announced from the ARIN address blocks: 34783 ARIN Region origin ASes present in the Internet Routing Table: 12620 ARIN Prefixes per ASN: 7.43 ARIN Region origin ASes announcing only one prefix: 4875 ARIN Region transit ASes present in the Internet Routing Table: 1203 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 401999520 Equivalent to 23 /8s, 246 /16s and 6 /24s Percentage of available ARIN address space announced: 82.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 60604 Total RIPE prefixes after maximum aggregation: 36259 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 56206 Unique aggregates announced from the RIPE address blocks: 37505 RIPE Region origin ASes present in the Internet Routing Table: 12249 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 6452 RIPE Region transit ASes present in the Internet Routing Table: 1870 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 17 Number of RIPE addresses announced to Internet: 380606560 Equivalent to 22 /8s, 175 /16s and 152 /24s Percentage of available RIPE address space announced: 87.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22517 Total LACNIC prefixes after maximum aggregation: 5598 LACNIC Deaggregation factor: 4.02 Prefixes being announced from the LACNIC address blocks: 20539 Unique aggregates announced from the LACNIC address blocks: 11442 LACNIC Region origin ASes present in the Internet Routing Table: 1038 LACNIC Prefixes per ASN: 19.79 LACNIC Region origin ASes announcing only one prefix: 339 LACNIC Region transit ASes present in the Internet Routing Table: 169 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 58459904 Equivalent to 3 /8s, 124 /16s and 7 /24s Percentage of available LACNIC address space announced: 58.1 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4151 Total AfriNIC prefixes after maximum aggregation: 1350 AfriNIC Deaggregation factor: 3.07 Prefixes being announced from the AfriNIC address blocks: 4453 Unique aggregates announced from the AfriNIC address blocks: 2199 AfriNIC Region origin ASes present in the Internet Routing Table: 271 AfriNIC Prefixes per ASN: 16.43 AfriNIC Region origin ASes announcing only one prefix: 84 AfriNIC Region transit ASes present in the Internet Routing Table: 55 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 13028352 Equivalent to 0 /8s, 198 /16s and 204 /24s Percentage of available AfriNIC address space announced: 25.9 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 17488 1442 101 104 Hathway IP Over Cable Interne 4766 1270 6409 364 Korea Telecom (KIX) 4755 1166 474 154 TATA Communications formerly 9583 1135 88 481 Sify Limited 4134 907 15536 371 CHINANET-BACKBONE 23577 803 34 692 Korea Telecom (ATM-MPLS) 18101 787 168 32 Reliance Infocom Ltd Internet 4780 727 357 63 Digital United Inc. 9498 688 295 50 BHARTI BT INTERNET LTD. 7545 649 152 82 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4376 3434 344 bellsouth.net, inc. 209 2988 4032 620 Qwest 6298 2168 334 632 Cox Communicatons 20115 1841 1460 737 Charter Communications 1785 1701 717 154 PaeTec Communications, Inc. 6478 1609 369 198 AT&T Worldnet Services 2386 1595 701 901 AT&T Data Communications Serv 4323 1592 1068 378 Time Warner Telecom 7018 1421 5872 982 AT&T WorldNet Services 11492 1219 192 12 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 432 1765 382 TDC Tele Danmark 12479 371 578 6 Uni2 Autonomous System 30890 369 80 196 SC Kappa Invexim SRL 3301 337 1429 306 TeliaNet Sweden 29049 331 26 3 AzerSat LLC. 8866 330 109 22 Bulgarian Telecommunication C 3320 326 7063 275 Deutsche Telekom AG 3215 314 2776 97 France Telecom Transpac 8452 311 188 11 TEDATA 8551 303 286 36 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1400 2832 221 UniNet S.A. de C.V. 11830 664 299 9 Instituto Costarricense de El 22047 552 270 14 VTR PUNTO NET S.A. 10620 546 122 40 TVCABLE BOGOTA 7303 497 244 72 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 425 88 50 ENTEL CHILE S.A. 11172 402 118 72 Servicios Alestra S.A de C.V 28573 354 483 28 NET Servicos de Comunicao S.A 14117 335 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 513 72 46 LINKdotNET AS number 3741 270 857 226 The Internet Solution 20858 261 34 3 EgyNet 2018 239 215 140 Tertiary Education Network 33783 143 10 17 EEPAD TISP TELECOM & INTERNET 6713 137 135 11 Itissalat Al-MAGHRIB 5536 120 8 17 Internet Egypt Network 5713 119 555 68 Telkom SA Ltd 33776 116 6 3 Starcomms Nigeria Limited 29571 112 15 8 Ci Telecom Autonomous system Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4376 3434 344 bellsouth.net, inc. 209 2988 4032 620 Qwest 6298 2168 334 632 Cox Communicatons 20115 1841 1460 737 Charter Communications 1785 1701 717 154 PaeTec Communications, Inc. 6478 1609 369 198 AT&T Worldnet Services 2386 1595 701 901 AT&T Data Communications Serv 4323 1592 1068 378 Time Warner Telecom 17488 1442 101 104 Hathway IP Over Cable Interne 7018 1421 5872 982 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2988 2368 Qwest 1785 1701 1547 PaeTec Communications, Inc. 6298 2168 1536 Cox Communicatons 6478 1609 1411 AT&T Worldnet Services 17488 1442 1338 Hathway IP Over Cable Interne 4323 1592 1214 Time Warner Telecom 11492 1219 1207 Cable One 8151 1400 1179 UniNet S.A. de C.V. 20115 1841 1104 Charter Communications 18566 1059 1049 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:19 /11:55 /12:158 /13:308 /14:550 /15:1078 /16:10184 /17:4479 /18:7721 /19:16582 /20:19468 /21:19158 /22:24307 /23:24990 /24:143522 /25:867 /26:1038 /27:796 /28:97 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2859 4376 bellsouth.net, inc. 6298 2142 2168 Cox Communicatons 209 1710 2988 Qwest 2386 1274 1595 AT&T Data Communications Serv 17488 1232 1442 Hathway IP Over Cable Interne 11492 1194 1219 Cable One 1785 1163 1701 PaeTec Communications, Inc. 6478 1106 1609 AT&T Worldnet Services 18566 1040 1059 Covad Communications 4766 1016 1270 Korea Telecom (KIX) Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:160 12:2183 13:2 15:21 16:3 17:5 20:36 24:1125 32:54 38:487 40:93 41:803 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:497 59:564 60:458 61:1041 62:1123 63:2012 64:3301 65:2445 66:3515 67:1368 68:847 69:2365 70:898 71:171 72:2084 73:7 74:1313 75:171 76:288 77:898 78:523 79:288 80:932 81:856 82:573 83:411 84:585 85:1047 86:503 87:651 88:350 89:1373 90:29 91:1718 92:325 93:995 94:689 95:49 96:92 97:138 98:403 99:9 100:1 110:1 111:1 113:41 114:127 115:163 116:1045 117:406 118:261 119:554 120:106 121:665 122:893 123:444 124:843 125:1246 128:358 129:219 130:136 131:410 132:72 133:9 134:187 135:31 136:223 137:116 138:144 139:86 140:414 141:111 142:371 143:303 144:308 145:52 146:373 147:143 148:607 149:212 150:143 151:210 152:141 153:131 154:10 155:276 156:165 157:302 158:168 159:298 160:273 161:132 162:251 163:132 164:518 165:513 166:361 167:341 168:650 169:155 170:459 171:40 172:10 173:126 174:7 187:18 188:1 189:324 190:2433 192:5823 193:4155 194:3288 195:2613 196:1020 198:3710 199:3313 200:5535 201:1476 202:7632 203:8060 204:3924 205:2188 206:2305 207:2761 208:3754 209:3438 210:2633 211:1132 212:1545 213:1637 214:70 215:25 216:4393 217:1241 218:359 219:419 220:1094 221:458 222:312 End of report From mansaxel at besserwisser.org Fri Nov 28 14:03:31 2008 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Fri, 28 Nov 2008 21:03:31 +0100 Subject: an over-the-top data center In-Reply-To: <200811281710.14397.simonw@zynet.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> Message-ID: <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> --On fredag, fredag 28 nov 2008 17.10.14 +0000 Simon Waters <simonw at zynet.net> wrote: > I'm thinking physical security is over done in some data centers. Sure it > is a great idea to make sure no one steals the hardware, but much beyond > that and allowing in expected personnel only, it soon gets to being > counter productive. > > I was once back-up for a facility so "secure" I never got to visit it?! > I'm not saying I might not have been that useful if I was ever called on > to provide support - guess we'll never know. Although for that one I did > at least happen to know where it was despite it not being sign posted. There are places whose location we do not talk about, where important stuff gets done, like peering. In Sweden, the Post and Telecommunications Authority has oversight over a number of first-rate data centres that are designed for those bits and pieces of infrastructure that need to work under all circumstances. Typically they rent space to telcos and ISP's for things like important central systems, backbone routers / transmission etc. The largest Internet exchange in Sweden, Netnod, has its five largest sites in these facilities. These data centres are designed to Swedish military command center specifications (not like Cheyenne Mountain but significantly better than, say, a Minuteman site) to withstand a number of adverse conditions, like near-misses from nuclear weapons, prolonged power outages, poison gas clouds, etc. Typically, they are buried in bedrock close to major cities. Exactly where is of course known in the business, but not so well that it is OK to post their locations on Nanog. Yes, we've got excellent bedrock in Sweden, and we use it ;-) -- M?ns Nilsson M A C H I N A I left my WALLET in the BATHROOM!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20081128/6d7a9daf/attachment.bin> From jfmezei at vaxination.ca Fri Nov 28 15:04:59 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Fri, 28 Nov 2008 16:04:59 -0500 Subject: an over-the-top data center In-Reply-To: <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> Message-ID: <49305CFB.9070703@vaxination.ca> M?ns Nilsson wrote: > Exactly where is of course known in the business, but not so well that it > is OK to post their locations on Nanog. The problem with this mentality is that it does not deter those wishing to do harm to the data centre or corporation. For banks, I think the biggest advantage of having a no-name building is that the general public will not try to enter the building thinking that there is a bank branch or ATMs available and then rudely be thrown out by the guards. If you look at Toronto, the main carrier hotel is quite famous at 151 Front Street, very near to the main train station, convention centre etc (aka: right at the core of the downtown). People who do not know about the internet infrastructure may not realise what this building is about, but anyone who knows how ISPs operate would know the strategic importance of that building. The thing about a carrier hotel is that it cannot be a secret location since you need to allow various carriers and ISPs to have physical access to the building so they can install/manage their servers/routers/switches. The advantage of this swedish data centre is that even if its location is well known, it is pretty hard to harm the building. You can't run a truck full of explosives into it for instance. From william.allen.simpson at gmail.com Fri Nov 28 15:19:48 2008 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 28 Nov 2008 16:19:48 -0500 Subject: an over-the-top data center In-Reply-To: <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> Message-ID: <49306074.2070408@gmail.com> M?ns Nilsson wrote: > These data centres are designed to Swedish military command center > specifications (not like Cheyenne Mountain but significantly better than, > say, a Minuteman site) > At one point some time ago, on NANOG we discussed putting exchanges in old minuteman silos. (so long ago a quick Google didn't find it -- where are all the old NANOG archives?) From sil at infiltrated.net Fri Nov 28 15:24:49 2008 From: sil at infiltrated.net (J. Oquendo) Date: Fri, 28 Nov 2008 15:24:49 -0600 Subject: an over-the-top data center In-Reply-To: <49306074.2070408@gmail.com> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> <49306074.2070408@gmail.com> Message-ID: <20081128212449.GB67666@infiltrated.net> On Fri, 28 Nov 2008, William Allen Simpson wrote: > At one point some time ago, on NANOG we discussed putting exchanges in old > minuteman silos. (so long ago a quick Google didn't find it -- where are > all > the old NANOG archives?) > http://www.irbs.net/internet/nanog/9708/0159.html http://www.irbs.net/internet/nanog/9711/0154.html http://www.irbs.net/internet/nanog/9610/0947.html http://www.irbs.net/internet/nanog/0109/1619.html =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "Each player must accept the cards life deals him or her: but once they are in hand, he or she alone must decide how to play the cards in order to win the game." Voltaire 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From jabley at hopcount.ca Fri Nov 28 15:33:17 2008 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 28 Nov 2008 16:33:17 -0500 Subject: an over-the-top data center In-Reply-To: <49305CFB.9070703@vaxination.ca> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> <49305CFB.9070703@vaxination.ca> Message-ID: <CBF3BA83-F6F4-4D0A-AD77-58FC382EF667@hopcount.ca> On 2008-11-28, at 16:04, Jean-Fran?ois Mezei wrote: > If you look at Toronto, the main carrier hotel is quite famous at 151 > Front Street, very near to the main train station, convention centre > etc > (aka: right at the core of the downtown). People who do not know about > the internet infrastructure may not realise what this building is > about, > but anyone who knows how ISPs operate would know the strategic > importance of that building. People who do not know that there's a Front Street East as well as a Front Street West also like to fight their way through the mantrap to front desk security and demand to see the dentist. So if anybody ever finds an operational advantage to having equipment in a building regularly visited by people with bad teeth, bear that in mind. Joe From warren at kumari.net Fri Nov 28 18:23:09 2008 From: warren at kumari.net (Warren Kumari) Date: Fri, 28 Nov 2008 19:23:09 -0500 Subject: an over-the-top data center In-Reply-To: <CBF3BA83-F6F4-4D0A-AD77-58FC382EF667@hopcount.ca> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> <49305CFB.9070703@vaxination.ca> <CBF3BA83-F6F4-4D0A-AD77-58FC382EF667@hopcount.ca> Message-ID: <A11742D8-74BC-4B69-9B18-4F1F3AE5870A@kumari.net> On Nov 28, 2008, at 4:33 PM, Joe Abley wrote: > > On 2008-11-28, at 16:04, Jean-Fran?ois Mezei wrote: > >> If you look at Toronto, the main carrier hotel is quite famous at 151 >> Front Street, very near to the main train station, convention >> centre etc >> (aka: right at the core of the downtown). People who do not know >> about >> the internet infrastructure may not realise what this building is >> about, >> but anyone who knows how ISPs operate would know the strategic >> importance of that building. > > People who do not know that there's a Front Street East as well as a > Front Street West also like to fight their way through the mantrap > to front desk security and demand to see the dentist. > > So if anybody ever finds an operational advantage to having > equipment in a building regularly visited by people with bad teeth, > bear that in mind. Hey, some of the best network engineers I have met are British.... W > > > > Joe > > From gtb at slac.stanford.edu Fri Nov 28 19:33:15 2008 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Fri, 28 Nov 2008 17:33:15 -0800 Subject: an over-the-top data center In-Reply-To: <20081128083433.0e18c7e2@cs.columbia.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: <D0D0330CBD07114D85B70B784E80C2F2022FCDC7@exch-mail2.win.slac.stanford.edu> > -----Original Message----- > From: Steven M. Bellovin [mailto:smb at cs.columbia.edu] > Sent: Friday, November 28, 2008 5:35 AM > To: nanog at nanog.org > Subject: an over-the-top data center > > http://royal.pingdom.com/2008/11/14/the-worlds-most-super-desi > gned-data-center-fit-for-a-james-bond-villain/ > (No, I don't know if it's real or not.) One could consider purchasing the underground tunnels in downtown London that BT is selling to build a competing "over-the-top" data center. http://www.nytimes.com/2008/11/28/business/worldbusiness/28tunnel.html From ops.lists at gmail.com Fri Nov 28 20:17:42 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 29 Nov 2008 07:47:42 +0530 Subject: an over-the-top data center In-Reply-To: <D0D0330CBD07114D85B70B784E80C2F2022FCDC7@exch-mail2.win.slac.stanford.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> <D0D0330CBD07114D85B70B784E80C2F2022FCDC7@exch-mail2.win.slac.stanford.edu> Message-ID: <bb0e440a0811281817w460ce45bo453c6653bafedb3e@mail.gmail.com> On Sat, Nov 29, 2008 at 7:03 AM, Buhrmaster, Gary <gtb at slac.stanford.edu> wrote: > One could consider purchasing the underground tunnels > in downtown London that BT is selling to build a > competing "over-the-top" data center. That's a "below the surface" datacenter, innit? srs (ok, I'll get my coat) From hcb at netcases.net Fri Nov 28 21:23:50 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Fri, 28 Nov 2008 22:23:50 -0500 (EST) Subject: an over-the-top data center In-Reply-To: <D0D0330CBD07114D85B70B784E80C2F2022FCDC7@exch-mail2.win.slac.stanford .edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> <D0D0330CBD07114D85B70B784E80C2F2022FCDC7@exch-mail2.win.slac.stanford.edu> Message-ID: <1944.76.118.12.107.1227929030.squirrel@webmail6.pair.com> Buhrmaster, Gary wrote: > > >> -----Original Message----- >> From: Steven M. Bellovin [mailto:smb at cs.columbia.edu] >> Sent: Friday, November 28, 2008 5:35 AM >> To: nanog at nanog.org >> Subject: an over-the-top data center >> >> http://royal.pingdom.com/2008/11/14/the-worlds-most-super-desi >> gned-data-center-fit-for-a-james-bond-villain/ >> (No, I don't know if it's real or not.) > > One could consider purchasing the underground tunnels > in downtown London that BT is selling to build a > competing "over-the-top" data center. > > http://www.nytimes.com/2008/11/28/business/worldbusiness/28tunnel.html > > It seems that all these cases are more under the bottom than over the top. From ge at linuxbox.org Fri Nov 28 21:35:46 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 28 Nov 2008 21:35:46 -0600 (CST) Subject: an over-the-top data center In-Reply-To: <1944.76.118.12.107.1227929030.squirrel@webmail6.pair.com> References: <20081128083433.0e18c7e2@cs.columbia.edu> <D0D0330CBD07114D85B70B784E80C2F2022FCDC7@exch-mail2.win.slac.stanford.edu> <1944.76.118.12.107.1227929030.squirrel@webmail6.pair.com> Message-ID: <alpine.DEB.0.999999.0811282134170.11461@linuxbox.org> On Fri, 28 Nov 2008, Howard C. Berkowitz wrote: >> > It seems that all these cases are more under the bottom than over the top. > Every couple of years there is a story about some anti virus company, data center, or whatever running out of an old nuclear bunker/military base/middle of no where. It is exciting the first few times. Gadi. From waf at brunz.org Sun Nov 30 12:42:31 2008 From: waf at brunz.org (Wayne Feick) Date: Sun, 30 Nov 2008 18:42:31 +0000 Subject: an over-the-top data center In-Reply-To: <49306074.2070408@gmail.com> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> <49306074.2070408@gmail.com> Message-ID: <1228070551.23941.60.camel@localhost.localdomain> On Fri, 2008-11-28 at 16:19 -0500, William Allen Simpson wrote: > At one point some time ago, on NANOG we discussed putting exchanges in old > minuteman silos. (so long ago a quick Google didn't find it -- where are all > the old NANOG archives?) > http://markmail.org/search/?q=list%3Aedu.merit.nanog+silo+exchange From patrick at ianai.net Sun Nov 30 19:33:37 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 30 Nov 2008 20:33:37 -0500 Subject: an over-the-top data center In-Reply-To: <49305CFB.9070703@vaxination.ca> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> <49305CFB.9070703@vaxination.ca> Message-ID: <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> On Nov 28, 2008, at 4:04 PM, Jean-Fran?ois Mezei wrote: > The thing about a carrier hotel is that it cannot be a secret location > since you need to allow various carriers and ISPs to have physical > access to the building so they can install/manage their > servers/routers/switches. > > The advantage of this swedish data centre is that even if its location > is well known, it is pretty hard to harm the building. You can't run a > truck full of explosives into it for instance. Unfortunately, you also cannot run your own fiber there, colo equipment there, visit it for any reason, etc. I was going to say 'this probably hinders customers adoption at NetNod', but I know for a fact the "probably" is superfluous. -- TTFN, patrick From trelane at trelane.net Sun Nov 30 21:19:05 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 30 Nov 2008 22:19:05 -0500 Subject: an over-the-top data center In-Reply-To: <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> Message-ID: <493357A9.1050803@trelane.net> Patrick W. Gilmore wrote: > On Nov 28, 2008, at 4:04 PM, Jean-Fran?ois Mezei wrote: > >> The thing about a carrier hotel is that it cannot be a secret location >> since you need to allow various carriers and ISPs to have physical >> access to the building so they can install/manage their >> servers/routers/switches. >> >> The advantage of this swedish data centre is that even if its location >> is well known, it is pretty hard to harm the building. You can't run a >> truck full of explosives into it for instance. > > Unfortunately, you also cannot run your own fiber there, colo > equipment there, visit it for any reason, etc. > > I was going to say 'this probably hinders customers adoption at > NetNod', but I know for a fact the "probably" is superfluous. > Fault free datacenters include neither people, nor computers, nor connectivity, nor HVAC, nor electricity. If you can eliminate those things you will have a 100% uptime datacenter. Andrew From tomb at byrneit.net Sun Nov 30 21:25:03 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 30 Nov 2008 19:25:03 -0800 Subject: an over-the-top data center In-Reply-To: <493357A9.1050803@trelane.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> <49305CFB.9070703@vaxination.ca><7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <493357A9.1050803@trelane.net> Message-ID: <70D072392E56884193E3D2DE09C097A9FA3D@pascal.zaphodb.org> > >Fault free datacenters include neither people, nor computers, nor >connectivity, nor HVAC, nor electricity. If you can eliminate those >things you will have a 100% uptime datacenter. > >Andrew Is this the network equivalent of Yin and Yang, or Darkness and Light being the same? Perhaps it is like an old joke: "How many Microsoft programmers does it take to change a lightbulb?" "None, they just make darkness the new standard." I guess, if uptime is a measure of your promised availability, then if you promise total unavailability, your uptime is 100% if no-one can reach you during the measured period. Not terribly useful, however, and likely to get breached, when those with means want to find out what you're hiding. From niels=nanog at bakker.net Sun Nov 30 21:50:10 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 1 Dec 2008 04:50:10 +0100 Subject: an over-the-top data center In-Reply-To: <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> Message-ID: <20081201035010.GH78345@burnout.tpb.net> * patrick at ianai.net (Patrick W. Gilmore) [Mon 01 Dec 2008, 02:34 CET]: > On Nov 28, 2008, at 4:04 PM, Jean-Fran?ois Mezei wrote: >> The advantage of this swedish data centre is that even if its location >> is well known, it is pretty hard to harm the building. You can't run a >> truck full of explosives into it for instance. > > Unfortunately, you also cannot run your own fiber there, colo > equipment there, visit it for any reason, etc. > > I was going to say 'this probably hinders customers adoption at > NetNod', but I know for a fact the "probably" is superfluous. I don't really get your reasoning here, Patrick. What were you going to do? Put your servers in the same racks as Netnod's switches? Rate their patch fiber management skills? I can buy the argument that there is one bit of infrastructure (a string of dark fiber) more between your router and the IX infrastructure than you will get in other locations but in this age of people connecting remotely to IXPs all the time this seems pretty minor, especially given the box full of advantages it gives the IXP operator regarding facility security and having a very clear demarcation point. -- Niels. -- "We humans get marks for consistency. We always opt for civilization after exhausting the alternatives." -- Carl Guderian From patrick at ianai.net Sun Nov 30 22:05:01 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 30 Nov 2008 23:05:01 -0500 Subject: an over-the-top data center In-Reply-To: <20081201035010.GH78345@burnout.tpb.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <EC769B32856AC3AF35F99BDD@rasmus.kthnoc.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> Message-ID: <D21639CF-EEA3-4210-ACC8-67D76A53E65A@ianai.net> On Nov 30, 2008, at 10:50 PM, Niels Bakker wrote: > * patrick at ianai.net (Patrick W. Gilmore) [Mon 01 Dec 2008, 02:34 CET]: >> On Nov 28, 2008, at 4:04 PM, Jean-Fran?ois Mezei wrote: >>> The advantage of this swedish data centre is that even if its >>> location is well known, it is pretty hard to harm the building. >>> You can't run a truck full of explosives into it for instance. >> >> Unfortunately, you also cannot run your own fiber there, colo >> equipment there, visit it for any reason, etc. >> >> I was going to say 'this probably hinders customers adoption at >> NetNod', but I know for a fact the "probably" is superfluous. > > I don't really get your reasoning here, Patrick. What were you > going to do? Put your servers in the same racks as Netnod's > switches? Rate their patch fiber management skills? > > I can buy the argument that there is one bit of infrastructure (a > string of dark fiber) more between your router and the IX > infrastructure than you will get in other locations but in this age > of people connecting remotely to IXPs all the time this seems pretty > minor, especially given the box full of advantages it gives the IXP > operator regarding facility security and having a very clear > demarcation point. I didn't say it would stop everyone. Of course some people will not be deterred, but some absolutely have. And most people are uninterested in the "box full of advantages it gives the IXP operator". Further, I would submit the "box full of advantages" are ephemeral at best, and arguably imaginary. Name another major IXP anywhere on the planet that has ever had a single issue NetNod's model would have avoided. Now compare that to forcing every single participant to use unknown fiber paths into an unknown facility. When are these fibers groomed, and onto which unknown paths? Which fiber maintenance schedules might impact me without my knowledge? Which construction projects elsewhere in the city might take me down and there's no way for me to even predict that? Etc., etc. I would prefer to take my chances with the known quantity, thankyouverymuch. Feel free to do with your network as you please. -- TTFN, patrick P.S. The demarcation point thing is pure BS and you know it.