Re: ml hacks for goodmail
On Tuesday 07 Feb 2006 22:08, Florian Weimer wrote: As far as I can tell, the filters at AOL are far less problematic than crude filters at smaller sites which simply use SORBS or bl.spamcop.net. Not here, no one cares if some small bit player has stupid filters, but when a significant volume of your email goes somewhere stupid filters hurt, queues build, users complain, and we are a bit player in the email world. We have a regular email to a customer rejected weekly by AOL because it contains a banned URL. Wouldn't be so bad, but it contains web referer stats, so is nothing but URLs. We've no idea which URL it is, and I'm not doing a binary filter approach to work around their broken filters. Simplistic content only based rejection of email is just a broken model, as is using end-user input in too simplistic a fashion (end users make too many mistakes), AOL do both. I manage to filter all my personal email with no content inspection over and above no Windows executable attachments here - thank you, no end user interaction, no silly places where falsely classified email stagnates, it really isn't difficult to deploy filters like this. But I thought the whole thing looked like a marketing campaign for Goodmail, and nothing more.
Denial of service Attack.
Hello. For the last couple of days we have intermittently been experiencing a (1gbps) denial of service attack. I want to apologize to anyone whose DNS servers have been (ab)used in the attack, and let you know what is occurring. The attacker is forging our source address on dns requests, and the DNS reply is routing to us. I promise, we're not attacking your dns servers. Please take a moment to consider implementing RPF checks to prevent these type of forged packet attacks. Advice is welcomed both on-list and off. Thanks, Ejay Hire ISDN-Net Network Engineer
Re: Middle Eastern Exchange Points
On 7-Feb-2006, at 23:25, Martin Hannigan wrote: You keep saying EMIX and you're confusing me. Peering or no? IX naturally insinuates yes regardless of neutrality. I'm not sure how to be more clear about this. EMIX is the name of a transit service offered by Emirates Telecom. Joe
Re: Middle Eastern Exchange Points
On Tue, 7 Feb 2006, william(at)elan.net wrote: And when ISP A buys access from ISP B for purpose of getting to ISP C is that peering or transit? I thought it was generally accepted that peering is the exhange of routes that are not re-sent to other organisations. Transit is when one entity sends the routes on to other organsiations, often with money involved. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: So -- what did happen to Panix?
On Wed, Feb 08, 2006 at 04:37:31AM +, Christopher L. Morrow wrote: I had thought Josh's paper (or maybe not josh, whomever it was) said something along the lines of: 1) if more than one announcement prefer 'longer term', 'older', 'more usual' route 2) if only one route take it and run! FWIW, this sort of mechanism was discussed among the IETF RPSEC WG task group that is working on BGP security requirements. On the presumption that some database of stable routes and paths is present, you could bias your preference in your routes for more stable routes and paths. You would also need to decide what to do about more specific routes covered by stable routes. Do you ignore them? This is a harder question. -- Jeff Haas NextHop Technologies
Re: So -- what did happen to Panix?
Here is what we propose in PGBGP. If you have a more specific route and its AS Path does not contain any of the less specific route's origins, then ignore it for a day and keep routing to the less specific origin. If it's legitimate the less specific origin should forward the data on for the day. We see about 30 of these suspicious routes per day. I imagine some of you will not like this sceheme. Please let me know why. Josh On 2/8/06, Jeffrey Haas [EMAIL PROTECTED] wrote: On Wed, Feb 08, 2006 at 04:37:31AM +, Christopher L. Morrow wrote: I had thought Josh's paper (or maybe not josh, whomever it was) said something along the lines of: 1) if more than one announcement prefer 'longer term', 'older', 'more usual' route 2) if only one route take it and run! FWIW, this sort of mechanism was discussed among the IETF RPSEC WG task group that is working on BGP security requirements. On the presumption that some database of stable routes and paths is present, you could bias your preference in your routes for more stable routes and paths. You would also need to decide what to do about more specific routes covered by stable routes. Do you ignore them? This is a harder question. -- Jeff Haas NextHop Technologies
ATT (AS7018) customer triggered blackhole routing?
Does anyone know if ATT (the old one, AS7018) has customer trigged blackhole routing? I looked in the copy of the BGP policy I have from 04/2005, and see nothing about it, and cannot find the updated online version. Off-list replies welcome.
Cogent
Can anyone shed some light on the current Cogent latency issues? The scoreboard is lit up like a Tree ... Thanks. Joe
Re: Cogent
At 11:53 AM 08/02/2006, Joseph Nuara wrote: Can anyone shed some light on the current Cogent latency issues? The scoreboard is lit up like a Tree ... Thanks. http://status.cogentco.com Cogent Network Status/DNS Server Status Description: Welcome to Cogent Communications' Network Status Message. Today is Wednesday Feb 8th at 10:30am EST. Cogent is currently experiencing an outage in the Chicago area. Some customers may experience latency on the Cogent backbone due to the Chicago outage. The outage is caused by break within our fiber providers network. The provider's techs are onsite where they believe the break is located as well as splice crews on the way. No estimate time of repair at this time. Please use HD376421 as a reference for this outage. We appreciate your patience in this matter. Joe
RE: Cogent
Fiber cut ... http://status.cogentco.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Nuara Sent: Wednesday, February 08, 2006 11:53 AM To: nanog@merit.edu Subject: Cogent Can anyone shed some light on the current Cogent latency issues? The scoreboard is lit up like a Tree ... Thanks. Joe Confidentiality Notice: The information contained in this email and any attachments may be legally privileged and confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify the sender and permanently delete the email and any attachments immediately. You should not retain, copy or use this email or attachment for any purpose, nor disclose all or any part of the contents to any person.
RE: Cogent
Heard rumor of a fiber cut near chicago.. Brance -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Nuara Sent: Wednesday, February 08, 2006 11:53 AM To: nanog@merit.edu Subject: Cogent Can anyone shed some light on the current Cogent latency issues? The scoreboard is lit up like a Tree ... Thanks. Joe
Re: Cogent
Heya, I'm not sure what's going on, but we were seeing problems on outbound traces on their DC-JFK-BOS stretch (we're connected to them in Boston) but it looks like it might have cleared itself up a few mintues ago. Eric :)
Re: Middle Eastern Exchange Points
On Wed, 8 Feb 2006, Mikael Abrahamsson wrote: On Tue, 7 Feb 2006, william(at)elan.net wrote: And when ISP A buys access from ISP B for purpose of getting to ISP C is that peering or transit? I thought it was generally accepted that peering is the exhange of routes that are not re-sent to other organisations. If I peer with you, you sent me your routes and routes for who you consider to be your customer and if ISP C is your customer then ISP A by having peering with ISP B gets access to ISP C. Transit is when one entity sends the routes on to other organsiations, often with money involved. More commonly understood is that transit involves one ISP sending all of its BGP routes and allowing any traffic to be send from ISP A for for delivery to destination. However number of organizations (say cogent buying from verio) only get routes from certain specific ISPs that they can not otherwise reach which is again scenario ISP A buys from ISP B to get to ISP C but most people call this transit in this case... The reality is that for outside observer (especially if you look at the net as whole), there is no clear view that separates peering from transit and most correct is to consider everything to be peering with various differences being as to what kind of filters are deployed and where and how money is being exchanged. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Middle Eastern Exchange Points
On Tue, 7 Feb 2006, william(at)elan.net wrote: So what exactly is definition of transit that does not make it peering? Transit is the exchange of TRANSITIVE routes to destinations which are not the downstream customers of either of the two parties to the transaction. And when ISP A buys access from ISP B for purpose of getting to ISP C is that peering or transit? That's transit. -Bill
Re: Middle Eastern Exchange Points
On Wed, 8 Feb 2006, Martin Hannigan wrote: Guys, are you being semantic? Yes, we're doggedly insisting that words mean what they're defined to mean, rather than the opposite. You keep saying EMIX and you're confusing me. Peering or no? IX naturally insinuates yes regardless of neutrality. Exactly. IX as a component of a name is _intended to insinuate_ the availability of peering, _regardless of whether that's actually true or false_. Which is why we keep analogizing to the STIX, which was _called_ an IX, but was _not_ an IX, in that it had nothing to do with peering, only with a single provider's commercial transit product. The same is currently true throughout much of the Middle East. -Bill
Re: Middle Eastern Exchange Points
On Tue, 7 Feb 2006, william(at)elan.net wrote: On Tue, 7 Feb 2006, Bill Woodcock wrote: different definitions. If you say transit is peering, just not by our definitions, then you're into 1984 territory. So what exactly is definition of transit that does not make it peering? And when ISP A buys access from ISP B for purpose of getting to ISP C is that peering or transit? cant believe you are even invoking this debate.. *cough troll* its quite simple: http://dictionary.reference.com/search?q=transit 1. The act of passing over, across, or through; passage. if another networks traffic enters your network, then you send it out to another network it has transitted you. doesnt matter what money is involved, its about the act of 'transitting' peering is just the act of exchanging traffic with another network, whether this is a transit or peering relationship depends on what routes are exchanged and whose customers are within those routes.. i think you can work the rest out Steve
Re: Middle Eastern Exchange Points
On Wed, Feb 08, 2006 at 10:45:47AM -0800, Bill Woodcock wrote: On Wed, 8 Feb 2006, Martin Hannigan wrote: Guys, are you being semantic? Yes, we're doggedly insisting that words mean what they're defined to mean, rather than the opposite. You keep saying EMIX and you're confusing me. Peering or no? IX naturally insinuates yes regardless of neutrality. Exactly. IX as a component of a name is _intended to insinuate_ the availability of peering, _regardless of whether that's actually true or false_. Which is why we keep analogizing to the STIX, which was _called_ an IX, but was _not_ an IX, in that it had nothing to do with peering, only with a single provider's commercial transit product. The same is currently true throughout much of the Middle East. -Bill the CIX STIX (as originally designed) models architecturally slightly different than what seems to be the case for EMIX and a few other tricks (PLDT comes to mind) where a telco is offering transit over its infrastructure. In the first two cases, all the participants (customers) fateshare ... the design was layer 3 peering, eg. everyone terminates on a port on a common router, managed by the friendly, neutral telco/cooperative association. Nearly everyone these days equates IX with a neutral layer 2 fabric. In a wide-area, you are still captive to the transmission provider to knit the disparate bits into a single, cohesive whole. --bill
Re: Middle Eastern Exchange Points
On Feb 8, 2006, at 12:30 PM, william(at)elan.net wrote: Transit is when one entity sends the routes on to other organsiations, often with money involved. More commonly understood is that transit involves one ISP sending all of its BGP routes and allowing any traffic to be send from ISP A for for delivery to destination. However number of organizations (say cogent buying from verio) only get routes from certain specific ISPs that they can not otherwise reach which is again scenario ISP A buys from ISP B to get to ISP C but most people call this transit in this case... The reality is that for outside observer (especially if you look at the net as whole), there is no clear view that separates peering from transit and most correct is to consider everything to be peering with various differences being as to what kind of filters are deployed and where and how money is being exchanged. Disagree. If you pass routes received from AS$I to AS$J, then you are providing transit to either $I or $J. Period. This is perfectly clear, even for an outside observer. What gets interesting is when you pay AS$N for access to only AS$N's prefixes. That looks like peering from the outside, but most people would call it transit. However, that does not make all transit equal to peering. In fact, purchasing transit vary rarely involves BGP, so it should not be considered peering even as a special case. If you want to define it as such, all BGP sessions are peering sessions, but we are not talking on the protocol level here. There is nothing in the protocol about transit, and using protocol level definitions when talking about business relationships makes about as much sense as arguing over Mac OS vs. Windows when discussing wire transfers. Also, just because it looks like something to an outside observer does not make it so. Transit vs. peering is a business relationship, and is defined by the parties involved, not the protocol used or how people outside view it. -- TTFN, patrick
Re: Middle Eastern Exchange Points
At 01:45 PM 2/8/2006, Bill Woodcock wrote: On Wed, 8 Feb 2006, Martin Hannigan wrote: Guys, are you being semantic? Yes, we're doggedly insisting that words mean what they're defined to mean, rather than the opposite. You keep saying EMIX and you're confusing me. Peering or no? IX naturally insinuates yes regardless of neutrality. Exactly. IX as a component of a name is _intended to insinuate_ the availability of peering, _regardless of whether that's actually true or false_. Which is why we keep analogizing to the STIX, which was _called_ an IX, but was _not_ an IX, in that it had nothing to do with peering, only with a single provider's commercial transit product. The same is currently true throughout much of the Middle East. Here's the accurate cairo data: - CRIX is DOA - CAIX is the government sponsored replacement -nile, Raya, Egynet, and others I can't discuss. - they are peering - Regional IX If you have a room full of providers who connect up to a common switch and exchange something, I'd tend to believe that it is an exchange. GRX, Layer3, etc. I didnt disagree with you for the most part on the UAE, I asked why I saw what I saw. Joe answered the technical question and I found the political/technical choke point for the UAE's access. Google can confirm that. I can understand the frustration. -M -- Martin Hannigan(c) 617-388-2663 Renesys Corporation(w) 617-395-8574 Member of Technical Staff Network Operations [EMAIL PROTECTED]
stp questions
With 802.1w how normal is it for an environment with 8 switches ~300 ports with to exhibit 1-3 seconds of packet losss/latency/jitter everytime any port transitions to STP forwarding and causes topology change notices to ripple through the entire stp domain? The ports causing this are connected to end-user devices, not the uplink/trunk ports. Is it reasonable to expect the vendor (not cisco) to support a port link-type that - does not cause topology changes to ripple through the domain - does not cause 1-2 seconds packet drops when transitioning to forwarding - transitions to forwarding quickly AND - blocks accidental loops ? IOW everything that I get from portfast and rpvst. Thanks. Joe
