CS Summer 2003 Lecture 4

CS Summer 2003 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.

CS Summer 2003 AS 500 AS 600 Update ( /16, AS_Path = {AS400, AS500, AS600}) AS /8 AS 400 (NLRI= /8, AS_Path{AS100}) (NLRI= /8, AS_Path{AS300}) (NLRI= /8, AS_Path{AS200}) AS /8 AS /8 (NLRI= /16, AS_Path{AS400}) (NLRI= /16, AS_Path{AS400, AS500}) Routing loop

CS Summer 2003 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.

CS Summer 2003 AS 500 AS 600 Update ( /16, AS_Path = {AS400, AS500, AS600{AS100,AS300,AS200}}) AS /8 AS 400 (NLRI= /8, AS_Path{AS100}) (NLRI= /8, AS_Path{AS300}) (NLRI= /8, AS_Path{AS200}) AS /8 AS /8 (NLRI= /16, AS_Path{AS400 (AS100,AS300,AS200}}) (NLRI= /16, AS_Path{AS400, AS500}) Update rejected

CS Summer 2003 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.

CS Summer 2003 iBGP AS100 AS200 AS300 AS400 AS / /8 DS1 DS3 OC30 R1 R2 R3 R1 Sets Loc_pref = 100 R2 Sets Loc_pref = 200 R3 Sets Loc_Pref = 300 Traffic

CS Summer 2003 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.

CS Summer 2003 AS200 AS300 AS400 AS /16 MED = 200 MED = 100 Traffic /16 MED = 50

CS Summer 2003 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.

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

CS Summer 2003 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.

CS Summer 2003 AS 300 R1 R2 R3iBGP R4 eBGP 2 AS If Destination BGP Next Hop Destination IGP next hop If1 R1’s Routing Table

CS Summer 2003 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)

CS Summer 2003 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

CS Summer 2003 AS /24 AS 400 (NLRI= /24, AS_Path{AS100}) (NLRI= /24, AS_Path{AS300}) (NLRI= /24, AS_Path{AS200}) AS /24 AS /24 (NLRI= /16, (Atomic_Aggregate), Aggregator (AS400, )} R1 sets the Aggregator attribute R1 ( )

CS Summer 2003 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.

CS Summer 2003 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)

CS Summer 2003 eBGP iBGP AS 100 AS 200 R1 R2 R3 Routing Updates Input Side Route Filtering Output Side Route Filtering Routing Updates

CS Summer 2003 Route Filtering Procedure Identify Routes Action (accept or reject) Modify Path Attributes

CS Summer 2003 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).

CS Summer 2003 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.

CS Summer 2003 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)

CS Summer 2003 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.

CS Summer 2003 AS100 AS200 eBGP IGP eBGP AS300 Update (NLRI= /16, AS100) Route is redistributed into IGP Update (NLRI= /16, AS200) Route is redistributed into BGP

CS Summer 2003 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).

CS Summer , Origin= Incomplete , Origin = Incomplete , Origin = Incomplete , Origin =Incomplete , Origin = IGP , Origin = IGP , Origin = IGP , Origin = IGP AS100 AS IGP redistribute network redistribute network

CS Summer 2003 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.

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

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

CS Summer 2003 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

CS Summer 2003 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.

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

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

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

CS Summer 2003 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.

CS Summer 2003 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

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

CS Summer 2003 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.