VRRP and BGP - default disabled behaviour and BGP trigger

Hi,
I am having two BGP servers in VRRP cluster, Both of servers having established BGP sessions to upstream, and prepending paaths according to VRRP situation.
This work smooth and with 100ms vrrp interval, outage is no loger than 300ms.

I am using preemption, because 1st server is always prefered.
Problem is, when I will shutdown 1st server, 2nd will come as master, but when I will power on 1st server again, it becoming a master immediatly after boot-up
This is ok, but time of establishing bgp sessions and fetching tables is roughly about 12-15 seconds.

Have you considered adding following thing:

  1. Default behaviour of VRRP interface - disabled on boot (option, of course)
  2. Adding VRRP enable triggers, I mean establishing BGP session and reaching > 600k tables

This would short outage in our case. I know can make scripting, but polling for state each X seconds is not good way, default-disabled behaviour and triggers would be much better,as interface will handover traffic when it’s completly ready to do that.

ps.
also consider instead of making static route number values (like 600k) just add another BGP state: connect, established… maybe add fetching-prefixes after connect, and before established, so it might simplify eventual scripting process? router will know when it will fetch all initial prefixes , so we don’t need to put any static values (as this may be problematic on BGP outage somewhere upstream, when BGP tables will drop 590k or so).

You should create a direct cable link between the two routers and allow them to forward packets between each other directly. This would fix your problem because when VRRP comes up, the newly-booted router could pass traffic through the well-established router while its routing table gets populated by eBGP.

If you have no more physical interfaces, you could do the “router-on-a-stick” method where your backup static default GW just points at the other router via the LAN interface (use the real IP of the other router) - this hairpins traffic through an interface, but it would at least work temporarily, and only affects the outbound traffic.

I can’t believe I am so dumb :smiley:

Yeah, seems adding default route on BGP1 pointing to BGP2 real-IP instance (not vrrp) should do the job, Since I already have L2 connectivity between those routers
So when adding more specific prefixes from BGP, it will send data upon newly established BGP link
For inboud traffic, I do not care, because my gateway and BGP linked routers with static routes , well maybe its not good way (but inside that BGP “core” vlan , I am assure no spoofed traffic will come), but rp_filter disabled and those gateways will accept incoming data from both routers, when in transition state

Just wondering about adding default route on BGP2 router - I think I will leave it as-is, because when gateway will look for prefix not foudn in BGp table, they will ping-pong packets till TTL exceed, am I correct?

I mean GW → BGP1 (prefix not found, fw to default gw) → BGP2 (not found, forward to default gw) → BGP1

Yes. If both BGP routers have no connectivity, then they would ping-pong packets until TTL expires. I would say that this is probably not an issue since being fully down is going to be a bigger concern…