1. Scaling iBGP

2. BGP iBGP –Internal BGP –BGP peering between routers in same AS –Goal: get routes from a border router to another border router without losing detail Communities, localpref, etc. eBGP –External BGP –BGP peering between routers in different ASes

3. AS1 External BGP Internal BGP 1a 1b 1c 1d AS2 AS3 AS4 AS5

4. 1a 1b 1c 1d AS2 AS3 AS4 AS5 Routes arriving from AS2 will be redistributed via iBGP from 1b to 1a, 1c, 1d.

5. 1a 1b 1c 1d AS2 AS3 AS4 AS5 1d will announce route learned to AS4 if appropriate BGP decision process

6. iBGP Requirement for Full Mesh An iBGP router will not further advertise a prefix with its own ASN in AS path –to prevent routing information loops Therefore iBGP has to be in full mesh for eBGP routes to propagate; (n * (n-1)) / 2 3 peers, 3 sessions4 peers, 6 sessions 5 peers, 10 sessions

7. Scaling Issues 100 peers; 4950 sessions 101 peers; 5050 sessions Requires significant operator resource whenever new router is added to network –operator has to manually setup n-1 iBGP sessions each time a new eBGP router is added to AS Significant BGP protocol overhead for each router

8. Two Methods for Scaling iBGP Confederations –RFC 5065 Route reflection –RFC 4456 Both approaches break AS into hierarchy to reduce size of iBGP domain –logical hierarchy tends to follow physical structure

9. Scaling iBGP: Confederations iBGP eBGP AS 1 AS 64513AS 64514 AS 64515 eBGP

10. Scaling iBGP: Confederations full iBGP mesh within confederation eBGP between confederations eBGP to external ASes AS_CONFED_SEQUENCE AS_CONFED_SET AS_CONFED numbers are removed from routes propagated outside parent AS

11. Scaling iBGP: Confederations Advantages –Easier to deal with smaller iBGP mesh when new eBGP router is added –Reduces number of iBGP sessions Disadvantage –Requires network to be reconfigured; no incremental deployment

12. Scaling iBGP: Route Reflectors iBGP AS 1 eBGP RR iBGP eBGP iBGP cluster non-client iBGP client iBGP

13. Scaling iBGP: Route Reflectors Clients vs. non-clients –RR clients should not peer with routers outside cluster –Non-clients of RR must be fully meshed –Easier to add new client to RR cluster than to add non-client. RR will only advertise best paths learned

14. Scaling iBGP: Route Reflectors Advantage: Incremental deployment –Non-RR speakers continue with iBGP mesh –Though less iBGP sessions as they are a non-client of RR

15. BGP RR attributes BGP-optional, non-transitive attributes –used in RR situation to prevent routing information loops ORIGINATOR_ID –4 bytes, specifies the iBGP router that first announced the route –Router should ignore prefix with its own ORIGINTOR_ID in this field CLUSTER_ID –4 bytes, specifies a RR cluster the prefix came from CLUSTER_LIST –List of CLUSTER_ID fields –A router should ignore prefix with its own CLUSTER_ID in it

16. Scaling iBGP: Route Reflectors Need redundancy in RR cluster –If RR fails, clients become isolated. –Solution: multiple RR per cluster RR

17. Hierarchical Route Reflection AS 1 RR

18. Putting it all together AS 1 RR,P PE RR,P

19. Further Reading Chapter 8, Internet Routing Architectures (Bassam / Halabi) RFC 5065 - Autonomous System Confederations for BGP RFC 4456 - BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)