BGP – Route-reflector Resilience Design

There are 2 major forms of route-reflector clustering:

1. Two or more RRs in the same cluster

2. Client is a member of multiple clusters

Let’s take a look at how it works in these 2 cases.  Assuming I have 2 RRs, RR1 and RR2 and 2 route reflector client C1 and C2. 

- RR1 has a peer session with RR2

- C1 has 2 peer sessions one to RR1 another to RR2

- C2 has 2 peer sessions one to RR1 another to RR2

Case 1 – Same Cluster, When everything is fine

- C1 gets an update from somewhere and advertise to RR-1 and RR-2

- Both RRs will advertise the update to C2

- RRs will send update to each other, but since the same cluster-id in the update message and it is identical to its own, it will discard the update

Case 2 – Same Cluster, C1-RR2 and C2-RR1 links down

- C1 gets update and advertises to RR1

- C1 can’t advertise to RR2 as the link is down

- RR1 can’t advertise to RR2 as the cluster-id is the same

- As a result C2 can’t get the update (50% of the routers in the cluster)

Case 3 – Different Cluster, When everything is fine

- C1 gets update and advertises to RR1 and RR2

- RR1 will advertise to RR2 and it will process it as the cluster-ids are different, and vice versa

- C2 gets the update

Case 4 – Different Cluster, C1-RR2 and C2-RR1 links down

- C1 gets update and advertise to RR1

- RR1 advertises to RR2 and it is accepted, as cluster-ids are different

- C2 will gets the update

- Therefore it provides better redundancy

If you want to know more on different forms of RR redundancy design, here is a good presentation on this topic:

http://www.ripe.net/ripe/meetings/ripe-42/presentations/ripe42-eof-bgp/index.html

BGP – Local Preference

Local preference is used to prefer an exit point for local AS when there are multiple exit points. 

My topology:

R1 – FR – R2

|             |

R4 – FR – R3

R1 in AS100 and R2, R3 and R4 in AS200.

Now I want to make sure that routers in AS200 uses R4 to reach network 1.0.0.0/8 in AS 100 using local preference.

R4(config)#access-list 1 permit 1.0.0.0
R4(config)#route-map setlocalpref permit 10
R4(config-route-map)#match ip addr 1
R4(config-route-map)#set local-preference 1000
R4(config-route-map)#route-map setlocalpref permit 20
R4(config-route-map)#router bgp 200
R4(config-router)#nei 123.1.14.1 route-map setlocalpref in

The route-map should be configued in the IN direction since the local preference affects the routers within the AS.

Before and After (on R2) – show ip bgp

BGP – aggregate-address

To advertise a summary route in BGP, aggregate-address is used. 

Example

The topology is:

R1 --- FR --- R2

BEFORE summarize the route:

R1 – show ip bgp

R2 – show ip bgp

To summarize the 2.x.x.x network, aggregate-address is used.

R2(config)# router bgp 200

R2(config-router)# aggregate-address 2.2.0.0 255.255.252.0

R1 – show ip bgp

R2 –show ip bgp

A summary route

*> 2.2.0.0/22       0.0.0.0                            32768 i

is advertised to R1.

Note that by default the aggregate AND ALL the specific routes are advertised.  If you want to suppress the specific routes, use the “summary-only” argument.

R2(config-router)#aggregate-address 2.2.0.0 255.255.252.0 summary-only

R1 – show ip bgp

 

R2 – show ip bgp

Notice that the specific routes are suppressed, only the summarized routes are advertised to the neighbors.

2 attributes are displayed: aggregator and atomic aggregate.

The aggregator attribute identifies the router that performed the aggregation.  In this case it is 2.2.3.2.

The atomic-aggregate attribute tells us that some information is lost because of aggregate.