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 , adel@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] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net [2]
Links: ------ [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net [2] http://webmail.123-reg.co.uk/parse.php?redirect=http://webmail.123-reg.co.u k/parse.php%3Fredirect%3Dhttp://www.sol.net
adel@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
adel@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.
I'm up against the same issue. I'm having a hard time understanding what partial routes will accomplish in the following scenario. Let's say we were BGP multi homed and accepting partial tables from two top level ISPs (like Sprint, Cogent, Telia, AT&T whatever). Let's say they get into a peering spat with another top level ISP. This results in one of your upstreams not routing packets to one or more ASs. In this situation, as far as I can tell, you'd want a full routing tables from your upstreams. Without a full routing table how would your router know that certain ASs are reachable through one upstream, but not the other? In this day of and age of wild-west, cowboy attitudes between some of the biggest players on the Internet, does protecting against these problems require a routing device that can handle multiple full routing tables? It would seem so... Cheers, Stef
Stef Walter wrote:
In this day of and age of wild-west, cowboy attitudes between some of the biggest players on the Internet, does protecting against these problems require a routing device that can handle multiple full routing tables? It would seem so...
It has been routinely observed in nanog presentations that settlement free providers by their nature miss a few prefixes that well connected transit purchasing ISPs carry. If business requirements for reachability necessitate multi-homing then carrying the tables if probably also a requirement. joel
Cheers,
Stef
It has been routinely observed in nanog presentations that settlement free providers by their nature miss a few prefixes that well connected transit purchasing ISPs carry.
just trying to understand what you mean, o no transit-free provider actually has all (covering) prefixes needed to cover the active space, but o one or more reasonably small subsets of the set of transit-free providers do cover the whole active space. randy
Randy Bush wrote:
It has been routinely observed in nanog presentations that settlement free providers by their nature miss a few prefixes that well connected transit purchasing ISPs carry.
just trying to understand what you mean,
o no transit-free provider actually has all (covering) prefixes needed to cover the active space, but
o one or more reasonably small subsets of the set of transit-free providers do cover the whole active space.
If your goal is near-complete coverage, under normal circumstances you need more than one (your subset). Settlement-free provider peering spats are a degenerate condition of the normal state of affairs. The non-settlement-free provider has some subset already. Pointing default into a settlement-free provider, that is deliberately not speaking to another is obviously a recipe to lose data, which speaks to the question of whether one should as for a full table from settlement free upstreams. My somewhat obtuse point was that this isn't some wild west frontier justice sort of affair, but rather, the normal state of affairs.
randy
participants (5)
-
adel＠baklawasecrets.com -
Joel Jaeggli -
Randy Bush -
Seth Mattinen -
Stef Walter