Failover how much complexity will it add?

adel at baklawasecrets.com adel at baklawasecrets.com
Mon Nov 9 10:36:08 CST 2009


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 at 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
> 
> 




More information about the NANOG mailing list