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.
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:
Post a Comment