botnet info
Is there a compiled list of network ranges that are being used as botnets avaialble anywhere that is kept relatively up to date? I've got a few networks within my influence that I'd like to ensure aren't being dirty. Thanks. -- Micheal Patterson
CISCO Hardware question for the masses..
Please forgive me if this is inappropriate for the list. We are looking to replace our current security solution with an ASA 5510. Per the info available from Cisco, this should fit the bill but I'm curious if any of you folks have these in place and if there are any gotcha's to it. -- Micheal Patterson .
Re: The Backhoe: A Real Cyberthreat?
- Original Message - From: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 19, 2006 12:00 PM Subject: Re: The Backhoe: A Real Cyberthreat? While it is always fun to call the government stupid, or anyone else for that matter, there is a little more to the story. - For one you do not need a backhoe to cut fiber - Two, fiber carries a lot more than Internet traffic - cell phone, 911, financial tranactions, etc. etc. - Three, while it is very unlikely terrorists would only attack telecom infrastructure, a case can be made for a telecom attack that amplifies a primary conventional attack. The loss of communications would complicate things quite a bit. I'll agree it is very far fethced you could hatch an attack plan from FCC outage reports, but I would not call worrying about attacks on telecommunications infrastructure stupid. Enough sobriety though, please return to the flaming. I would tend to disagree on that depending on how detailed those reports are. For example, if they indicate that junction X will hinder / disable communications to sector/grid Y, then yes, it could be a serious threat if you have police, fire, hospitals, etc on that section of the grid. Mike P.
Re: GoDaddy.com shuts down entire data center?
- Original Message - From: Patrick W. Gilmore [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Patrick W. Gilmore [EMAIL PROTECTED] Sent: Tuesday, January 17, 2006 1:09 AM Subject: Re: GoDaddy.com shuts down entire data center? On Jan 17, 2006, at 1:32 AM, Jim Popovitch wrote: I want to say, from an outsider's perspective, that I whole heartily applaud GoDaddy on the actions they took [...] There seems to be a wide split on this topic. I was wondering if people would privately tell me yes or no on a few questions so I can understand the issue better. 1) Do you think it is acceptable to cause any collateral damage to innocent bystanders if it will stop network abuse? If the damage of the persistant abuse is greater than the lost of the innocent persons, yes. 2) If yes, do you still think it is acceptable to take down 100s of innocent bystanders because one customer of a provider is misbehaving? Yes I do and more than likely, so do you. If you are a common end point for all of my users and I'm the common end point for yours, either of us has the right to deny access to the other at any point for no reason really. Now, should your network start flooding me or vice versa, one of us, if not both, will toss up some filters. If either of our networks is larger than the other and causing a dos for the other end, the effected one of us would have no recourse but to contact the upstream of the source point and request assistance. 3) If yes, do you still think it is acceptable if the misbehaving customer is not intentionally misbehaving - i.e. they've been hacked? Intentional or not, it doesn't negate the fact that the system has been hacked and is now owned by someone other than the actual owner. If one of my systems were to be hacked and I miss it, and it starts causing problems for your network, I expect my network to be filtered. If your filters aren't effective enough to deal with the issue, and I'm not helping you to correct the problem, I expect you to go to my carrier to file a complaint. 3) If yes, do you still think it is acceptable if the collateral damage (taking out 100s of innocent businesses) doesn't actually stop the spam run / DoS attack / etc.? There is no simple yes / no for this one. It would depend on the circumstances of the issue. snip Using the case under discussion as an example, I am wondering why anyone thinks taking down 100s of innocent domains is a good way to stop a single hacked machine from doing whatever it is doing? If you somehow think all that is worth it, take a close look at your cost / benefit analysis. At this rate, every business on the Internet will be out of business before we take out even a single moderately large botnet. You can wonder why, however I, IMHO, think that if more carriers would take that stance, then the problems that we face daily would be much less severe. Currently, there's not much to keep the big players in check when it comes to their network. Now, imagine, what could happen if they were forced to play by the same rules that we have to go by? If our network is causing problems, our uplink(s) have the authority to disconnect them for that generally. Can you see Sprint, SBC/ATT, L3, Cogent, AOL, Cox, etc having those same rules applicable to them or be depeered from all peers and become network dead? Now, is it feasible to do such a thing? Not usually because it causes financial issues on both sides of the depeering. That's because the internet that we have is used as a means of financial gain and isn't geared for being easily segregated in the event of compromise. Yet, that's the current mechanism for a compromised end user. The same means should be used all the way to the NAP imo. I am also wondering why anyone thinks the miscreant will stop just because the legitimate owner's domain no longer resolves? Not only is the machine likely to continue sending spam as if nothing happened, we aren't even catching the guy. I guess you could say well, it put pressure on his hosting provider to clean the infected machine, which is true. I just think that's a bit silly. But maybe I'm the one who's silly. Why should you or I be the ones responsible for catching the miscreant when the compromised system isn't on our network? If it were, then that task would fall to us to do so. If the threat of a delinking were over our heads, we'd have some major incentive to find the idiot and make sure he's not on our net anymore wouldn't we. Lastly, I wonder what average people - people who run businesses on hosting providers who really don't understand all this computer stuff - think about such actions. How many 100s of people have we just alienated for life to stop - er, NOT stop - a single zombie? And how many of their friends are going to hear over an over how the Internet is not a real business and no one should put any faith in it? Average
Re: SMTP store and forward requires DSN for integrity
- Original Message - From: Douglas Otis [EMAIL PROTECTED] To: Andrew - Supernews [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: Saturday, December 10, 2005 3:54 PM Subject: Re: SMTP store and forward requires DSN for integrity On Sat, 2005-12-10 at 17:37 +, Andrew - Supernews wrote: BATV doesn't help you if the problem is SMTP transaction volume, any more than a firewall will help you cope with a saturated network link. I agree with most of your statements. AV filters should be done within the session when possible, etc. Your statement regarding BATV is not correct however. There are two ways BATV reduces SMTP transaction volume when dealing with forged DSNs. ... BATV reduces SMTP transaction volume when dealing with forged DSNs. If malware detection systems would not generate a DSN to the originator upon detection in the first place, there would be no need to reduce those transactions as there would be no transactions to reduce. The solution, to me, seems so simple, I must be overlooking something or not comprehending fully what the issue truly is. I thought that the initial problem was with AV mechanisms sending out DSN's to incorrect sender addresses. Please, if I'm so far off base, would someone be so kind as to email me off list and clear this up for me? Honestly Doug, you do realize that your reluctance to stop the problem at the source conveys to everyone on this list the impression that you're only trying to gain support for your proposal don't you? Let's take the malware and av scanners out of the picture for a moment. There was a time, long ago, where malware didn't exist in the email network. At that time, when a message was undeliverable, a DSN was sent to the originator of the message. It happens. Typo's and such. No one complained. Why? Because legitimate email, in order to function requires a valid email address for both parties. Why would they falsify it if they wish to communicate? Now, let's look at it as of today. If someone sends someone a virus, intentionally, it's main purpose is to get to as many systems as it possibly can, as fast as it can to allow the software to propagate before it's detected by AV software. Do you REALLY think that the initial sender wishes to be told that he sent a virus? Do you really believe he/she wishes to even be known or contacted by you in any way? Of course not. Then why do these systems still attempt to send these notices? Well after all logical reasoning has indicated that the sender is forged. The software of today has no way of knowing if the originating system is the actual system that's introduced it into the wild or a carrier. It has no way to validate the email address of the sender. Can BATV correct this? Possibly. But at what cost Doug? How much will it cost them to get the latest and greatest so that they can implement BATV? How much down time will they have to deal with to implement it? Multiply that by the millions of mta's around the globe. Now, you tell me Doug, which is easier for everyone to do? Upgrade/update their mta's around the world or have those few AV detection vendors recode their software? I don't know about you, but if what little information I've found on BATV is current, most folks will have to switch to Exim or NetQmail just to get it to work currently. There's a lot of postfix and sendmail networks out there that may not want to switch. What happens to them? Mike P.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: Geo. [EMAIL PROTECTED] To: nanog@merit.edu Sent: Friday, December 09, 2005 9:57 AM Subject: RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) While AV scanning may be done during the session, it would also require additional steps to also contain _all_ upstream activity within the same session as well, when attempting to achieve an apparent point-to-point operation. If SMTP were point-to-point, this would be evolving into the IM model where the message queue or storage would always be at the sender. Such mode of operation will increase the average transaction time needed for email. You know, the problem we are trying to solve is virus notification blowback, etc. So instead of changing the system why not work with it. If everyone would just standardize on at least the first part of every virus notification being the same thing, say: XXX VIRUS NOTIFICATION: blah blah blah where XXX is some error number, we could all easily control virus notifications at the receiving end, allowing or blocking, as the recipients choice. A simple standard message format and all the problems and complaints go away. George Roettger Netlink Services Standardizing the DSN is an exercise in futility. Mainly because it still requires the message to pass through your outbound pipe and into my inbound pipe, hit my server port where my server starts processing that traffic. What has been accomplished here? Providing me a mechanism to block the notification if it's for a virus? For systems that are sending out notifications with forged addresses, this becomes UBE and provisions are already in place in the mta via access or in worst cases, the border firewall or even the border router for dealing with the originating network itself. If a system is incapable of determining the validity of the sender address, then that address should not be getting a DSN from any system regarding a virus, trojan or other malware. One can say, well *this* system is going into place or *that* system is in place at these locations, but it's simply not good enough. It's not standardized. There is currently no 100% tried and true method of dealing with this that is *standard* through out the net. So, the next best thing is to simply not send the DSN for viri / trojan infection at all. What was the quote from Wargames? Oh yes, The only winning move is not to play. Mike P.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: Geo. [EMAIL PROTECTED] To: nanog@merit.edu Sent: Friday, December 09, 2005 10:59 AM Subject: RE: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) It doesn't matter what the notifications look like. There is no reason that my SMTP server should be subject to more than TEN THOUSAND of these damned things every day, I hear you but you and I both know AV companies are not going to give up the automated spamming feature that easily. A standard message beginning they might be willing to impliment in a relatively short time and AV software is constantly updated so this could make a difference and happen relatively quickly. As for the quantity you receive, its nothing compared to the amount of spam those infected machines are soon going to be generating. George Roettger Netlink Services They may not a choice if those that are being hammered with their auto-generated DSN's deem it unusually high traffic rate and simply black list the domains using these devices. AOL.com comes to mind and a few others in the recent weeks that are hammering me with notifications that weren't sent by anyone within my network. That's the problem that I'm looking at George, the amount of traffic that those systems will be generating in the future. Including the bogus DSN's that are a direct result of that initial burst traffic. Mike P.
Re: SMTP store and forward requires DSN for integrity (wasRe:Clueless anti-virus )
- Original Message - From: Douglas Otis [EMAIL PROTECTED] To: Todd Vierling [EMAIL PROTECTED] Cc: Geo. [EMAIL PROTECTED]; nanog@merit.edu Sent: Friday, December 09, 2005 11:03 AM Subject: RE: SMTP store and forward requires DSN for integrity (wasRe:Clueless anti-virus ) On Fri, 2005-12-09 at 11:16 -0500, Todd Vierling wrote: On Fri, 9 Dec 2005, Geo. wrote: If everyone would just standardize on at least the first part of every virus notification being the same thing, say: XXX VIRUS NOTIFICATION: blah blah blah where XXX is some error number, we could all easily control virus notifications at the receiving end, allowing or blocking, as the recipients choice. Have you not even read the rest of the prior thread? It doesn't matter what the notifications look like. There is no reason that my SMTP server should be subject to more than TEN THOUSAND of these damned things every day, which I must receive all the way through the DATA phase in order to block. That's the problem: just like other forms of UBE, virus-worm warnings (to forged addresses) *do not scale*. I don't care what kind of duck the UBE looks like. Content is irrelevant. It still looks, walks, and quacks like a UBE duck. There is a solution you can implement now that gets rid of these tens of thousands of virus and abuse laden DSNs you see every day before the data phase. It could be seen as less than altruistic to bounce content of suspected malware, so perhaps one should not expect standardization of DSN content either. There are many languages to deal with as well. It's only a solution if it's available for all accepted MTA's that currently exist. According to MIPA, the only currently available BATV equipped mta's are Exim and NetQmail. I'll admit that I'm not up to par on the BATV project but damn, if you can't find information on it through a google search, or you find very limited information on it, then how can you say that it's ready for implementation now? Also, regardless of it's status, why should I have to redo my entire mail system to deploy BATV because others can't play nice on the net? With BATV, the slogan could be a quote from Socrates Know thyself. With BATV, you should stop blaming others for _your_ inability to deal with a DSN problem. Calling DSNs UBE is not a solution, although traffic from AV applications seems to be approaching that definition. If it has a null return-path, that is all you should need. -Doug When DSN's become autogenerated by systems that are not MTA's then those messages should no longer be considered DSNs should they. My inability to deal with a DSN problem? Please allow me to assure you that I have various methods of dealing with bogus DSN's within my network infrastructure. Regardless of that, why should I have to accept traffic not destined for my network? That is, afterall, what is happening when a DSN is sent to a forged originating address is it not? Truth of the matter is that I don't have to accept it at all. Your belief that I have the inability to deal with the problem is a misconception on your part. One has various methods in place already to deal with the problem at a very basic level. One can merely filter traffic at their upstream provider, place restrictions on their local MTA, firewall appliance or router. Those of us that see that DSN's are becoming UBE are trying to get the issue resolved before it comes to that. It will either happen or filters will go live. It's just that simple. Mike P.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: Matt Ghali [EMAIL PROTECTED] To: Micheal Patterson [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: Friday, December 09, 2005 1:49 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) On Fri, 9 Dec 2005, Micheal Patterson wrote: They may not a choice if those that are being hammered with their auto-generated DSN's deem it unusually high traffic rate and simply black list the domains using these devices. AOL.com comes to mind and a few others in the recent weeks that are hammering me with notifications that weren't sent by anyone within my network. I especially appreciate the ones from Yahoo!, who apparently do not bother checking domainkeys at all before generating bounces. gg. matto [EMAIL PROTECTED]darwin I like the ones from aol.com that also include all of the other addresses that the initial hit was sent to within their domain. Some of them are upwards of 10 pages of nothing but email addresses. Mike P.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: Douglas Otis [EMAIL PROTECTED] To: Todd Vierling [EMAIL PROTECTED] Cc: Steven J. Sobol [EMAIL PROTECTED]; Geo. [EMAIL PROTECTED]; nanog@merit.edu Sent: Friday, December 09, 2005 1:58 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote: 1. Virus warnings to forged addresses are UBE, by definition. This definition would be making at least two of the following assumptions: 1) Malware detection has a 0% false positive. 2) Lack of DSN for email falsely detected containing malware is okay. 3) Purported malware should be assumed to use a forged return-path. 4) The return-path can be validated prior to accepting a message. 5) SMTP should appear to be point-to-point. 6) MTAs with AV filters are the only problem. While there could be best practices created for AV filtering, it seems unlikely to be effective. Simplistic filters for DSNs also seem counter to ensuring the integrity of email delivery. Defending against DSN exploits with BATV will remove this vector, which in turn will end DSN exploits attempts over the long term. Why expect others to fix this problem, when there is a solution that one could make the investment in to deploy. This will reduce this problem over the long term. The BATV alternative would not cause otherwise valuable DSNs to be lost, nor make assumptions about the quality of malware detection. If you can't trust AV handling of DSNs, why trust their detections? Would you rather see emails simply disappear? I would rather see the problem stop at the source instead of the current issue being used as a crutch to attempt to get people to go to BATV or Mass-Rep (as described in your draft). There's an old military comm saying that fits perfectly here. Clean House. For those of you ex comm folks, you'll probably recognize it. For those of you who don't, it simply means, fix your stuff before you point blame at the distant end for the problem. 2. It is the responsibility of the *SENDER* not to send UBE. When the recipient is a legitimate email provider, it could seriously lower the integrity of email delivery for these providers to toss DSNs because many fall into a category you want to define as UBE. While I agree whole heartily this malware notification problem stinks, there is a much safer and surer solution. -Doug Do you not comprehend what's really being said here Doug? Yes, blocking / rejecting of a DSN is a BAD thing and should never be done. Rejecting of a notification of malware != the same thing. If the reciever of your DSN didn't sent the message, then it's no longer a DSN.. It's now officially, by definition, UBE from YOU to the incorrect originator now isn't it. This is the case in the majority of malware notifications by anyone / anything that generates them. More than likely, the viri / trojan writer is depending on them to help propogate their ilk because they too can be network admins and are aware that DSN's don't get tossed. What better method to get them out to the masses but to have our main feeds, and huge pipes help them along? I mean, really, who's better to help them? Mom and dat with the 56k dialup or us with the DS3's - OC12's to help them along? Look at the big picture Doug instead of 45 degrees to the left and right. You hate spam, I hate spam, I don't send DSN's to senders because I know that roughly 90% of them are bogus. You feel that's bad. You have the right to disagree. I have the right to deny traffic that is in response to traffic that didn't originate from my network(s) regardless of your belief. Mike P.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: Douglas Otis [EMAIL PROTECTED] To: Todd Vierling [EMAIL PROTECTED] Cc: Steven J. Sobol [EMAIL PROTECTED]; Geo. [EMAIL PROTECTED]; nanog@merit.edu Sent: Friday, December 09, 2005 1:58 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote: 1. Virus warnings to forged addresses are UBE, by definition. This definition would be making at least two of the following assumptions: 1) Malware detection has a 0% false positive. 2) Lack of DSN for email falsely detected containing malware is okay. 3) Purported malware should be assumed to use a forged return-path. 4) The return-path can be validated prior to accepting a message. 5) SMTP should appear to be point-to-point. 6) MTAs with AV filters are the only problem. Case in point Doug.. Current versions of Sober.U are sending mail from: [EMAIL PROTECTED] (xx's to hide the actual host). I have a slew of these in my detected malware folder. I suppose that you'd prefer, by your reasoning, that I be sending DSN's to these addresses, knowing full well that it won't make it and just clutter up comcast's smtp gateway with DSN's. I'm sure that they'd like that very much. Mike P.
Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- Original Message - From: Micheal Patterson [EMAIL PROTECTED] To: Douglas Otis [EMAIL PROTECTED]; Todd Vierling [EMAIL PROTECTED] Cc: Steven J. Sobol [EMAIL PROTECTED]; Geo. [EMAIL PROTECTED]; nanog@merit.edu Sent: Friday, December 09, 2005 4:01 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) - Original Message - From: Douglas Otis [EMAIL PROTECTED] To: Todd Vierling [EMAIL PROTECTED] Cc: Steven J. Sobol [EMAIL PROTECTED]; Geo. [EMAIL PROTECTED]; nanog@merit.edu Sent: Friday, December 09, 2005 1:58 PM Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus ) On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote: 1. Virus warnings to forged addresses are UBE, by definition. This definition would be making at least two of the following assumptions: 1) Malware detection has a 0% false positive. 2) Lack of DSN for email falsely detected containing malware is okay. 3) Purported malware should be assumed to use a forged return-path. 4) The return-path can be validated prior to accepting a message. 5) SMTP should appear to be point-to-point. 6) MTAs with AV filters are the only problem. Case in point Doug.. Current versions of Sober.U are sending mail from: [EMAIL PROTECTED] (xx's to hide the actual host). I have a slew of these in my detected malware folder. I suppose that you'd prefer, by your reasoning, that I be sending DSN's to these addresses, knowing full well that it won't make it and just clutter up comcast's smtp gateway with DSN's. I'm sure that they'd like that very much. Mike P. And before anyone points out that the mx for comcast would not see that message, I know that on this particular host, they would not. I also realize the the DSN would sit in my outbound queue until it was purged after 5 days due to non-delivery. The point remains the same for this example as if it were addresses from [EMAIL PROTECTED] or [EMAIL PROTECTED] The originator is forged and the DSN is unable to get to the originating sender. Mike P.
Re: Clueless anti-virus products/vendors (was Re: Sober)
- Original Message - From: Douglas Otis [EMAIL PROTECTED] To: Todd Vierling [EMAIL PROTECTED] Cc: Steven M. Bellovin [EMAIL PROTECTED]; Church, Chuck [EMAIL PROTECTED]; nanog@merit.edu Sent: Tuesday, December 06, 2005 6:26 PM Subject: Re: Clueless anti-virus products/vendors (was Re: Sober) On Dec 6, 2005, at 2:15 PM, Todd Vierling wrote: On Tue, 6 Dec 2005, Douglas Otis wrote: Holding at the data phase does usually avoid the need for a DSN, but this technique may require some added (less than elegant) operations depending upon where the scan engine exists within the email stream. Not my problem. I don't need or want, and should not be hammered with, virus warnings sent to forged addresses -- ever. They are unsolicited (I didn't request it, and definitely don't want it), bulk (automated upon receipt of viruses by the offending server), e- mail... thus UBE. I know of no cases where a malware related DSN would be generated by our products, nevertheless, DSNs are not Unsolicited Bulk Email. That's good Doug, and IMHO, your products should never generate them. However, I will disagree with you concerning the DSN being UBE. As a general rule, you are correct, DSN's != UBE. However, in the case of av systems (scanning engine and mta configurations) they can be. While I agree with you that the scanning engine(s) used by most of us, do not actually send reject notifications, the mechanisms that employ them, both commercial and open source, usually can, and do, unless configured not to. Some may see it as a violation of RFC to not return a DSN on failed delivery. Others, like myself see the need to not return a failure notice on virus / trojan infected email as it has become the norm that the sender information is forged. Especially those systems that contain the infected data along with the message. To many trojans / viri as of late, the DSN's that include the message (with infection) are being used as a repeater to further propogate the infection. Those that release these things are starting to depend on our mechanisms to help them spread. I, like others, prefer not to help them break the net from my little piece of it. -- Mike P.
Re: Cogent/Level 3 depeering
- Original Message - From: Daniel Roesen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 05, 2005 2:11 PM Subject: Re: Cogent/Level 3 depeering On Wed, Oct 05, 2005 at 02:08:01PM -0400, Richard A Steenbergen wrote: You can only be a tier 1 and maintain global reachability if you peer with every other tier 1. Level 3 is obviously the real thing, and Cogent is close enough (at least in their own minds :P) that they won't buy real transit, only spot routes for the few things that they are missing (ATDN and Sprint basically). There is no route filtering going on, only the lack of full propagation due to transit purchasing decisions, or in this case the lack thereof. Exactly. And this is why Cogent's statement to the public (and their customers) is an outright lie. Level 3 isn't denying Level 3's customers access to Cogent's customers and denying Cogent's customers access to Level 3 customers.. It's just that they deny Cogent settlement-free direct peering anymore. Cogent can get the L3 and L3 customer routes elsewhere if they want. But Cogent doesn't. It's Cogents decision to break connectivity, not L3's. If I would be a Cogent customer, I would have a _very_ warm word with my sales rep why they are trying to bs me with those kind of statements and think that I actually am dumb enough to believe that. Regards, Daniel Some would argue about Cogent being a tier 1 carrier. I honestly don't know anymore. All I do know, is that when I was still provisioning circuits within PSINet years ago, PSINet was on the verge of being a tier 1 as they had bilateral peering with the majority of the other tier 1 carriers at the time. Now, when Cogent took over the PSINet fiber backbone, I've no idea if they kept those peering points hot or not. If they did, then they should have plenty of pathing to L3 even with the direct peer being down. As you also said, I would think that if that traffic isn't getting through from Cogent's net to L3, there's an issue with Cogent's routing of that traffic unless L3 has placed a direct acl prohibiting any Cogent IP space from entering their network. That's a big if though simply because of the amount of traffic that will get just blown away by doing that. -- Micheal Patterson Senior Communications Systems Engineer 405-917-0600 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: Cogent/Level 3 depeering
- Original Message - From: Jeff Shultz [EMAIL PROTECTED] To: Simon Lockhart [EMAIL PROTECTED] Cc: NANOG list [EMAIL PROTECTED] Sent: Wednesday, October 05, 2005 2:35 PM Subject: Re: Cogent/Level 3 depeering Simon Lockhart wrote: Yes, it could have - I'm led to believe that one of the parties does purchase transit. However, moving all that traffic over transit rather than peering would cost them a significant amount of money - and as they're running their transit service at extremely low cost, they probably would find it hard to fund the use of transit to reach the other party. Simon Okay, here is how I see this war... which seems to be the proper term for it. 1. Level 3 is probably annoyed at Cogent for doing the extremely low cost transit thing, thus putting price pressures on other providers - including them. So they declared war. 2. Level 3's assault method is to drop peering with Cogent, in hopes this will force Cogent to purchase transit to them in some fashion (does Level 3 have an inflated idea of their own worth?), also forcing them to raise prices and hopefully (for Level 3) returning some stability to the market. 3. Cogent's counter-attack is to instead offer free transit to all single homed Level 3 customers instead, effectively stealing them (and their revenue) from Level 3... and lowering the value of Level 3 service some amount as well. 4. Next move, if they choose to make one, is Level 3's. Fun. I think I'll stay in the trenches. -- Jeff Shultz Could be that a bilateral peer contract isn't being fulfilled and L3 got tired of taking the full load of the traffic. PSInet killed the peer with CW for that very reason, regardless of what was told to the general public about it years ago. CW simply wouldn't provision their peering OC3 so PSINet killed theirs. Without know all sides of this one, and having access to the router configs at each side, no one will be able to really say who's breaking routing or who's got an active acl up and who doesn't. Traffic flow is apparently still broken otherwise, with these two peering as they do with over tier 1's, bgp should have settled the problem as intended. My guess is that either one or even both sides may still have active static routes in place breaking bgp routing. -- Micheal Patterson Senior Communications Systems Engineer 405-917-0600 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
