Does BGP aggregation increase convergence time?

[lionell1000]

---

Hello, 

We have a DC, DR setup with a router at each site having an eBGP neighborhood with the same remote site router. 

At both sites, we are only advertising our supernets (aggregate summary only) and controlled via outbound route-maps so smaller routes are not advertised.

We have OSPF running in LAN and being redistributed into BGP. Total 5 routes/supernets being advertised. 3 of these have null 0 routes within LAN and learner by OSPF so the aggregate address is not really necessary. 2 of them really depend on the aggregate command.

Below is our observation -

When the DR BGP neighborship fails, traffic for all user seamlessly fails over to DR with no impact to end users (probably because the neighborship and advertisements are in place).

When DC eBGP comes up and traffic fails over to DC which is automatic, the user in the 2 subnets (which need aggregation) face issues. The other users do not.

Sorry if this is confusing but can elaborate as required. Is aggregation causing this?

[balaji.bandi]

When DC eBGP comes up and traffic fails over to DC which is automatic, the user in the 2 subnets (which need aggregation) face issues. The other users do not.

this required more information and config example to suggest.

[Georg Pauwen]

Hello,

hard to say. What is the output of:

show ip route x.x.x.x

where 'x.x.x.x' is the aggregate ?

[MHM Cisco World]

please can we see show ip bgp for both DC and DR ?

[paul driver]

Hello

---

@lionell1000 wrote:

---

we are only advertising our supernets (aggregate summary only)

We have OSPF running in LAN and being redistributed into BGP. Total 5 routes/supernets being advertised.

When DC eBGP comes up and traffic fails over to DC which is automatic, the user in the 2 subnets (which need aggregation) face issues. The other users do not.

---

When the ebgp session re-establishes it’s possible that the routing path can become asymmetric and be sub-optimal and the reason being is due to the way mutual redistribution occurs between bgp and igp.

As the Ebgp session fails, the igp routes take precedence and routing will go via your rtrs lan igp peering

However, as the ebgp session comes back, the wan rtr will receive routes via the ebgp peer and also the same prefixes from your other wan rtr redistributed into bgp via igp.

Now you would have dual routes in bgp rib table however the redistributed igp routes have an additional weight value attached 32768
1- via wan (no weight)
2- via igp ( 32768)

And due to bgp best path selection the weight attribute is most preferred , so your wan rtr would install the igp route in its route table and then still route via IGP path even though your failed ebgp session has re-established.

The way to negate such race condition would be to set a default weight on the ebgp peering higher than 32768

neighbour <isp> weight 40000

Another cause could be the way you have setup aggregation for the longer prefixes within that summary, as by default the As numbers(s) from the rtrs that those prefixes have originated would be hidden in the summary route which could negate bgp loop prevention upstream, usually I would set any aggregation with the as-set command

aggregate-address x.x.x.x y.y.y.y.y summary-only as-set