Re: Failover how much complexity will it add?
You will laugh, but the budget at the moment looks like £13k. Impossible? Do only linux and openbsd solutions remain in the mix for this pittance? On Sun 11:47 PM , Dale Rumph da...@ibbs.com wrote: What does your budget look like? A pair of Cisco 7246vxr's with G1's sitting on the edge of the network would be very effective and still allow expansion. Or you could go up to the 7609. However this gear may be slightly overkill. You might be ok with a 3660 enterprise and a ton of ram. I have done single sessions on them but not with the level of HA your looking for. Just my 2c - Original Message - From: a...@baklawasecrets.com To: nanog@nanog.org Sent: Sun Nov 08 18:36:31 2009 Subject: Re: Failover how much complexity will it add? Basically the organisation that I'm working for will not have the skills in house to support a linux or bsd box. They will have trouble with supporting the BGP configuration, however I don't think they will be happy with me if I leave them with a linux box when they don't have linux/unix resource internally. At least with a Cisco or Juniper they are familiar with IOS and it won't be too foreign to them. On Sun 11:30 PM , Renato Frederick wrote: There are any problems with quagga+BSD/Linux that you know or something like that? Or in your scenario a cisco/juniper box is a requirement? I'm asking this because I'm always running BGP with upstreams providers using quagga on BSD and everything is fine until now. -- From: Sent: Sunday, November 08, 2009 8:39 PM To: Subject: Re: Failover how much complexity will it add? So if my requirements are as follows: - BGP router capable of holding full Internet routing table. (whether I go for partial or full, I think I want something with full capability). - Capable of pushing 100meg plus of mixed traffic. What are my options? I want to exclude openbsd, or linux with quagga. Probably looking at Cisco or Juniper products, but interested in any other alternatives people suggest. I realise this is quite a broad question, but hoping this will provide a starting point. Oh and if I have missed any specs I should have included above, please let me know. Thanks Adel
Re: Failover how much complexity will it add?
Looking at two 100Mbit/s BGP connections, so I think I want something that will do more than 100 but nowhere close to a gig. So full routing table capability with throughput of mixed traffic around 200Mbit/s. If that makes sense. Do the 2850s fall into that sort of price point? Adel On Mon 11:13 AM , Joe Abley jab...@hopcount.ca wrote: On 2009-11-09, at 19:53, a...@baklawasecrets.com wrote: You will laugh, but the budget at the moment looks like £13k. Impossible? Do only linux and openbsd solutions remain in the mix for this pittance? I don't see an indication of the traffic you need to push (maybe I deleted a message too enthusiastically) but check the 2800 series from cisco. The 2850 will take full tables and has gigabit interfaces, but don't expect them to do wire speed. Other 2800s suffer from reduced RAM, but perhaps you don't need full tables. Also look at Juniper J-series boxes, and maybe Force10 S-series boxes. There's a healthy market in used cisco gear in most places I have ever visited, if you don't need new. Joe
Re: Failover how much complexity will it add?
Basically the organisation that I'm working for will not have the skills in house to support a linux or bsd box. They will have trouble with supporting the BGP configuration, however I don't think they will be happy with me if I leave them with a linux box when they don't have linux/unix resource internally. At least with a Cisco or Juniper they are familiar with IOS and it won't be too foreign to them. On Sun 11:47 PM , Dale Rumph da...@ibbs.com wrote: What does your budget look like? A pair of Cisco 7246vxr's with G1's sitting on the edge of the network would be very effective and still allow expansion. Or you could go up to the 7609. However this gear may be slightly overkill. You might be ok with a 3660 enterprise and a ton of ram. I have done single sessions on them but not with the level of HA your looking for. Just my 2c You will laugh, but the budget at the moment looks like £13k. Impossible? Do only linux and openbsd solutions remain in the mix for this pittance? No, you have the buy-it-off-eBay solutions as well. Beware the fakes. If they're familiar with IOS, then they can be familiar with Quagga about as easily as they could be familiar with a switch or other network gizmo that had a Ciscoesque CLI but wasn't actually Cisco. You've painted yourself into a corner. I have a word for you: Reconsider. I don't care what you reconsider, but reconsider something. You can reconsider taking BGP with a full table. You can reconsider Quagga. Or you can reconsider your budget. This is the end result of the pick any two problem. Most end user organizations have no need of full routes in BGP. To try to take them dooms TCAM-based equipment at some future point, though if you have a lot of money to throw at it, you can make that point be years in the future. It is essentially planned obsolescence. If you discard the requirement for full routes, you open up a bunch of reasonably-priced possibilities. Finding someone knowledgeable in BSD or Linux isn't that rough. Unlike a Cisco 76xx router, the hardest part of a Quagga-based solution is finding the right mix of hardware and software at the beginning. PC hardware has a lot going for AND against it. There is no reason you can't make a good router out of a PC. If you buy the Cisco software-based routers, you're essentially buying a prepackaged version, except that it'll be specced to avoid any real competition with their low-end TCAM-based offerings. A contemporary PC can easily route gigabits. Vyatta makes what I hear is a fantastic canned solution of some sort, for a reasonable cost, and they will sell just software or software/hardware. If you really can't put it together yourself, there's someone to do it for you. Reconsidering your budget is probably the most painful thing to do, but also opens up the just buy big Cisco option. I think my point here would have to be that what you're looking for would have needed big Cisco... ten years ago. Now, dealing with a few hundred megs of traffic, that's not that big a deal, the thing that's killing you is the BGP table size. Your best option may be to see if you can settle for partial routes plus a default. ... 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: Failover how much complexity will it add?
Thanks, Their offering certainly looks appealing. Will be interested to hear user experiences of the Vyatta BGP router range. Having said that I will still be examining the Cisco offering, just because of the support, larger user community and skills base issue. However if I can't meet the price point using Cisco, obviously other solutions are going to come into the picture. Adel On Mon 11:39 AM , Arnold Nipper arn...@nipper.de wrote: On 09.11.2009 11:53 a...@baklawasecrets.com wrote You will laugh, but the budget at the moment looks like £13k. Impossible? Do only linux and openbsd solutions remain in the mix for this pittance? Do you know Vyatta (http://www.vyatta.com/)? [1] CLI and config is Cisco-ish. Prices e.g. Vyatta Appliance, Vyatta 2502, Enterprise Subscription, Basic Warranty, 1 Year (ships with US Power Cord as standard) (Typically ships in 10-12 business days) Price: $2,997.00 Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 Links: -- [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.vyatta.com/%29%3 F
Re: Failover how much complexity will it add?
Thanks, I've taken your advice and decided to reconsider my requirement for a full routing table. I believe I'm being greedy and a partial table will be sufficient. With regards to Linux/BSD, its not the CLI of quagga that will be an issue, rather the sysadmin and lack of supporting infrastructure for Linux boxes within the organisation. So things like package management, syslog servers, monitoring, understanding of security issues etc. I don't want to leave them with a linux/bsd solution that they won't be able to maintain/manage effectively when I am gone. Thanks for your comments. Look forward to hearing which solutions come back into the mix having dropped the full routing table requirement. Regards, Adel On Mon 11:45 AM , Joe Greco jgr...@ns.sol.net wrote: Basically the organisation that I'm working for will not have the skills in house to support a linux or bsd box. They will have trouble with supporting the BGP configuration, however I don't think they will be happy with me if I leave them with a linux box when they don't have linux/unix resource internally. At least with a Cisco or Juniper they are familiar with IOS and it won't be too foreign to them. On Sun 11:47 PM , Dale Rumph wrote: What does your budget look like? A pair of Cisco 7246vxr's with G1's sitting on the edge of the network would be very effective and still allow expansion. Or you could go up to the 7609. However this gear may be slightly overkill. You might be ok with a 3660 enterprise and a ton of ram. I have done single sessions on them but not with the level of HA your looking for. Just my 2c You will laugh, but the budget at the moment looks like £13k. Impossible? Do only linux and openbsd solutions remain in the mix for this pittance? No, you have the buy-it-off-eBay solutions as well. Beware the fakes. If they're familiar with IOS, then they can be familiar with Quagga about as easily as they could be familiar with a switch or other network gizmo that had a Ciscoesque CLI but wasn't actually Cisco. You've painted yourself into a corner. I have a word for you: Reconsider. I don't care what you reconsider, but reconsider something. You can reconsider taking BGP with a full table. You can reconsider Quagga. Or you can reconsider your budget. This is the end result of the pick any two problem. Most end user organizations have no need of full routes in BGP. To try to take them dooms TCAM-based equipment at some future point, though if you have a lot of money to throw at it, you can make that point be years in the future. It is essentially planned obsolescence. If you discard the requirement for full routes, you open up a bunch of reasonably-priced possibilities. Finding someone knowledgeable in BSD or Linux isn't that rough. Unlike a Cisco 76xx router, the hardest part of a Quagga-based solution is finding the right mix of hardware and software at the beginning. PC hardware has a lot going for AND against it. There is no reason you can't make a good router out of a PC. If you buy the Cisco software-based routers, you're essentially buying a prepackaged version, except that it'll be specced to avoid any real competition with their low-end TCAM-based offerings. A contemporary PC can easily route gigabits. Vyatta makes what I hear is a fantastic canned solution of some sort, for a reasonable cost, and they will sell just software or software/hardware. If you really can't put it together yourself, there's someone to do it for you. Reconsidering your budget is probably the most painful thing to do, but also opens up the just buy big Cisco option. I think my point here would have to be that what you're looking for would have needed big Cisco... ten years ago. Now, dealing with a few hundred megs of traffic, that's not that big a deal, the thing that's killing you is the BGP table size. Your best option may be to see if you can settle for partial routes plus a default. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net [1] 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. Links: -- [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net
Re: Failover how much complexity will it add?
Actually thinking about this, I still need to understand the implications of not taking a full routing table to my setup. So what is the likely impact going to be if I take partial instead of full routing table. Would appreciate any feedback on this. My organisation is only looking at using BGP as a means of failover between two separate upstream ISPs. We are not an ISP. Thanks Adel On Mon 1:32 PM , a...@baklawasecrets.com wrote: Thanks, I've taken your advice and decided to reconsider my requirement for a full routing table. I believe I'm being greedy and a partial table will be sufficient. With regards to Linux/BSD, its not the CLI of quagga that will be an issue, rather the sysadmin and lack of supporting infrastructure for Linux boxes within the organisation. So things like package management, syslog servers, monitoring, understanding of security issues etc. I don't want to leave them with a linux/bsd solution that they won't be able to maintain/manage effectively when I am gone. Thanks for your comments. Look forward to hearing which solutions come back into the mix having dropped the full routing table requirement. Regards, Adel On Mon 11:45 AM , Joe Greco wrote: Basically the organisation that I'm working for will not have the skills in house to support a linux or bsd box. They will have trouble with supporting the BGP configuration, however I don't think they will be happy with me if I leave them with a linux box when they don't have linux/unix resource internally. At least with a Cisco or Juniper they are familiar with IOS and it won't be too foreign to them. On Sun 11:47 PM , Dale Rumph wrote: What does your budget look like? A pair of Cisco 7246vxr's with G1's sitting on the edge of the network would be very effective and still allow expansion. Or you could go up to the 7609. However this gear may be slightly overkill. You might be ok with a 3660 enterprise and a ton of ram. I have done single sessions on them but not with the level of HA your looking for. Just my 2c You will laugh, but the budget at the moment looks like £13k. Impossible? Do only linux and openbsd solutions remain in the mix for this pittance? No, you have the buy-it-off-eBay solutions as well. Beware the fakes. If they're familiar with IOS, then they can be familiar with Quagga about as easily as they could be familiar with a switch or other network gizmo that had a Ciscoesque CLI but wasn't actually Cisco. You've painted yourself into a corner. I have a word for you: Reconsider. I don't care what you reconsider, but reconsider something. You can reconsider taking BGP with a full table. You can reconsider Quagga. Or you can reconsider your budget. This is the end result of the pick any two problem. Most end user organizations have no need of full routes in BGP. To try to take them dooms TCAM-based equipment at some future point, though if you have a lot of money to throw at it, you can make that point be years in the future. It is essentially planned obsolescence. If you discard the requirement for full routes, you open up a bunch of reasonably-priced possibilities. Finding someone knowledgeable in BSD or Linux isn't that rough. Unlike a Cisco 76xx router, the hardest part of a Quagga-based solution is finding the right mix of hardware and software at the beginning. PC hardware has a lot going for AND against it. There is no reason you can't make a good router out of a PC. If you buy the Cisco software-based routers, you're essentially buying a prepackaged version, except that it'll be specced to avoid any real competition with their low-end TCAM-based offerings. A contemporary PC can easily route gigabits. Vyatta makes what I hear is a fantastic canned solution of some sort, for a reasonable cost, and they will sell just software or software/hardware. If you really can't put it together yourself, there's someone to do it for you. Reconsidering your budget is probably the most painful thing to do, but also opens up the just buy big Cisco option. I think my point here would have to be that what you're looking for would have needed big Cisco... ten years ago. Now, dealing with a few hundred megs of traffic, that's not that big a deal, the thing that's killing you is the BGP table size. Your best option may be to see if you can settle for partial routes plus a default. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net [1] [1] 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. Links: -- [1]
Re: Failover how much complexity will it add?
Thanks, I've taken your advice and decided to reconsider my requirement for a full routing table. I believe I'm being greedy and a partial table will be sufficient. With regards to Linux/BSD, its not the CLI of quagga that will be an issue, rather the sysadmin and lack of supporting infrastructure for Linux boxes within the organisation. So things like package management, You don't need to run Apache on your router. syslog servers, If you didn't have syslog servers for the Cisco, you don't need one for the Quagga. monitoring, If you didn't monitor the Cisco, you don't need to monitor the Quagga. understanding of security issues etc. What security issues? The thing is, people get all tied up over this idea that it is some major ongoing burden to support a Linux based device. I have a shocker for you. The CPE your residential broadband relies on may well run Linux, and you didn't even know it. The wifi router you use may run Linux. There are thousands of embedded uses for Linux. I highly doubt that the average TiVo user has a degree in Linux. Many different things you use in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly without any need of someone to handhold them on security issues. Of course, security issues do come up. But they do with Cisco as well. A proper Linux router doesn't have ports open, aside from bgp and ssh, and those can be firewalled appropriately. This makes it very difficult to have any meaningful security problems relating to the platform... You can expect the occasional issue. Just like anything else. But trying to compare it to security issues on a general Linux platform is only meaningful if you're trying to argue against the solution. (I'm a BSD guy myself, but I don't see any reason for undue Linux paranoia) I don't want to leave them with a linux/bsd solution that they won't be able to maintain/manage effectively when I am gone. If they're unable to maintain something as straightforward as BSD or Linux when you're gone, this raises alarm bells as to whether or not BGP is really suited for them. BGP is *much* more arcane, relatively speaking. You can go to your local bookstore and pick up a ton of Linux or BSD sysadm books, but you'll be lucky to find a book on BGP. Thanks for your comments. Look forward to hearing which solutions come back into the mix having dropped the full routing table requirement. There's a whole plethora of BGP-capable gear that becomes possible once you make that call. Cisco and Juniper both make good gear. A variety of other mfrs do as well. Something as old as an Ascend GRF 400 (fast ethernet, line speed, 150K routes, ~1998?) is perfectly capable of dealing with the load, though I mention this primarily to make the point that there is a lot of equipment within the last decade that can support this. ... 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: What DNS Is Not
Alex Balashov wrote: Thought-provoking article by Paul Vixie: http://queue.acm.org/detail.cfm?id=1647302 Bah, many of the CDN's I've dealt with don't seed geographical responses based on DNS, but rather use many out of band methods for determining what response they will hand out. The primary reason for short cutting cache is to limit failures in case the system a requestor is going to goes down. And different CDN's behave differently, depending on how they deliver content, support provider interconnects, etc. I'd hardly call many of them DNS lies, as they do resolve you to the appropriate IP, and if that IP disappears, try and quickly get you to another appropriate IP. The rest of the article was informative,though. Jack
Re: Failover how much complexity will it add?
Hi Joe, I agree with most of what you say below regarding linux sysadmin, BSD etc. I'm quite happy and actually would prefer building a linux solution on our own hardware. However, politically I think this is going to be difficult. I just feel that they will be more comfortable with embedded network boxes as a pose to a linux solution. I guess what I'm saying is this is partially a political thing. Adel On Mon 3:20 PM , Joe Greco jgr...@ns.sol.net wrote: Thanks, I've taken your advice and decided to reconsider my requirement for a full routing table. I believe I'm being greedy and a partial table will be sufficient. With regards to Linux/BSD, its not the CLI of quagga that will be an issue, rather the sysadmin and lack of supporting infrastructure for Linux boxes within the organisation. So things like package management, You don't need to run Apache on your router. syslog servers, If you didn't have syslog servers for the Cisco, you don't need one for the Quagga. monitoring, If you didn't monitor the Cisco, you don't need to monitor the Quagga. understanding of security issues etc. What security issues? The thing is, people get all tied up over this idea that it is some major ongoing burden to support a Linux based device. I have a shocker for you. The CPE your residential broadband relies on may well run Linux, and you didn't even know it. The wifi router you use may run Linux. There are thousands of embedded uses for Linux. I highly doubt that the average TiVo user has a degree in Linux. Many different things you use in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly without any need of someone to handhold them on security issues. Of course, security issues do come up. But they do with Cisco as well. A proper Linux router doesn't have ports open, aside from bgp and ssh, and those can be firewalled appropriately. This makes it very difficult to have any meaningful security problems relating to the platform... You can expect the occasional issue. Just like anything else. But trying to compare it to security issues on a general Linux platform is only meaningful if you're trying to argue against the solution. (I'm a BSD guy myself, but I don't see any reason for undue Linux paranoia) I don't want to leave them with a linux/bsd solution that they won't be able to maintain/manage effectively when I am gone. If they're unable to maintain something as straightforward as BSD or Linux when you're gone, this raises alarm bells as to whether or not BGP is really suited for them. BGP is *much* more arcane, relatively speaking. You can go to your local bookstore and pick up a ton of Linux or BSD sysadm books, but you'll be lucky to find a book on BGP. Thanks for your comments. Look forward to hearing which solutions come back into the mix having dropped the full routing table requirement. There's a whole plethora of BGP-capable gear that becomes possible once you make that call. Cisco and Juniper both make good gear. A variety of other mfrs do as well. Something as old as an Ascend GRF 400 (fast ethernet, line speed, 150K routes, ~1998?) is perfectly capable of dealing with the load, though I mention this primarily to make the point that there is a lot of equipment within the last decade that can support this. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net [1] 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. Links: -- [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net
Cisco Security Advisory: Transport Layer Security Renegotiation Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Transport Layer Security Renegotiation Vulnerability Advisory ID: cisco-sa-20091109-tls http://www.cisco.com/warp/public/707/cisco-sa-20091109-tls.shtml Revision 1.0 For Public Release 2009 November 9 1600 UTC (GMT) Summary === An industry-wide vulnerability exists in the Transport Layer Security (TLS) protocol that could impact any Cisco product that uses any version of TLS and SSL. The vulnerability exists in how the protocol handles session renegotiation and exposes users to a potential man-in-the-middle attack. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20091109-tls.shtml. Affected Products = Cisco is currently evaluating products for possible exposure to these TLS issues. Products will only be listed in the Vulnerable Products or Products Confirmed Not Vulnerable sections of this advisory when a final determination about product exposure is made. Products that are not listed in either of these two sections are still being evaluated. Vulnerable Products - --- This section will be updated when more information is available. Products Confirmed Not Vulnerable - - The following products are confirmed not vulnerable: * Cisco AnyConnect VPN Client This section will be updated when more information is available. Details === TLS and its predecessor, SSL, are cryptographic protocols that provide security for communications over IP data networks such as the Internet. An industry-wide vulnerability exists in the TLS protocol that could impact any Cisco product that uses any version of TLS and SSL. The vulnerability exists in how the protocol handles session renegotiation and exposes users to a potential man-in-the-middle attack. The following Cisco Bug IDs are being used to track potential exposure to the SSL and TLS issues. The bugs listed below do not confirm that a product is vulnerable, but rather that the product is under investigation by the appropriate product teams. Registered Cisco customers can view these bugs via Cisco's Bug Toolkit: http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl ++ | Product |Bug ID | |+---| | Cisco Adaptive Security| CSCtd01491| | Device Manager (ASDM) | | |+---| | Cisco AON Software | CSCtd01646| || | |+---| | Cisco AON Healthcare for | CSCtd01652| | HIPAA and ePrescription| | |+---| | Cisco Application and | CSCtd01529| | Content Networking System | | | (ACNS) Software| | |+---| | Cisco Application | CSCtd01480| | Networking Manager | | |+---| | Cisco ASA 5500 Series | CSCtd00697| | Adaptive Security | | | Appliances | | |+---| | Cisco ASA Advanced | | | Inspection and Prevention | CSCtd01539| | (AIP) Security Services| | | Module | | |+---| | Cisco AVS 3100 Series | CSCtd01566| | Application Velocity | | | System | | |+---| | Cisco Catalyst 6500 Series | CSCtd06389| | SSL Services Module| | |+---| | Firewall Services Module | CSCtd04061| | FWSM | | |+---| | Cisco CSS 11000 Series | CSCtd01636| | Content Services Switches | | |+---| | Cisco Unified SIP Phones | CSCtd01446
Re: Failover how much complexity will it add?
a...@baklawasecrets.com wrote: Actually thinking about this, I still need to understand the implications of not taking a full routing table to my setup. So what is the likely impact going to be if I take partial instead of full routing table. Would appreciate any feedback on this. My organisation is only looking at using BGP as a means of failover between two separate upstream ISPs. We are not an ISP. Some Cisco L3 switches should support this fine. A 3560 or 3750 can speak BGP and route at line rate as long as your total number of routes will fit in its TCAM space. Ask your upstreams how big a partial feed from them is. desktop routing template: The selected template optimizes the resources in the switch to support this level of features for 8 routed interfaces and 1024 VLANs. number of unicast mac addresses: 3K number of IPv4 IGMP groups + multicast routes:1K number of IPv4 unicast routes:11K number of directly-connected IPv4 hosts:3K number of indirect IPv4 routes: 8K number of IPv4 policy based routing aces: 0.5K number of IPv4/MAC qos aces: 0.5K number of IPv4/MAC security aces: 1K If you ever need IPv6 it gets smaller: number of unicast mac addresses: 2K number of IPv4 IGMP groups + multicast routes:1K number of IPv4 unicast routes:3K number of directly-connected IPv4 hosts:2K number of indirect IPv4 routes: 1K number of IPv6 multicast groups: 1.125k number of directly-connected IPv6 addresses: 2K number of indirect IPv6 unicast routes: 1K number of IPv4 policy based routing aces: 0 number of IPv4/MAC qos aces: 0.5K number of IPv4/MAC security aces: 1K number of IPv6 policy based routing aces: 0 number of IPv6 qos aces: 0.625k number of IPv6 security aces: 0.5K Anything in Cisco land that can hold two full tables in hardware and can do line rate is going to be hideously expensive. ~Seth
Re: Failover how much complexity will it add?
On Mon, 09 Nov 2009 13:39:34 GMT, Adam Armstrong said: Sure, if you want to hand over your entire profit margin to a 3rd party. Do you really want to give away the keys to your business, and rely entirely upon a third party organisation? Better to acquire the skills which are vital to your organisation yourself. Umm.. You did that *anyhow* the instant you paid somebody else to run the cables to your location rather than dig your own ditches. Similarly for electricity and everything else you don't create yourself. NOTE: I am not an employee, or paid affiliate of packet exchange... I have used them for services and am promoting them due to my own good experiences with their services. I used to work for them. Then as now, I honestly can see little purpose in their productset. There's little purpose if you're an ISP that's supposed to be good at BGP yourself. If however, your business is running a /24 worth of webservers that sells your company's product, and Best Practices says you should be multi-homed but the in-house skill set runs more to Apache than BGP, a well-designed BGP appliance can be a ghodsend. (I admit I missed the OP's statement of what business line they were in). pgpNkXzugtzja.pgp Description: PGP signature
BGP Peer Selection Considerations
Hi, Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows: BGP Peer with Provider A who is multihomed to other providers. BGP Peer with Provider B who is not peered with provider A I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B (they say they have a diverse fibre backhaul network). This is quite attractive from a support and billing perspective. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to. Am I missing things that I need to consider?
Re: Failover how much complexity will it add?
On Nov 8, 2009, at 2:39 PM, a...@baklawasecrets.com wrote: So if my requirements are as follows: - BGP router capable of holding full Internet routing table. (whether I go for partial or full, I think I want something with full capability). - Capable of pushing 100meg plus of mixed traffic. What are my options? I want to exclude openbsd, or linux with quagga. Why is that?
RE: Failover how much complexity will it add?
Most purpose-built routing appliances use ternary content addressable memory (TCAM) in order to accomplish deterministic, hardware-based, longest-prefix lookups in large routing tables, such as a full Internet BGP feed. TCAM is used to replace software-based table lookup algorithms which have been empirically shown to lack scalability as the number of routes in the routing table increases, and as the line rate in/out of the routers increases. Current TCAM hardware-based routing engines scale to 10 Gbps, and beyond. Much research has been done in this area in the last 15 years. I don't think general purpose BSD/Linux systems meet the scalability requirement for deterministic network design. Nothing political about that. -Original Message- From: a...@baklawasecrets.com [mailto:a...@baklawasecrets.com] Sent: Monday, November 09, 2009 8:36 AM To: nanog@nanog.org Subject: Re: Failover how much complexity will it add? Hi Joe, I agree with most of what you say below regarding linux sysadmin, BSD etc. I'm quite happy and actually would prefer building a linux solution on our own hardware. However, politically I think this is going to be difficult. I just feel that they will be more comfortable with embedded network boxes as a pose to a linux solution. I guess what I'm saying is this is partially a political thing. Adel On Mon 3:20 PM , Joe Greco jgr...@ns.sol.net wrote: Thanks, I've taken your advice and decided to reconsider my requirement for a full routing table. I believe I'm being greedy and a partial table will be sufficient. With regards to Linux/BSD, its not the CLI of quagga that will be an issue, rather the sysadmin and lack of supporting infrastructure for Linux boxes within the organisation. So things like package management, You don't need to run Apache on your router. syslog servers, If you didn't have syslog servers for the Cisco, you don't need one for the Quagga. monitoring, If you didn't monitor the Cisco, you don't need to monitor the Quagga. understanding of security issues etc. What security issues? The thing is, people get all tied up over this idea that it is some major ongoing burden to support a Linux based device. I have a shocker for you. The CPE your residential broadband relies on may well run Linux, and you didn't even know it. The wifi router you use may run Linux. There are thousands of embedded uses for Linux. I highly doubt that the average TiVo user has a degree in Linux. Many different things you use in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly without any need of someone to handhold them on security issues. Of course, security issues do come up. But they do with Cisco as well. A proper Linux router doesn't have ports open, aside from bgp and ssh, and those can be firewalled appropriately. This makes it very difficult to have any meaningful security problems relating to the platform... You can expect the occasional issue. Just like anything else. But trying to compare it to security issues on a general Linux platform is only meaningful if you're trying to argue against the solution. (I'm a BSD guy myself, but I don't see any reason for undue Linux paranoia) I don't want to leave them with a linux/bsd solution that they won't be able to maintain/manage effectively when I am gone. If they're unable to maintain something as straightforward as BSD or Linux when you're gone, this raises alarm bells as to whether or not BGP is really suited for them. BGP is *much* more arcane, relatively speaking. You can go to your local bookstore and pick up a ton of Linux or BSD sysadm books, but you'll be lucky to find a book on BGP. Thanks for your comments. Look forward to hearing which solutions come back into the mix having dropped the full routing table requirement. There's a whole plethora of BGP-capable gear that becomes possible once you make that call. Cisco and Juniper both make good gear. A variety of other mfrs do as well. Something as old as an Ascend GRF 400 (fast ethernet, line speed, 150K routes, ~1998?) is perfectly capable of dealing with the load, though I mention this primarily to make the point that there is a lot of equipment within the last decade that can support this. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net [1] 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. Links: -- [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net
Re: BGP Peer Selection Considerations
a...@baklawasecrets.com wrote: Hi, Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows: BGP Peer with Provider A who is multihomed to other providers. BGP Peer with Provider B who is not peered with provider A I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B (they say they have a diverse fibre backhaul network). This is quite attractive from a support and billing perspective. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to. Am I missing things that I need to consider? Don't let them cross connect over their network. Bring it in to your site separate from A, otherwise there's no point in the multihoming exercise. ~Seth
Re: BGP Peer Selection Considerations
On Mon, Nov 9, 2009 at 12:40 PM, a...@baklawasecrets.com wrote: I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B (they say they have a diverse fibre backhaul network). This is quite attractive from a support and billing perspective. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to. Am I missing things that I need to consider? What happens when provider A is bought by provider C and you want to dump provider C but keep provider B? You'll have created a conflict of interest for provider B in any negotiation you have with them. Be aware that provider A's diverse network for provider A's service is the same diverse network they'll use to connect you to provider B. As a result, many or most of the outages which impact provider A will also impact your connectivity to provider B, defeating the central purpose of having a provider B. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Failover how much complexity will it add?
Most purpose-built routing appliances use ternary content addressable memory (TCAM) in order to accomplish deterministic, hardware-based, longest-prefix lookups in large routing tables, such as a full Internet BGP feed. TCAM is used to replace software-based table lookup algorithms which have been empirically shown to lack scalability as the number of routes in the routing table increases, and as the line rate in/out of the routers increases. Current TCAM hardware-based routing engines scale to 10 Gbps, and beyond. Much research has been done in this area in the last 15 years. I don't think general purpose BSD/Linux systems meet the scalability requirement for deterministic network design. Nothing political about that. Whoa. How'd you manage to get it completely inverted? It's the TCAM based platforms that are a scaling problem. You have to do a forklift upgrade of them every now and then in order to assure yourself of being able to continue to hold a full table. Put another way: Software-based lookup tables do tend to perform more slowly as the number of routes grows. However, a Linux or BSD router that was operational in 1999 will still be functional today, able to route a full table today. It will suffer a mild degradation in forwarding capabilities as the route table grows, but this is mild. Hardware-based lookup tables have a really bad failure mode: they fill. When they fill, generally speaking, parts of the Internet may vanish. It is great to be able to forward at line speed up to the table capacity of the box, but you can do the same thing on a software-based platform... to get line rate simply means you need to ensure you've got sufficient excess resources. Software-based platforms are finicky at high PPS rates, but these days it'd be kinda hard to come up with a platform that *couldn't* route 1Gbps. We're talking a fraction of that for this guy who has a few 100Mbps links. Now, of course, if he plans to scale that few 100Mbps links up to a few 10Gbps links in the next few years, then there is definitely a question about the suitability of a software-based platform, but it is also the case that any inexpensive TCAM-based platform that might be selected will also need to be upgraded ... at significant expense. I would have thought that this lesson would still be fresh in the minds of people, as we just passed 256K routes a little while ago and broke a whole bunch of Catalyst 6500/7600 SUP720-3B's (etc). I guess the pain isn't as memorable as I thought. ... 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 Peer Selection Considerations
Don't let them cross connect over their network. Bring it in to your site separate from A, otherwise there's no point in the multihoming exercise. s/no point/less benefit/ ... 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 Peer Selection Considerations
William Herrin wrote: Be aware that provider A's diverse network for provider A's service is the same diverse network they'll use to connect you to provider B. As a result, many or most of the outages which impact provider A will also impact your connectivity to provider B, defeating the central purpose of having a provider B. I'll just add to the OP: you want them independent *to you* not internally diverse between themselves. How would that help your site be independent? I'm sure the billing/support sounds attractive (and they get to upsell you), but you won't gain provider independence, only a larger bill. ~Seth
ATT Admin
Ok, guess we'll see if this really works or not. Would an ATT mail admin contact me offlist? I have an issue I need to start moving up the chain since I'm getting nowhere fast with normal channels. Thanks, Aaron
Re: What DNS Is Not
i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of. i knew that the incoherent DNS market would rise up on its hind legs and say all kinds of things in its defense against the ACM Queue article, and i'm not going to engage with every such speaker. there three more-specific replies below. Dave Temkin dav...@gmail.com writes: Alex Balashov wrote: For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS? In most cases it already is. He completely fails to address the concept of Anycast DNS and assumes people are using statically mapped resolvers. anycast DNS appears to mean different things to different people. i didn't mention it because to me anycast dns is a bgp level construct whereby the same (coherent) answer is available from many servers having the same IP address but not actually being the same server. see for example how several root name servers are distributed. http://www.root-servers.org/. if you are using anycast DNS to mean carefully crafted (noncoherent) responses from a similarly distributed/advertised set of servers, then i did address your topic in the ACM Queue article. David Andersen d...@cs.cmu.edu writes: This myth ... was debunked years ago: DNS Performance and the Effectiveness of Caching Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris http://pdos.csail.mit.edu/papers/dns:ton.pdf my reason for completely dismissing that paper at the time it came out was that it tried to predict the system level impact of DNS caching while only looking at the resolver side and only from one client population having a small and uniform user base. show me a trace driven simulation of the whole system, that takes into account significant authority servers (which would include root, tld, and amazon and google) as well as significant caching servers (which would not include MIT's or any university's but which would definitely include comcast's and cox's and att's), and i'll read it with high hopes. note that ISC SIE (see http://sie.isc.org/ may yet grow into a possible data source for this kind of study, which is one of the reasons we created it.) Simon Lyall si...@darkmere.gen.nz writes: I heard some anti-spam people use DNS to distribute big databases of information. I bet Vixie would have nasty things to say to the guy who first thought that up. someone made this same comment in the slashdot thread. my response there and here is: the MAPS RBL has always delivered coherent responses where the answer is an expressed fact, not kerned in any way based on the identity of the querier. perhaps my language in the ACM Queue article was imprecise (delivering facts rather than policy) and i should have stuck with the longer formulation (incoherent responses crafted based on the identity of the querier rather than on the authoritative data). -- Paul Vixie KI6YSY
Re: ATT Admin
Aaron Wendel wrote: Ok, guess we'll see if this really works or not. Would an ATT mail admin contact me offlist? I have an issue I need to start moving up the chain since I'm getting nowhere fast with normal channels. FYI replying and changing the subject keeps your message under the same thread. You should start a new message. ~Seth
Re: What DNS Is Not
Hi, Paul - I share your dislike of DNS services that break the DNS model for profit in ways that break applications. For instance, returning the IP address of your company's port-80 web server instead of NXDOMAIN not only breaks non-port-80-http applications, it also breaks the behaviour that browsers such as IE and Firefox expect, which is that if a domain isn't found, they'll do something that the user chooses, such as sending another query to the user's favorite search engine. There is one special case for which I don't mind having DNS servers lie about query results, which is the phishing/malware protection service. In that case, the DNS response is redirecting you to the IP address of a server that'll tell you You really didn't want to visit PayPa11.com - it's a fake or You really didn't want to visit dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware. It's technically broken, but you really _didn't_ want to go there anyway. It's a bit friendlier to administrators and security people if the response page gives you the IP address that the query would have otherwise returned, though obviously you don't want it to be a clickable hyperlink. However, I disagree with your objections to CDN, and load balancers in general - returning the address of the server that example.com thinks will give you the best performance is reasonable. (I'll leave the question of whether DNS queries are any good at determining that to the vendors.) Maintaining a cachable ns.example.com record in the process is friendly to everybody; maintaining cachable A records is less important. If reality is changing rapidly, then the directory that points to the reality can reasonably change also. On Mon, Nov 9, 2009 at 12:00 PM, Paul Vixie vi...@isc.org wrote: i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of. Well, there's the built-in GPS navigation system that tells you to go drive off the dock into the water, because it wasn't smart enough to know that the route the map database showed in dotted lines was a ferryboat... -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: What DNS Is Not
When I write applications that make DNS queries, I expect the request to turn NXDOMAIN if the host does not exist - HTTP as well as non-HTTP, but especially non-HTTP. Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: What DNS Is Not
On 11/9/09 6:06 PM, Alex Balashov wrote: Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial. Because some people want the ability and choice to block DNS responses they don't like; just as they have the ability and choice to reject email they don't want to accept. When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is. -David
Re: What DNS Is Not
On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote: i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of. i knew that the incoherent DNS market would rise up on its hind legs and say all kinds of things in its defense against the ACM Queue article, and i'm not going to engage with every such speaker. Paul: I completely agree with you that putting wildcards into the roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. Users have little (no?) choice on their TLDs. Stopping those is a Good Thing, IMHO. However, I own a domain (or couple hundred :). I have a wildcard on my domain. I point it where I want. I feel not the slightest twinge of guilt at this. Do you think this is a Bad Thing, or should this be allowed? Also, why are you upset at OpenDNS. People _intentionally_ select to use OpenDNS, which is clear in its terms of service, and even allows users to turn off the bits that annoy you. Exactly what is the issue? And lastly, DNS is not truth. DNS is the Domain Name System, it is what people configure it to be. You yourself have argued things like responding with 192.0.2.1 for DNSBLs that are being shut down. That is clearly NOT truth. -- TTFN, patrick P.S. Yes, I am intentionally ignoring the CDN side of things. Find me in private, preferably with a shot of single-malt, if you want my opinion. there three more-specific replies below. Dave Temkin dav...@gmail.com writes: Alex Balashov wrote: For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS? In most cases it already is. He completely fails to address the concept of Anycast DNS and assumes people are using statically mapped resolvers. anycast DNS appears to mean different things to different people. i didn't mention it because to me anycast dns is a bgp level construct whereby the same (coherent) answer is available from many servers having the same IP address but not actually being the same server. see for example how several root name servers are distributed. http://www.root-servers.org/. if you are using anycast DNS to mean carefully crafted (noncoherent) responses from a similarly distributed/advertised set of servers, then i did address your topic in the ACM Queue article. David Andersen d...@cs.cmu.edu writes: This myth ... was debunked years ago: DNS Performance and the Effectiveness of Caching Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris http://pdos.csail.mit.edu/papers/dns:ton.pdf my reason for completely dismissing that paper at the time it came out was that it tried to predict the system level impact of DNS caching while only looking at the resolver side and only from one client population having a small and uniform user base. show me a trace driven simulation of the whole system, that takes into account significant authority servers (which would include root, tld, and amazon and google) as well as significant caching servers (which would not include MIT's or any university's but which would definitely include comcast's and cox's and att's), and i'll read it with high hopes. note that ISC SIE (see http://sie.isc.org/ may yet grow into a possible data source for this kind of study, which is one of the reasons we created it.) Simon Lyall si...@darkmere.gen.nz writes: I heard some anti-spam people use DNS to distribute big databases of information. I bet Vixie would have nasty things to say to the guy who first thought that up. someone made this same comment in the slashdot thread. my response there and here is: the MAPS RBL has always delivered coherent responses where the answer is an expressed fact, not kerned in any way based on the identity of the querier. perhaps my language in the ACM Queue article was imprecise (delivering facts rather than policy) and i should have stuck with the longer formulation (incoherent responses crafted based on the identity of the querier rather than on the authoritative data). -- Paul Vixie KI6YSY
Re: What DNS Is Not
Alex Balashov wrote: When I write applications that make DNS queries, I expect the request to turn NXDOMAIN if the host does not exist - HTTP as well as non-HTTP, but especially non-HTTP. Actually, the one I hate is when they return NXDOMAIN for any RR type other than A, breaking DNS. Most common is to return NXDOMAIN, which immediately has the effect of breaking the ability to fallback to A (why query for another RR, when the domain doesn't exist?). Several high end load balancers have the ability to do this according to the content providers I have addressed the matter with. As a side note, any IPv6 capable stack which has determined there is IPv6 connectivity (through 6to4, native, teredo, etc) cannot access these sites. For an example (an ongoing issue) see www.txu.com. Responds to A, gives NXDOMAIN to . I will not shame the high profile websites that have fixed their loadbalancers/DNS servers, but everyone on this list knows and has probably used them. Jack
Re: What DNS Is Not
David Ulevitch wrote: On 11/9/09 6:06 PM, Alex Balashov wrote: Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial. Because some people want the ability and choice to block DNS responses they don't like; just as they have the ability and choice to reject email they don't want to accept. When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. Dealing with 10k~ uni students who like to spread new viruses faster than STD's I often make light of the fact that we can use OpenDNS to a) keep tabs on who's infected at what sites and b) prevent them from possibly doing more damage by phoning home with info or to collect instructions. To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is. -David It's as David says, there are a lot of us who would rather have the choice than not have it. If that's not acceptable to some then that's their decision however as a part of our network this DNS 'tomfoolery' is something that both we and the end user see benefits from so I don't see it going away anytime soon. Regards, Andrew Cox AccessPlus HNA
Re: What DNS Is Not
On Mon, Nov 09, 2009 at 06:24:52PM -0500, Patrick W. Gilmore wrote: On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote: i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of. i knew that the incoherent DNS market would rise up on its hind legs and say all kinds of things in its defense against the ACM Queue article, and i'm not going to engage with every such speaker. Paul: I completely agree with you that putting wildcards into the roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. Users have little (no?) choice on their TLDs. Stopping those is a Good Thing, IMHO. However, I own a domain (or couple hundred :). I have a wildcard on my domain. I point it where I want. I feel not the slightest twinge of guilt at this. Do you think this is a Bad Thing, or should this be allowed? notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes. Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be a Bad Thing and should be stopped? --bill
RE: What DNS Is Not
-Original Message- From: bmann...@vacation.karoshi.com [mailto:bmann...@vacation.karoshi.com] Sent: Monday, November 09, 2009 4:32 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: What DNS Is Not ... notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes. Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be a Bad Thing and should be stopped? Ok, devils advocate argument. Is there is a difference between being a domain owner (Patrick wanting to wildcard the domain he has paid for), and a domain custodian (Verisign for the .com example) in whether wildcards are ever acceptable in the DNS responses you provide?
Re: What DNS Is Not
At 0:32 + 11/10/09, bmann...@vacation.karoshi.com wrote: not being Paul, its rude of me to respond - yet you posted this to a public list ... so here goes. Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be a Bad Thing... Not being anyone who has posted on this thread on a public list... I agree that the rules for what is acceptable in the operations of DNS zones vary from zone to zone. This is because of the different relationships between the zone administrator and the entities represented in the zone and the different relationships between the zone administrator and the relying parties. (Im just going to pick on one reason.) For the root zone or aTLD (which themselves have differences) the relationships tend to be global, multilingual, etc. Stability and coherence here are vital for operations, because as you know being in operations really means handling outages. Once a problem pops up, it might take a while (hours, days) to go from report to root cause analysis to long-term fix. If the root and TLDs have lots of bells and whistles then, well, this is hard, so the root and TLDs are kept simple. For a zone lower in the stack assumptions are different. Generally speaking, the zone represents a single entity (a government agency, store, school) who will have a varying degree of active management of what is in the zone. They may even be able to roll back to some point in time and see what is in the zone. On-the-fly response generation is even acceptable because they can see what mislead someone, etc. (if they zone is properly run). And by on-the-fly I am including wildcards generated answers, calculated answers or answers based on source of the request, etc., and other demographics or current load measures. As far as relying parties, think about who do I call? when I can't get through. They have two obvious choices - their ISP or the organization they want to reach. Calls will end up with the ISP if the issue is high up in the zone, calls might get to the organization if the problems are lower in the tree. (Because perhaps they got to the main web page but not to the department page.) This is just one reason why it's reasonable to manage different DNS zones differently, why the rules don't apply the same everywhere. There are many other reasons. But this is a public list. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
Re: What DNS Is Not
On Nov 9, 2009, at 7:52 PM, Buhrmaster, Gary wrote: -Original Message- From: bmann...@vacation.karoshi.com [mailto:bmann...@vacation.karoshi.com] Sent: Monday, November 09, 2009 4:32 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: What DNS Is Not ... notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes. Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be a Bad Thing and should be stopped? Ok, devils advocate argument. Is there is a difference between being a domain owner (Patrick wanting to wildcard the domain he has paid for), and a domain custodian (Verisign for the .com example) in whether wildcards are ever acceptable in the DNS responses you provide? I think this is spot on. In particular: Patrick, for some domains at least, can implement a wildcard with the full cooperation and agreement of all of the customers of sub-zones within his domain. Particularly if he doesn't resell any subdomains within it. Verisign cannot. [1] [1] As a customer of .com, my own disagreement on this is sufficient to prove that they don't have unanimous agreement. :-) -Dave
Re: What DNS Is Not
On Mon, Nov 09, 2009 at 04:52:35PM -0800, Buhrmaster, Gary wrote: -Original Message- From: bmann...@vacation.karoshi.com [mailto:bmann...@vacation.karoshi.com] Sent: Monday, November 09, 2009 4:32 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: What DNS Is Not ... notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes. Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be a Bad Thing and should be stopped? Ok, devils advocate argument. Is there is a difference between being a domain owner (Patrick wanting to wildcard the domain he has paid for), and a domain custodian (Verisign for the .com example) in whether wildcards are ever acceptable in the DNS responses you provide? good question - does patrick own the domain or has he paid for the registration of mapping a string into a database? either? both? neither? I'll lay out what I just did in private email a moment ago. regardless of payment, ownership, or other considerations, we all (who manage a delegation point) are stewards of that delegation. Patrick, as steward of a domain, feels certain behaviours are acceptable when he performs them within his stewardship, yet is nonplused when another steward does the exact same thing in a different delegation. not being able to resist the analogy Its ok for me to practice indentured servitude in my home, yet when I see my neighbor practicing it in their home - I call the cops on her for practicing slavery. and hope that no one notices me. --bill
Re: What DNS Is Not
Sent from my iPhone, please excuse any errors. On Nov 9, 2009, at 19:32, bmann...@vacation.karoshi.com wrote: On Mon, Nov 09, 2009 at 06:24:52PM -0500, Patrick W. Gilmore wrote: On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote: i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of. i knew that the incoherent DNS market would rise up on its hind legs and say all kinds of things in its defense against the ACM Queue article, and i'm not going to engage with every such speaker. Paul: I completely agree with you that putting wildcards into the roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. Users have little (no?) choice on their TLDs. Stopping those is a Good Thing, IMHO. However, I own a domain (or couple hundred :). I have a wildcard on my domain. I point it where I want. I feel not the slightest twinge of guilt at this. Do you think this is a Bad Thing, or should this be allowed? notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes. Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be a Bad Thing and should be stopped? Thought I was clear: Choice. I believe there is a qualitative difference between a *TLD and a second level domain. /Especially/ for the GTLDs. I guess one could argue CCTLDs are different, but I disagree. If you are in Germany, a .de is nearly as important as .com in the US. (Don't believe me? Go to www.dtag.com.) But no one has to use ianai.net. Or aa.com. Or A second issue is ownership. I own my domain. The .com domain is not owed by Verisign (despite what they may think :-). Again, one could make an argument that the CCTLDs are different - owned by their host countries. I personally disagree, but I admit that argument is less objective than the GTLDs. Do you disagree wih my logic? Do you believe Verisign should be allowed to do with .net the same things I should be allowed to do with ianai.net ? If so, please explain why. If not, uh ... Why did you ask? =) -- TTFN, patrick
Re: What DNS Is Not
A second issue is ownership. I own my domain. Interesting statement, did you get a property title with your domain name ? Just curious
about interdomain multipath routing.
Hi: These days, in the research, the interdomain multipath routing is pretty hot but i doubt its actually use in reality. Does anyone tell me any use of interdomain multipath routing like multipath BGP in the real world? Best, Daniel
Re: What DNS Is Not
On Mon, Nov 09, 2009 at 08:32:38PM -0500, Patrick W. Gilmore wrote: notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes. Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be a Bad Thing and should be stopped? Thought I was clear: Choice. I believe there is a qualitative difference between a *TLD and a second level domain. /Especially/ for the GTLDs. so you are making the arguement that as one navigates the dns heirarchy, operational choices nearer the root affect more people. as may be. - yet we see ICANN under serious pressure to flatten out the root zone - to create the same amount of choice at the root as one might find in .COM I will echo your original question to Paul, If its a Bad Thing at the root or TLD, is it a Bad Thing in ianai.com? I would say yes it is - looking for consistency in the stewardship guidelines for any delegation. personally, I take the path less traveled and woudl suggest that a wildcard - at any delegation point - can be a useful tool. the unspoken compoent here is the diversity of expectation on what one might do with a wildcard. Is the wildcard in and of itself a Bad Thing or has the wildcard been used in conjunction with other heinous practice to unfairly exploit the gullible masses? I don't think it fair to blame wildcards here - they are a symptom but not the actual cause of Bad Thing - for that you need other bits in play. --bill
Re: What DNS Is Not
On Mon, 09 Nov 2009 15:04:06 PST, Bill Stewart said: For instance, returning the IP address of your company's port-80 web server instead of NXDOMAIN not only breaks non-port-80-http applications Remember this... There is one special case for which I don't mind having DNS servers lie about query results, which is the phishing/malware protection service. In that case, the DNS response is redirecting you to the IP address of a server that'll tell you You really didn't want to visit PayPa11.com - it's a fake or You really didn't want to visit dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware. It's technically broken, but you really _didn't_ want to go there anyway. It's a bit friendlier to administrators and security people if the response page gives you the Returning bogus non-NXODMAIN gives non-port-80-http apps heartburn as well. pgpJo9eqAx0jr.pgp Description: PGP signature
Re: BGP Peer Selection Considerations
a...@baklawasecrets.com wrote: Hi, Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows: BGP Peer with Provider A who is multihomed to other providers. BGP Peer with Provider B who is not peered with provider A I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B ...I've likely missed something, but get the IP/ASN for yourself. *ensure* that A B will peer and provide transit for you. (they say they have a diverse fibre backhaul network). This is quite attractive from a support and billing perspective. ...until you find out that the backhaul network is owned by Provider B, or virtualized within an existing circuit to someplace else. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to. But at what cost? Am I missing things that I need to consider? I think so. Long-term survival for one. If you are budgeted for a diverse and redundant network, then I recommend that you ensure one. My current understanding is that you can negotiate terms with potential providers where there is competition. Don't allow any of your ISPs to manage/dictate the use of your address space. It will bite you, and cause undue frustration. Steve
Re: about interdomain multipath routing.
We use eBGP multipath where I work. We usually get two or more connections to each provider we have. Using multipath we are able to add hardware redundancy with bandwidth balancing (to an extent) with this method. There are some providers who will only allow multipath eBGP and not even let you run multihop eBGP. Bin Dai wrote: Hi: These days, in the research, the interdomain multipath routing is pretty hot but i doubt its actually use in reality. Does anyone tell me any use of interdomain multipath routing like multipath BGP in the real world? Best, Daniel -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
Re: about interdomain multipath routing.
On Mon, Nov 9, 2009 at 5:56 PM, Bin Dai bin.daniel...@gmail.com wrote: Hi: These days, in the research, the interdomain multipath routing is pretty hot but i doubt its actually use in reality. Does anyone tell me any use of interdomain multipath routing like multipath BGP in the real world? I've outlawed the use of multihop eBGP for load-sharing here; when we get multiple links off the same router to a peer or upstream, they are configured with multipath. We've got hundreds of BGP sessions across the network configured with multipath on them. Matt Best, Daniel
Re: What DNS Is Not
Shouldn't such apps be checking the content they receive back from a server anyway? Regardless of if they think they're getting to the right server (due to a bogus non-NXDOMAIN response) there should be some sort of validation in place.. otherwise you're open in any sort of man-in-the-middle attack. I think the issue is more that older apps would expect that if they can get a response then everything is ok.. perhaps this simply an outdated method and needs to be rethought. valdis.kletni...@vt.edu wrote: On Mon, 09 Nov 2009 15:04:06 PST, Bill Stewart said: For instance, returning the IP address of your company's port-80 web server instead of NXDOMAIN not only breaks non-port-80-http applications Remember this... There is one special case for which I don't mind having DNS servers lie about query results, which is the phishing/malware protection service. In that case, the DNS response is redirecting you to the IP address of a server that'll tell you You really didn't want to visit PayPa11.com - it's a fake or You really didn't want to visit dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware. It's technically broken, but you really _didn't_ want to go there anyway. It's a bit friendlier to administrators and security people if the response page gives you the Returning bogus non-NXODMAIN gives non-port-80-http apps heartburn as well.
Re: about interdomain multipath routing.
Matthew Petach wrote: I've outlawed the use of multihop eBGP for load-sharing here; when we get multiple links off the same router to a peer or upstream, they are configured with multipath. We've got hundreds of BGP sessions across the network configured with multipath on them. Same here for my connections, though some of my customers are stuck with multihop eBGP in certain remote areas, but that's a completely different scenario (single link, but obsolete equipment) and out of my control. I much prefer multipath, especially given that the standard multihop config uses static routing and there are conditions that could cause the flap of the eBGP session during a single link outage. With Multipath, only the effected path goes down, as it should. Jack
Re: What DNS Is Not
Andrew Cox wrote: I think the issue is more that older apps would expect that if they can get a response then everything is ok.. perhaps this simply an outdated method and needs to be rethought. The app is expecting a response of some kind. When it gets back bogus information that has it connecting to an IP that may not respond at all, the app will have to sit around waiting on a timeout. Jack
Re: about interdomain multipath routing.
Bin Dai wrote: Hi: These days, in the research, the interdomain multipath routing is pretty hot but i doubt its actually use in reality. Does anyone tell me any use of interdomain multipath routing like multipath BGP in the real world? BGP multipath is extremely common and used to load balance multiple links to the same neighbor ASN. As implemented by popular vendors it requires most attributes (like as-path) to be identical. Did you really mean this or something that uses different as-paths in parallel? - Kevin
Re: about interdomain multipath routing.
Those are very good points Jack. We stopped using multihop for those same reasons. Jack Bates wrote: Matthew Petach wrote: I've outlawed the use of multihop eBGP for load-sharing here; when we get multiple links off the same router to a peer or upstream, they are configured with multipath. We've got hundreds of BGP sessions across the network configured with multipath on them. Same here for my connections, though some of my customers are stuck with multihop eBGP in certain remote areas, but that's a completely different scenario (single link, but obsolete equipment) and out of my control. I much prefer multipath, especially given that the standard multihop config uses static routing and there are conditions that could cause the flap of the eBGP session during a single link outage. With Multipath, only the effected path goes down, as it should. Jack -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
Re: What DNS Is Not
As someone just said to me privately: I dislike the pedantic nerds pull sometimes. (The is mine, not the original quote, so the Communications Committee doesn't send me a warning.) On Nov 9, 2009, at 8:10 PM, bmann...@vacation.karoshi.com wrote: good question - does patrick own the domain or has he paid for the registration of mapping a string into a database? either? both? neither? The argument is silly at best. I own the domain for the year I paid for it. You call it stewardship. I won't argue if you want to play that game. (BTW, I seriously considered putting the word own in quotes, but it would have required five extra keystrokes on the iPhone and I didn't think it was worth the effort. Everyone - including Bill - knows exactly what I meant. I mean, we're not newbies or idiots or Oh, right. Teach me to be lazy.) Let's use stewardship, or any other string of characters that makes you happy. The basic premise does not change. My stewardship of ianai.net (and it's not .com - one would think someone like you would realize the difference) is qualitatively different than the stewardship of the *TLDs. For one thing, I have every right to point any hostname in my domain at any IP address I want.[*] I could create a zone file with 36^N entries pointing them all at the same IP address. No one would blink an eye. It is not unexpected, inappropriate, or in any way wrong. Putting * IN A 1.2.3.4 has the exact same results for any hostname up to N letters. Consider it shorthand. Think of all the RAM I'll save! Verisign putting a domain into .com that does not exist is not only unexpected, it is inappropriate, and Just Plain Wrong. They do not own the zone, they have _no_right_ to put any entries in that zone that are not requested through the appropriate method. If you do not (want to) see that, we will have to agree to disagree. Also, you were so busy picking on my choice of words that you completely ignored the choice point. Guess you couldn't come up with any feeble semantic arguments on that one? not being able to resist the analogy s/the/a really bad/ Its ok for me to practice indentured servitude in my home, yet when I see my neighbor practicing it in their home - I call the cops on her for practicing slavery. and hope that no one notices me. Honestly, Bill, don't you think that was a little pathetic? Why don't you just compare me to Hitler and get it over with. -- TTFN, patrick [*] I'm not going to explain things like I shouldn't point hostnames at IP addresses I do not own (er, steward) because anyone who brings up that point is not worth talking to. If your best counter argument is so stupid that anyone with more than three brain cells to rub together already knows, understands, and has gone right past, then please un-sub from NANOG, throw your laptop in a lake, and go get a job a HS drop out can do. Because that's all you deserve.
Re: What DNS Is Not
On Mon, Nov 9, 2009 at 8:54 PM, Jorge Amodio jmamo...@gmail.com wrote: A second issue is ownership. I own my domain. Interesting statement, did you get a property title with your domain name ? Just curious I'd take that question up with your IP attorney. [ Summary: lots of lawyers and courts seem to think that domain names are property ] http://news.cnet.com/2100-1023-223597.html http://www.domainnamenews.com/legal-issues/are-domain-names-considered-property-or-not/2917 http://newmedialaw.proskauer.com/2008/12/articles/domain-names/appellate-watch-are-domain-names-property-that-can-be-seized-under-state-forfeiture-laws/ http://www.law.duke.edu/journals/dltr/articles/2001dltr0032.html http://pblog.bna.com/techlaw/2009/09/domain-name-deemed-tangible-property-web-pages-too-in-utah.html -M -- Martin Hannigan mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
