generate default route and export to kernel if remote peer is up

[Nikola Mitev]

On Fri, 2018-09-07 at 09:44 -0600, Grant Taylor wrote:
> > I have a setup of ISP1 -- R1 -- LAN -- R2 -- ISP2 with BGP peerings
> > from 
> > R1 to ISP1 and R2 to ISP2
> Are your BGP neighbors advertising a default route to you?

Unfortunately no. I am creating the second peering now, the one which
is live is through a Hurricane Electric 6in4 tunnel - it is a free
service and I am not sure how much I can ask of them.

> I would think that R1 and R2 would iBGP neighbors (or similar with
> other 
> protocols) with each other.  Thus they would both re-advertise the 
> default that each receives to the other.
> 
> This has the added benefit of R2 learning prefixes that are close to 
> ISP1 and routing out that way instead of going out ISP2 and around
> the 
> Internet to get back to prefixes close to ISP1.

My only concern here is adding the entire BGP routing table to the
kernel table - would that be safe to do and easy enough to work with?
Is there a better way that I'm missing?

> > Some hosts on the LAN have R1 as primary gateway, others R2 to
> > distribute 
> > the load between the ISPs.
> Okay.
> 
> I'd think seriously about VRRP or ideally GLBP for this.

You are right - as it happens I am already redesigning that part.
Multiple default gateways distributed with DHCP seemed like an simple
solution but it doesn't work for me - not sure what needs to happen for
a host to actually make use of the secondary gateway.

> It's my understanding that Gateway Load Balancing Protocol can allow
> all 
> GLBP members to be active and share load where as VRRP will have one 
> active member.  —  You can have two VRRP ""routers and divide
> clients 
> between them that way.

It will have to be VRRP since the routers are both PC Engines APU
boards running Debian.

> > I want to add a default route to the kernel on each router but only
> > if 
> > the remote peer is up. The remote peer does not respond to BFD so
> > that's 
> > not an option.
> I've been wanting a solution to this problem for about 20 years.
> 
> Specifically I want to be able to detect if the static default
> gateway 
> is functioning or not and dynamically alter the local routing
> tables.  — 
>   I've not found a solution for this yet.  (Granted, I've not spent
> a 
> lot of time trying to find one.)

A negative answer is still a good answer :) Should be able to script
some pinging/BGP connection state tracking solution. Just wanted to be
sure I'm not reinventing the wheel as it will no doubt take some time
to test & get it right.

> 
> I had hoped that BFD would do this, but that apparently requires
> active 
> support from the remote neighbor.

Yep.

> This can get complicated if the local link doesn't go down when the 
> remote neighbor is not reachable.  I.e.:
> 
> [router]---[switch]-X-[bridging DSL modem]-X-[ISP router]
> 
> The Ethernet between the router and the switch is up/up, but the link
> on 
> either side of the modem is down.

In my case it's a 6in4 tunnel which should go down if the remote goes
but I am yet to find out in what ways may the remote fail. Seems
perfectly possible the tunnel remains up but the BGP session breaks
etc. The BGP session breaking doesn't mean outbound routing is broken
but is likely to cause some asymmetric routing as the replies start
coming back through the other ISP.

> The only way that I've contemplated solving this is to watch traffic 
> coming back from the Internet via the ISP's router, and dynamically 
> modify the local routing tables.

If you mean BGP session traffic on TCP/179 that could work, otherwise
my link might not be busy enough at times.

> I can see this as a simple test of is anything coming in from the
> ISP 
> -or- something beyond the ISP's router.
> 
> Can this be extended to watch routes to / from specific destinations 
> (via the gateway)?  Should this be done?

It's easy on a linux box. I'm thinking track the BGP session with e.g.
'ss -npt state established | grep :179 |wc -l' say every second and
then doing a ping every 5s or so. It will need up/down wait timers
tuned.

> Seeing as how I haven't found an answer for this problem, I'd
> strongly 
> encourage you to try to get your BGP neighbors to advertise a
> default 
> route over the existing BGP neighbor sessions.

I'll ask and see how far I get :)

> > I searched for a recipe that would fit the above but found nothing
> > yet, 
> > hoping someone here can help :)
> I'd love to see a suggestion from someone too.

Thanks for your reply.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20180908/2b21ecec/attachment.sig>