Re: FW: ISPs slowing P2P traffic...
On Mon, 14 Jan 2008 18:43:12 -0500 William Herrin [EMAIL PROTECTED] wrote: On Jan 14, 2008 5:25 PM, Joe Greco [EMAIL PROTECTED] wrote: So users who rarely use their connection are more profitable to the ISP. The fat man isn't a welcome sight to the owner of the AYCE buffet. Joe, The fat man is quite welcome at the buffet, especially if he brings friends and tips well. But the fat man isn't allowed to take up residence in the restaurant and continously eat - he's only allowed to be there in bursts, like we used to be able to assume people would use networks they're connected to. Left running P2P is the fat man never leaving and never stopping eating. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: FW: ISPs slowing P2P traffic...
On Tue, Jan 15, 2008, Mark Smith wrote: But the fat man isn't allowed to take up residence in the restaurant and continously eat - he's only allowed to be there in bursts, like we used to be able to assume people would use networks they're connected to. Left running P2P is the fat man never leaving and never stopping eating. ffs, stop with the crappy analogies. The internet is like a badly designed commodity network. Built increasingly cheaper to deal with market pressures and unable to shift quickly to shifting technologies. Just like the telcos I recall everyone blasting when I was last actually involved in networks bigger than a university campus. Adrian
Re: FW: ISPs slowing P2P traffic...
On 1/15/08, Adrian Chadd [EMAIL PROTECTED] wrote: ffs, stop with the crappy analogies. The internet is like a badly designed commodity network. Built increasingly cheaper to deal with market pressures and unable to shift quickly to shifting technologies. Just like the telcos I recall everyone blasting when I was last actually involved in networks bigger than a university campus. Adrian I think no matter what happens, it's going to be very interesting as Comcast rolls out DOCSIS 3.0 (with speeds around 100-150Mbps possible), Verizon FIOS expands it's offering (currently, you can get 50Mb/s down and 30Mb/sec up), etc. If things are really as fragile as some have been saying, then the bottlenecks will slowly make themselves apparent. -brandon
Re: FW: ISPs slowing P2P traffic...
On Tue, 15 Jan 2008, Brandon Galbraith wrote: I think no matter what happens, it's going to be very interesting as Comcast rolls out DOCSIS 3.0 (with speeds around 100-150Mbps possible), Verizon FIOS Well, according to wikipedia DOCSIS 3.0 gives 108 megabit/s upstream as opposed to 27 and 9 megabit/s for v2 and v1 respectively. That's not what I would call revolution as I still guess hundreds if not thousands of subscribers share those 108 megabit/s, right? Yes, fourfold increase but ... that's still only factor 4. expands it's offering (currently, you can get 50Mb/s down and 30Mb/sec up), etc. If things are really as fragile as some have been saying, then the bottlenecks will slowly make themselves apparent. Upstream capacity will still be scarce on shared media as far as I can see. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
ipflow/netflow appliance
Hi, thanks for all your answers it helped a lot, we will do a test with nProbe. Best Stefan -- Stefan Hegger Internet System Engineer Lycos Europe GmbH Carl-Bertelsmann Str. 29 Postfach 315 33312 Gütersloh Phone: Tel: +49 5241 8071 334 Fax: +49 5241 80671 334 Mobile: +49 170 1892720 Sitz der Gesellschaft: Gütersloh Amtsgericht Gütersloh, HRB 2157 Geschäftsführer: Christoph Mohn http://www.lycos-europe.com/L/A/
Re: FW: ISPs slowing P2P traffic...
On Tue, 15 Jan 2008 17:56:30 +0900 Adrian Chadd [EMAIL PROTECTED] wrote: On Tue, Jan 15, 2008, Mark Smith wrote: But the fat man isn't allowed to take up residence in the restaurant and continously eat - he's only allowed to be there in bursts, like we used to be able to assume people would use networks they're connected to. Left running P2P is the fat man never leaving and never stopping eating. ffs, stop with the crappy analogies. They're accurate. No network, including the POTS, or the road networks you drive your car on, are built to handle 100% concurrent use by all devices that can access it. Data networks (for many, many years) have been built on the assumption that the majority of attached devices will only occasionally use it. If you want to _guaranteed_ bandwidth to your house, 24x7, ask your telco for the actual pricing for guaranteed Mbps - and you'll find that the price per Mbps is around an order of magnitude higher than what your residential or SOHO broadband Mbps is priced at. That because for sustained load, the network costs are typically an order of magnitude higher. The internet is like a badly designed commodity network. Built increasingly cheaper to deal with market pressures and unable to shift quickly to shifting technologies. That's because an absolute and fundamental design assumption is changing - P2P changes the traffic profile from occasional bursty traffic to a constant load. I'd be happy to build a network that can sustain high throughput P2P from all attached devices concurrently - it isn't hard - but it's costly in bandwidth and equipment. I'm not against the idea of P2P a lot, because it distributes load for popular content around the network, rather than creating the slashdot effect. It's the customers that are the problem - they won't pay $1000 per/Mbit per month I'd need to be able to do it... TCP is partly to blame. It attempts to suck up as much bandwidth as available. That's great if you're attached to a network who's usage is bursty, because if the network is idle, you get to use all it's available capacity, and get the best network performance possible. However, if your TCP is competing with everybody else's TCP, and you're expecting idle network TCP performance - you'd better pony up money for more total network bandwidth, or lower your throughput expectations. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: Looking for geo-directional DNS service
At 12:14 AM 16-01-08 +1300, jamie baddeley wrote: Yes, but that would require them to run a DNS server at each of their 4 locations. They do not want to run their own DNS. They want it outsourced. Thanks, -Hank Thought about anycasting? Broad as a barn door, but if you add health checking of the services and integrate that into what your DC router announces you get closer to what you want. jamie On Tue, 2008-01-15 at 12:55 +0200, Hank Nussbacher wrote: I am looking for a commercial DNS service that provides geo-directionality. Suppose I have 4 data centers scattered thruout the world and want users to hit the closest data center based on proximity checks (pings, TTLs, latency, load, etc.). I know one can roll their own, using various geo-locational data from companies like Maxmind. I am *not* interested in that. I am *not* interested in applicances like the Cisco ACE GSS 4400 either (that do this as well): http://www.cisco.com/en/US/products/hw/contnetw/ps4162/ What I am looking for is a commercial DNS service. Is the Akamai Edgescape service the closest to what I want: http://www.akamai.com/html/technology/products/edgescape.html Is anyone using it? Can you recommend it? Another service I know about is the Ultradns (now Neustar) Directional DNS: http://www.neustarultraservices.biz/solutions/directionaldns.html But this service is based on statically defined IP responses at each of their 14 sites so there is no proximity checking done. Thanks, Hank
Looking for geo-directional DNS service
I am looking for a commercial DNS service that provides geo-directionality. Suppose I have 4 data centers scattered thruout the world and want users to hit the closest data center based on proximity checks (pings, TTLs, latency, load, etc.). I know one can roll their own, using various geo-locational data from companies like Maxmind. I am *not* interested in that. I am *not* interested in applicances like the Cisco ACE GSS 4400 either (that do this as well): http://www.cisco.com/en/US/products/hw/contnetw/ps4162/ What I am looking for is a commercial DNS service. Is the Akamai Edgescape service the closest to what I want: http://www.akamai.com/html/technology/products/edgescape.html Is anyone using it? Can you recommend it? Another service I know about is the Ultradns (now Neustar) Directional DNS: http://www.neustarultraservices.biz/solutions/directionaldns.html But this service is based on statically defined IP responses at each of their 14 sites so there is no proximity checking done. Thanks, Hank
Re: FW: ISPs slowing P2P traffic...
On Mon, 14 Jan 2008 18:43:12 -0500 William Herrin [EMAIL PROTECTED] wrote: On Jan 14, 2008 5:25 PM, Joe Greco [EMAIL PROTECTED] wrote: So users who rarely use their connection are more profitable to the ISP. The fat man isn't a welcome sight to the owner of the AYCE buffet. Joe, The fat man is quite welcome at the buffet, especially if he brings friends and tips well. But the fat man isn't allowed to take up residence in the restaurant and continously eat - he's only allowed to be there in bursts, like we used to be able to assume people would use networks they're connected to. Left running P2P is the fat man never leaving and never stopping eating. Time to stop selling the always on connections, then, I guess, because it is always on - not P2P - which is the fat man never leaving. P2P is merely the fat man eating a lot while he's there. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: FW: ISPs slowing P2P traffic...
Joe Greco wrote: Time to stop selling the always on connections, then, I guess, because it is always on - not P2P - which is the fat man never leaving. P2P is merely the fat man eating a lot while he's there. As long as we're keeping up this metaphor, P2P is the fat man who says he's gonna get a job real soon but dude life is just SO HARD and crashes on your couch for three weeks until eventually you threaten to get the cops involved because he won't leave. Then you have to clean up thirty-seven half-eaten bags of Cheetos. Every network has limitations, and I don't think I've ever seen a network that makes every single end-user happy with everything all the time. You could pipe 100Mbps full-duplex to everyone's door, and someone would still complain because they don't have gigabit access to lemonparty. Whether those are limitations of the technology you chose, limitations in your budget, policy restrictions, whatever. As long as you fairly disclose to your end-users what limitations and restrictions exist on your network, I don't see the problem. David Smith MVN.net
Re: BGP Filtering
On Tue, Jan 15, 2008 at 04:11:36PM -, Ben Butler wrote: As a transit consumer - why would I want to carry all this cr*p in my routing table, I would still be getting a BGP route to the larger prefix anyway - let my transit feeds sort out which route they use traffic engineering. Well, you could always just take Customer routes from each of your providers (since you're running BGP I presume you're actually multihomed and not adding to the pollution) and point default at one/both providers for the other networks (or take default from one or both of them). - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
BGP Filtering
Hi, Considering: http://thyme.apnic.net Total number of prefixes smaller than registry allocations: 113220 ! /20:17046 /21:16106 /22:20178 /23:21229 /24:126450 That is saying to me that a significant number of these smaller prefixes are due to de-aggregation of PA and not PI announcements. My question is - how can I construct a filter / route map that will filter out any more specific prefixes where a less specific one exists in the BGP table. If my above conclusion is correct a significant portion ~47% of the number of the prefixes in the table could be argued to be very unnecessary at one level or another. Is such a filter possible easily or would it have to be explicitly declared, any chance of a process the automatically tracks and publishes a list of offending specifics similar to Team Cymru's Bogon BGP feed. As a transit consumer - why would I want to carry all this cr*p in my routing table, I would still be getting a BGP route to the larger prefix anyway - let my transit feeds sort out which route they use traffic engineering. Thoughts anyone? Kind Regards Ben
RE: BGP Filtering
Hi, Default wont work - I do care about my transit providers network becoming partitioned or IXPs having problems or fiber cuts etc etc So I need my router to see all the reachability of a prefix in BGP so that my router knows which transit to send it to. Defaults wont work because a routing decision has to be made, my transit originating a default or me pointing a default at them does not guarantee the reachability of all prefixes.. But if I can see the /19 in the table, do I care about a load of /24s because the whole of the /19 should be reachable as the origin AS is announcing it somewhere in their network and it is being received my a transit so should be reachable. Ok, I can dream up a few emergencies where it might be helpful to pin a /24 as well as the /19 - but I am sure there aren't 100K+ emergencies happening continuously in the route table and it is on the whole general whatever because there is no incentive to stop de-aggregating once you have started. If they are only announcing the de-aggregated /24s and no summary /19 then my question doesn't apply as I only want to drop the more specifics where a less specific exists. I am struggling to see a defensible position for why just shy of 50% of all routes appears to be mostly comprised of de-aggregated routes when aggregation is one of the aims RIRs make the LIRs strive to achieve. If we cant clean the mess up because there is no incentive than cant I simply ignore the duplicates. Regards Ben -Original Message- From: Jared Mauch [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 16:19 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering On Tue, Jan 15, 2008 at 04:11:36PM -, Ben Butler wrote: As a transit consumer - why would I want to carry all this cr*p in my routing table, I would still be getting a BGP route to the larger prefix anyway - let my transit feeds sort out which route they use traffic engineering. Well, you could always just take Customer routes from each of your providers (since you're running BGP I presume you're actually multihomed and not adding to the pollution) and point default at one/both providers for the other networks (or take default from one or both of them). - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: BGP Filtering
Hi Jason, Fantastic news, it is possible. We are using Cisco - would you be so kind as to give me a clue into which bit of Cisco's website you would like me to read as I have already read the bits I suspected might tell me how to do this but have guessed wrong / the documentation hasn't helped - so a handy pointer would be appreciated. Kind Regards Ben -Original Message- From: Jason Dearborn [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 16:35 To: Ben Butler Subject: Re: BGP Filtering That's typically a function of your router software. Juniper, Force10, and Cisco all have support for this. Check your manual. On Jan 15, 2008 8:11 AM, Ben Butler [EMAIL PROTECTED] wrote: Hi, Considering: http://thyme.apnic.net Total number of prefixes smaller than registry allocations: 113220 ! /20:17046 /21:16106 /22:20178 /23:21229 /24:126450 That is saying to me that a significant number of these smaller prefixes are due to de-aggregation of PA and not PI announcements. My question is - how can I construct a filter / route map that will filter out any more specific prefixes where a less specific one exists in the BGP table. If my above conclusion is correct a significant portion ~47% of the number of the prefixes in the table could be argued to be very unnecessary at one level or another. Is such a filter possible easily or would it have to be explicitly declared, any chance of a process the automatically tracks and publishes a list of offending specifics similar to Team Cymru's Bogon BGP feed. As a transit consumer - why would I want to carry all this cr*p in my routing table, I would still be getting a BGP route to the larger prefix anyway - let my transit feeds sort out which route they use traffic engineering. Thoughts anyone? Kind Regards Ben
Level 3 (3356) issues?
Just curious if anyone is seeing issues with Level 3 right now? Our session is still up but we can't see any outside routes through them currently. I'm guessing by the fact that I've been on hold for 25 minutes that I'm not the only one having an issue with them but wanted to double check. Thanks, David
RE: BGP Filtering
Ben, Look here. They show an example of prefix filtering on the 128.0.0.0/8 network. I would assume you could extrapolate and come up with your own rule. http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cbgp.h tml#wp7487 Mike Walter, MCP Systems Administrator 3z.net a PCD Company http://www.3z.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Butler Sent: Tuesday, January 15, 2008 11:45 AM To: nanog@merit.edu Subject: RE: BGP Filtering Hi Jason, Fantastic news, it is possible. We are using Cisco - would you be so kind as to give me a clue into which bit of Cisco's website you would like me to read as I have already read the bits I suspected might tell me how to do this but have guessed wrong / the documentation hasn't helped - so a handy pointer would be appreciated. Kind Regards Ben -Original Message- From: Jason Dearborn [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 16:35 To: Ben Butler Subject: Re: BGP Filtering That's typically a function of your router software. Juniper, Force10, and Cisco all have support for this. Check your manual. On Jan 15, 2008 8:11 AM, Ben Butler [EMAIL PROTECTED] wrote: Hi, Considering: http://thyme.apnic.net Total number of prefixes smaller than registry allocations: 113220 ! /20:17046 /21:16106 /22:20178 /23:21229 /24:126450 That is saying to me that a significant number of these smaller prefixes are due to de-aggregation of PA and not PI announcements. My question is - how can I construct a filter / route map that will filter out any more specific prefixes where a less specific one exists in the BGP table. If my above conclusion is correct a significant portion ~47% of the number of the prefixes in the table could be argued to be very unnecessary at one level or another. Is such a filter possible easily or would it have to be explicitly declared, any chance of a process the automatically tracks and publishes a list of offending specifics similar to Team Cymru's Bogon BGP feed. As a transit consumer - why would I want to carry all this cr*p in my routing table, I would still be getting a BGP route to the larger prefix anyway - let my transit feeds sort out which route they use traffic engineering. Thoughts anyone? Kind Regards Ben
RE: Level 3 (3356) issues?
No issues here full feed coming in and no issues getting out (that have been noticed so far) 2 so-8-0.hsa1.Detroit1.Level3.net (166.90.248.1) [AS 3356] 12 msec 8 msec 12 msec 3 so-4-3-0.mp1.Detroit1.Level3.net (4.68.115.1) [AS 3356] 12 msec 12 msec 8 msec 4 as-4-0.bbr2.NewYork1.Level3.net (64.159.0.238) [AS 3356] 36 msec ae-0-0.bbr1.NewYork1.Level3.net (64.159.1.41) [AS 3356] 40 msec 36 msec 5 ae-4-99.edge6.NewYork1.Level3.net (4.68.16.202) [AS 3356] 36 msec ae-3-89.edge6.NewYork1.Level3.net (4.68.16.138) [AS 3356] 36 msec ae-1-69.edge6.NewYork1.Level3.net (4.68.16.10) [AS 3356] 36 msec 6 pop2-nye-P5-0.atdn.net (66.185.137.209) [AS 1668] 40 msec 40 msec 36 msec 7 bb1-nye-P1-0.atdn.net (66.185.151.64) [AS 1668] 40 msec 36 msec 40 msec 8 bb2-ash-P13-0.atdn.net (66.185.152.87) [AS 1668] 36 msec 36 msec 40 msec 9 pop1-ash-S1-1-0.atdn.net (66.185.144.35) [AS 1668] 40 msec 36 msec 36 msec 10 dar1-mtc-S0-0-0.atdn.net (66.185.148.222) [AS 1668] 40 msec dar1-mtc-S1-2-0.atdn.net (66.185.152.105) [AS 1668] 40 msec 40 msec Take care, Paul Stewart Senior Network Administrator Nexicom 5 King St. E., Millbrook, ON, LOA 1GO Phone: 705-932-4127 Web: http://www.nexicom.net Nexicom - Connected. Naturally. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Hubbard Sent: Tuesday, January 15, 2008 11:45 AM To: nanog@merit.edu Subject: Level 3 (3356) issues? Just curious if anyone is seeing issues with Level 3 right now? Our session is still up but we can't see any outside routes through them currently. I'm guessing by the fact that I've been on hold for 25 minutes that I'm not the only one having an issue with them but wanted to double check. Thanks, David The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
Re: Level 3 (3356) issues?
Our DS3 here in Cupertino, Ca seems to be working flawless -Mike On Jan 15, 2008 8:44 AM, David Hubbard [EMAIL PROTECTED] wrote: Just curious if anyone is seeing issues with Level 3 right now? Our session is still up but we can't see any outside routes through them currently. I'm guessing by the fact that I've been on hold for 25 minutes that I'm not the only one having an issue with them but wanted to double check. Thanks, David
Re: BGP Filtering
On 15-Jan-2008, at 11:40, Ben Butler wrote: Defaults wont work because a routing decision has to be made, my transit originating a default or me pointing a default at them does not guarantee the reachability of all prefixes.. Taking a table that won't fit in RAM similarly won't guarantee reachability of anything :-) Filter on assignment boundaries and supplement with a default. That ought to mean that you have a reasonable shot at surviving de-peering/ partitioning events, and the defaults will pick up the slack in the event that you don't. For extra credit, supplement with a bunch of null routes for bogons so packets with bogon destination addresses don't leave your network, and maybe make exceptions for golden prefixes. I am struggling to see a defensible position for why just shy of 50% of all routes appears to be mostly comprised of de-aggregated routes when aggregation is one of the aims RIRs make the LIRs strive to achieve. If we cant clean the mess up because there is no incentive than cant I simply ignore the duplicates. You can search the archives I'm sure for more detailed discussion of this. However, you can't necessarily always attribute the presence of covered prefixes to incompetence. Joe
Re: Looking for geo-directional DNS service
On Tue, 15 Jan 2008, Hank Nussbacher wrote: The Ultradns (now Neustar) Directional DNS service is based on statically defined IP responses at each of their 14 sites so there is no proximity checking done. Yes, and that's how anycast works: it directs traffic to the _topologically nearest_ server. So as long as there's a DNS server topologically near your data server, your users will get the topologically nearest of your servers. Which is why so many content folks _do_ roll their own: to ensure fate-sharing between the DNS traffic which effectively selects the data server, and the eventual data traffic. If you're doing things on the Internet, instead of the physical world, topological distance is presumably of much greater interest than whatever geographic proximity may coincidentally obtain. -Bill
RE: BGP Filtering
Hi, I might be being slow, or you might not understand my question - I am not sure it has been a long day. I want a filter that will automatically match the shorter prefixes that match any longer prefix, once I can match them I can drop them. I don't want to manually configure a static prefix list for lots and lots and lots of reasons. If the longer prefix disappears from the route table I want to stop filtering the shorter prefixes - automatically. -Original Message- From: Mike Walter [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 16:52 To: Ben Butler; nanog@merit.edu Subject: RE: BGP Filtering Ben, Look here. They show an example of prefix filtering on the 128.0.0.0/8 network. I would assume you could extrapolate and come up with your own rule. http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cbgp.h tml#wp7487 Mike Walter, MCP Systems Administrator 3z.net a PCD Company http://www.3z.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Butler Sent: Tuesday, January 15, 2008 11:45 AM To: nanog@merit.edu Subject: RE: BGP Filtering Hi Jason, Fantastic news, it is possible. We are using Cisco - would you be so kind as to give me a clue into which bit of Cisco's website you would like me to read as I have already read the bits I suspected might tell me how to do this but have guessed wrong / the documentation hasn't helped - so a handy pointer would be appreciated. Kind Regards Ben -Original Message- From: Jason Dearborn [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 16:35 To: Ben Butler Subject: Re: BGP Filtering That's typically a function of your router software. Juniper, Force10, and Cisco all have support for this. Check your manual. On Jan 15, 2008 8:11 AM, Ben Butler [EMAIL PROTECTED] wrote: Hi, Considering: http://thyme.apnic.net Total number of prefixes smaller than registry allocations: 113220 ! /20:17046 /21:16106 /22:20178 /23:21229 /24:126450 That is saying to me that a significant number of these smaller prefixes are due to de-aggregation of PA and not PI announcements. My question is - how can I construct a filter / route map that will filter out any more specific prefixes where a less specific one exists in the BGP table. If my above conclusion is correct a significant portion ~47% of the number of the prefixes in the table could be argued to be very unnecessary at one level or another. Is such a filter possible easily or would it have to be explicitly declared, any chance of a process the automatically tracks and publishes a list of offending specifics similar to Team Cymru's Bogon BGP feed. As a transit consumer - why would I want to carry all this cr*p in my routing table, I would still be getting a BGP route to the larger prefix anyway - let my transit feeds sort out which route they use traffic engineering. Thoughts anyone? Kind Regards Ben
RE: FW: ISPs slowing P2P traffic...
As long as we're keeping up this metaphor, P2P is the fat man who says Guys, according to wikipedia over 70 million people fileshare http://en.wikipedia.org/wiki/Ethics_of_file_sharing That's not the fat man, that's a significant portion of the market. Demand is changing, meet the new needs or die at the hands of your customers. It's not like you have a choice. The equipment makers need to recognize that it's no longer a one size fits all world (where download is the most critical) but instead that the hardware needs to adjust the available bandwidth to accomodate the direction data is flowing at that particular moment. Hopefully some of them monitor this list and are getting ideas for the next generation of equipment. George Roettger Netlink Services
RE: BGP Filtering
Hi, Agreed that is why I have lots of RAM - doesn't mean I should carry on upgrading my tower of babble though to make it ever higher and higher if there is a better way of doing things. I still don't see how a default route to a portioned pop is going to help in the slightest - you are saved by getting the prefixes from an alternate transit and the default doesn't get used. Where is does help is to capture anything which has been filtered out completely and then there is no prefix from the alternate transit provider anyway - so whichever default gets used and takes its chances. Bogons - obviously. My question was if what I was asking was possible. Kind Regards Ben -Original Message- From: Joe Abley [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 17:07 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering On 15-Jan-2008, at 11:40, Ben Butler wrote: Defaults wont work because a routing decision has to be made, my transit originating a default or me pointing a default at them does not guarantee the reachability of all prefixes.. Taking a table that won't fit in RAM similarly won't guarantee reachability of anything :-) Filter on assignment boundaries and supplement with a default. That ought to mean that you have a reasonable shot at surviving de-peering/ partitioning events, and the defaults will pick up the slack in the event that you don't. For extra credit, supplement with a bunch of null routes for bogons so packets with bogon destination addresses don't leave your network, and maybe make exceptions for golden prefixes. I am struggling to see a defensible position for why just shy of 50% of all routes appears to be mostly comprised of de-aggregated routes when aggregation is one of the aims RIRs make the LIRs strive to achieve. If we cant clean the mess up because there is no incentive than cant I simply ignore the duplicates. You can search the archives I'm sure for more detailed discussion of this. However, you can't necessarily always attribute the presence of covered prefixes to incompetence. Joe
RE: Level 3 (3356) issues?
Looks like this was localized to Tampa. I've received emails from two other people connected through Tampa, like us, who were having the same issues. I finally got TCAM on the phone after about an hour. They have a master ticket for a failure of three DLM modules lasting 47 minutes but it is showing believed to be resolved via reset but they have not yet diagnosed the cause. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Hubbard Sent: Tuesday, January 15, 2008 11:45 AM To: nanog@merit.edu Subject: Level 3 (3356) issues? Just curious if anyone is seeing issues with Level 3 right now? Our session is still up but we can't see any outside routes through them currently. I'm guessing by the fact that I've been on hold for 25 minutes that I'm not the only one having an issue with them but wanted to double check. Thanks, David
Re: Looking for geo-directional DNS service
On Jan 15, 2008, at 12:00 PM, Bill Woodcock wrote: On Tue, 15 Jan 2008, Hank Nussbacher wrote: The Ultradns (now Neustar) Directional DNS service is based on statically defined IP responses at each of their 14 sites so there is no proximity checking done. Yes, and that's how anycast works: it directs traffic to the _topologically nearest_ server. So as long as there's a DNS server topologically near your data server, your users will get the topologically nearest of your servers. Which is why so many content folks _do_ roll their own: to ensure fate-sharing between the DNS traffic which effectively selects the data server, and the eventual data traffic. If you're doing things on the Internet, instead of the physical world, topological distance is presumably of much greater interest than whatever geographic proximity may coincidentally obtain. Except Hank is asking for true topological distance (latency / throughput / packetloss). Anycast gives you BGP distance, not topological distance. Say I'm in Ashburn and peer directly with someone in Korea where he has a node (1 AS hop), but I get to his node in Ashburn through my transit provider (2 AS hops), guess which node anycast will pick? -- TTFN, patrick
Re: BGP Filtering
Ben, I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. You'd drop traffic, unless you had a default, in which case you'd just route it suboptimally. -Dave Ben Butler wrote: Hi, Agreed that is why I have lots of RAM - doesn't mean I should carry on upgrading my tower of babble though to make it ever higher and higher if there is a better way of doing things. I still don't see how a default route to a portioned pop is going to help in the slightest - you are saved by getting the prefixes from an alternate transit and the default doesn't get used. Where is does help is to capture anything which has been filtered out completely and then there is no prefix from the alternate transit provider anyway - so whichever default gets used and takes its chances. Bogons - obviously. My question was if what I was asking was possible. Kind Regards Ben -Original Message- From: Joe Abley [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 17:07 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering On 15-Jan-2008, at 11:40, Ben Butler wrote: Defaults wont work because a routing decision has to be made, my transit originating a default or me pointing a default at them does not guarantee the reachability of all prefixes.. Taking a table that won't fit in RAM similarly won't guarantee reachability of anything :-) Filter on assignment boundaries and supplement with a default. That ought to mean that you have a reasonable shot at surviving de-peering/ partitioning events, and the defaults will pick up the slack in the event that you don't. For extra credit, supplement with a bunch of null routes for bogons so packets with bogon destination addresses don't leave your network, and maybe make exceptions for golden prefixes. I am struggling to see a defensible position for why just shy of 50% of all routes appears to be mostly comprised of de-aggregated routes when aggregation is one of the aims RIRs make the LIRs strive to achieve. If we cant clean the mess up because there is no incentive than cant I simply ignore the duplicates. You can search the archives I'm sure for more detailed discussion of this. However, you can't necessarily always attribute the presence of covered prefixes to incompetence. Joe
Re: FW: ISPs slowing P2P traffic...
Joe Greco wrote:
Time to stop selling the always on connections, then, I guess, because
it is always on - not P2P - which is the fat man never leaving. P2P
is merely the fat man eating a lot while he's there.
As long as we're keeping up this metaphor, P2P is the fat man who says
he's gonna get a job real soon but dude life is just SO HARD and crashes
on your couch for three weeks until eventually you threaten to get the
cops involved because he won't leave. Then you have to clean up
thirty-seven half-eaten bags of Cheetos.
I have no idea what the networking equivalent of thirty-seven half-eaten
bags of Cheetos is, can't even begin to imagine what the virtual equivalent
of my couch is, etc. Your metaphor doesn't really make any sense to me,
sorry.
Interestingly enough, we do have a pizza-and-play place a mile or two
from the house, you pay one fee to get in, then quarters (or cards or
whatever) to play games - but they have repeatedly answered that they
are absolutely and positively fine with you coming in for lunch, and
staying through supper. And we have a discount card, which they used
to give out to local businesspeople for business lunches, on top of it.
Every network has limitations, and I don't think I've ever seen a
network that makes every single end-user happy with everything all the
time. You could pipe 100Mbps full-duplex to everyone's door, and someone
would still complain because they don't have gigabit access to lemonparty.
Certainly. There will be gigabit in the future, but it isn't here (in
the US) just yet. That has very little to do with the deceptiveness
inherent in selling something when you don't intend to actually provide
what you advertised.
Whether those are limitations of the technology you chose, limitations
in your budget, policy restrictions, whatever.
As long as you fairly disclose to your end-users what limitations and
restrictions exist on your network, I don't see the problem.
You've set out a qualification that generally doesn't exist. For example,
this discussion included someone from a WISP, Amplex, I believe, that
listed certain conditions of use on their web site, and yet it seems like
they're un{willing,able} (not assigning blame/fault/etc here) to deliver
that level of service, and using their inability as a way to justify
possibly rate shaping P2P traffic above and beyond what they indicate on
their own documents.
In some cases, we do have people burying TC in lengthy TC documents,
such as some of the 3G cellular providers who advertise Unlimited
Internet(*) data cards, but then have a slew of (*) items that are
restricted - but only if you dig into the fine print on Page 3 of the
TC. I'd much prefer that the advertising be honest and up front, and
that ISP's not be allowed to advertise unlimited service if they are
going to place limits, particularly significant limits, on the service.
... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.
Re: Level 3 (3356) issues?
I know of Level 3 issues in the Tampa area. Where are you? -Scott - Original Message - From: David Hubbard [EMAIL PROTECTED] To: nanog@merit.edu Sent: Tuesday, January 15, 2008 11:44:31 AM (GMT-0500) America/New_York Subject: Level 3 (3356) issues? Just curious if anyone is seeing issues with Level 3 right now? Our session is still up but we can't see any outside routes through them currently. I'm guessing by the fact that I've been on hold for 25 minutes that I'm not the only one having an issue with them but wanted to double check. Thanks, David
RE: NANOG website unreachable?
I see the site, not the error. --Patrick Darden -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Daniele Arena Sent: Tuesday, January 15, 2008 12:48 PM To: nanog@merit.edu Subject: NANOG website unreachable? Hi, Am I the only one to get a 403 on http://www.nanog.org/ ? Regards, Daniele.
RE: BGP Filtering
Hi Dave, Yes that is what I was thinking I want to do - so I am guessing here - I think what we are saying is the /17s never get re-added when the /16 is withdrawn because this does not - for very good reasons when I think about it- cause the filter to be evaluated upon the withdrawal of a prefix, only on when it is newly announced does it get checked - or maybe the odd table scan in the code?? But basically the /17s just sit there and continue to be filtered. Is that approximately correct? so umm, yes a default would be needed, ummm. Is it even technically possible to easily achieve though? Ben From: Dave Israel [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 17:51 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering Ben, I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. You'd drop traffic, unless you had a default, in which case you'd just route it suboptimally. -Dave Ben Butler wrote: Hi, Agreed that is why I have lots of RAM - doesn't mean I should carry on upgrading my tower of babble though to make it ever higher and higher if there is a better way of doing things. I still don't see how a default route to a portioned pop is going to help in the slightest - you are saved by getting the prefixes from an alternate transit and the default doesn't get used. Where is does help is to capture anything which has been filtered out completely and then there is no prefix from the alternate transit provider anyway - so whichever default gets used and takes its chances. Bogons - obviously. My question was if what I was asking was possible. Kind Regards Ben -Original Message- From: Joe Abley [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 17:07 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering On 15-Jan-2008, at 11:40, Ben Butler wrote: Defaults wont work because a routing decision has to be made, my transit originating a default or me pointing a default at them does not guarantee the reachability of all prefixes.. Taking a table that won't fit in RAM similarly won't guarantee reachability of anything :-) Filter on assignment boundaries and supplement with a default. That ought to mean that you have a reasonable shot at surviving de-peering/ partitioning events, and the defaults will pick up the slack in the event that you don't. For extra credit, supplement with a bunch of null routes for bogons so packets with bogon destination addresses don't leave your network, and maybe make exceptions for golden prefixes. I am struggling to see a defensible position for why just shy of 50% of all routes appears to be mostly comprised of de-aggregated routes when aggregation is one of the aims RIRs make the LIRs strive to achieve. If we cant clean the mess up because there is no incentive than cant I simply ignore the duplicates. You can search the archives I'm sure for more detailed discussion of this. However, you can't necessarily always attribute the presence of covered prefixes to incompetence. Joe
Re: FW: ISPs slowing P2P traffic...
Joe Greco wrote: I have no idea what the networking equivalent of thirty-seven half-eaten bags of Cheetos is, can't even begin to imagine what the virtual equivalent of my couch is, etc. Your metaphor doesn't really make any sense to me, sorry. There isn't one. The fat man metaphor was getting increasingly silly, I just wanted to get it over with. Interestingly enough, we do have a pizza-and-play place a mile or two from the house, you pay one fee to get in, then quarters (or cards or whatever) to play games - but they have repeatedly answered that they are absolutely and positively fine with you coming in for lunch, and staying through supper. And we have a discount card, which they used to give out to local businesspeople for business lunches, on top of it. That's not the best metaphor either, because they're making money off the games, not the buffet. (Seriously, visit one of 'em, the food isn't very good, and clearly isn't the real draw.) I suppose you could market Internet connectivity this way - unlimited access to HTTP and POP3, and ten free SMTP transactions per month, then you pay extra for each protocol. That'd be an awfully tough sell, though. As long as you fairly disclose to your end-users what limitations and restrictions exist on your network, I don't see the problem. You've set out a qualification that generally doesn't exist. I can only speak for my network, of course. Mine is a small WISP, and we have the same basic policy as Amplex, from whence this thread originated. Our contracts have relatively clear and large (at least by the standards of a contract) no p2p disclaimers, in addition to the standard no traffic that causes network problems clause that many of us have. The installers are trained to explicitly mention this, along with other no-brainer clauses like don't spam. When we're setting up software on their computers (like their email client), we'll look for obvious signs of trouble ahead. If a customer already has a bunch of p2p software installed, we'll let them know they can't use it, under pain of find a new ISP. We don't tell our customers they can have unlimited access to do whatever the heck they want. The technical distinctions only matter to a few customers, and they're generally the problem customers that we don't want anyway. To try to make this slightly more relevant, is it a good idea, either technically or legally, to mandate some sort of standard for this? I'm thinking something like the Nutrition Facts information that appears on most packaged foods in the States, that ISPs put on their Web sites and advertisements. I'm willing to disclose that we block certain ports for our end-users unless they request otherwise, and that we rate-limit certain types of traffic. I can see this sort of thing getting confusing and messy for everyone, with little or no benefit to anyone. Thoughts? David Smith MVN.net
Re: houston.rr.com MX fubar?
I see roadrunner listens. frodo:~ dig +short houston.rr.com mx 0 . frodo:~ dig +short houston.rr.com txt v=spf1 -all --srs On Jan 13, 2008 8:55 AM, Suresh Ramasubramanian [EMAIL PROTECTED] wrote: A bunch of roadrunner subdomains migrated over to comcast and those are dud. One operationally better way to go seems to be Mark Delany's mx0dot proposal, which started out as an internet draft, but seems to have lost momentum .. the concept is sound though. http://ietfreport.isoc.org/idref/draft-delany-nullmx That'd mean houstonIN MX 0 . --srs On Jan 13, 2008 8:32 AM, Chris Boyd [EMAIL PROTECTED] wrote: We're bouncing email to houston.rr.com due to the MX being set to localhost. [EMAIL PROTECTED]:~$ host -t mx houston.rr.com houston.rr.com mail is handled by 10 localhost. Setting the MX to 127.0.0.1 seems like an odd way to handle the switch. http://www.chron.com/disp/story.mpl/business/silverman/4842611.html -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: BGP Filtering
The /17 isn't sitting there still being filtered; it was never there to begin with. Your router heard the /17, saw that it didn't want it because of your filter settings, and promptly forgot it. You can tell your router to remember routes it doesn't install; it's called soft reconfiguration on a Cisco and is the normal mode of operation for a Juniper. But if you do that, you're not saving memory; an inactive route does not take less RAM than an active one. I am pretty sure that there isn't a way to match a route on whether a larger aggregate exists using the current route map/policy statement verbage on the routers I have worked with. Doing so would be a reasonably simple code tweak, but without a purpose it isn't a tweak you're going to see any time soon. -Dave Ben Butler wrote: Hi Dave, Yes that is what I was thinking I want to do - so I am guessing here - I think what we are saying is the /17s never get re-added when the /16 is withdrawn because this does not - for very good reasons when I think about it- cause the filter to be evaluated upon the withdrawal of a prefix, only on when it is newly announced does it get checked - or maybe the odd table scan in the code?? But basically the /17s just sit there and continue to be filtered. Is that approximately correct? so umm, yes a default would be needed, ummm. Is it even technically possible to easily achieve though? Ben *From:* Dave Israel [mailto:[EMAIL PROTECTED] *Sent:* 15 January 2008 17:51 *To:* Ben Butler *Cc:* nanog@merit.edu *Subject:* Re: BGP Filtering Ben, I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. You'd drop traffic, unless you had a default, in which case you'd just route it suboptimally. -Dave Ben Butler wrote: Hi, Agreed that is why I have lots of RAM - doesn't mean I should carry on upgrading my tower of babble though to make it ever higher and higher if there is a better way of doing things. I still don't see how a default route to a portioned pop is going to help in the slightest - you are saved by getting the prefixes from an alternate transit and the default doesn't get used. Where is does help is to capture anything which has been filtered out completely and then there is no prefix from the alternate transit provider anyway - so whichever default gets used and takes its chances. Bogons - obviously. My question was if what I was asking was possible. Kind Regards Ben -Original Message- From: Joe Abley [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 17:07 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering On 15-Jan-2008, at 11:40, Ben Butler wrote: Defaults wont work because a routing decision has to be made, my transit originating a default or me pointing a default at them does not guarantee the reachability of all prefixes.. Taking a table that won't fit in RAM similarly won't guarantee reachability of anything :-) Filter on assignment boundaries and supplement with a default. That ought to mean that you have a reasonable shot at surviving de-peering/ partitioning events, and the defaults will pick up the slack in the event that you don't. For extra credit, supplement with a bunch of null routes for bogons so packets with bogon destination addresses don't leave your network, and maybe make exceptions for golden prefixes. I am struggling to see a defensible position for why just shy of 50% of all routes appears to be mostly comprised of de-aggregated routes when aggregation is one of the aims RIRs make the LIRs strive to achieve. If we cant clean the mess up because there is no incentive than cant I simply ignore the duplicates. You can search the archives I'm sure for more detailed discussion of this. However, you can't necessarily always attribute the presence of covered prefixes to incompetence. Joe
Off Topic
At the risk of incurring Mr. Pilosoft's wrath (the Putin of NANOG?), I'll looking for NANOG style ISP meetings to attend in Europe this year (France, Germany, UK, Belgium, and Netherlands). Any suggestions would be appreciated. Please bypass the list and send them directly to me. Roderick S. Beck Director of European Sales Hibernia Atlantic 1, Passage du Chantier, 75012 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. Landline: 33-1-4346-3209. French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth [EMAIL PROTECTED] [EMAIL PROTECTED] ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein.
Re: houston.rr.com MX fubar?
On Tue, 15 Jan 2008, Mark Andrews wrote: Since there is no [MX] fallback to Wrong. http://www1.ietf.org/mail-archive/web/ietf/current/msg49841.html Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FISHER GERMAN BIGHT: SOUTHERLY BECOMING CYCLONIC THEN WESTERLY 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 IN GERMAN BIGHT, DECREASING 6 TO GALE 8 LATER. ROUGH OR VERY ROUGH. RAIN. MODERATE.
Re: houston.rr.com MX fubar?
On Tue, 15 Jan 2008, Randy Bush wrote: Fallback to A should be removed sure sounds like a plan. great idea. it will only break mail to 42% of the internet. Randy's right, though it's email *from* 42% of the Internet that's the biggest problem. [rant about email from shitty php web forms elided] Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ SOUTHEAST ICELAND: NORTHEASTERLY VEERING SOUTHERLY 5 TO 7, PERHAPS GALE 8 LATER. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH LATER. WINTRY SHOWERS THEN RAIN. MODERATE OR GOOD.
Re: Looking for geo-directional DNS service
Except Hank is asking for true topological distance (latency / throughput / packetloss). Anycast gives you BGP distance, not topological distance. Say I'm in Ashburn and peer directly with someone in Korea where he has a node (1 AS hop), but I get to his node in Ashburn through my transit provider (2 AS hops), guess which node anycast will pick? Ashburn and other major network meet points are oddities in a very complex network. It would be fair to note that anycast is likely to be reasonably effective if deployed in a manner that was mindful of the overall Internet architecture, and made allowances for such things. Anycast by itself probably isn't entirely desirable in any case, and could ideally be paired up with other technologies to fix problems like this. I haven't seen many easy ways to roll-your-own geo-DNS service. The ones I've done in the past simply built in knowledge of the networks in question, and where such information wasn't available, took best guess and then may have done a little research after the fact for future queries. This isn't as comprehensive as doing actual latency / throughput / pl checking. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: BGP Filtering
On Jan 15, 2008 12:51 PM, Dave Israel [EMAIL PROTECTED] wrote: I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. Dave, That's half-true. The routing table is comprised of two components: the Routing Information Base (RIB) and the Forwarding Information Base (FIB). The RIB sits in slow, cheap memory and contains routes and metrics for every route as announced by every neighbor. The FIB sits in fast, expensive memory and contains the currently best route for each destination. The FIB is built by choosing the best routes from the RIB. Packet-forwarding decisions are made by consulting the FIB. Opportunistically filtering routes from the RIB would have exactly the problem you point out: routing updates are incremental. The knowledge that the /16 has been withdrawn may not accompany the knowledge that the /17s are available. Opportunistically filtering more-specific routes from the FIB, however, could be very valuable at the edge of the DFZ. If Cisco supported such filtering, those Sup2's could have another few years of life left in them. With 512m ram in a two-transit provider scenario a Sup2 could handle upwards of 1M routes in the RIB. Unfortunately, they can only handle 244k routes in the FIB. Ben, coming back to your question: I don't think there is a way to make the software filter the routes inserted into the FIB. I don't see a reason why it couldn't be programmed to do that. But the fine folks at Cisco didn't see fit to write that software. Its a pity 'cause it would be very useful. The next best thing you can do is statically filter /8's from distant regions. You're posting to NANOG, so I assume that the RIPE and APNIC regions are distant for you. Go to IANA's web site and download the list of /8's assigned exclusively to each of those registries. For each, create a set of /8 static routes towards each of your transit providers with a route target address picked from an address block that will disappear or become distant if your link to that transit provider is severed. Then use prefix lists to filter more specific routes within those /8's. That should give you a result that's almost as good as if you carried all the routes while cutting a bunch of routes from your table. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: FW: ISPs slowing P2P traffic...
This is amazing. People are discovering oversubscription. When we put the very first six 2400bps modems for the public on the internet in 1989 and someone shortly thereafter got a busy signal and called support the issue was oversubscription. What? You mean you don't have one modem and phone line for each customer??? Shortly thereafter the fuss was dial-up ISPs selling unlimited dial-up accounts for $20/mo and then knocking people off if they were idle to accomodate oversubscription. But as busy signals mounted it wasn't just idle, it was on too long or unlimited means 200 hours per month until attornies-general began weighing in. And here it is over 18 years later and people are still debating oversubscription. Not what to do about it, that's fine, but seem to be discovering oversubscription de novo. Wow. It reminds me of back when I taught college and I'd start my first Sept lecture with a puzzled look at the audience and didn't I explain all this *last* year? But at least they'd laugh. Hint: You're not getting a dedicated megabit between chicago and johannesburg for $20/month. Get over it. HOWEVER, debating how to deal with the policies to accomodate oversubscription is reasonable (tho perhaps not on this list) because that's a moving target. But here we are a week later on this thread (not to mention nearly 20 years) and people are still explaining oversubscription to each other? Did I accidentally stumble into Special Nanog? -- -Barry Shein The World | [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: BGP Filtering
William Herrin wrote: On Jan 15, 2008 12:51 PM, Dave Israel [EMAIL PROTECTED] wrote: I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. Dave, That's half-true. [discussion of FIB vs RIB deleted] But, as you said yourself: Ben, coming back to your question: I don't think there is a way to make the software filter the routes inserted into the FIB. I don't see a reason why it couldn't be programmed to do that. But the fine folks at Cisco didn't see fit to write that software. Its a pity 'cause it would be very useful. Ergo, why I didn't discuss the FIB in my email. If you want to filter routes, you generally have to filter them at the RIB. How you move data from the RIB to the FIB is one of those questions that keep router engineers up all night. The transfer must be fast, reliable, and cheap on the CPU. Often, this means keeping logic out of it. A paradigm is decided upon early, and if it takes ten years to actually come back to haunt them, they haven't done too badly. Fixing something that far down in the nuts and bolts isn't easy. (I am not saying the presence of a revenue-generating hardware fix doesn't influence the decision not to make a risky change to the software; I'm just saying there's a lot of grey area to play in.) -Dave
Re: FW: ISPs slowing P2P traffic...
Joe Greco wrote: I have no idea what the networking equivalent of thirty-seven half-eaten bags of Cheetos is, can't even begin to imagine what the virtual equivalent of my couch is, etc. Your metaphor doesn't really make any sense to me, sorry. There isn't one. The fat man metaphor was getting increasingly silly, I just wanted to get it over with. Actually, it was doing pretty well up 'til near the end. Most of the amusing stuff was [off-list.] The interesting conclusion to it was that obesity is a growing problem in the US, and that the economics of an AYCE buffet are changing - mostly for the owner. Interestingly enough, we do have a pizza-and-play place a mile or two from the house, you pay one fee to get in, then quarters (or cards or whatever) to play games - but they have repeatedly answered that they are absolutely and positively fine with you coming in for lunch, and staying through supper. And we have a discount card, which they used to give out to local businesspeople for business lunches, on top of it. That's not the best metaphor either, because they're making money off the games, not the buffet. (Seriously, visit one of 'em, the food isn't very good, and clearly isn't the real draw.) True for Chuck E Cheese, but not universally so. I really doubt that Stonefire is expecting the people who they give their $5.95 business lunch card to to go play games. Their pizza used to taste like cardboard (bland), but they're much better now. The facility as a whole is designed to address the family, and adults can go get some Asian or Italian pasta, go to the sports theme area that plays ESPN, and only tangentially notice the game area on the way out. The toddler play areas (8yr) are even free. http://www.whitehutchinson.com/leisure/stonefirepizza.shtml This is falling fairly far from topicality for NANOG, but there is a certain aspect here which is exceedingly relevant - that businesses continue to change and innovate in order to meet customer demand. I suppose you could market Internet connectivity this way - unlimited access to HTTP and POP3, and ten free SMTP transactions per month, then you pay extra for each protocol. That'd be an awfully tough sell, though. Possibly. :-) As long as you fairly disclose to your end-users what limitations and restrictions exist on your network, I don't see the problem. You've set out a qualification that generally doesn't exist. I can only speak for my network, of course. Mine is a small WISP, and we have the same basic policy as Amplex, from whence this thread originated. Our contracts have relatively clear and large (at least by the standards of a contract) no p2p disclaimers, in addition to the standard no traffic that causes network problems clause that many of us have. The installers are trained to explicitly mention this, along with other no-brainer clauses like don't spam. Actually, that's a difference, that wasn't what [EMAIL PROTECTED] was talking about. Amplex web site said they would rate limit you down to the minimum promised rate. That's disclosed, which would be fine, except that it apparently isn't what they are looking to do, because their oversubscription rate is still too high to deliver on their promises. When we're setting up software on their computers (like their email client), we'll look for obvious signs of trouble ahead. If a customer already has a bunch of p2p software installed, we'll let them know they can't use it, under pain of find a new ISP. We don't tell our customers they can have unlimited access to do whatever the heck they want. The technical distinctions only matter to a few customers, and they're generally the problem customers that we don't want anyway. There is certainly some truth to that. Getting rid of the unprofitable customers is one way to keep things good. However, you may find yourself getting rid of some customers who merely want to make sure that their ISP isn't going to interfere at some future date. To try to make this slightly more relevant, is it a good idea, either technically or legally, to mandate some sort of standard for this? I'm thinking something like the Nutrition Facts information that appears on most packaged foods in the States, that ISPs put on their Web sites and advertisements. I'm willing to disclose that we block certain ports for our end-users unless they request otherwise, and that we rate-limit certain types of traffic. ABSOLUTELY. We would certainly seem more responsible, as providers, if we disclosed what we were providing. I can see this sort of thing getting confusing and messy for everyone, with little or no benefit to anyone. Thoughts? It certainly can get confusing and messy. It's a little annoying to help someone go shopping for broadband and then have to dig out the dirty details in the TC, if they're even there. In a similar way, I get highly annoyed
Re: FW: ISPs slowing P2P traffic...
On Jan 15, 2008 3:52 PM, Joe Greco [EMAIL PROTECTED] wrote: Joe Greco wrote: I have no idea what the networking equivalent of thirty-seven half-eaten bags of Cheetos is, can't even begin to imagine what the virtual equivalent of my couch is, etc. Your metaphor doesn't really make any sense to me, sorry. There isn't one. The fat man metaphor was getting increasingly silly, I just wanted to get it over with. Actually, it was doing pretty well up 'til near the end. \ Not really, it's been pretty far out there for more than a few posts and was completely dead when farting and burping was used in an analogy. -M
RE: FW: ISPs slowing P2P traffic...
I have reached the conclusion that some of these threads are good indicators of the degree of underemployment among our esteemed members. But don't worry, I am not a snitch. Roderick S. Beck Director of European Sales Hibernia Atlantic 1, Passage du Chantier, 75012 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. Landline: 33-1-4346-3209. French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth [EMAIL PROTECTED] [EMAIL PROTECTED] ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -Original Message- From: [EMAIL PROTECTED] on behalf of Martin Hannigan Sent: Tue 1/15/2008 9:25 PM To: Joe Greco Cc: nanog@merit.edu Subject: Re: FW: ISPs slowing P2P traffic... On Jan 15, 2008 3:52 PM, Joe Greco [EMAIL PROTECTED] wrote: Joe Greco wrote: I have no idea what the networking equivalent of thirty-seven half-eaten bags of Cheetos is, can't even begin to imagine what the virtual equivalent of my couch is, etc. Your metaphor doesn't really make any sense to me, sorry. There isn't one. The fat man metaphor was getting increasingly silly, I just wanted to get it over with. Actually, it was doing pretty well up 'til near the end. \ Not really, it's been pretty far out there for more than a few posts and was completely dead when farting and burping was used in an analogy. -M
Re: BGP Filtering
But if I can see the /19 in the table, do I care about a load of /24s because the whole of the /19 should be reachable as the origin AS is announcing it somewhere in their network and it is being received my a transit so should be reachable. The presumption in cases like this is that the /24 may take a different path than the /19 in some or all cases. If you have only a single provider you can safely dump more specifics -- but then, you could just point default. If you *are* multihomed and the /19 and /24 both have the same primacy (first choice in a routing decision and same path) you can safely drop the more specific. The presumption is that in some cases the /24 would take a different path than the /19 in a routing fight. How much cost you want to incur for these is your choice. If enough people drop the more specifics, they will go away as well -- if they provided no benefit, fewer would exist. Some of this originates from the peering-contests where folks have x number of prefixes which makes them bigger than y number of prefixes. I'd be interested to see any metrics on rate of growth of allocations longer than RIR limits since Verio instituted then dropped mandatory prefix filters. (vs the rate of growth of prefixes overall). I would guess that they accelerated. Deepak
RE: BGP Filtering
Hi, It is late and am just checking email. But... The /24 is more specific than the /19 therefore the /24 take priority. In my opinion AS path length became somewhat redundant with the rise of confederations and BGP doesn't understand bandwidth, latency and congestion. But I didn't write it, I am not that clever and it works and is what we have today. But I don't care about the remote de-aggregating AS's local traffic engineering, I care about the reach ability of the IP my customer has requested, and the /19 is a valid route in the route table the origin AS put it there and it is in my local transit feed. Why should I pay in my router for the degaregated AS's traffic engineering which doesnt benefit me, I care about my transit and peers as long as the /19 is reachable. Personally it is the deagregating ASs problem if they have poor transit and peering not mine, maybe if they took ownership of their problem rather than trying to make it everyone else's problem we would not find ourselves in the mess we are currently in with no sign of the problem diminishing or fixing itself. This is not about my router or processor - it is fine thank you with plenty of capacity transits and peers - but that doesn't excuse the generation of dross in the table - I refuse to believe there are justifiable reasons for anywhere near the majority of those 100K+ suspect routes. As a wide general rough rule of thumb, more specifics (if any) for peering should only be getting announced to peers + customers not back up into transit providers. RIPE RIR rules don't deagreagte - period - these ASs should not expect others to carry their extra x prefixes just because they want to stretch the size of their table in a router waiving contest. I know I can dump them, for identical origination ASes, and things will continue to work for me - the trick and my question is how to dynamically classify them so that it is possible to think about dropping them. The question was how? The answer is - seems it cant be done. The main/best I have heard work around seems to be RIR minimum allocation PA space filtering plus defaults to capture the very small number of unique prefixes of PA less than minimum allocation size that would get filtered - as I understand it, it is top of my reading list on my desk tommorow. The idea as much as possible is to go with what is in the routing table not to pin default routes all over the place and to simply try and easily with minimum maintenance drop a slice of the dross without impacting customer experience. Thank you to all who suggested solutions. Ben -Original Message- From: Deepak Jain [mailto:[EMAIL PROTECTED] Sent: 15 January 2008 22:09 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering But if I can see the /19 in the table, do I care about a load of /24s because the whole of the /19 should be reachable as the origin AS is announcing it somewhere in their network and it is being received my a transit so should be reachable. The presumption in cases like this is that the /24 may take a different path than the /19 in some or all cases. If you have only a single provider you can safely dump more specifics -- but then, you could just point default. If you *are* multihomed and the /19 and /24 both have the same primacy (first choice in a routing decision and same path) you can safely drop the more specific. The presumption is that in some cases the /24 would take a different path than the /19 in a routing fight. How much cost you want to incur for these is your choice. If enough people drop the more specifics, they will go away as well -- if they provided no benefit, fewer would exist. Some of this originates from the peering-contests where folks have x number of prefixes which makes them bigger than y number of prefixes. I'd be interested to see any metrics on rate of growth of allocations longer than RIR limits since Verio instituted then dropped mandatory prefix filters. (vs the rate of growth of prefixes overall). I would guess that they accelerated. Deepak
RE: FW: ISPs slowing P2P traffic...
I'm not aware of MSOs configuring their upstreams to attain rates for 9 and 27 Mbps for version 1 and 2, respectively. The numbers you quote are the theoretical max, not the deployed values. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mikael Abrahamsson Sent: Tuesday, January 15, 2008 3:27 AM To: nanog@merit.edu Subject: Re: FW: ISPs slowing P2P traffic... On Tue, 15 Jan 2008, Brandon Galbraith wrote: I think no matter what happens, it's going to be very interesting as Comcast rolls out DOCSIS 3.0 (with speeds around 100-150Mbps possible), Verizon FIOS Well, according to wikipedia DOCSIS 3.0 gives 108 megabit/s upstream as opposed to 27 and 9 megabit/s for v2 and v1 respectively. That's not what I would call revolution as I still guess hundreds if not thousands of subscribers share those 108 megabit/s, right? Yes, fourfold increase but ... that's still only factor 4. expands it's offering (currently, you can get 50Mb/s down and 30Mb/sec up), etc. If things are really as fragile as some have been saying, then the bottlenecks will slowly make themselves apparent. Upstream capacity will still be scarce on shared media as far as I can see. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: FW: ISPs slowing P2P traffic...
On Tue, 15 Jan 2008, Frank Bulk wrote: I'm not aware of MSOs configuring their upstreams to attain rates for 9 and 27 Mbps for version 1 and 2, respectively. The numbers you quote are the theoretical max, not the deployed values. But with 1000 users on a segment, don't these share the 27 megabit/s for v2, even though they are configured to only be able to use 384kilobit/s peak individually? -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: FW: ISPs slowing P2P traffic...
Except that upstreams are not at 27 Mbps (http://i.cmpnet.com/commsdesign/csd/2002/jun02/imedia-fig1.gif show that you would be using 32 QAM at 6.4 MHz). The majority of MSOs are at 16-QAM at 3.2 MHz, which is about 10 Mbps. We just took over two systems that were at QPSK at 3.2 Mbps, which is about 5 Mbps. And upstreams are usually sized not to be more than 250 users per upstream port. So that would be a 10:1 oversubscription on upstream, not too bad, by my reckoning. The 1000 you are thinking of is probably 1000 users per downstream power, and there is a usually a 1:4 to 1:6 ratio of downstream to upstream ports. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mikael Abrahamsson Sent: Tuesday, January 15, 2008 5:41 PM To: nanog@merit.edu Subject: RE: FW: ISPs slowing P2P traffic... On Tue, 15 Jan 2008, Frank Bulk wrote: I'm not aware of MSOs configuring their upstreams to attain rates for 9 and 27 Mbps for version 1 and 2, respectively. The numbers you quote are the theoretical max, not the deployed values. But with 1000 users on a segment, don't these share the 27 megabit/s for v2, even though they are configured to only be able to use 384kilobit/s peak individually? -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: BGP Filtering
Date: Tue, 15 Jan 2008 15:16:04 -0500 From: William Herrin [EMAIL PROTECTED] Subject: Re: BGP Filtering On Jan 15, 2008 12:51 PM, Dave Israel [EMAIL PROTECTED] wrote: I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. Dave, That's half-true. The routing table is comprised of two components: the Routing Information Base (RIB) and the Forwarding Information Base (FIB). The RIB sits in slow, cheap memory and contains routes and metrics for every route as announced by every neighbor. The FIB sits in fast, expensive memory and contains the currently best route for each destination. The FIB is built by choosing the best routes from the RIB. Packet-forwarding decisions are made by consulting the FIB. Opportunistically filtering routes from the RIB would have exactly the problem you point out: routing updates are incremental. The knowledge that the /16 has been withdrawn may not accompany the knowledge that the /17s are available. Opportunistically filtering more-specific routes from the FIB, however, could be very valuable at the edge of the DFZ. If Cisco supported such filtering, those Sup2's could have another few years of life left in them. With 512m ram in a two-transit provider scenario a Sup2 could handle upwards of 1M routes in the RIB. Unfortunately, they can only handle 244k routes in the FIB. Ben, coming back to your question: I don't think there is a way to make the software filter the routes inserted into the FIB. I don't see a reason why it couldn't be programmed to do that. But the fine folks at Cisco didn't see fit to write that software. Its a pity 'cause it would be very useful. This leads to one 'obviuous' approach to the matter. a smart BGP 'proxy' that accepts 'full' data from all the peers, manages the RIB and outputs =only= the current 'most desired' subset of routes to the target router. In _that_ router the RIB and FIB are going to be equivalent, This gets the 'hog' part of things off into 'commodity' hardware, and where you can afford to burn CPU cycles implementing 'smarts' to compensate for other people's 'dumbs'. At a quick glance it looks like this would not be terribly difficult to build, using Quagga/Zebra as a base platform.
Re: Looking for geo-directional DNS service
On 15-Jan-2008, at 12:50, Patrick W. Gilmore wrote: Anycast gives you BGP distance, not topological distance. Yeah, it's topology modulated by economics :-) Joe
Re: Off Topic
On Jan 15, 2008 2:42 PM, Rod Beck [EMAIL PROTECTED] wrote: At the risk of incurring Mr. Pilosoft's wrath (the Putin of NANOG?), I'll he's not a bad guy actually :) it's a rough job corralling all the -admin folks I'm certain. Also this isn't really that off topic is it? looking for NANOG style ISP meetings to attend in Europe this year (France, Germany, UK, Belgium, and Netherlands). Any suggestions would be RIPE? In berlin in May: http://www.ripe.net/ripe/meetings/ripe-56/index.html -Chris
Re: BGP Filtering
On Jan 15, 2008 2:02 PM, Jon Lewis [EMAIL PROTECTED] wrote: On Tue, 15 Jan 2008, Ben Butler wrote: I want a filter that will automatically match the shorter prefixes that match any longer prefix, once I can match them I can drop them. I don't want to manually configure a static prefix list for lots and lots and lots of reasons. If the longer prefix disappears from the route table I want to stop filtering the shorter prefixes - automatically. This was talked about / requested several months ago on cisco-nsp. IIRC, the thread ended along the lines of don't hold your breath. Implementation of this sort of feature is very icky (lots of details you may not be considering) and why should cisco spend time writing this code when they can sell you a bigger router instead? Jon, didn't you start: http://www.wibble.co.uk/archives/nanog/2007/msg05265.html and Ben, is this sort of what you are looking for? Or would it accomplish the same thing for you? -Chris
Re: [Fwd: Unstable BGP Peerings?]
On Jan 13, 2008 6:56 PM, Paul Ferguson [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Interesting, given that TTNet sits atop this ranking: https://nssg.trendmicro.com/nrs/reports/rank.php?page=1 I wonder if this is somehow related? ;-) probably not... but only based on as much a guess on my part as paul's I suspect, a little more below. - -- Sue Joiner [EMAIL PROTECTED] wrote: Forwarding for Mohit Lad and Jonathan Park. -sue Sue Joiner Merit Network - Original Message Subject:Unstable BGP Peerings? Date: Sun, 13 Jan 2008 17:49:44 + From: ParkJonathan [EMAIL PROTECTED] To: nanog@merit.edu CC: [EMAIL PROTECTED], [EMAIL PROTECTED] During our recent study on BGP routing instability, we found cases where lots of routes changed from one subpath to another subpath, repeating this kind of behavior over a few months . We do not know the cause of this repeated instability, but suspect the BGP peering between routers in two AS was unstable or had some problems and this caused routing changes seen by many observation points. It seems, to me, that from the data you have on the website perhaps this is just oscillation in best-path decision or internal traffic engineering decisions exposed to the outside world? Perhaps (taking the first picture example) 9121 decides partway through a day or month that they want to use cogent more (ratio levelling or cost reasons) so they draw traffic via 174, then after some metric is met (cost or ratio) they spread the load across their other transit links? This could easily account for the changes you are showing, right? In point of fact the next few examples also seem to reflect the same behaviour... I suppose this could even be automated with one of those fancy-dan InterNap route-optimizer boxes, right? I'd be curious to know if this makes sense to: 1) other folks on-list, 2) the researchers. -Chris Specifically, the peerings in question are 174 (Cogent) and 9121 (TTNet) 3257 (Tiscali) and 9121 (TTNet) 9304 (Hutchison) and 15412 (Flag Telecom) 1273 (CableWireless) 4651 (Thai Gateway) 6762 (Seabone) and 7473 (Singapore Telecom) For details of events and timings, please find a short summary on the link below. http://irl.cs.ucla.edu/pca/active-links.html We would really appreciate if somebody from the ISPs involved in this activity (or anybody who might know what happened) would contact us and throw some light on the reasons for this behavior. Thanks Mohit Lad, Jonathan Park UCLA -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHiqUVq1pz9mNUZTMRAkVEAJ0Y4u5AYr/CiG65e3e+Y88HCQJGjQCg723O P17FTAUFOw3Ms1KQW6v2+44= =013x -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: BGP Filtering
On Tue, 15 Jan 2008, Christopher Morrow wrote: Jon, didn't you start: http://www.wibble.co.uk/archives/nanog/2007/msg05265.html Yep. and Ben, is this sort of what you are looking for? Or would it accomplish the same thing for you? I don't think it's at all what Ben wants, but I think it's the closest thing to it that's actually available, relatively simple to configure, and accomplishes the desired savings. For anyone in need of such savings, I recommned you start with one RIR at a time and carry a default route, because you're going to lose some networks. If you want to be somewhat charitable, bump the limits up 1-bit and filter on RIR minimums + 1. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Off Topic
On Tue, 15 Jan 2008, Rod Beck wrote: At the risk of incurring Mr. Pilosoft's wrath (the Putin of NANOG?), You meant the srh of nanog. And I'm not ;) I'll looking for NANOG style ISP meetings to attend in Europe this year (France, Germany, UK, Belgium, and Netherlands). Any suggestions would be appreciated. Please bypass the list and send them directly to me. The first thing that comes to mind is RIPE. Next thing that comes to mind is UKNOF. Also, that isn't really off-topic. However, if you get off-list replies, could you please do a follow-up summary post and list the european neteng groups, that would be quite helpful. A good starting point for the search is www.euro-ix.net, which lists european IXPs. Many IXP's have annual (or more often) meetings of members, which serve similarly to NANOG. See: https://www.euro-ix.net/news/meetevent/ for starters. -alex
Re: Looking for geo-directional DNS service
On Jan 15, 2008, at 3:03 PM, Joe Greco wrote: Except Hank is asking for true topological distance (latency / throughput / packetloss). Anycast gives you BGP distance, not topological distance. Say I'm in Ashburn and peer directly with someone in Korea where he has a node (1 AS hop), but I get to his node in Ashburn through my transit provider (2 AS hops), guess which node anycast will pick? Ashburn and other major network meet points are oddities in a very complex network. It would be fair to note that anycast is likely to be reasonably effective if deployed in a manner that was mindful of the overall Internet architecture, and made allowances for such things. You are not disagreeing with me. I was responding to Woody who said: On Jan 15, 2008, at 12:00 PM, Bill Woodcock wrote: Yes, and that's how anycast works: it directs traffic to the _topologically nearest_ server. [...] If you're doing things on the Internet, instead of the physical world, topological distance is presumably of much greater interest than whatever geographic proximity may coincidentally obtain. Unless you define topologically nearest as what BGP picks, that is incorrect. And even if you do define topology to be equivalent to BGP, that is not what is of the greatest interest. Goodput (latency, packet loss, throughput) is far more important. IMHO. If you don't like my example, then ignore Ashburn and take a random, medium-sized network. Now assume an anycast node which is topologically (i.e. latency, bit-miles, throughput, whatever your definition) closer through transit, compared to a node topologically farther away through peering. Which is chosen? And this is not even close to an unusual situation. This in no way means anycast sux. It just means anycast is not, by a long shot, guaranteed to give you the closest node by any reasonable definition. (Sorry, I don't think node BGP picks is reasonable. You are welcome to disagree, but the point still stands that other definitions of reasonable are not satisfied.) In general, anycast is better than not-anycast, and can be optimized to be better than non-anycast for nearly all user by someone with enough clue + money + time. This is not in question. It is essentially impossible to guarantee anycast is better than any other solution for all applications and all end users, especially over time as the Internet changes. This is not in question either. -- TTFN, patrick Anycast by itself probably isn't entirely desirable in any case, and could ideally be paired up with other technologies to fix problems like this. I haven't seen many easy ways to roll-your-own geo-DNS service. The ones I've done in the past simply built in knowledge of the networks in question, and where such information wasn't available, took best guess and then may have done a little research after the fact for future queries. This isn't as comprehensive as doing actual latency / throughput / pl checking. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e- mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Looking for geo-directional DNS service
[EMAIL PROTECTED] (Patrick W.Gilmore)] And even if you do define topology to be equivalent to BGP, that is not what is of the greatest interest. Goodput (latency, packet loss, throughput) is far more important. IMHO. in my less humble justified true belief, this is 100% truth. This in no way means anycast sux. It just means anycast is not, by a long shot, guaranteed to give you the closest node by any reasonable definition. (Sorry, I don't think node BGP picks is reasonable. ... i also second this notion. in our (ISC's) current use of anycase (for f-root and other dns servers), anycast is a crutch for not having a global backbone, but wanting f-root to have global representation and extreme replication. informal studies don't show as much locality as we'd like -- but by peering aggressively everywhere and by setting no-export on our route almost everywhere, we've been able to localize and isolate ddos effects, which is all we were trying to accomplish. but note, f-root is a normal dns server, it has an absolute mapping between qname,qtype,qclass,time and answer. i don't believe in stupid dns tricks (where that mapping is relativized for TE purposes), and one of the reasons for my disbelief is that many ISP's in f-root's ~40 IXP locations do not peer with us, and their traffic is therefore answered in remote (to them) places where TE can't be predicted. in other words, people doing stupid dns tricks are probably counting on anycast to do something f-root doesn't care about (and which i think BGP won't do even on its best day.) -- Paul Vixie
Re: Looking for geo-directional DNS service
Unless you define topologically nearest as what BGP picks, that is incorrect. And even if you do define topology to be equivalent to BGP, that is not what is of the greatest interest. Goodput (latency, packet loss, throughput) is far more important. IMHO. Certainly, but given some completely random transaction, there's still going to be a tendency for anycast to be some sort of improvement over pure random chance. 1000 boneheaded anycast implementations cannot be wrong. :-) That you don't get it right every time doesn't make it wrong every time. I'm certainly not arguing for anycast-only solutions, and said so. I'll be happy to consider it as a first approximation to getting something to a topologically nearby network, though as I also said, there needs to be some care taken in the implementation. Anycast can actually be very powerful within a single AS, where of course you have some knowledge of the network and predictability. You lose some (probably a lot) of that in the translation to the public Internet, but I'm going to go out on a bit of a limb and guess that if I were to stick an anycast node in Chicago, Sydney, and Amsterdam, I'm very likely to be able to pick my networks such that I get a good amount of localization. Of course, nobody's perfect, and it probably needs to be a data-driven business if you really want well-optimized redirection. However, that's a bit of magic. Even the fabled Akamai used to direct us to some ISP up in Minnesota... (BFG) So, anyways, would it be entertaining to discuss the relative merits of various DNS implementations that attempt to provide geographic answers to requests, versus doing it at a higher level? (I can hear everyone groaning now, and some purist somewhere probably having fits) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: FW: ISPs slowing P2P traffic...
Joe Greco wrote:
As long as you fairly disclose to your end-users what limitations and
restrictions exist on your network, I don't see the problem.
You've set out a qualification that generally doesn't exist. For example,
this discussion included someone from a WISP, Amplex, I believe, that
listed certain conditions of use on their web site, and yet it seems like
they're un{willing,able} (not assigning blame/fault/etc here) to deliver
that level of service, and using their inability as a way to justify
possibly rate shaping P2P traffic above and beyond what they indicate on
their own documents.
Actually you misrepresent what I said versus what you said. It's
getting a little old.
I responded to the original question by Deepak Jain over why anyone
cared about P2P traffic rather then just using a hard limit with the
reasons why a Wireless ISP would want to shape P2P traffic.
You then took it upon yourself to post sections of our website to Nanog
and claim that your service was much superior because you happen to run
Metro Ethernet.
Our website pretty clearly spells out our practices and they are MUCH
more transparent than any other provider I know of.Can we do EXACTLY
what we say on our website if EVERY client wants to run P2P at the full
upload rate? No - but we can do it for the ones who care at this
point.At the moment the only people who seem to care about this are
holier than thou network engineers and content providers looking for
ways to avoid their own distribution costs. Neither one of them is
paying me a dime.
Mark
Re: FW: ISPs slowing P2P traffic...
- Original Message -
From: Joe Greco [EMAIL PROTECTED]
[snip]
As long as you fairly disclose to your end-users what limitations and
restrictions exist on your network, I don't see the problem.
You've set out a qualification that generally doesn't exist. For example,
this discussion included someone from a WISP, Amplex, I believe, that
listed certain conditions of use on their web site, and yet it seems like
they're un{willing,able} (not assigning blame/fault/etc here) to deliver
that level of service, and using their inability as a way to justify
possibly rate shaping P2P traffic above and beyond what they indicate on
their own documents.
In some cases, we do have people burying TC in lengthy TC documents,
such as some of the 3G cellular providers who advertise Unlimited
Internet(*) data cards, but then have a slew of (*) items that are
restricted - but only if you dig into the fine print on Page 3 of the
TC. I'd much prefer that the advertising be honest and up front, and
that ISP's not be allowed to advertise unlimited service if they are
going to place limits, particularly significant limits, on the service.
... JG
Yep.
In the US, Internet access is still generally sold as all-you-can-eat, with few restrictions on the types of services or
applications that can be run across the network (except for wireless, of course), but things are different across the
pond. In the UK, ISP plus.net doesn't even offer unlimited packages, and they explain why on their web site.
'Most providers claiming to offer unlimited broadband will have a fair use policy to try and prevent people over-using
their service, they write. But if it's supposed to be unlimited, why should you use it fairly? The fair use policy stops
you using your unlimited broadband in an unlimited fashion-so, by our reckoning, it's not unlimited. We don't believe in
selling 'unlimited broadband' that's bound by a fair use policy. We'd rather be upfront with you and give you clear usage
allowances, with FREE overnight usage.'
The above (and there's much more) from:
http://arstechnica.com/articles/culture/Deep-packet-inspection-meets-net-neutrality.ars/
If I was a WISP, I'd be saving up for that DPI box.
--Michael
RE: BGP Filtering
Hi, That is where I got to last night with my cogitations before I feel asleep. Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Bonomi Sent: 16 January 2008 01:26 To: nanog@merit.edu Subject: Re: BGP Filtering Date: Tue, 15 Jan 2008 15:16:04 -0500 From: William Herrin [EMAIL PROTECTED] Subject: Re: BGP Filtering On Jan 15, 2008 12:51 PM, Dave Israel [EMAIL PROTECTED] wrote: I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. Dave, That's half-true. The routing table is comprised of two components: the Routing Information Base (RIB) and the Forwarding Information Base (FIB). The RIB sits in slow, cheap memory and contains routes and metrics for every route as announced by every neighbor. The FIB sits in fast, expensive memory and contains the currently best route for each destination. The FIB is built by choosing the best routes from the RIB. Packet-forwarding decisions are made by consulting the FIB. Opportunistically filtering routes from the RIB would have exactly the problem you point out: routing updates are incremental. The knowledge that the /16 has been withdrawn may not accompany the knowledge that the /17s are available. Opportunistically filtering more-specific routes from the FIB, however, could be very valuable at the edge of the DFZ. If Cisco supported such filtering, those Sup2's could have another few years of life left in them. With 512m ram in a two-transit provider scenario a Sup2 could handle upwards of 1M routes in the RIB. Unfortunately, they can only handle 244k routes in the FIB. Ben, coming back to your question: I don't think there is a way to make the software filter the routes inserted into the FIB. I don't see a reason why it couldn't be programmed to do that. But the fine folks at Cisco didn't see fit to write that software. Its a pity 'cause it would be very useful. This leads to one 'obviuous' approach to the matter. a smart BGP 'proxy' that accepts 'full' data from all the peers, manages the RIB and outputs =only= the current 'most desired' subset of routes to the target router. In _that_ router the RIB and FIB are going to be equivalent, This gets the 'hog' part of things off into 'commodity' hardware, and where you can afford to burn CPU cycles implementing 'smarts' to compensate for other people's 'dumbs'. At a quick glance it looks like this would not be terribly difficult to build, using Quagga/Zebra as a base platform.
RE: FW: ISPs slowing P2P traffic...
On Tue, 15 Jan 2008, Frank Bulk wrote: Except that upstreams are not at 27 Mbps (http://i.cmpnet.com/commsdesign/csd/2002/jun02/imedia-fig1.gif show that you would be using 32 QAM at 6.4 MHz). The majority of MSOs are at 16-QAM at 3.2 MHz, which is about 10 Mbps. We just took over two systems that were at QPSK at 3.2 Mbps, which is about 5 Mbps. Ok, so the wikipedia article http://en.wikipedia.org/wiki/Docsis is heavily simplified? Any chance someone with good knowledge of this could update the page to be more accurate? And upstreams are usually sized not to be more than 250 users per upstream port. So that would be a 10:1 oversubscription on upstream, not too bad, by my reckoning. The 1000 you are thinking of is probably 1000 users per downstream power, and there is a usually a 1:4 to 1:6 ratio of downstream to upstream ports. 250 users sharing 10 megabit/s would mean 40 kilobit/s average utilization which to me seems very tight. Or is this 250 apartments meaning perhaps 40% subscribe to the service indicating that those 250 really are 100 and that the average utilization then can be 100 kilobit/s upstream? With these figures I can really see why companies using HFC/Coax have a problem with P2P, the technical implementation is not really suited for the application. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
