1 / 39

Lecture 4

Lecture 4. Route Aggregation. The process of representing a group of prefixes with a single prefix is known as route aggregation. Benefits of route aggregation Reduction in BGP routing table size Drawbacks of route aggregation

zocha
Download Presentation

Lecture 4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 4

  2. Route Aggregation • The process of representing a group of prefixes with a single prefix is known as route aggregation. • Benefits of route aggregation • Reduction in BGP routing table size • Drawbacks of route aggregation • The individual route path information (e.g., AS numbers) is not included in the summarized route • As a result, potential for routing loops.

  3. (NLRI= 172.64.0.0/16, AS_Path{AS400}) (NLRI= 172.64.14.0/8, AS_Path{AS100}) AS 500 (NLRI= 172.64.15.0/8, AS_Path{AS200}) (NLRI= 172.64.0.0/16, AS_Path{AS400, AS500}) 172.64.15.0/8 172.64.14.0/8 172.64.16.0/8 AS 200 AS 100 AS 300 AS 400 (NLRI= 172.64.16.0/8, AS_Path{AS300}) AS 600 Routing loop Update (172.64..0.0/16, AS_Path = {AS400, AS500, AS600})

  4. AS_Set List • The loss of path information in the summarized route (or aggregate) can be compensated by using AS_SET list. • AS_Set is an unordered set of AS traversed by route. • Because the aggregate using AS_Set list keeps tracks of path attributes (e.g., AS numbers), this helps to eliminate routing loops.

  5. (NLRI= 172.64.0.0/16, AS_Path{AS400 (AS100,AS300,AS200}}) (NLRI= 172.64.14.0/8, AS_Path{AS100}) AS 500 (NLRI= 172.64.15.0/8, AS_Path{AS200}) (NLRI= 172.64.0.0/16, AS_Path{AS400, AS500}) 172.64.15.0/8 172.64.14.0/8 172.64.16.0/8 AS 200 AS 100 AS 300 AS 400 (NLRI= 172.64.16.0/8, AS_Path{AS300}) AS 600 Update rejected Update (172.64..0.0/16, AS_Path = {AS400, AS500, AS600{AS100,AS300,AS200}})

  6. Local Preference (Local_Pref) Attribute • Local_Pref is a well-known, discretionary attribute. • A BGP speaker use this attribute to indicate its local preference for the advertised route to other speakers in the same AS. • Local_Pref attribute is local to the AS and get exchanged between iBGP peers (not between eBGP peers). • A larger value for Local_Pref indicates higher degree of preference. • Local_Ref attribute is commonly used to select (prioritize) AS exit points.

  7. 192.32.64.0/8 AS200 Traffic OC30 R3 iBGP DS3 AS300 AS600 R2 iBGP 192.32.64.0/16 192.32.64.0/8 iBGP AS100 R1 DS1 AS400 192.32.64.0/8 R1 Sets Loc_pref = 100 R2 Sets Loc_pref = 200 R3 Sets Loc_Pref = 300

  8. Multi_Exit_Disc (MED) Attribute • MED (Attribute Type Code = 4) is an optional non-transitive attribute. • MED is exchanged between eBGP peers • MED attribute that is received from an eBGP peer can be propagated to iBGP peers but not to eBGP peers. • If all other factors assumed the same, BGP decision process selects a route with lower MED value. • The MED parameter is based on IGP metric value. • IGP metric shows proximity of destination to the exit point • Thus MED value based on IGP metric allows traffic entry from exits which are closer to destinations • The advertising AS uses MED parameter to influence outgoing traffic of another AS.

  9. MED = 50 192.32.64.0/16 192.32.64.0/16 MED = 200 AS200 Traffic AS300 AS600 192.32.64.0/16 192.32.64.0/16 MED = 100 AS400

  10. Next_Hop Attribute • Next_Hop attribute is a well-known mandatory attribute. • Next_Hop attribute contains IP address of the border router that should be used as a next hop when forwarding traffic for destinations listed in NLRI field. • In IGP, the next hop refers to a directed connected neighbor. • In BGP, however, next hop may refer to directly or indirectly connected neighbor. • When a route is learned from an eBGP peer, the BGP Next_Hop for the route is the IP address of the eBGP peer. • If this route is in turn advertised to an iBGP peer, its Next_Hop attribute is passed without any changes. • When a route is originated inside an AS, its BGP Next_Hop is the IP address of the originating router.

  11. R2 R1 iBGP R3 AS 300 3 3 2 1 2 1 eBGP R4 iBGP R5 R6 R6 originates a BGP route for 179.16.12.0/8 with NEXT_HOP = R6’s IP address. R3 installs the route with R4 as the next hop and advertises this route to R1 with NEXT_ HOP = R4’s IP address. R4 installs the route with R6 as the next hop and advertises this route with NEXT_HOP = R4’s IP address. AS 200

  12. Next_Hop and Recursive Lookup • We have seen that BGP Next_Hop does not necessarily contains the IP address of a directly connected peer. • Before BGP can install a route, its BGP Next_Hop address must be resolved. • A BGP speaker immediate next hop to the address contained in the Next_Hop attribute via recursively looks up in the IGP routing table. • A BGP route with unresolved (unreachable) Next_Hop address is considered to be an inaccessible route and excluded from the BGP decision process.

  13. R2 178..65.16.0 If1 R1 iBGP R3 178..64.16.0 2 1 eBGP AS 300 192.32.16.0 R4 192.29..18..0 AS 200 R1’s Routing Table Destination BGP Next Hop 192.32.16.0 192.29.18.0 R1’s Routing Table Destination IGP next hop 192.32.16.0 192.29.18.0 192.32.16.0 178..65.16.0 178..65.16.0 If1

  14. Atomic_Aggregate Attribute • The Atomic_Aggregate is a well-known discretionary attribute. • Whenever a BGP speaker summarize routing information that cause loss of information, it sets the Atomic_Aggregate to inform other speakers. • A BGP speaker does not need to attach Atomic_Aggregate if loss of routing information has been indicated through other means (e.g., AS_Set list)

  15. Aggregator Attribute • The Aggregator is a an optional transitive attribute. • This attribute is used to indicate the AS and speaker who has performed route aggregation. • The above information is encoded as: • AS number and IP address

  16. (NLRI= 172.64.14.0/24, AS_Path{AS100}) (NLRI= 172.64.0.0/16, (Atomic_Aggregate), Aggregator (AS400, 192.32.15.1)} (NLRI= 172.64.15.0/24, AS_Path{AS200}) 172.64.15.0/24 172.64.14.0/24 172.64.16.0/24 R1 (192.32.15.1) AS 200 AS 100 AS 300 AS 400 (NLRI= 172.64.16.0/24, AS_Path{AS300}) R1 sets the Aggregator attribute

  17. BGP Routing Policies • BGP provides capabilities to apply policies based on routing preferences and constraints. • BGP policies are determined by the AS • BGP policies are applied through various configurations. • BGP policies are enforced: • By influencing the selection of certain paths from multiple available paths • By controlling the distribution of routing information. • Examples • If an AS does not wish to act as a transit AS for certain destinations, it does not advertise routing information for those destinations. • To protect against unwanted traffic, an AS can apply route filtering.

  18. Route Filtering • BGP route filtering is the mechanism to enforce routing policies. • BGP route filtering is the process of deciding: • (Input Side) What routes to receive from other peers? • (Output Side) What routes to advertise to other peers? • Route filtering can be applied at the: • Inter-peers • to control in/out routing information between BGP peers. • Inter-Protocol • to control in/out routing exchange between protocols (e.g., IGP and BGP)

  19. R1 Input Side Route Filtering Routing Updates AS 200 eBGP Routing Updates R3 Routing Updates iBGP R2 Routing Updates AS 100 Output Side Route Filtering

  20. Route Filtering Procedure Identify Routes Action (accept or reject) Modify Path Attributes

  21. Route Filtering • Route Identification: • In order to perform route filtering, first, the route must be identified. • To identify routes, different types of filtering criteria or rules are used. • Each route is compared against these rules. Different instances of rules are organized as a list (like a case statement in C language). • A route that matches one of these rules is selected for further processing. Otherwise, discarded. • Route identification is commonly based on: • NLRI (i.e., IP destination addresses) and AS_Path list (i.e., AS numbers).

  22. Route Filtering • Action: • Based on the configured policy, routes identified in the previous step are either accepted (e.g., installed in the RIB) or rejected (discarded). • Attribute modification: • Based on configured routing policy, the path attribute of each accepted route may be modified to influence the decision process (own and neighbor’s). • Thus through path attributes manipulation, BGP controls inter- and intra-AS routing behavior.

  23. BGP/IGP Routing Exchanges • The routing information carried in BGP update message comes from • dynamic routing (e.g., IGP) • Static routing • BGP may be regarded as a pipe for transporting routing information (prefixes) injected by above two sources sources. • Routing information into BGP can be injected in two ways: • Automatically (e.g., via Cisco redistribute command) • Manually (e.g., via Cisco IOS network command)

  24. BGP/IGP Routing Exchanges • Routing information (i.e., dynamic and static) into BGP can be injected in two ways: • Automatic (e.g., via Cisco IOS redistribute command) • Semiautomatic (e.g., via Cisco IOS network command) • When first option is enabled, all IGP/static routes are injected (redistributed) into the BGP. • Pros: less manual configuration • Cons: The existence of routes in not verified before redistribution. Can inject wrong routing information that can cause routing loops. • When the second option is used, only a manually configured subset of dynamic/static routes are injected. • Pros: existence of dynamic routes verified in the IGP table. • Cons: more configuration. Hard to manage for large number of routes.

  25. Update (NLRI=192.56.0.0/16, AS200) Route is redistributed into BGP AS300 eBGP IGP IGP IGP AS200 eBGP Route is redistributed into IGP Update (NLRI=192.56.0.0/16, AS100) AS100

  26. Route Injection and Origin Attribute • Routes that are injected via network command are regarded as internal to the AS • BGP considers source of all routes that are injected using semiautomatic option (e.g., network command) as internal to the AS. • BGP advertises such routes with Origin (well-known, mandatory) set to 0 (IGP) • In contrast, the source of all routes (dynamic or static) that are injected automatically (e.g., redistribute command) is considered to be incomplete. • BGP advertises such routes with Origin set to 2 (Incomplete).

  27. 127.16.0.0, Origin= Incomplete 126.16.0.0, Origin = Incomplete 123.16.0.0, Origin = Incomplete 122.16.0.0, Origin =Incomplete 125.16.0.0, Origin = IGP 124.16.0.0, Origin = IGP 121.16.0.0, Origin = IGP 120.16.0.0, Origin = IGP 127.16.0.0 126.16.0.0 125.16.0.0 124.16.0.0 123.16.0.0 122.16.0.0 121.16.0.0 120.16.0.0 IGP IGP redistribute network redistribute network AS200 AS100

  28. BGP and IGP Synchronization • BGP should wait for propagation of transit routes (learned via eBGP) inside AS via IGP before advertising such routes to another AS. • To avoid the above problem, BGP speaker does not advertise routes learned from iBGP peers to an eBGP peers before verifying reachability of routes though IGP. • Thus routes is not advertised unless it also exists in the IGP routing table. • The above process involves looking up IGP table. • Because next hop address for a BGP route is not always directly connected neighbor, the determination of IGP reachability of that route may involve recursive lookups into IGP routing table.

  29. R3 advertise this route to R5 but R2 (a non-BGP speaker) has not Learned about the BGP route yet BGP route injected into IGP Update (172.32.0.0) R2 IGP R3 IGP Update (172.32.0.0) R1 iBGP Update (172.32.0.0) eBGP Traffic eBGP R5 R4 R2 IGP table does not know know BGP route yet. Traffic dropped. R3 knows about the BGP route. After recursive IGP lookup, forwards the traffic towards BGP next hop (i.e., R2)

  30. R3 verifies existence of the BGP route in IGP routing table before advertising it to R5. BGP route injected into IGP Update (172.32.0.0) R2 IGP R3 IGP Update (172.32.0.0) R1 iBGP Update (172.32.0.0) eBGP Traffic eBGP R5 R4

  31. eBGP and iBGP Sessions • From session negotiation and establishment perspective, iBGP and eBGP sessions are very similar. • The main differences between iBGP and eBGP sessions exists in: • Route processing • Attribute setting (e.g., Next_Hop) • Route advertisement

  32. Route Advertisement in eBGP/iBGP Sessions • eBGP and iBGP sessions follow different rules for route advertisements. For example, • When a route (i.e., Update message) is received from an eBGP peer, the receiving speaker can advertise (e.g., after running decision process) this route to its eBGP and iBGP peers. • In contrast, when a BGP speaker receives a route from an iBGP peer, it can advertise this route to eBGP peers but not to its iBGP peers. The latter mechanism is there to avoid routing loops inside the AS. • As a result, for proper propagation of routing information, a full-mesh of iBGP sessions must be established between BGP speakers inside the AS.

  33. AS 300 R2 R1 R3 iBGP R4 iBGP iBGP 2 2 1 1 2 2 eBGP R5 R5 originates a BGP route to an eBGP peer R4. AS 200 R4 installs the route with R5 as the next hop and advertises this route to eBGP peers R1,R2,R3.

  34. AS 300 R2 R1 R3 iBGP R4 iBGP iBGP 2 2 1 1 eBGP R5 R3 advertises a route to an iBGP peer R4. R4 installs the route and re-advertises this route to an eBGP peer R5 but not to iBGP peers R1, R2. AS 200

  35. Solution: iBGP between Multan and Islamabad Routes received from R7 are not advertised to Islamabad AS 300 R2 Routes received from R6 are not advertise to Multan R1 R3 Multan Islamabad R4 iBGP iBGP Lahore eBGP eBGP R7 R6 eBGP AS500 AS400 R5 AS 200

  36. Drawbacks of iBGP Session Mesh • We know that in order to propagate external routing information to all BGP speakers inside the AS, a full iBGP mesh is required. • For large AS (e.g., order of few hundred iBGP sessions), it becomes hard to configure and manage so many iBGP sessions. • To avoid iBGP mesh yet still be able to propagate external routing information to all internal BGP speakers, the concept of Route Reflector (RR) is used.

  37. BGP Route Reflector (RR) • RR is a BGP speaker that performs the route reflection function. • The iBGP peers of the RR are known as Clients. • The RR and its clients form what is known as Cluster. • All BGP speakers that are not clients are called non-clients. • All full iBGP mesh is established between RR and non-clients. • A partial iBGP mesh is maintained between clients inside a cluster. • Clients don not peer outside their outside their own cluster

  38. AS 200 Cluster Route Reflector Non-clients form iBGP session mesh R1 R5 iBGP RR R2 iBGP iBGP iBGP R3 iBGP iBGP R6 Clients R1,R2,R3 do not form iBGP Session mesh eBGP R7 AS 100

  39. BGP Route Reflector (RR) • The route processing and advertisement functions of a RR can be summarized as: • A route that is received from an eBGP peer is reflected to all clients and non-clients. • A route that is received from a non-client is reflected to clients peers only. • A route that is received from a client peer is reflected to all other clients excluding the originating client.

More Related