To get internet full routing table
Hi, Is that possible to get full internet routing table without help from upstream ISP? or is there anyway to get some backbone network's internet routing table directly? thanks Joe Send instant messages to your online friends http://asia.messenger.yahoo.com
Re: To get internet full routing table
On Wed, 2 Nov 2005, Joe Shen wrote: Is that possible to get full internet routing table without help from upstream ISP? or is there anyway to get some backbone network's internet routing table directly? Do you mean as an eBGP feed, to your router? Or just a static copy to look at? -Bill
SBC/ATT + Verizon/MCI Peering Restrictions
Any thoughts on this: http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=16437 --- snip The applicants committed, for a period of three years, to maintain settlement-free peering arrangements with at least as many providers of Internet backbone services as they did in combination on the Merger Closing Dates. The applicants committed for a period of two years to post their peering policies on publicly accessible websites. During this two-year period, the applicants will post any revisions to their peering policies on a timely basis as they occur. /snip Published SFI peering policies are nice, but the overlap in SFI peering between each pair of merging carriers may require them to peer with additional networks. For example, there is some overlap between SBC and ATT in regards to SFI peers. This might require the combined network to interconnect with additional networks to MAINTAIN the overall number of SFI peers. I guess its a good time to apply to 701 for SFI, although it appears the number of slots are limited to some unknown (and probably low) number. Gentlefolk, start your engines :) Can anyone else think of regulatory restrictions previously placed on SFI relationships in North America? I realize this is more like a consent decree than true regulation, but its an interesting move by the regulators. Regulation is generally a bad thing, but publishing SFI requirements - and even SFI relationships - won't hurt anyone, IMHO. -- Daniel Golding
Re: SBC/ATT + Verizon/MCI Peering Restrictions
the two year window is far too low given the sbc ceo's recent public statements on the use of his wires by google and the like. randy
Re: oh k can you see
On Mon, Oct 31, 2005 at 12:19:58PM -1000, Randy Bush wrote: Hi, this implies that a non-trivial part of the net can not see anycast services for which some of the servers are marking their announcements as NO_EXPORT. Is it an idea to have anycasted instances using NO_EXPORT announce /25's instead of /24's? That way you would still have global connectivity for the /24 and still respect the NO_EXPORT. Another possibility is for $LARGE_ISP to localpref the NO_EXPORTED down to $LOW value (some of you will go 'doh' now). Thanks, -- Sabri please do not throw salami pizza away
Re: oh k can you see
Is it an idea to have anycasted instances using NO_EXPORT announce /25's instead of /24's? many many folk filter on /24, so the /25 would not be seen. Another possibility is for $LARGE_ISP to localpref the NO_EXPORTED down to $LOW value and then how will the down-preffed prefix be seen within $large_isp? local-pref is a very heavy hammer. randy, at the clue edge i guess
Equal access to content
On Wed, 2 Nov 2005, Randy Bush wrote: the two year window is far too low given the sbc ceo's recent public statements on the use of his wires by google and the like. Should content suppliers be required to provide equal access to all networks? Or can content suppliers enter into exclusive contracts? If Google sets up a WiFi network in San Francisco or buys AOL with Comcast, can Google create a custom content for users on its networks? Or must Google offer the same cotent on the same terms and conditions to everyone? Should AOL be able to offer selected content to only its customers, such as music downloads? Or must AOL supply that content to everyone equally? Comcast offers its users access to the Disney Connection web site, should Disney be required to offer it to all Internet users equally? The NFL offers its Sunday Ticket exclusively through DirecTV? Or must the NFL offer the same content to every network? What rules should exist on how Google operates? Or is it just traditionally lobbying? Google says regulate the other guy, but not itself. The other guys say regulate Google, but not them.
Re: Equal access to content
the two year window is far too low given the sbc ceo's recent public statements on the use of his wires by google and the like. Should content suppliers be required to provide equal access to all networks? Or can content suppliers enter into exclusive contracts? the content providers are not common carriers whose irreplacable access to the customer prem was subsidized by public funding and protection. and perhaps we should be declaring our employment affiliations. mine is iij, a large japanese/asian non-carrier isp with some service in the us, plus various consulting gigs, none for content providers. randy
Re: cogent+ Level(3) are ok now
Richard A Steenbergen wrote: Pete Templin wrote: John Curran wrote: Cold-potato only addresses the long-haul; there's still cost on the receiving network even if its handed off at the closest interconnect to the final destination(s). And there's still revenue, as the traffic is going to customers (we all filter our prefixes carefully, right?). What's the problem with cold-potato again, or should we all just try to double-dip? I can almost smell your sarcasm from here. :) The problem here is that people naively assume all traffic is the same, and costs the same to deliver, which is just not the case. On-net traffic costs significantly more to deliver than outbound traffic, because you are virtually guaranteed that you are going to have to haul it somewhere at your expense. Time out here. John set the stage: cold potato addressed the long haul (or at least that's the assumption in place when I hopped on board). If NetA and NetB are honoring MED (or other appropriate knob), NetA-NetB traffic has already arrived at the closest mutual peering point in the A-B direction. The rest of the infrastructure would be the responsibility of NetB to get the traffic to CustomerPortXYZ, no? How could CustomerXY get any closer to NetA without cutting NetB out of the middle, and if NetB is out of the middle, why should CustomerXY pay NetB anything? pt
Re: SBC/ATT + Verizon/MCI Peering Restrictions
On Nov 2, 2005, at 8:04 AM, Randy Bush wrote:the two year window is far too low given the sbc ceo's recent publicstatements on the use of his wires by google and the like.You can pretty much s/the sbc/rboc/g in this context. Leadership seems to believe that because those who conduct business over 'their' infrastructure aren't paying them a transaction fee, there's somehow something wrong with that model. Fact is, they _are_ getting paid for their pipes, and they've never been part of the transaction model (aka tax collectors). If you want to be something else, dump the pipes r us business model. But then you can't have your cake and eat it, too. Somehow, I'm very reminded of how the music industry has acted when faced with a disruptor. Very classic threat reponse of somebody thinking like a mono/duo/whateverpartitionedmarketpoly. Sections in http://www.usatoday.com/tech/news/techpolicy/business/2005-10-31-bellsouth-mergers_x.htm have publically confirmed similar thought patterns. But then again, the CEO's of the companies mentioned here do look like twins separated at birth, with companies sharing very similar DNA (even though they all think they're very different).So, my point being in response to what Randy wrote.. expect a lot more where that came from, especially as margins come under more pressure. As long as they pretend disruption can be controlled or isn't happening, this will continue. And one could argue that the recently approved mergers might fuel such attitudes.Best regards,Christian
Re: SBC/ATT + Verizon/MCI Peering Restrictions
if i am a paying sbc or other foopoloy voice customer, and i place a voice call to aunt tillie, does aunt tillie pay sbc to hold up her end of the conversation? if i am a paying sbc or other foopoloy dsl customer and i go to http://content.provider, why should content.provider pay to give the sbc paying customer what they're already charged for? what these greedy bleeps want it a way to double bill. your analogy to the riaa/mpa desperation is apt. randy
Re: Equal access to content
On Wed, 2 Nov 2005, Sean Donelan wrote: On Wed, 2 Nov 2005, Randy Bush wrote: the two year window is far too low given the sbc ceo's recent public statements on the use of his wires by google and the like. Should content suppliers be required to provide equal access to all networks? Or can content suppliers enter into exclusive contracts? equal access at same cost perhaps... though honestly it's their content so they can decide if they don't want one or some folks to view it I'd think. (ianal, of course) If Google sets up a WiFi network in San Francisco or buys AOL with Comcast, can Google create a custom content for users on its networks? Or this is a 'customer portal' no? Don't lots of folks do this today? to provide customized content to their subscribers, somehow wrapping that cost into the cost of the network service they offer? must Google offer the same cotent on the same terms and conditions to everyone? Should AOL be able to offer selected content to only its customers, such as music downloads? Or must AOL supply that content to everyone equally? Comcast offers its users access to the Disney aol/google/content-provider-foo might provide exclusive content for a higher (or lower) price than to normal folks, it also might be bitten by the lose of potential customers that way :( This sounds like a business decision not a legislative one, eh? Connection web site, should Disney be required to offer it to all Internet users equally? The NFL offers its Sunday Ticket exclusively through DirecTV? Or must the NFL offer the same content to every network? no one cares about football... Now, hockey! That's a sport that everyone should get access to! :) What rules should exist on how Google operates? Or is it just traditionally lobbying? Google says regulate the other guy, but not itself. The other guys say regulate Google, but not them. Isn't this just the normal political/regulator/lobbyist dance? Those with the slickest, loudest, most-involved lobbyists 'win' in the end don't they? Take Disney's constant push to up the Copyright timeframes for example... -Chris
Re: SBC/ATT + Verizon/MCI Peering Restrictions
On 11/2/05 2:04 PM, Randy Bush [EMAIL PROTECTED] wrote: the two year window is far too low given the sbc ceo's recent public statements on the use of his wires by google and the like. randy For the curious on the list... How do you think they're going to get to customers? Through a broadband pipe. Cable companies have them. We have them. Now what they would like to do is use my pipes free, but I ain't going to let them do that because we have spent this capital and we have to have a return on it. So there's going to have to be some mechanism for these people who use these pipes to pay for the portion they're using. Why should they be allowed to use my pipes? The Internet can't be free in that sense, because we and the cable companies have made an investment and for a Google or Yahoo! or Vonage or anybody to expect to use these pipes [for] free is nuts! - Ed Whitacre, CEO of SBC - I choose to view this as ineffectual railing against the seemingly inevitable subordination of bit transport to compelling content. Memo to Ed Whitace: They ARE using your pipes right now, and they AREN'T paying you money. The funny thing is that your customers ARE paying you money for access to Google and Yahoo. Broadband gets a lot less compelling without content, so don't push it. -- Daniel Golding
Re: SBC/ATT + Verizon/MCI Peering Restrictions
On Nov 2, 2005, at 9:36 AM, Randy Bush wrote: if i am a paying sbc or other foopoloy voice customer, and i place a voice call to aunt tillie, does aunt tillie pay sbc to hold up her end of the conversation? No, but they pay their local carrier. And somewhere there's an IXC in the middle. And settlement happens. Access charges, LD charges and all. Hell, they even bill their customers on behalf of all those other guys. And they all want access charges (remember the fights a few years back?), and then they want a cut what goes over the pipe which the access charges just enabled. And I stand here shaking my head, going blblblblblb, wtf. All because they don't want and can't (sic) accept that the pipes r us business has been commoditized and evolution must happen for them to get money out of other services. Now, if they made bw free, and wanted a cut from the transaction.. I don't think anyone would object. Pull up the recent balance sheets and see how much money you'd have to make up to cover the gap. Ooof. if i am a paying sbc or other foopoloy dsl customer and i go to http://content.provider, why should content.provider pay to give the sbc paying customer what they're already charged for? That's my precisely my point as well. It's nutty. There are several people reading along here who saw first hand with me what sort of curious models this brought to light.. what these greedy bleeps want it a way to double bill. your analogy to the riaa/mpa desperation is apt. Thanks. And tomorrow we'll all wonder out loud why all these guys haven't been poaching customers in the other's backyard thus far in what's basically been a decade now since 1996, in spite of having hardly any regulatory restraints placed on them (about which they bitch so loudly at home). ;-) Best regards, Christian
Internap BGP Contact
Can someone from internap (AS 12179) contact me offlist regarding a BGP route issue? -- Thanks, - Joseph W. Breu, CCNA phone : +1.319.268.5228 Senior Network Administratorfax : +1.319.266.8158 Cedar Falls Utilities cell : +1.319.493.1686 support: +1.319.268.5221 url : http://www.cfu.net
Re: Equal access to content
aol/google/content-provider-foo might provide exclusive content for a higher (or lower) price than to normal folks, it also might be bitten by the lose of potential customers that way :( This sounds like a business decision not a legislative one, eh? Connection web site, should Disney be required to offer it to all Internet users equally? The NFL offers its Sunday Ticket exclusively through DirecTV? Or must the NFL offer the same content to every network? no one cares about football... Now, hockey! That's a sport that everyone should get access to! :) insert tongue in cheek here I, for one, welcome Christopher Morrow, and Sean Donelan as my new monopoly overlords. I'd like to remind him that as a trusted former associate/acquaintance, I can be helpful in rounding up others to toil in their underground sugar caves. /insert tongue in cheek here And yes, it has been done to death... I am not proud...
Re: SBC/ATT + Verizon/MCI Peering Restrictions
On Nov 2, 2005, at 9:54 AM, Daniel Golding wrote: They ARE using your pipes right now, and they AREN'T paying you money. The funny thing is that your customers ARE paying you money for access to Google and Yahoo. Broadband gets a lot less compelling without content, so don't push it. Hah. Classic. But, but, Dan, that trick-or-treating wasn't all. But if they harness their own content, then what would you have.. a captive supplier to an mono/whateverpoly? Oh what fun that would be for Christmas, on a one horse open sleigh. 'Tis the season, guys. Ho Ho Ho. http://www.cabledatacomnews.com/nov05/nov05-6.html You've got to admit, though, the ability to completely fade out reality and invent your own is impressive, and those CEO's ought to be commended. And while we're doing this with RBOCs, we can bitch about MSOs just the same. One might find a surprising number of similarities. Best regards, Christian
ConEd down ?
Our BGP peering with ConEd (AS 27506) went down around 10:20am EST. Per ConEd NOC, they are investigating. Does anyone have any insight on this issue ? Thanks, - Joe DISCLAIMER This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify me and permanently delete the original and any copy of any e-mail and any printout thereof. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. NOTICE REGARDING PRIVACY AND CONFIDENTIALITY Knight Capital Group may, at its discretion, monitor and review the content of all e-mail communications. http://www.knight.com
Re: To get internet full routing table
On Wed, Nov 02, 2005 at 04:26:04PM +0800, Joe Shen wrote: Hi, Is that possible to get full internet routing table without help from upstream ISP? or is there anyway to get some backbone network's internet routing table directly? whats a full internet routing table and how can you tell? (SFI and/or having no default is -NOT-, a priora, indicative of a full table...) see woodys note on your potential choices... --bill thanks Joe Send instant messages to your online friends http://asia.messenger.yahoo.com
Cisco Security Advisory: IOS Heap-based Overflow Vulnerability in System Timers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: IOS Heap-based Overflow Vulnerability in System Timers == Document ID: 68064 Revision 1.0 For Public Release 2005 November 2 1600 UTC (GMT) - --- Contents Summary Affected Products Background Information Regarding Heap Overflows Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: FINAL Distribution Revision History Cisco Security Procedures - --- Summary === The Cisco Internetwork Operating System (IOS) may permit arbitrary code execution after exploitation of a heap-based buffer overflow vulnerability. Cisco has included additional integrity checks in its software, as further described below, that are intended to reduce the likelihood of arbitrary code execution. Cisco has made free software available that includes the additional integrity checks for affected customers. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20051102-timers.shtml. Cisco is not aware of any active exploitation of this vulnerability. This advisory documents changes to Cisco IOS? as a result of continued research related to the demonstration of the exploit for another vulnerability which occurred in July 2005 at the Black Hat USA Conference. Cisco addressed the IPv6 attack vector used in that demonstration in a separate advisory published on July 29, 2005. Affected Products = This security advisory applies to all Cisco products that run Cisco IOS Software. Any version of Cisco IOS prior to the versions listed in the Fixed Software table below may be susceptible to heap overflow exploitation. Cisco IOS XR is not affected. To determine the software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS Software will identify itself as Internetwork Operating System Software or simply IOS. On the next line of output, the image name will be displayed between parentheses, followed by Version and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product running IOS release 12.3(6) with an installed image name of C3640-I-M: Cisco Internetwork Operating System Software IOS (tm) 3600 Software (C3640-I-M), Version 12.3(6), RELEASE SOFTWARE (fc3) The next example shows a product running IOS release 12.3(11)T3 with an image name of C3845-ADVIPSERVICESK9-M: Cisco IOS Software, 3800 Software (C3845-ADVIPSERVICESK9-M), Version 12.3(11)T3, RELEASE SOFTWARE (fc4) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2005 by Cisco Systems, Inc. Additional information about Cisco IOS release naming can be found at http://www.cisco.com/warp/public/620/1.html. No other Cisco products are currently known to be affected by the vulnerability addressed in this advisory. Background Information Regarding Heap Overflows === As this security advisory pertains to heap overflows, the following additional information is provided to aid in understanding the terminology used in this advisory. RFC 2828 defines a vulnerability as A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy. The threat from any particular vulnerability in a system or a protocol depends on the ease and likelihood in which the normal operations of a system can be disrupted or compromised. In order to minimize the threat, each possible attack vector for a particular vulnerability should either be mitigated with protections which may prevent the circumstances required for exploitation or remediated with software that no longer contains the vulnerability. Many forms of malicious software, commonly known as exploits, contain a payload that seeks to disrupt or compromise a system delivered through well-known attack vectors for particular vulnerabilities. In cases where it is likely that unpatched vulnerable systems exist, counter-measures are often employed to attempt to block any and all attack vectors to minimize the threat of successful exploitation. One popular attack method often found in the payload of exploits is known as a buffer overflow. A heap-based overflow is a type of buffer overflow against a data structure residing within the memory heap. The memory heap is a section of system memory used by the operating system of the device to satisfy the dynamic data storage requirements for currently running processes. In a successful heap-based
Problem with peering between Gblx and WCG?
1 ge4-1-0-226-1000M.ar4.PHX1.gblx.net (67.17.64.89) 0 msec 0 msec 0 msec 2 so1-0-0-2488M.ar1.LAX2.gblx.net (67.17.67.169) 12 msec 8 msec 12 msec 3 lsanca3lcx1-pos13-2.wcg.net (64.200.142.193) 772 msec 796 msec 804 msec 4 anhmca1wcx2-pos5-0.wcg.net (64.200.140.69) [AS 7911] 804 msec 832 msec 852 msec 5 lsanca1wcx1-pos0-0-oc48.wcg.net (64.200.140.142) [AS 7911] 856 msec 988 msec 1000 msec Would anyone happen to be aware of problems between Global Crossing and WCG in CA? We're hearing reports of intermittent latency across this link over the past three days. Thanks, ~ Rob Reeves IP Network Engineer Arbinet 703-456-4172 [EMAIL PROTECTED] ~
Re: cymru down?
Hi, NANOGers. Just a quick interruption in your day to update you on the routing fun we had. :) The problem was two-fold: 1. An errant provider router that randomly selected which prefixes to propagate. Mix that with uRPF, and you have FUN FUN FUN! :) 2. An interesting use of LOCAL_PREF by the provider, now mitigated. Our tests from multiple external pods and route servers show that we're globally visible again. If you're having any difficulty reaching us, please let us know at [EMAIL PROTECTED]. Again we apologize for the inconvenience! Thanks, Rob, for Team Cymru. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
The Folly of Peering Ratios
Hi all - At the Peering BOF X at NANOG 35 in Los Angeles last week we held a debate on the rationality of Peering Traffic Ratios as a Peering Partner selection criteria. During the debate both sides made good points, but interestingly, some of the strongest arguments on both sides of the debate came out during the QA and during coffee break/bar/beer-n-gear ad hoc debates that followed. I have classified roughly six arguments culled from these discussion, attributed where I remembered the source, along with the corresponding counter arguments that seemed to collectively reveal the folly of peering traffic ratios as a peering discriminator. I have documented and diagrammed these arguments in the form of a white paper titled, of course, The Folly of Peering Traffic Ratios. I am looking for some people to review the paper, provide feedback, better defend an argument on either side, provide anecdotes, whatever you believe would help make the paper an accurate portrayal of the arguments on both sides of this issue. If you have the time to let me walk you through the paper over the phone (about 20 minutes) and discuss, that would be the best - I find I get the most feedback this way. I'll send out a note to the list when I have done enough walk throughs to feel comfortable enough that I have things about right and that the draft can be circulated more broadly. Here is the current summary from The Folly of Peering Ratios v0.5: -- snip --- Summary In the heated discussions surrounding this topic there were six flavors of arguments put forth to support peering traffic ratios as a peering selection criteria. Argument #1 - I don't want to haul your content all over the world for free. This argument is countered with the observation that, whether peered with a content heavy or an access heavy ISP, the ISP is being paid by its customers for providing access to that traffic. It is not hauling the traffic for free. Argument #2 – OK, but there is massive asymmetry here. Look at how many bits miles I have to carry your content, while you have only to deliver your content across the exchange point. Regardless of whether peered with content or access the load on your network is about the same; the access or content traffic has to traverse your network to get to your customers. This is an argument perhaps for more geographically distributed points of interconnection. Argument #3 – As an Access Heavy ISP, I don't want to peer with Content Heavy ISPs, because doing so will screw up my peering traffic ratios with my other peers. The analysis and diagrammed traffic flows in this paper prove this assertion true, however, the argument is circular: 'Peering Traffic Ratios are valid criteria because they support Peering Traffic Ratios with others.' Argument #4 – I want revenue for carrying your packets. While this argument is business rational, peering traffic ratios are a poor indicator of the value derived from the interconnection. Argument #5 – My backbone is heavily loaded in one direction – I don't have $ to upgrade the congested part of my core without a corresponding increase in revenue. This loading problem can better be solved with better traffic engineering, with more resources for the core or by temporarily postponing all additional peering until the core is upgraded. Introducing a peering traffic ratio requirement is at best a temporary solution and signals a poorly managed network – a bad image for peers and transit customers alike. Argument #6 – I don't want to peer with anyone else. Peering ratios help me systematically keep people out. This is an understandable (although seldom articulated out loud) argument but is a poor defense for peering traffic ratios per se since it is an arbitrary discriminator; one could just as well have specified the size of the backbone core, the market capitalization or debt structure, or an extremely large number of distributed interconnect points. Peering Traffic Ratios emerged years ago in the Internet as a peering candidate discriminator, but appear to have their roots in the PSTN world. Ratios reflect the telephony settlement model of buying and selling minutes, where the traffic difference between in and out is used for settling at the end of the month. However, the Peering Traffic Ratio discriminator model for the Internet interconnection fails because traffic ratios are a poor indicator of relative value derived from the interconnect. If you have time to review the paper (about 6 pages), please send me a note. Thanks! Bill -- // // William B. Norton [EMAIL PROTECTED] // Co-Founder and Chief Technical Liaison, Equinix // GSM Mobile: 650-315-8635 // Skype, Y!IM: williambnorton
Re: SBC/ATT + Verizon/MCI Peering Restrictions
--- Randy Bush [EMAIL PROTECTED] wrote: if i am a paying sbc or other foopoloy dsl customer and i go to http://content.provider, why should content.provider pay to give the sbc paying customer what they're already charged for? There is one scenario where the content.provider is paying the carrier as well - when the content.provider is a direct customer of the carrier, rather than being either a SFI-peer or a customer of an SFI-peer. This of course goes back to the question of depeering/transit/etc which we beat to death a couple of weeks ago - many carriers want to get paid both by the sources and sinks of traffic (it's certainly an understandable, if unlikely, desire). I would just like to point out for the record that none of the recent depeering battles have involved any RBOCs... -David Barak __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: Problem with peering between Gblx and WCG?
Yes, we had two tickets w/ WilTel related to this during the past week. We initially noted a problem on Saturday (10/29). After escalation, they resolved it sometime yesterday per my understanding. After confirming the problem did not still exist from the GBLX route-server (telnet://route-server.gblx.net) we turned our session back up with them yesterday evening. It appears alright from our perspective at present. My understanding was that they had a saturated OC12c between them @ LAX. Not sure where else they inter-connect but it took several days for them to upgrade that link. Not sure why they didn't shift traffic elsewhere while working on the upgrade. -jr * Reeves, Rob [EMAIL PROTECTED] [20051102 17:42]: 1 ge4-1-0-226-1000M.ar4.PHX1.gblx.net (67.17.64.89) 0 msec 0 msec 0 msec 2 so1-0-0-2488M.ar1.LAX2.gblx.net (67.17.67.169) 12 msec 8 msec 12 msec 3 lsanca3lcx1-pos13-2.wcg.net (64.200.142.193) 772 msec 796 msec 804 msec 4 anhmca1wcx2-pos5-0.wcg.net (64.200.140.69) [AS 7911] 804 msec 832 msec 852 msec 5 lsanca1wcx1-pos0-0-oc48.wcg.net (64.200.140.142) [AS 7911] 856 msec 988 msec 1000 msec Would anyone happen to be aware of problems between Global Crossing and WCG in CA? We're hearing reports of intermittent latency across this link over the past three days. Thanks, ~ Rob Reeves IP Network Engineer Arbinet 703-456-4172 [EMAIL PROTECTED] ~ -- Josh Richards| Colocation Web Hosting Bandwidth Digital West Networks| +1 805 781-9378 / www.digitalwest.net San Luis Obispo, CA | AS14589 (Production) / AS29962 (RD) [EMAIL PROTECTED] | DWNI - Making Internet Business Better
Re: cogent+ Level(3) are ok now
On Tue, 2005-11-01 at 18:48 -0500, [EMAIL PROTECTED] wrote: On Tue, 01 Nov 2005 11:46:20 EST, John Payne said: What am I missing? Obviously, the same thing that management at SBC is missing: snip He argued that because SBC and others have invested to build high-speed networks, they are due a return. There's going to have to be some mechanism for these people ... to pay for the portion they're using. Why should they be allowed to use my pipes? He offered no details how his idea could be accomplished. For an Internet company to expect to use these pipes free is nuts! Whitacre added for good measure. /snip Sounds like an extremely short-sighted view of the Net and it's economics. Claiming content providers should be charged for using broadband access-pipes is fine and dandy, but coveniently forgetting that without content there probably wouldn't be a great deal of customers wanting broadband in the first place is a bit sloppy, no? Erik -- Erik Haagsman Network Architect We Dare BV tel: +31.10.7507008 fax: +31.10.7507005 http://www.we-dare.nl
FW: Using BGP to force inbound and outbound routing through particular routes
I recently made a request to get a cable modem connection at my home. I went for one of those $29.95 for three month specials in case I run afoul of some rules prohibiting what I am going to do. I already have a multi-T1 connection with a Class C block and BGP running on my Cisco 3640 router, and was looking to become multi-homed. The cable connection is via bridge/DHCP cable modem, and was going to hook it up to the Cisco 3640. I have already done the research and know from what block of IP addresses I will be assigned, and the BGP route tables/peers. I would like to use BGP to force inbound and outbound routing only through particular peers, Sprint (AS 1239) and UUNET (AS 701). I have been reading Practical BGP by Whate, McPherson and Sangli and this appears to be possible. However, do my adjacent routers need to support BGP in order for this to work? Could I use other routing protocols to accomplish this, or would this require knowledge of all possible downstream router IP addresses? Edward W. Ray
Using BGP to force inbound and outbound routing through particular routes
spam was a lousy name... -Original Message- From: spam [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 02, 2005 11:44 AM To: 'nanog@merit.edu' Subject: FW: Using BGP to force inbound and outbound routing through particular routes I recently made a request to get a cable modem connection at my home. I went for one of those $29.95 for three month specials in case I run afoul of some rules prohibiting what I am going to do. I already have a multi-T1 connection with a Class C block and BGP running on my Cisco 3640 router, and was looking to become multi-homed. The cable connection is via bridge/DHCP cable modem, and was going to hook it up to the Cisco 3640. I have already done the research and know from what block of IP addresses I will be assigned, and the BGP route tables/peers. I would like to use BGP to force inbound and outbound routing only through particular peers, Sprint (AS 1239) and UUNET (AS 701). I have been reading Practical BGP by Whate, McPherson and Sangli and this appears to be possible. However, do my adjacent routers need to support BGP in order for this to work? Could I use other routing protocols to accomplish this, or would this require knowledge of all possible downstream router IP addresses? Edward W. Ray
Re: Equal access to content
Sean Donelan wrote: Should content suppliers be required to provide equal access to all networks? Or can content suppliers enter into exclusive contracts? SBC and Yahoo! have already answered this question (for example). I also think that most people on this list will remember the early days of broadband suppliers like RoadRunner who tried to build a we are mostly local content, plus some Internet access model which the customers hated, and they (for the most part) eventually abandoned altogether. Even AOL was forced by market pressure to provide real Internet to its customers. Doug .oO(Glad I don't own any SBC stock ...) -- If you're never wrong, you're not trying hard enough
RE: Using BGP to force inbound and outbound routing through particular routes
What's the netblock and ASN you already have? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Edward W. Ray Sent: Wednesday, November 02, 2005 2:50 PM To: nanog@merit.edu Subject: Using BGP to force inbound and outbound routing through particular routes spam was a lousy name... -Original Message- From: spam [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 02, 2005 11:44 AM To: 'nanog@merit.edu' Subject: FW: Using BGP to force inbound and outbound routing through particular routes I recently made a request to get a cable modem connection at my home. I went for one of those $29.95 for three month specials in case I run afoul of some rules prohibiting what I am going to do. I already have a multi-T1 connection with a Class C block and BGP running on my Cisco 3640 router, and was looking to become multi-homed. The cable connection is via bridge/DHCP cable modem, and was going to hook it up to the Cisco 3640. I have already done the research and know from what block of IP addresses I will be assigned, and the BGP route tables/peers. I would like to use BGP to force inbound and outbound routing only through particular peers, Sprint (AS 1239) and UUNET (AS 701). I have been reading Practical BGP by Whate, McPherson and Sangli and this appears to be possible. However, do my adjacent routers need to support BGP in order for this to work? Could I use other routing protocols to accomplish this, or would this require knowledge of all possible downstream router IP addresses? Edward W. Ray
Re: cogent+ Level(3) are ok now
Sounds like an extremely short-sighted view of the Net and it's economics. Claiming content providers should be charged for using broadband access-pipes is fine and dandy, but coveniently forgetting that without content there probably wouldn't be a great deal of customers wanting broadband in the first place is a bit sloppy, no? while valid, this argument plays into the power play game. the key point is that the content providers already paid once for transport [0], as did the content users. we may need more gummint support to keep the rbocs from abusing their subsidized monopoly ownership of the last mile. two years ain't enough to get the cartel-minded out of control of the fcc. randy --- [0] - whether to transit upstreams or by deploying a large network themselves (aol)
Re: To get internet full routing table
On Wed, 2 Nov 2005, Joe Shen wrote: Is that possible to get full internet routing table without help from upstream ISP? or is there anyway to get some backbone network's internet routing table directly? is this one of those deep philosophical questions .. like trees falling in forests with no one around? :) you can look at route-views.oregon-ix.net if you want to take a peak at the bgp table. alternatively you can find a friendly ISP to send you a bgp table if you want your own copy. www.traceroute.org may also be helpful for you Steve
RE: Using BGP to force inbound and outbound routing through particular routes
66.6.208.1/24, ASN is currently 11509 but I will be getting my own shortly. Edward W. Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hannigan, Martin Sent: Wednesday, November 02, 2005 11:54 AM To: Edward W. Ray; nanog@merit.edu Subject: RE: Using BGP to force inbound and outbound routing through particular routes What's the netblock and ASN you already have? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Edward W. Ray Sent: Wednesday, November 02, 2005 2:50 PM To: nanog@merit.edu Subject: Using BGP to force inbound and outbound routing through particular routes spam was a lousy name... -Original Message- From: spam [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 02, 2005 11:44 AM To: 'nanog@merit.edu' Subject: FW: Using BGP to force inbound and outbound routing through particular routes I recently made a request to get a cable modem connection at my home. I went for one of those $29.95 for three month specials in case I run afoul of some rules prohibiting what I am going to do. I already have a multi-T1 connection with a Class C block and BGP running on my Cisco 3640 router, and was looking to become multi-homed. The cable connection is via bridge/DHCP cable modem, and was going to hook it up to the Cisco 3640. I have already done the research and know from what block of IP addresses I will be assigned, and the BGP route tables/peers. I would like to use BGP to force inbound and outbound routing only through particular peers, Sprint (AS 1239) and UUNET (AS 701). I have been reading Practical BGP by Whate, McPherson and Sangli and this appears to be possible. However, do my adjacent routers need to support BGP in order for this to work? Could I use other routing protocols to accomplish this, or would this require knowledge of all possible downstream router IP addresses? Edward W. Ray
Re: cogent+ Level(3) are ok now
On Wed, Nov 02, 2005 at 08:22:20AM -0600, Pete Templin wrote: Time out here. John set the stage: cold potato addressed the long haul (or at least that's the assumption in place when I hopped on board). If NetA and NetB are honoring MED (or other appropriate knob), NetA-NetB traffic has already arrived at the closest mutual peering point in the A-B direction. The rest of the infrastructure would be the responsibility of NetB to get the traffic to CustomerPortXYZ, no? How could CustomerXY get any closer to NetA without cutting NetB out of the middle, and if NetB is out of the middle, why should CustomerXY pay NetB anything? You're forgetting that MEDs suck. When used on real complex production networks, they almost always degrade the quality of the routing. Yes with enough time and energy (or a small enough network) you *can* beat perfect MEDs out of the system (and your customers). You can selectively deaggregate the hell out of your network, then you can zero out all the known aggregate blocks and regions that are in the middle of two MED-speaking interconnection points, and get your customers to tag aggregate blocks announced in multiple locations so that you can zero out those MEDs. With enough time and energy anything is possible, the point is that most folks don't consider it to be worth the time, let alone the customer anger when it degrades your traffic. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: SBC/ATT + Verizon/MCI Peering Restrictions
On Wed, Nov 02, 2005 at 03:04:52AM -1000, Randy Bush wrote: the two year window is far too low given the sbc ceo's recent public statements on the use of his wires by google and the like. Come on, you didn't see that coming? I'd wager money that right now, somewhere at SBC, there are two executives in a board room with arms interlocked at the elbow, skipping merrily in a circle with giant grins on their faces, chanting: o/~ We're gonna be a tier 1 o/~ o/~ We're gonna be a tier 1 o/~ -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: cogent+ Level(3) are ok now
Richard A Steenbergen wrote: Yes with enough time and energy (or a small enough network) you *can* beat perfect MEDs out of the system (and your customers). You can selectively deaggregate the hell out of your network, then you can zero out all the known aggregate blocks and regions that are in the middle of two MED-speaking interconnection points, and get your customers to tag aggregate blocks announced in multiple locations so that you can zero out those MEDs. With enough time and energy anything is possible, the point is that most folks don't consider it to be worth the time, let alone the customer anger when it degrades your traffic. I came up with a reasonably scalable solution using communities and route-map continue, but: CSCsc36517 Externally found severe defect: New (N) Bus Error reload after configure route-map and then clear bgp neighbor Release-note: When a bgp route-map is configured on the router and then clear ip bgp neighbor.. command is executed router experiences Unexpected Reload due to Bus Error. Currently there is no other workaround other than to prevent executing the clear ip bgp neighbor command. ...kinda gets in my way. For what it's worth, it doesn't even require clear ip bgp ne to crash the box. Joy. pt
Re: New Rules On Internet Wiretapping Challenged
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 comments in-line: Peter Dambier wrote: Vicky Rode wrote: ...Raising my hand. My question is on Terry Hartle's comments, maybe someone with more insight into this could help clear my confusion. Why would it require to replace every router and every switch when my understanding is, FCC is looking to install *additional* gateway(s) to monitor Internet-based phone calls and emails. In a datacenter you have lines coming in and lines going out. And you have internal equippment. You have to eavesdrop on all of this because the supposed terrorist might come in via ssh and use a local mail programme to send his email. - -- How do you differentiate between a hacker and a terrorist? For all you know this so called terrorist might be coming from a spoofed machine(s) behind anyone's desk. So you have to eavesdrop on all incoming lines because you dont know where he comes in. Via aDSL? via cable modem? Via a glass fiber? And you have to monitor all internal switches because you dont know which host he might have hacked. Guess a cheap switch with 24 ports a 100 Mbit. That makes 2.4 Gig. You have to watch all of these. They can all send at the same time. Your switch might have 1 Gig uplink. But that uplink is already in use for your uplink and it does not even support 2.4 Gig. - - There are ways to address over-subscription issues. How about switches used in datacenters with 48 ports, 128 ports, ... Where do you get the capacity for multiple Gigs just for eavesdropping? On the other hand - most switches have a port for debugging. But this port can only listen on one port not on 24 or even 48 of them. So you have to invent a new generation of switches. - I don't believe this is the primary reason for replacing every router and every switch. I think (correct me if I'm wrong) it has to do with the way wiretap feature (lack of a better term) that .gov is wanting vendors to implement within their devices, may be at the network stack level. I guess it's time to revisit rfc 2804. How about the routers? They are even more complicated than a switch. As everybody should know by now - every router can be hacked. So your monitoring must be outside the router. The gouvernment will offer you an *additional* gateway. I wonder what that beast will look like. It must be able to take all input you get from a glass fiber. Or do they ask us to get down with our speed so they have time to eavesdrop. - - powered by dhs w/ made in china sticker :-) I'm not being smarty pants about this...it is actually happening. That's all I can say. regards, /virendra I can see some sort of network redesign happening in order to accodomate this but replacing every router and every switch sounds too drastic, unless I mis-understood it. Please, I'm not advocating this change but just trying to understand the impact from an operation standpoint. Yes, it is drastic. But if they want to eavesdrop that is the only way to do it. Any insight will be appreciated. regards, /virendra Here in germany we accidently have found out why east germany had to finally give up: They installed equippement to eavesdrop and tape on every single telefone line. They could not produce enough tapes to keep up with this :) Not to mention what happened when they recycled the tapes and did not have the time to first erase them :) Kind regards, Peter and Karin -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDaSmqpbZvCIJx1bcRAhU9AJoC54jYhsUMs7aO6xQ/5kEX79gt9wCcDWkT L8hApJtW2gqfibjYfq7E7Z0= =3yz1 -END PGP SIGNATURE-
RE: FW: Using BGP to force inbound and outbound routing through particular routes
Yes, you are correct I have decided to go for my CCIE:Security and need some practice before the lab exam. My only choices for multi-homing at home are T1s/DS3s... And cable. I already have a 3-T1 setup where the Class C block is homed now. This is my main business line and hosts my DNS, Web, Mail servers and VPN connections. The ISP I use is has punched a hole in their Class B to allow my Class C block to leak through. At some point I may get a business class cable line. But since I do not know if what I am doing will violate Roadrunner's AUP and/or cause them to disconnect me, I decided to go with the $29.95 special. My ISP already peers with Level3, and Roadrunner peers with Level3 (AS3356) and AOL (AS 1668). My goal is to block all routes via Roadrunner/Level3 and force all inbound and outbound traffic via Roadrunner to go through AS 1668 only. Edward W. Ray -Original Message- From: Mike Damm [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 02, 2005 12:22 PM To: spam Subject: Re: FW: Using BGP to force inbound and outbound routing through particular routes Let me see if I understand what you are saying... You have a real network with routers, T1 lines, all that jazz. And you'd like to multihome with a cable modem? Right? -Mike On 11/2/05, spam [EMAIL PROTECTED] wrote: I recently made a request to get a cable modem connection at my home. I went for one of those $29.95 for three month specials in case I run afoul of some rules prohibiting what I am going to do. I already have a multi-T1 connection with a Class C block and BGP running on my Cisco 3640 router, and was looking to become multi-homed. The cable connection is via bridge/DHCP cable modem, and was going to hook it up to the Cisco 3640. I have already done the research and know from what block of IP addresses I will be assigned, and the BGP route tables/peers. I would like to use BGP to force inbound and outbound routing only through particular peers, Sprint (AS 1239) and UUNET (AS 701). I have been reading Practical BGP by Whate, McPherson and Sangli and this appears to be possible. However, do my adjacent routers need to support BGP in order for this to work? Could I use other routing protocols to accomplish this, or would this require knowledge of all possible downstream router IP addresses? Edward W. Ray
RE: Using BGP to force inbound and outbound routing through particular routes
There is nothing about a cable modem that would normally prevent a BGP session. Nor do all the intermediate routers need to support BGP (multi-hop BGP). However, direct connections are preferred. Your _real_ challenge is convincing Roadrunner's NOC staff to program one of their backbone routers to do a BGP session with a cable modem sub. Or, for that matter, getting them to even route a non-roadrunner IP block to a cable modem sub. Instead you might try borrowing a bunch of old 2500s and setting up a test lab that isn't connected to actual net. Best of luck on your CCIE. John At 02:06 PM 11/2/2005, Edward W. Ray wrote: 66.6.208.1/24, ASN is currently 11509 but I will be getting my own shortly. Edward W. Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hannigan, Martin Sent: Wednesday, November 02, 2005 11:54 AM To: Edward W. Ray; nanog@merit.edu Subject: RE: Using BGP to force inbound and outbound routing through particular routes What's the netblock and ASN you already have? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Edward W. Ray Sent: Wednesday, November 02, 2005 2:50 PM To: nanog@merit.edu Subject: Using BGP to force inbound and outbound routing through particular routes spam was a lousy name... -Original Message- From: spam [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 02, 2005 11:44 AM To: 'nanog@merit.edu' Subject: FW: Using BGP to force inbound and outbound routing through particular routes I recently made a request to get a cable modem connection at my home. I went for one of those $29.95 for three month specials in case I run afoul of some rules prohibiting what I am going to do. I already have a multi-T1 connection with a Class C block and BGP running on my Cisco 3640 router, and was looking to become multi-homed. The cable connection is via bridge/DHCP cable modem, and was going to hook it up to the Cisco 3640. I have already done the research and know from what block of IP addresses I will be assigned, and the BGP route tables/peers. I would like to use BGP to force inbound and outbound routing only through particular peers, Sprint (AS 1239) and UUNET (AS 701). I have been reading Practical BGP by Whate, McPherson and Sangli and this appears to be possible. However, do my adjacent routers need to support BGP in order for this to work? Could I use other routing protocols to accomplish this, or would this require knowledge of all possible downstream router IP addresses? Edward W. Ray
Re: cogent+ Level(3) are ok now
I don't understand them, either. However, if you define incoming traffic as bad, it encourages depeering by the receiving side if the incoming/outgoing ratio exceeds a certain value, especially among close-to-tier-1 carriers: the traffic does not automatically disappear just because you depeer. Now suppose that the sending side doesn't want to play games and buys transit from one of your other peers. Given the tier-1 status, there is some chance that this has a measurable impact on the traffic ratio with that other peer. Essentially, this is a self-fulfilling prophecy, and it works equally well if you define outgoing traffic as bad. I was trying to stay out of this. But I think I'm going to chime in here. I think (originally)... means... whenever the NAP structure was created and the NSFnet was decommissioned, long haul moving of the bits was very expensive. Perhaps more so than the local-distance piece because you had comparatively few of these links and had to cart bits a very long way to dump them off. Now I believe that with the influx of large, reasonable colos and 20+ high speed interconnects in a region (or slightly larger area). This coupled with dramatically reduced long haul costs has shifted the value/expense ratios in peering. For example if you are a content network. If you needed to peer in 5 places in the old (long-haul=expensive) model would colo your content in 5 places near your interconnected and the only interconnections between your colos would be whatever you needed to keep heartbeat and data sync between them. But you incurred a large cost for this colo and manpower and other things. Now... let's just say you don't need to do that... because you can run a few circuits around the country (or MPLS them) and its pretty cheap. However, the last-mile piece for access networks HASN'T moved as much in the same time period. Lots of networks (Q, LVLT, GBLX, etc) built long haul networks. Lots of them colo'd in ILEC switch (and tandem buildings). But this doesn't do ISP type businesses very much good. You still have to pay interconnect fees to the ILEC or exorbitant colo fees to them to backhaul the circuit to your DC with all of your equipment. Means... that even though you control the customer and the CPE, you are paying fees to many folks that _really_ own the copper (or coax) or underlying infrastructure and they have little to NO competitive pressure to be more than slightly price concerned. This drives you to the idea that actually moving higher PPS is bad while increasing peak speeds is good. Customers are buying/being marketed to by peak speed. So you give them large pipes because once you've paid the underlying tariffs to get to their house/business (say a dry pair) whatever speed you signal on it is your equipment cost, nothing else. But actually encouraging them to USE that bandwidth is expensive because your cost of growing the T3, OC3, OC12 or whatever you are backhauling from the various COs to your network is BAD and expensive. This is the model as I understand it today. Formerly the longhaul and cost of transit was so expensive these costs were more negligible. Now we have a playing field. Now if you depeer a guy [Cogent] for example, and you force him to buy transit from someone who doesn't have a very vibrant transit business [NTT/Verio, I'm being kind] you increase his costs and force [NTT/Verio] to upgrade their network which may take time. The depeered guy suffers. Maybe he doesn't suffer much at all [Like when Cogent could force all of its AOL traffic through its Level3 connection]. But his customers... They want speedy access to your eyeballs. Maybe some of them will want to reduce the number of networks traversed to get to your eyeballs. By limiting the number of SFI connections you have... I would theorize you can force those who can afford it to interconnect with you directly. Not everyone. But a few. If you perceive your network as better than your SFI peers, then naturally you would assume that the business of their customers would eventually flow to you. The problem with this kind of increased instability is that the perception and tenacity of all the players is very difficult to assess and is often not as vastly different as the players would hope. But to the extent you can force others to have to redo their network interconnections with little impact [at least what you believe when you are taking the action] the better it is for you. Especially if you are running out of value-added sales pitches. Further proving the counterpoint: Large eyeball networks (like Verizon broadband) that use Level3 (formerly genuity) a lot, didn't get affected by this depeering. Why? Because they've already added diversity to their network. Even if the Level3 routes are normally chosen more often than the other providers [guessing, not saying its true], Level3 forced their 95th percentile to peak with
Re: Using BGP to force inbound and outbound routing through particular routes
On Wed, Nov 02, 2005 at 03:35:07PM -0600, John Dupuy wrote: There is nothing about a cable modem that would normally prevent a BGP session. Nor do all the intermediate routers need to support BGP (multi-hop BGP). However, direct connections are preferred. Your _real_ challenge is convincing Roadrunner's NOC staff to program one of their backbone routers to do a BGP session with a cable modem sub. Or, for that matter, getting them to even route a non-roadrunner IP block to a cable modem sub. Instead you might try borrowing a bunch of old 2500s and setting up a test lab that isn't connected to actual net. Best of luck on your CCIE. A) No cable company in their right mind is going to speak BGP to a $29.95/mo residential customer, period. B) The answer to his question about I don't know if what I'm doing will violate the AUP or not is, when in doubt the answer is YES. No sane comapny is going to let this guy near bgp with a 10ft pole after that statement, but then again no sane people read nanog any more I suspect. C) If this guy actually had a CCIE, I would encourage Cisco to quickly implement a SWAT team responsible for reposessing the CCIE medals of anyone caught using the words Class C for a /24 out of 66. space. D) Please do not feed the trolls. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: SBC/ATT + Verizon/MCI Peering Restrictions
There is one scenario where the content.provider is paying the carrier as well - when the content.provider is a direct customer of the carrier, rather than being either a SFI-peer or a customer of an SFI-peer. This of course goes back to the question of depeering/transit/etc which we beat to death a couple of weeks ago - many carriers want to get paid both by the sources and sinks of traffic (it's certainly an understandable, if unlikely, desire). I would just like to point out for the record that none of the recent depeering battles have involved any RBOCs... Playing devil's advocate here... But what if (assuming a new generation of peering agreements came into being)... They allowed SELECTIVE depeering... say... by Customer? So SBC could depeer Google... (assume here the SBC wants Google to become a customer and isn't actually competing with Google as an SE guy). And assume that the FCC/Courts will take a few years to deal with the issue. I think it might be able to happen. What would a Google do? Anywhere it moves its bits, SBC would just drop them/ignore them. SBC is running a private network with some interconnections as far as SBC is concerned, and barring any wild lawsuits from customers and assuming an amendment to its TOS... You could selectively depeer BIG guys... that aren't SO big that your customers will mass defect.. So maybe Google isn't the right example. Maybe real.com is a better one. Would you lose many customers if real.com wasn't available to them? I bet not. But would real be willing to pay you $4K a month to keep access to your network??? probably. Just a thought. Deepak
Re: cogent+ Level(3) are ok now
On Wed, Nov 02, 2005 at 02:44:20PM -0600, Pete Templin wrote: I came up with a reasonably scalable solution using communities and route-map continue, but: For what value of scalable? --Jeff
Re: cogent+ Level(3) are ok now
On Wed, 2 Nov 2005, Jeff Aitken wrote: On Wed, Nov 02, 2005 at 02:44:20PM -0600, Pete Templin wrote: I came up with a reasonably scalable solution using communities and route-map continue, but: For what value of scalable? anything, its 'scalable' :) Steve
Re: cogent+ Level(3) are ok now
Jeff Aitken wrote: On Wed, Nov 02, 2005 at 02:44:20PM -0600, Pete Templin wrote: I came up with a reasonably scalable solution using communities and route-map continue, but: For what value of scalable? For me, plenty, but a four-POP single-state network usually has different constraints on scalable. However, I'd categorize it as one community-list per MED tier (i.e. if you just want near/far, that's two tiers, etc.) and one community-list entry per POP (or group of POPs, if you have some grouping logic embedded in your internal communities). pt
Re: cogent+ Level(3) are ok now
For me, plenty, but a four-POP single-state network usually has different constraints on scalable. However, I'd categorize it as one community-list per MED tier (i.e. if you just want near/far, that's two tiers, etc.) and one community-list entry per POP (or group of POPs, if you have some grouping logic embedded in your internal communities). I think Pete is saying that as long as you aren't a control-nazi, its a good system. :) Given that constraint, I wonder how of NANOG it applies to. ;) Deepak
Re: Using BGP to force inbound and outbound routing through particular routes
RAS, I have to admit that I'm guilty of using the phrase class C more or less interchangably with /24 - I suspect a lot of us still do that... On 11/2/05 2:22 PM, Richard A Steenbergen [EMAIL PROTECTED] wrote: On Wed, Nov 02, 2005 at 03:35:07PM -0600, John Dupuy wrote: There is nothing about a cable modem that would normally prevent a BGP session. Nor do all the intermediate routers need to support BGP (multi-hop BGP). However, direct connections are preferred. Your _real_ challenge is convincing Roadrunner's NOC staff to program one of their backbone routers to do a BGP session with a cable modem sub. Or, for that matter, getting them to even route a non-roadrunner IP block to a cable modem sub. Instead you might try borrowing a bunch of old 2500s and setting up a test lab that isn't connected to actual net. Best of luck on your CCIE. A) No cable company in their right mind is going to speak BGP to a $29.95/mo residential customer, period. B) The answer to his question about I don't know if what I'm doing will violate the AUP or not is, when in doubt the answer is YES. No sane comapny is going to let this guy near bgp with a 10ft pole after that statement, but then again no sane people read nanog any more I suspect. C) If this guy actually had a CCIE, I would encourage Cisco to quickly implement a SWAT team responsible for reposessing the CCIE medals of anyone caught using the words Class C for a /24 out of 66. space. D) Please do not feed the trolls. :) -- Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-213-1302 Cell: 650-207-0372 Fax: 650-969-2124
Re: Using BGP to force inbound and outbound routing through particular routes
I have to admit that I'm guilty of using the phrase class C more or less interchangably with /24 - I suspect a lot of us still do that... well, now you can do it for /64s and class B can be /48s (or is it /56s?) and class A can be /32s we have all been here before -- csny except i guess some of us either haven't or have forgotten. randy
Re: Using BGP to force inbound and outbound routing through particular routes
On Wed, Nov 02, 2005 at 03:21:15PM -0800, Joe McGuckin wrote: RAS, I have to admit that I'm guilty of using the phrase class C more or less interchangably with /24 - I suspect a lot of us still do that... Well, on behalf of the entire networking community, I hereby ask you to stop it. :) It's just a bad habit, and while you may know exactly what it means and doesn't mean, it does nothing but confuse new people about how and why classless routing works. It is absolutely absurd that so many people still teach classful routing FIRST to new students in this day and age, and then approach classless routing like it is something new and different which should be considered as an afterthought. Just remember, the people you confuse today are the ones who are going to be announcing their legacy erm class B allocations as /24s tomorrow, because they don't know any better. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
classful routes redux
er.. would this be a poor characterization of the IPv6 addressing architecture which is encouraged by the IETF and the various RIR members? class A == /32 class B == /48 class C == /56 hostroute == /64 (and just think of all that spam than can originate from all those loose IP addresses in that /64 for your local SMTP server!!! Yummy) -- Oat Willie
Re: classful routes redux
actually, no, I could compare a /48 to a class A. On Nov 2, 2005, at 3:51 PM, [EMAIL PROTECTED] wrote: er.. would this be a poor characterization of the IPv6 addressing architecture which is encouraged by the IETF and the various RIR members? class A == /32 class B == /48 class C == /56 hostroute == /64 (and just think of all that spam than can originate from all those loose IP addresses in that /64 for your local SMTP server!!! Yummy) -- Oat Willie -- Don't worry about the world coming to an end today. It's already tomorrow in Australia. (Charles Schulz )
Re: classful routes redux
On Wed, 2 Nov 2005, Fred Baker wrote: actually, no, I could compare a /48 to a class A. ...which makes the /32s-and-shorter that everybody's actually getting double-plus-As, or what? -Bill
Re: classful routes redux
On Nov 2, 2005, at 4:01 PM, Bill Woodcock wrote: On Wed, 2 Nov 2005, Fred Baker wrote: actually, no, I could compare a /48 to a class A. ...which makes the /32s-and-shorter that everybody's actually getting double-plus-As, or what? A class A gives you 16 bits to enumerate 8 bit subnets. If you start from the premise that all subnets are 8 bits (dubious, but I have heard it asserted) in IPv4, and that all subnets in IPv6 are 16 bits (again dubious, given the recent suggestion of a /56 allocation to an edge network), a /48 is the counterpart of a class A. We just have a lot more of them. All of which seems a little twisted to me. While I think /32, /48, / 56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense.
Re: classful routes redux
On Wed, 2 Nov 2005, Fred Baker wrote: While I think /32, /48, /56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense. Yeah, that's what seems important to me here... I mean, I've lived through the whole classful thing once... I'm still not clear why there are people who want to do it again. -Bill
Re: classful routes redux
* [EMAIL PROTECTED] (Fred Baker) [Thu 03 Nov 2005, 01:17 CET]: A class A gives you 16 bits to enumerate 8 bit subnets. If you start You've been reading too much Cisco Press material. All a Class A gives you today is filthy looks, and people who know better shake their heads, feeling sorry for you. The operational world left classful IPv4 addressing behind us, over a decade ago. Perhaps it's time that certain vendors did the same, in their literature and certification programmes. Recycling outdated terms to apply to new concepts (Class C to represent a /24 in the CIDR IPv4 world, or a /48 or whatever in IPv6) is a folly that can only lead to suffering. -- Niels.
Re: classful routes redux
On Wed, 2 Nov 2005, Fred Baker wrote: A class A gives you 16 bits to enumerate 8 bit subnets. If you start from the premise that all subnets are 8 bits (dubious, but I have heard it asserted) in IPv4, not according to my view of the internet.. /8: 18 /9: 5 /10: 8 /11: 17 /12: 79 /13: 179 /14: 335 /15: 651 /16: 8553 /17: 2855 /18: 4793 /19: 10791 /20: 11877 /21: 9990 /22: 13168 /23: 14299 /24: 93293 and that all subnets in IPv6 are 16 bits (again dubious, given the recent suggestion of a /56 allocation to an edge network), a /48 is the counterpart of a class A. We just have a lot more of them. well, /56 /48 /32 seem to have resonance but are not special in any way All of which seems a little twisted to me. you think? :) While I think /32, /48, / 56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense. classes are bad. but recognise v6 is a bit different, /48 or /56 is the per site bit which is not comparable to v4. then /32 is is largest generally accepted prefix for bgp. this suggests anything can happen from 0-32 in bgp and anything can happen in provider igp for 32-48 or 32-56 and again anything in end user igp for 48/56-128 repeat 3 times, twice daily. classes are bad, v6 is not v4 Steve
Re: classful routes redux
Bill Woodcock wrote: On Wed, 2 Nov 2005, Fred Baker wrote: While I think /32, /48, /56, and /64 are reasonable prefix lengths for what they are proposed for, I have this feeling of early fossilization when it doesn't necessarily make sense. Yeah, that's what seems important to me here... I mean, I've lived through the whole classful thing once... I'm still not clear why there are people who want to do it again. It's not quite the same as classful addressing in IPv4. There is no definition of prefix length by address range. At the RIR-ISP level It is actually CIDR with a minimum allocation size that intentionally covers 95+% of applicants. Shorter allocations of various sizes are made based on justification. An extra 1-3 bits is even reserved around each allocation for future growth. The same thing applies to End sites. You can get a /47 or shorter with justification. It's might be rare but it is possible. I think the goal was to avoid making multiple non-aggregatable allocations as is done with IPv4. An alternative would be to allocate based on initial need but still reserve a much larger prefix for future growth. This would avoid the illusion of fixed sizes and carry less risk of unused space. Is that worth the extra RIR effort? Maybe, maybe not. - Kevin
Re: cogent+ Level(3) are ok now
On Wed, Nov 02, 2005 at 05:13:27PM -0600, Pete Templin wrote: For me, plenty, but a four-POP single-state network usually has different constraints on scalable. Right. On Wed, Nov 02, 2005 at 06:20:39PM -0500, Deepak Jain wrote: I think Pete is saying that as long as you aren't a control-nazi, its a good system. :) My point wasn't that his system doesn't work for him; presumably it does. My point was that in the context of global peering, what works for a small network may not (and probably does not) work for someone the size of, say, Level3. There are a lot of operational issues that arise if you listen to MEDs from peers. Apart from the minor issues like oscillations, ratchet-down, and packing inefficiencies, there is the fundamental problem that you will see potentially significant churn as a result of changes in your peers' networks. There is also the problem that there is no single best exit point for many large prefixes (e.g., if you peer with L3, there is no one best place to send traffic destined for something inside 4/8). --Jeff
Re: Using BGP to force inbound and outbound routing through particular routes
On Wed, 2 Nov 2005, Richard A Steenbergen wrote: It's just a bad habit, and while you may know exactly what it means and doesn't mean, it does nothing but confuse new people about how and why classless routing works. It is absolutely absurd that so many people still keep them confused, then they can't join 'the club'...
Re: classful routes redux
On Wed, 2 Nov 2005, Fred Baker wrote: actually, no, I could compare a /48 to a class A. (someone might already have asked this, but...) why /48? Perhaps it's the convenience of it all, but I was pretty much willing to 'accept' the listing as bill/randy had laid it out (accept the wording i suppose) On Nov 2, 2005, at 3:51 PM, [EMAIL PROTECTED] wrote: er.. would this be a poor characterization of the IPv6 addressing architecture which is encouraged by the IETF and the various RIR members? class A == /32 class B == /48 class C == /56 hostroute == /64 (and just think of all that spam than can originate from all those loose IP addresses in that /64 for your local SMTP server!!! Yummy) -- Oat Willie -- Don't worry about the world coming to an end today. It's already tomorrow in Australia. (Charles Schulz )
Re: classful routes redux
hostroute == /64 (and just think of all that spam than can originate from all those loose IP addresses in that /64 for your local SMTP server!!! Yummy) -- Oat Willie ok... so is it -just- me that gets the willies thinking of the 2x64-1 available IPv6 addresses that can be forged as source addresses for spam origination?i REALLY want to have a tidy way of only announcing -EXACTLY- what is being used (ok, modulo one or two adjacent numbers) and not some architecturally constrained addressing plan that has to conserve elsewhere. (yeah, and my co-bills want ponies) --bill
Re: classful routes redux
On Thu, 3 Nov 2005 [EMAIL PROTECTED] wrote: hostroute == /64 (and just think of all that spam than can originate from all those loose IP addresses in that /64 for your local SMTP server!!! Yummy) -- Oat Willie ok... so is it -just- me that gets the willies thinking of the 2x64-1 available IPv6 addresses that can be forged as source addresses for spam origination?i REALLY want to have a tidy but, but, but... ipv6 is more SECURE! :) I'm really not sure I understand why my LAN has to have more available ip space than the current Internet, but boy, it sure makes it easy to spam^H^H^H^Hfind available addresses! I view the 48/56/64 boundaries about like Woody does (and I suspect Mr. Narkins and Mr. Bush) they are in the documentation so people use them, it's not particularly a great idea, but it is an idea. (Oh, and some equipment won't do the lovely autoconfig unless you have a /64, someone should open a bug report on that)
Re: classful routes redux
I was pretty much willing to 'accept' the listing as bill/randy had laid it out (accept the wording i suppose) actually, bill and i disagreed. this is not unusual :-) On Nov 2, 2005, at 3:51 PM, [EMAIL PROTECTED] wrote: class A == /32 class B == /48 class C == /56 hostroute == /64 and i: I have to admit that I'm guilty of using the phrase class C more or less interchangably with /24 - I suspect a lot of us still do that... well, now you can do it for /64s and class B can be /48s (or is it /56s?) and class A can be /32s as, in the truely classful days, a lan was a C == /24, i'll stick to my guns for the moment that a new C is a /64 and so forth. as there is no emoticon for sarcasm, the naive should know that i (and maybe bill) draw this comparison to point out that, by codifying such boundaries in technology and policy, we're making the same old mistakes again. randy
Re: classful routes redux
On Wed, 2 Nov 2005, Randy Bush wrote: I was pretty much willing to 'accept' the listing as bill/randy had laid it out (accept the wording i suppose) actually, bill and i disagreed. this is not unusual :-) oh silly me, I skipped over 'hostroute' and read 'class c' doh :( anyway, this all seems foolish in the end, making the same mistakes again is going to bite someone in the behind.
Re: classful routes redux
class C == /56 hostroute == /64 and i: as, in the truely classful days, a lan was a C == /24, i'll stick to my guns for the moment that a new C is a /64 and so forth. and this from the man who actually received a /33 delegation in v4 space! :) as there is no emoticon for sarcasm, the naive should know that i (and maybe bill) draw this comparison to point out that, by codifying such boundaries in technology and policy, we're making the same old mistakes again. amen... in spades. --bill randy
Re: classful routes redux
At 01:16 PM 3/11/2005, Christopher L. Morrow wrote: On Wed, 2 Nov 2005, Fred Baker wrote: actually, no, I could compare a /48 to a class A. (someone might already have asked this, but...) why /48? Because the thinking at the time appears to be that to ease' renumbering reduce the costs associated with address distribution functions (and associated network assessment tasks) and because there were heaps of addresses, all end-sites would get the same address allocation, and the uniform amount that was arrived at was a /48 . When asked whether this referred to _everything_ that may require subnets, the answer was yes. When asked whether this encompassed everything from a mobile phone to a large corporate the answer given was, once more, yes. Why /48 rather than /47 or /49? - alignment to nibble boundaries to make DNS delegation easier. Why /48 rather than /32 or /40? I really cannot say - I suspect that /48 is the largest end site number that meets the projected scope as described in RFC 3177. regards, Geoff
Re: classful routes redux
On Wed, 2 Nov 2005, [EMAIL PROTECTED] wrote: er.. would this be a poor characterization of the IPv6 addressing architecture which is encouraged by the IETF and the various RIR members? class A == /32 class B == /48 class C == /56 hostroute == /64 It's quite arbitrary though, unlike the old classful IPv4 divisions - a matter of policy, not technology. The allocation sizes can and do vary over both time (as policy changes, IIRC RIPE used to assign /35s iirc, now it's /32) and between different RIRs. A hostroute is /128 btw. ;) regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: QOTD: Every morning I read the obituaries; if my name's not there, I go to work.
