Scaling i BGP BGP i BGP Internal BGP

Scaling i. BGP

BGP • i. BGP – 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. • e. BGP – External BGP – BGP peering between routers in different ASes

AS 3 External BGP 1 a AS 1 1 d AS 2 AS 4 1 b 1 c Internal BGP AS 5

AS 3 1 a AS 2 1 b 1 d 1 c Routes arriving from AS 2 will be redistributed via i. BGP from 1 b to 1 a, 1 c, 1 d. AS 5 AS 4

AS 3 1 a AS 2 1 b 1 d 1 c 1 d will announce route learned to AS 4 if appropriate • BGP decision process AS 5 AS 4

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

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 i. BGP sessions each time a new e. BGP router is added to AS • Significant BGP protocol overhead for each router

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

Scaling i. BGP: Confederations AS 1 e. BGP i. BGP e. BGP AS 64513 i. BGP e. BGP AS 64514 i. BGP e. BGP AS 64515 e. BGP

Scaling i. BGP: Confederations • full i. BGP mesh within confederation • e. BGP between confederations • e. BGP to external ASes • AS_CONFED_SEQUENCE • AS_CONFED_SET • AS_CONFED numbers are removed from routes propagated outside parent AS

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

Scaling i. BGP: Route Reflectors AS 1 e. BGP cluster e. BGP i. BGP RR i. BGP e. BGP i. BGP client i. BGP non-client i. BGP e. BGP

Scaling i. BGP: 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

Scaling i. BGP: Route Reflectors • Advantage: Incremental deployment – Non-RR speakers continue with i. BGP mesh – Though less i. BGP sessions as they are a nonclient of RR

BGP RR attributes • BGP-optional, non-transitive attributes – used in RR situation to prevent routing information loops • ORIGINATOR_ID – 4 bytes, specifies the i. BGP 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

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

Hierarchical Route Reflection AS 1 RR RR RR

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

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)