Route Aggregation

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
(No Transcript)
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
(No Transcript)
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
(No Transcript)
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
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
(No Transcript)
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
R1s Routing Table
Destination
BGP Next Hop
192.32.16.0
192.29.18.0
R1s 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
(No Transcript)
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
(No Transcript)
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
  neighbors).
• 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 (NLRI192.56.0.0/16, AS200)
Route is redistributed into BGP
AS300
eBGP
IGP
IGP
IGP
AS200
eBGP
Route is redistributed into IGP
Update (NLRI192.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
(No Transcript)
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
(No Transcript)
30
(No Transcript)
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
(No Transcript)
34
(No Transcript)
35
(No Transcript)
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
(No Transcript)
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.