17 November 2014

iBGP Peering - Using Router Reflector Option

A route reflector (RR) is a network routing component. It offers an alternative to the logical full-mesh requirement of internal border gateway protocol (IBGP)

Clients advertise BGP updates to servers, and servers then reflect them to the other clients. Here a example:


Before the reflector configuration:

R1
router bgp 109
nei 131.108.1.2 remote-as 109
nei 206.56.89.1 remote-as 109

R8
router bgp 109
net 100.100.100.0 mask 255.255.255.0
nei 206.56.89.2 remote-as 109
ip route 100.100.100.0 255.255.255.0 null 0

R2
router bgp 109
nei 131.108.1.1 remote-as 109

iBGP comes with a significant restriction: iBGP peers should not re-advertise iBGP-learned routes to other iBGP speakers, which is why they all need to be fully meshed. If you can’t re-advertise IBGP routes, you must be directly connected to the originator of the route, hence the full mesh requirement. Remember, iBGP has no dedicated loop prevention mechanism, and this is why you need route reflectors for large networks.

R1# sh ip bgp
BGP table version is 2, local router ID is 206.56.89.2
...
Network          Next Hop            Metric LocPrf Weight Path
*>i 100.100.100.0/24 206.56.89.1              0    100      0 i

R1# sh ip bgp 100.100.100.0
BGP routing table entry for 100.100.100.0/24, version 2
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
206.56.89.1 from 206.56.89.1 (206.56.89.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

R2# sh ip bgp summary
BGP router identifier 131.106.1.2, local AS number 109
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
131.106.1.1     4          109       5       4        1    0    0 00:00:17        0

R2# sh ip bgp
<empty>

Route reflection allows sharing of routing information among a group of routers without having to send the exact same information to each of them individually.

So, let's add the magic line:

R1# sh run | s bgp
router bgp 109
bgp log-neighbor-changes
neighbor 131.106.1.2 remote-as 109
neighbor 131.106.1.2 route-reflector-client
neighbor 206.56.89.1 remote-as 109
neighbor 206.56.89.1 route-reflector-client

And.. see the result..

R1# sh ip bgp 100.100.100.0
BGP routing table entry for 100.100.100.0/24, version 4
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2         
Refresh Epoch 1
Local, (Received from a RR-client)
206.56.89.1 from 206.56.89.1 (206.56.89.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

R2# sh ip bgp
BGP table version is 4, local router ID is 131.106.1.2
...
Network          Next Hop            Metric LocPrf Weight Path
*>i 100.100.100.0/24 206.56.89.1              0    100      0 i

R2#sh ip bgp 100.100.100.0
BGP routing table entry for 100.100.100.0/24, version 4
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
Local
206.56.89.1 (metric 20) from 131.106.1.1 (206.56.89.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 206.56.89.1, Cluster list: 206.56.89.2
rx pathid: 0, tx pathid: 0x0

If a route is received from nonclient peer, reflect to clients only.
If a route is received from a client peer, reflect to all nonclient peers and also to client peers, except the originator of the route.
If a route is received from an EBGP peer, reflect to all client and nonclient peers.
A router reflector is a single point of failure, therefore redundancy
should be implemented in a network containing router reflectors.


biOos

No comments: