iBGP: Route Reflectors
In order to correctly spread knowledge iBGP requires a full mesh of peering. This is true even in a hub’n’spoke network. Typically iBGP needs to be used in a service provide network for carrying (= transit) and announcing BGP routes towards border eBGP routers. The full mesh of iBGP neighborships is in this situation a clear scalability problem. Route Reflector is an aid for achieving scalability of iBGP in large networks, limiting the number of iBGP sessions to a minimum.
For the iBGP sessions a Route Reflector router becomes the hub center iBGP speaker of a star of iBGP sessions, with Route Relfector “Clients” as spokes. Clients need only a standard iBGP session to the RR(s) in the “Cluster”. As iBGP DOES NOT MODIFY the next_hop attribute this does not impose the same topology from a forwarding plane perspective: the route reflector do not need (as normally it is designed) to be in the path of the announced routes and to forward any payload traffic.
The basic idea is that the RR work around the BGP “split horizon” rule and reflect the announcements of a RR client to all other RR clients, releasing the full mesh for a simplified star topology. As Route Reflectors reflect announcements BUT DO NOT change the next hop attribute, this allows routes to be distributed while not influencing traffic routing flow.
As the only modification in iBGP behaviour is on the Route Reflector servers (the reflection of one neighbor rout, to all other neighbors), no configuration is required on clients. RR Clients are not aware of the RR Server precence and work as with usual iBGP peers.
As the role of RR in the signaling of route becomes crucial, making RR servers redundant is often a design must. RR servers peer with each other as normal iBGP peers, all clients peering with them. Therefore routes are reflected by two RR sources. To avoid route advertisements loops an “originator-id” community is added as a tag to the advertisement by the RR server, only to be checked by RR servers in order to not install own routes (as potentially reflected back).
Further, in case of very large iBGP networks, a hirarchy or RR clusters can be built: for instance a cluster A with two redundant RRs and another cluster B with other two RRs. Each RR client would be member of either the first or second cluster, and all RRs will have usual iBGP full mesh between each other. A RR router will anyway only RR for one cluster only (in a higher level of hierarchy is present it could be client only for other clusters). The cluster-id attribute is set by RR to recognize if a route is reflected back to the same cluster. Redundant RR in the same Cluster use identical cluster-id.
Design Rules:
– Divide the iBGP domain in clusters;
– Each cluster should have two RRs;
– RR-Clients have only standard iBGP neighborships to the RRs (double-star), accepting the Originator ID;
– Non RR clients (non recognizing the Originator ID) need to have full iBGP mesh to all clients and RRs;
– RR have full mesh iBGP to non RR clients (including other RRs, also from other clusters);
– Eventually hierarchy can be applied (RRs of level x-1 are clients to RRs of level X);
Configuration:
– If multiple RR in the cluster are needed, configure the Cluster-ID explicitely. The cluster-ID is by default initialized to the Router-ID and is 4 bytes long;
– If multiple Clusters are needed, also configure the Cluster-ID explicitely. The cluster-ID is by default initialized to the Router-ID and is 4 bytes long;
– Add then all RR-clients using the “neighbor route-reflector-client”;
Note: RR ignore “set” clauses in outbound route maps to clients. This could possiblycreate routing loops. To avoid this behavior, set clauses of outbound route maps are ignored for routes reflected to iBGP peers. Set the attributes on the clients, instead.
hostname 1600b
!
router bgp 100
no synchronization
bgp router-id 192.168.0.5
bgp cluster-id 3232263425
bgp log-neighbor-changes
bgp bestpath med missing-as-worst
timers bgp 30 90
neighbor Route_Reflector_client peer-group
neighbor Route_Reflector_client remote-as 100
neighbor Route_Reflector_client password test_pswd
neighbor Route_Reflector_client update-source Loopback999
neighbor Route_Reflector_client route-reflector-client
neighbor 192.168.0.3 peer-group Route_Reflector_client
neighbor 192.168.0.6 peer-group Route_Reflector_client
neighbor 192.168.104.1 remote-as 400
neighbor 192.168.109.2 remote-as 200
!
end
hostname 1600a
!
router bgp 100
no synchronization
bgp router-id 192.168.0.6
bgp log-neighbor-changes
bgp bestpath med missing-as-worst
timers bgp 30 90
neighbor eBGP_to_AS400 peer-group
neighbor eBGP_to_AS400 remote-as 400
neighbor Route_Reflector peer-group
neighbor Route_Reflector remote-as 100
neighbor Route_Reflector password 7 051F031C35735E1A0E01
neighbor Route_Reflector update-source Loopback999
neighbor 192.168.0.5 peer-group Route_Reflector
neighbor 192.168.103.1 peer-group eBGP_to_AS400
neighbor 192.168.107.1 peer-group eBGP_to_AS400
!
end
hostname 1720b
!
router bgp 100
no synchronization
bgp router-id 192.168.0.3
bgp log-neighbor-changes
bgp bestpath med missing-as-worst
timers bgp 30 90
neighbor Route_Reflector peer-group
neighbor Route_Reflector remote-as 100
neighbor Route_Reflector update-source Loopback999
neighbor Route_Reflector password test_pswd
neighbor 192.168.0.5 peer-group Route_Reflector
neighbor 192.168.102.1 remote-as 400
neighbor 192.168.106.2 remote-as 300
no auto-summary
!
end
iBGP: Confederations
Confederations are an alternative to RR, aimed to solve the same issue (scalability of iBGP, avoiding full iBGP mesh). While RR basically modifies the iBGP “split horizon” rule, confederations take a different approach: make iBGP more similar to eBGP in the way that only direct peers need a session. To achive this, the (public) AS is “subdivided” into areas, each one assigned a private AS number (64512-65535); “confederated eBGP sessions” work similar to eBGP BUT modify attributes as in iBGP. Within any confederation private AS, iBGP works as usual; when “real” eBGP is done (to outside the confederation) “intra-confederation” private AS numbers” are removed, making the AS still appear as one single AS.
Modifications to the population of attributes:
· The AS-PATH within the confederation is formatted differently: “Intraconfederation-AS numbers” are codified closed into “()” for lately being recognised and removed, other AS numbers left in the AS Path as usual.
· The Next-hop is NOT changed across “confederated eBGP sessions” (as in iBGP)
· MED is treated within the logic of the entire AS: it is propagated across the confederated private AS boundaries. If MED is to be used across confederated AS boundaries, the “bgp bestpath med confed” must be used.
· Local Pref is bounded to the memeber AS and propagated by confederated eBGP peers.
Configuration:
1. To configure a BGP confederation, you must specify a confederation identifier at all routers. To the outside world, the group of member autonomous systems will look like a single autonomous system with the confederation identifier as the autonomous system number. The BGP process AS though must be the memeber AS in the confederation.
Router(config)router bgp 65000
Router(config-router)bgp confederation identifier 200
2. Specifies the memeber autonomous systems that belong to the confederation.
Router(config-router)bgp confederation peers 65001 65002
3. Configure neighborships and commands as usual:
Router(config-router)network 10.0.1.0 route-map set-community
Router(config-router)neighbor 172.16.232.50 remote-as 100
Router(config-router)neighbor 172.16.233.2 remote-as 65001
4. Specials: modify the use of MED. By default MED is treated as usual. Sent to eBGP neighbors, removed from iBGP neighbors, checked from the same neighbor, etc. In case MED needs to be used for intra-confederation purposes only, the following can be set to configure the router to consider the MED in choosing a path from among those advertised by different sub-autonomous systems within a confederation, but not if a real AS appears in the path. If there is an external autonomous system in the path, then the external MED is passed transparently through the confederation, and the comparison is not made.
Router(config-router) bgp bestpath med confed
The following example compares route A with these paths:
path1= 65000 65004, med=2
path2= 65001 65004, med=3
path3= 65002 65004, med=4
path4= 65003 1234, med=1
In this case, path1 would be chosen if the “bgp bestpath med confed” router configuration command is enabled. The fourth path has a lower MED, but it is not involved in the MED comparison because there is an external autonomous system is in this path.
hostname 1600b
!
router bgp 65001
no synchronization
bgp confederation identifier 100
bgp confederation peers 65002 65003
bgp router-id 192.168.0.5
bgp log-neighbor-changes
bgp bestpath med missing-as-worst
timers bgp 30 90
neighbor 192.168.105.1 remote-as 65002
neighbor 192.168.104.2 remote-as 65003
neighbor 192.168.104.1 remote-as 400
neighbor 192.168.109.2 remote-as 200
!
end
hostname 1600a
!
router bgp 65002
no synchronization
bgp confederation identifier 100
bgp confederation peers 65001 65003
bgp router-id 192.168.0.6
bgp log-neighbor-changes
bgp bestpath med missing-as-worst
timers bgp 30 90
neighbor eBGP_to_AS400 peer-group
neighbor eBGP_to_AS400 remote-as 400
neighbor 192.168.105.2 remote-as 65001
neighbor 192.168.103.1 peer-group eBGP_to_AS400
neighbor 192.168.107.1 peer-group eBGP_to_AS400
!
end
hostname 1720b
!
router bgp 65003
no synchronization
bgp confederation identifier 100
bgp confederation peers 65001 65002
bgp router-id 192.168.0.3
bgp log-neighbor-changes
bgp bestpath med missing-as-worst
timers bgp 30 90
neighbor 192.168.104.254 remote-as 65001
neighbor 192.168.102.1 remote-as 400
neighbor 192.168.106.2 remote-as 300
no auto-summary
!
end
Path Selection: as usual. Note Member AS are NOT counted!
1600ash ip bgp
BGP table version is 4, local router ID is 192.168.0.6
Status codes: s suppressed, d damped, h history, valid, > best, i – internal
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
> 0.0.0.0 192.168.106.2 4294967294 100 0 (65001 65003) 300 200 i
> 10.30.0.0/16 192.168.106.2 0 100 0 (65001 65003) 300 i
10.40.0.0/16 192.168.103.1 4294967294 0 400 i
> 192.168.107.1 0 0 400 i
1600ash ip bgp 10.40.0.0
BGP routing table entry for 10.40.0.0/16, version 3
Paths: (2 available, best 2)
Advertised to peer-groups:
eBGP_to_AS400
Advertised to non peer-group peers:
192.168.105.2
400
192.168.103.1 from 192.168.103.1 (192.168.0.2)
Origin IGP, metric 4294967294, localpref 100, valid, external
400
192.168.107.1 from 192.168.107.1 (192.168.0.1)
Origin IGP, metric 0, localpref 100, valid, external, best
=> Prefix W LcPref AS Origin MED iB/eB igp BGP ID
— ————- —— —— —– —— — ——– — ————-
10.40.0.0/16 0 100 400 igp 4294.. extern – (192.168.103.1)
> 10.40.0.0/16 0 100 400 igp – extern – (192.168.107.1)
=> MED is the tie breaker.
1600bsh ip bgp
BGP table version is 4, local router ID is 192.168.0.5
Status codes: s suppressed, d damped, h history, valid, > best, i – internal
Origin codes: i – IGP, e – EGP, ? – incomplete
> 0.0.0.0 192.168.106.2 4294967294 100 
0 (65003) 300 200 i
> 10.30.0.0/16 192.168.106.2 0 100 0 (65003) 300 i
10.40.0.0/16 192.168.104.1 4294967294 0 400 i
> 192.168.107.1 0 100 0 (65002) 400 i
=> MED is the tie breaker. AS-PATH does not count memeber AS.
1720bsh ip bgp
BGP table version is 4, local router ID is 192.168.0.3
Status codes: s suppressed, d damped, h history, valid, > best, i – internal,
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
> 0.0.0.0 192.168.106.2 4294967294 0 300 200 i
> 10.30.0.0/16 192.168.106.2 0 0 300 i
10.40.0.0/16 192.168.102.1 4294967294 0 400 i
> 192.168.107.1 0 100 0 (65001 65002) 400 i
=> MED is the tie breaker. AS-PATH does not count memeber AS.
Making 1600b preferred to AS400:
1600b(config-router)neighbor 192.168.104.1 weight 1000
1600abgc
router bgp 65002
no synchronization
bgp router-id 192.168.0.6
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 65001 65003
bgp bestpath med missing-as-worst
timers bgp 30 90
neighbor eBGP_to_AS400 peer-group
neighbor eBGP_to_AS400 remote-as 400
neighbor 192.168.103.1 peer-group eBGP_to_AS400
neighbor 192.168.105.2 remote-as 65001
neighbor 192.168.105.2 route-map SET_PREF in
neighbor 192.168.107.1 peer-group eBGP_to_AS400
!
route-map SET_PREF permit 10
set local-preference 200
!
end
1600ash ip bgp
BGP table version is 36, local router ID is 192.168.0.6
Status codes: s suppressed, d damped, h history, valid, > best, i – internal
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
> 0.0.0.0 192.168.106.2 4294967294 200 0 (65001 65003) 300 200 i
> 10.30.0.0/16 192.168.106.2 0 200 0 (65001 65003) 300 i
> 10.40.0.0/16 192.168.104.1 4294967294 200 0 (65001) 400 i
192.168.103.1 4294967294 0 400 i
192.168.107.1 0 0 400 i