BGP, provider indepenent IP's, failover

djr

allo there.

i have a question about failover routing....

we currently operate an internet connection from provider A, but would like to add a higher-spec connection from provider B. now i'm well aware that we would need to move from Provider A's IP pool to Provider B's, but what i would like to do is instead is get our own "provider-independant" /27 or /26.

both ISP's have confirmed that they can support this (afaik they *have* to support it...). what i'd like to know about is the issue of BGP and that kinda thing.

i have a number of tunnels (10+) terminating on Provider A's IP pool, which would be moved to my new "provider independent" pool, but how would the routing work in the event that one of the provider's connection fails? i understand that "inside" my end of the network, the cisco router (the one performing the bgp stuff, outside the firewall) would handle outbound traffic, but how do upsteam routers (handling inbound traffic *from* the internet), know how to route traffic? does there have to be an agreement between provider A + B?

also, what type of box would be required? could i do this with one of the newer linux-based routers (snapgear etc...) if NAT was disabled? i'll attach a diagram so this makes a bit more sense in a moment....

djr

yeah, so...

my Q is how is traffic handled beyond my "mystery BGP router" box if link A or B goes down, and i'm using "provider-indepenent" addresses.

ta,

d.

ttm

djr wrote: »

yeah, so...

my Q is how is traffic handled beyond my "mystery BGP router" box if link A or B goes down, and i'm using "provider-indepenent" addresses.

ta,

d.

Not really thought toooo much about this but my first though would be why make your vpn connections to an IP address in the first place?

If mystery box updates a DNS server according to which Provider was available and your client connected to a FQDN it would solve the problem.

Edit> You could even monitor the services yourself and change the records if one Provider goes down. However you do it I can't see that it would be seemless for your vpn clients, they are going to have to make a new connection unless they have two connections open all the time as could be the case in server to server site vpn connections.

ro2

djr wrote: »

allo there.

i have a question about failover routing....

we currently operate an internet connection from provider A, but would like to add a higher-spec connection from provider B. now i'm well aware that we would need to move from Provider A's IP pool to Provider B's, but what i would like to do is instead is get our own "provider-independant" /27 or /26.

both ISP's have confirmed that they can support this (afaik they *have* to support it...). what i'd like to know about is the issue of BGP and that kinda thing.

I wouldn't do it unless you can justify a /24. A lot of providers filter out anything larger than a /24 to keep their routing tables down.

If provider B is a decent sized ISP you may be able to get two diverse cables into your location. You could then configure one path as a backup if the primary went down.

djr wrote: »

i have a number of tunnels (10+) terminating on Provider A's IP pool, which would be moved to my new "provider independent" pool, but how would the routing work in the event that one of the provider's connection fails? i understand that "inside" my end of the network, the cisco router (the one performing the bgp stuff, outside the firewall) would handle outbound traffic, but how do upsteam routers (handling inbound traffic *from* the internet), know how to route traffic? does there have to be an agreement between provider A + B?

If one of your connections went down your IP addresses would automatically route over the other connection. You wouldn't have to change anything on your firewall.

djr wrote: »

also, what type of box would be required? could i do this with one of the newer linux-based routers (snapgear etc...) if NAT was disabled? i'll attach a diagram so this makes a bit more sense in a moment....

You'd need a Cisco/Juniper router or you could look into Quagga if you wanted to save a few quid.

steve-hosting36

The vast majority of ISPs and providers won't route less than a /24 (which of course you'll need to justify under standard RIPE guidelines).

But, that aside, your own dedicated IP's will always then point to you, regardless of your upstream carriers, as long as those carriers are announcing your /24 through their networks.

steve-hosting36

If the kit is already in a DC, perhaps there is the option of a managed router from your provider that can sort the BGP for you, or, simpler still, handle failover with some kind of load balancing?

It all depends on what the end result needs to be

djr

@ttm

we're legally bound to have a static address to terminate VPNs at, as this is required by our customer contracts.

so....as long as we go with carriers that will advertise our required subnet size, we'll be peachy? it makes sense now when you say that the provider advertises the route, and merely forwards to the preferred or standby carrier

thanks for the help, will look into quagga (didn't that used to be called zebra?)...

not keen on spending super-€ on a hardware box, but also need something that ISP's will "support", a-la cisco/juniper....

steve-hosting36

Quagga (ex Zebra) is actually a really good, low cost way of doing relatively mall amounts of traffic.

loyatemu

theres a good presentation on Multihoming here:
http://www.nanog.org/mtg-0110/ppt/smith.pdf

tbh, its not something you'd do lightly - and if you're a small company it may not be practical to do at all.

Snaga

Just because you find an ISP that will route a smaller subnet for you - does not mean their upstream providers (or more importantly - the rest of the internet) will honour it.

Firstly - RIPE wont give you anything less than a /24 of PI anyway

Even if they did (as a practical joke maybe) - large swathes of the internet will filter it out - leaving your network unreachable from many locations.

PI is for big networks, its not suitable for small networks (And RIPE will really make you justify your request).

So if you try and bluff a /24 and fail - try and get 2 links from one ISP, as physically diverse as possible into your network (a combo of local Fiber/ethernet + bonded SDSL, or licensed radio).

You can run BGP using private AS numbers to this ISP over both links - using the larger/most robust circuit as your primary link. At least you should be able to get over an individual circuit failure in this way.

johnmd

Hi
Getting your PI /24 actually routed and visible,is not really going to be a runner for you,it will be filtered all over the place.
If your customers firewalls have the option of entering a redundant VPN gateway into their config,simply specifing this on the customer end and your own should sort this out for you.
YOu would mearly give the customer two static IPs and keep with your contract.
Even the Base/Mid range Zywall/Cisco kit will do this.

macrubicon

Getting BGP to do the business is not the hard part - there are a fwe options there in relation to splitting your PI and using different route metrics with Failover and the like. NAT and the like can be made fault tollerant and load balanced using SNAT and the likes.

The problem will be getting a /24 or greater out of RIPE as anything smaller is unlikely to get routed.

djr

....to drag up an old thread, but am i reading this correctly?

http://www.ripn.net:8080/nic/ripe-docs/ripe-332.txt

states that a /29 allocation can be assigned from the 193/8, 194/8 or 195/8 address spaces.

and

"Routing decisions for blocks of address space are the sole
responsibility of network operators. However, network operators taking
routing decisions based on prefix length are requested and encouraged
to route at least blocks of sizes corresponding to the "smallest
allocation" and larger."

...which implies you could pressure your ISPs / carriers into complying with RIPE no?

still on the same old chesnut, multihoming with multiple providers etc...

thanks,

dave.

Moriarty

You misread it a tad.

Routing decisions for blocks of address space are the sole
responsibility of network operators. However, network operators taking
routing decisions based on prefix length are requested and encouraged
to route at least blocks of sizes corresponding to the "smallest
allocation" and larger.

IPv4 CIDR block 	Smallest RIPE NCC	Smallest RIPE NCC 
			**Allocation**		Assignment 
62/8			/19			/19 
80/8			/20			/20 
81/8			/20			/20 
82/8			/20			/20 
83/8			/21			/21 
84/8			/21			/21 
85/8			/21			/21
86/8			/21			/21
87/8			/21			/21
88/8			/21			/21
193/8			*/19*			/29 
194/8			*/19*			/29 
195/8			*/19*			/29 
196.200/13		/20			/24
212/8			/19			/19 
213/8			/19			/19 
217/8			/20			/20

Unfortunately, anything smaller than a /24 of PI space has a very good chance of being unroutable to large portions of the internet. That's not going to change.