Re: Can P2P applications learn to play fair on networks?
On 10/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > It's a network > > operations thing... why should Comcast provide a fat pipe for > > the rest of the world to benefit from? Just my $.02. > > Because their customers PAY them to provide that fat pipe? You are correct, customers pay Comcast to provide a fat pipe for THEIR use (MSO's typically understand this as eyeball heavy content retrieval, not content generation). They do not provide that pipe for somebody on another network to use, I mean abuse.Comcast's SLA is with their user, not the remote user. Also, its a long standing policy on most "broadband" type networks that the do not support user offered services, which this clearly falls into. charles
nanog@merit.edu
On 11/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: We are AS35985 and provide transit for AS36845. Currently, AS7018 is able to route to us (AS35985), but not our customer (AS36845). I have checked every looking glass and traceroute site I can think of. Every network I have tried has a route through us to AS36845 except AS7018. I of course checked AT&T's looking glass and didn't find a route to our customer. I would expect AT&T to have a route to our customer via AS1299, but they don't. Have you contacted AT&T to have your network's BGP filter updated? (This way they would be able to accept your customers route via your peer with them) If not, please contact your sales rep, or email me privately for the information. This is not something for the nanog mailing list. charles
Re: register.com down sev0? - More information
5. AT&T (at least when I've dealt with them in their datacenters) does not support BGP community strings for null routing (or any strings for that matter :) Think about that for a second. To stop an attack Register.com would need to call AT&T and request a filter/null route. Since AT&T operations is based in Singapore (again this was last time I dealt with them) I'm sure getting those filters/routes in probably doesn't happen nearly fast enough. I have heard that AT&T is currently in the process of setting up communities- maybe someone who knows more could comment. Well, this is not exactly true.AT&T does support BGP communities, although their communities aren't all that powerful, IMO. To my knowledge, you are correct when you say that they do not support any null-routing capabilities. I would love to find out the procedure and string required to request/implement null routing via a community. For those who would like to see AT&T's official guide, it can be found at: http://www.onesc.net/communities/as7018 charles
Re: BGP community guide for AS7911 (willtel, now L3)
For those of you who are interested. Additional community information has been posted on http://www.onesc.net/communities/as7911 . For those 7911 customers who do use, or want to use communities, this document outlines both 7911 and 3356 communities (to ease the transition to 3356 when the time comes). thanks, charles On 4/27/06, Matthew Sprague <[EMAIL PROTECTED]> wrote: > I have this from L3/WCG from Feb... it should still be accurate. > > >7911:90 -> Sets local preference for the prefix with this community to > >>90 7911:100 -> Sets local preference for the prefix with this community > >>to 100 7911:110 -> Sets local preference for the prefix with this > >>community to 110 > >> > >>We set a default local preference on all customer routes to 120. > >>We set a default local preference on all peer routes to 110. > >>We set a default local preference on all transit routes to 100. > >> > >>We accept the well known community "no-export" or 7911:888 which tells > >>us not to advertise the prefix with this community to any other AS. > >> > >>We accept the community 7911:999 which is a conditional advertisement > >>and tells us to advertise the prefixes with this community to our > >>customers only. > >> > >>Finally, we accept and honor all customer MEDs. > -- > Matthew Sprague [EMAIL PROTECTED] > ReadyTechs, L.L.C. www.readytechs.com > 973.455.0606, x204 > > ======= > Cut out spam by 98% or more with FilterPro! > http://www.readytechs.com/filterpro > === > > > Charles Gucker wrote: > > On 4/27/06, John van Oppen <[EMAIL PROTECTED]> wrote: > > > >>Does anybody have a list of communities that the old AS7911 accepts from > >>customers? I can't find their guide anywhere and nobody at level3 > >>seems to have it. > >> > >>I really need to keep traffic from a couple of ASes away from them if > >>possible and prepending to them results in almost no usage. In any > >>case, the list is not at http://www.onesc.net/communities/ with the > >>others. > > > > > > It should go without saying, if anybody knows of a guide, or a > > location to obtain the guide, please let me know and I will add it to > > the site, even if it's going to be a short lived guide (from this > > point on). > > > > thanks, > > charles >
Re: BGP community guide for AS7911 (willtel, now L3)
On 4/27/06, John van Oppen <[EMAIL PROTECTED]> wrote: > > Does anybody have a list of communities that the old AS7911 accepts from > customers? I can't find their guide anywhere and nobody at level3 > seems to have it. > > I really need to keep traffic from a couple of ASes away from them if > possible and prepending to them results in almost no usage. In any > case, the list is not at http://www.onesc.net/communities/ with the > others. It should go without saying, if anybody knows of a guide, or a location to obtain the guide, please let me know and I will add it to the site, even if it's going to be a short lived guide (from this point on). thanks, charles
Re: IP ranges, re- announcing 'PA space' via BGP, etc
On 4/7/06, Alexander Koch <[EMAIL PROTECTED]> wrote: > On Fri, 7 April 2006 07:03:09 -0400, Patrick W. Gilmore wrote: > > Can you give us some examples so us "dumb Americans" can more > > precisely explain the problem? :) > > When a random customer (content hoster) asks you to accept > something out of 8/8 that is Level(3) space, and there is no > route at this moment in the routing table, do you accept it, > or does Level(3) have some fancy written formal process and > they get approval to do it, etc.? Btw, I hope you folks would defer to Level(3)'s reannouncement policy, which is very clear in their AS object located within RIPE's IRR, which reads: If you are a provider who has been asked to route a more-specific network block that is part of 4.0.0.0/8, please ask your customer to contact Level 3 to obtain a new network block. Level 3 will not accept advertisements for any networks that are part of 4.0.0.0/8 from any non-customer peer. So, if you want to do what's "right", tell your customer to go talk with Level(3), so they can renumber into IP space that would be permitted to be announced more specifically. If anybody wants to see the comments in their as object, just look at http://www.onesc.net/communities/as3356 it's very clear. charles
Re: Honest Cogent opinions without rhetoric.
On Wed, Mar 08, 2006 at 12:10:35PM -0500, Omachonu Ogali wrote: > I have the need to de-pref my routes to Level3, to be of equal value as the > routes they receive from their peers, but they don't offer a community for > that. But wow, I can see that this route originated from Tustin, CA! Hrm, this seems very straight forward to me: >From http://www.onesc.net/communities/as3356 customer traffic engineering communities - LocalPref 3356:70 - set local preference to 70 3356:80 - set local preference to 80 3356:90 - set local preference to 90 I believe peering routes are set to a local preference of 70 within L3, but I could be mistaken. Would be best to ask the TCAM group what a peer's LP is set to by default. > Everyone's traffic engineering needs are different. BGP communities were > created because one size doesn't fit all. But that doesn't mean that you > will find the same communities (that are of use to you) on a different > provider. Agreed, but you also have to understand that some networks have more or less flexiblity with their peers. The ones who have more "authority" (or believe they do) will publically offer greater control, while those with less "authority" may decide to limit their public statements. The other train of thought I've seen with a number of providers is.. The more communities they support, the more questions/misconfiguration they will run into as a result. I even know a few providers who refuse to give out their community guides without proving your technical knowledge first. charles
Re: Honest Cogent opinions without rhetoric.
> > Much of the negatives is from jaded competitors who don't > > want to fairly compete. Other than that, the answer is 'it depends'. > > Depends on if you like to do traffic engineering; Cogent's > BGP community support, consisting of a whole three things you > can set (two if you only have a single connection to them), > makes that rather difficult. Umm, where did you get that mis-information from? The last communitiy guide I've seen from them has quite a bit more than two ;p For a quick reference: http://www.onesc.net/communities/as174/as174.pdf charles
Re: Issue AS and Subnet Announcment on BGP - Conflict with a major TelCO - 30h+ of route flapping unresolved
On Tue, Nov 15, 2005 at 11:46:35PM -0500, Alain Hebert wrote: > >Hi, > >I know somebody that is experiencing route flapping for more than a > day now and we found out 10h ago that it was due to the announcement of > his subnet by a major TelCO. > >Once that telco contacted, we got the run around for 10h now and no > willingness from their part to fix the problem immediately. Well, a 'normal' solution (short term) would be to announce more specific announcements of your address space, then contact said Telco's upstream providers to have your prefix filtered from their connection(s). A nicely worded (polite) email/fax would go a long way with the NOC. This is of course, if they are not returning your calls, or as you say giving you the run around. I would also try to find a sympathetic body at the telco to help to properly resolve the issue, so you can go back to announcing only your aggregate netblock. >We're wondering what is the proper process to make the TelCo correct > their behavior and cooperate? >(ARIN Conflict Resolution Process, etc ... We found nothing about > this situation) ARIN will not step in here. They allocate resources, they do not police or enforce those resources. charles
Re: Cogent/Level 3 depeering
On 07 Oct 2005 19:00:46 +, Paul Vixie <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] (Charles Gucker) writes: > > > > Ok, as I understand it, Level3 can get Cogent connectivity back > > > simply be restoring the peering that they suspended, right? > First off, that's not my quote. ;-) Second, it would appear routes are once again beng exchanged between Level(3) and Cogent. BGP routing table entry for 209.244.0.0/14, version 103309841 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 174 3356, (aggregated by 3356 4.68.0.12) 66.28.1.1 from 66.28.1.1 (66.28.1.1) Origin IGP, metric 1000, localpref 100, valid, external, atomic-aggregate, best Community: 174:21000 16631:1000 >From an outside view, it seems like Level(3) caved in to customer demand, but what the true outcome is, nobody will know [publically]. charles > that's what this press release says: > > http://www.cogentco.com/htdocs/press.php?func=detail&person_id=62 > > disclaimer-- my employer has friendly relations with both Level(3) and Cogent. > -- > Paul Vixie >
Re: Cogent/Level 3 depeering
On Fri, Oct 07, 2005 at 02:53:02AM -0600, Lewis Butler wrote: > > On 05 Oct 2005, at 13:44 , Charles Gucker wrote: > >Oh man, I have to jump in here for a moment. Not that I agree with > >what happened, but to refute your claim that Cogent can get L3 > >elsewhere, it goes both ways. L3 can also get Cogent connectivity > >elsewhere. This is a big game of chicken, it will be interesting to > >see who backs down first. > > Ok, as I understand it, Level3 can get Cogent connectivity back > simply be restoring the peering that they suspended, right? Simply put, yes. Longer answer, Level(3) would have to "kiss and make up" with Cogent before the sessions would be coordinated to be turned up. There would certainly have to be a renewed level of communication between these two networks to come up with this result. > I mean, Cogent can pay someone to route to L3 or L3 can fix what they > did on their side, they have no need to go anywhere but their own > routers, right? Well, there are three options here. -> Both networks kiss and make up, ending up turning up the pre-existing peering session, or possibly additional peering sessions. -> Cogent obtains transit from another provider to Level(3). -> Level(3) obtains transit from another provider to Cogent. Business decisions do not always make sense, stubbornness can very easily get in the way of a proper decison[1]. charles [1] As outlined in this thread, one person's proper decision may not be another person's.
Re: Cogent/Level 3 depeering
On 10/5/05, Daniel Roesen <[EMAIL PROTECTED]> wrote: > > 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. Oh man, I have to jump in here for a moment. Not that I agree with what happened, but to refute your claim that Cogent can get L3 elsewhere, it goes both ways. L3 can also get Cogent connectivity elsewhere. This is a big game of chicken, it will be interesting to see who backs down first. > 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. Well, as I somewhat said above, there will always be three sides to every story. Side 1, Side 2 and the truth. Each side has a case, it's up to the lawyers now to sort it all out. charles
Re: Calling all NANOG'ers - idea for national hardware price quote registry
On Fri, Sep 16, 2005 at 03:37:08PM -0700, Matt Bazan wrote: > > a) the quote was in fact from a particular company (sure, it may look > darn similar - but prove? and if you're really worried, fudge some > details a bit) > - sure, if it's a $10 million quote that's one thing. But say a > $150,000 quote? Those are garden variety, least where I'm from (bay > area, California). Well, httpd style logs will certainly "tell" where the information came from. > b) who leaked it? it's completely anonymous. Think of all the 'senior > government' officials that leak info all the time. Often times they're > expressly forbidden from doing so and somehow the word still gets out. > Very rarely is someone nailed for it. And that's hardly anonymous if > push came to shove. Uhh, make sure the data isn't stored anywhere vendor X's attornies can get to it. Rest assured, whoever hosts the site would be sent paperwork in hours, if not minutes from it's discovery. Btw, this is why froogle.google.com and pricewatch.com exist. Although, they do not include list prices for the types of items you are looking for. charles
Re: Providers that support prepending to specific remote AS's?
On Thu, Aug 11, 2005 at 08:06:09PM -0400, David Hubbard wrote: > Hi all, I'd appreciate any on or offlist emails > with the names of larger providers that allow > you, through communities, to do prepending of > your AS path to selected remote AS's. We use two > providers that allow this since we use the feature > but am wanting to dump one of our providers who > does not. I guess cutting to the chase here would be best. I have been collecting BGP community guides for a number of service providers who publically state their BGP communities and their usage. This would include your desired abilities. You can find the collection at: http://www.onesc.net/communities For a quick shameless plug, if anybody has additional community guide locations, big or small, please let me know offlist. > Basically we have a customer within AS X and us > and AS X both have transit through AS Y. The link > between AS Y and AS X is seriously overloaded so our > customer is pretty much dead in the water since AS X > is a countrywide monopoly telco for the country in > question. We've forced traffic to AS X to take > a different route in but since we can't path prepend > just to AS X through AS Y, we're stuck with the > only solution being disable the link to AS Y or > prepend to all of AS Y which we don't want to do. > AS Y doesn't feel the need to help since their view > is the customer of theirs has chosen to not upgrade > the oversubscribed link. Hrm, sounds like you'd really make out from being able to tell your upstream to surpress the announcements out to that network, provided they aren't a customer of the upstream that is ;-) Keep in mind, if they are a customer the communities, in most cases, will not the results you are looking for. charles
Re: 216.119.248.0/21
Uhhh, from IANA: 216/8 ARIN - North AmericaApr 98 >From ARIN: >whois -h whois.arin.net 216.119.248.0 No match for "216.119.248.0". %%% NO MATCH TIP % %% % ALL OF THE POINT OF CONTACT HANDLES IN THE ARIN % % WHOIS END WITH "-ARIN", IF YOU ARE QUERYING A POINT % % OF CONTACT HANDLE PLEASE ADD -ARIN TO YOUR QUERY. % %% %% The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and whois.nic.mil for NIPRNET Information. So, there's a disjointment somewhere. RADB is not an registrar, just a way to do route filtering. Charlie On Wed, Mar 06, 2002 at 01:39:56PM -0800, David Barak wrote: > > What's ARIN got to do with it? > > > route: 216.119.248.0/21 > descr: Nuvox Communications > origin: AS16994 > notify: [EMAIL PROTECTED] > mnt-by: MAINT-AS11456 > changed:[EMAIL PROTECTED] 20020130 > source: RADB > > -David Barak > "Quis custodes ipsos custodiet?" - Juvenal > > > = > > > JD Falk wrote: > Has ARIN begun assigning from 216 (but not > updating whois), or > is AS16994 playing silly buggers here? > > (Apparently this network was sending spam.) > > route-views.oregon-ix.net>sh ip bgp 216.119.251.98 > BGP routing table entry for 216.119.248.0/21, version > 1338771 > Paths: (53 available, best #14) > Advertised to non peer-group peers: > 64.166.72.140 > 9057 3549 11456 11456 16994 > > > > > __ > Do You Yahoo!? > Try FREE Yahoo! Mail - the world's greatest free email! > http://mail.yahoo.com/
