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 <jgreco@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
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: adel@baklawasecrets.com [mailto:adel@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 <jgreco@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
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.
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.
Not all of us forgot... I remember the day our 7606's filled and started trying to software switch. Was a painful day indeed. At least we knew it was coming.. just couldn't do anything about it due to budgets.
participants (4)
-
adelï¼ baklawasecrets.com -
Brad Fleming -
Holmes,David A -
Joe Greco