Scaling BGP

1
Scaling BGP

• BGP's main strength is its capability to impose
  routing policy, primarily through route maps that
  manipulate BGP path attributes. These attributes
  allow for very precise and complex policy
  implementation.
• This chapter discusses the following key features
  needed to simplify and streamline large BGP
  domains route reflectors, route filtering, the
  Community attribute, and peer groups.

2
Scaling BGP

• Moreover, we will examine BGP scalability issues
  such as redundancy, load balancing, multihomed
  connections, and route redistribution.

3
Route Reflector Basics

• Autonomous systems consisting of hundreds of BGP
  routers can pose a serious management problem. If
  Internal BGP (IBGP) speakers are configured as a
  logical full mesh, BGP operation becomes
  extremely complex.
• Imagine a network in which more than 100 neighbor
  statements are required just to define the
  remote-as of each peer!

4
(No Transcript)
5
Route Reflector Basics

• The route reflector (RR) is a recent addition to
  BGP (IOS 11.1) that offers an alternative to the
  logical full-mesh requirement of IBGP. An RR acts
  as a focal point for IBGP sessions.
• Multiple BGP routers can peer with a central
  point (the RR) rather than peer with every other
  router in a full mesh. This approach, similar to
  OSPF's DR/BDR feature, provides large ISPs with
  added IBGP scalability.

6
Route Reflector Basics

• The use of route reflectors is recommended only
  for autonomous systems that support a large
  internal BGP mesh, approximately more than 100
  sessions per router.
• This feature introduces processing overhead on
  the routers that act as route reflectors and, if
  configured incorrectly, can cause routing loops
  and instability. Therefore, if your network can
  tolerate it, a logical full mesh is usually the
  best solution.

7
(No Transcript)
8
(No Transcript)
9
Route Reflector Operations

• The IBGP peers of a route reflector fall under
  two categories clients and nonclients. A route
  reflector and its clients form a cluster.
• All IBGP peers of the route reflector that are
  not part of the cluster are nonclients and must
  be fully meshed to all other IBGP routers.
• Never configure route reflector clients to peer
  with IBGP speakers outside their cluster as this
  can cause routing loops.

10
Route Reflector Operations

• How is route reflection configured? The commands
  needed are surprisingly simple. In fact, only the
  route reflector servers themselves receive the
  configuration.
• Clients and nonclients do not even know that
  route reflection is occurring. To identify
  clients and clusters, use the neighbor command,
  which has the following syntax, on the route
  reflector server

11
Route Reflector Operations

• router(config-router)neighbor IP-address
  route-reflector-client.

12
(No Transcript)
13
(No Transcript)
14
Route Reflector Operations

• If the route is received from a nonclient peer,
  reflect to clients only.
• If the route is received from a client peer,
  reflect to all nonclient peers and also to client
  peers, except the originator of the route.
• If the route is received from an EBGP peer,
  reflect to all client and nonclient peers.

15
BGP Route Filtering

• Route filtering empowers a BGP speaker to choose
  what routes to exchange with any of its BGP
  peers. Route filtering is the cornerstone of
  policy routing.
• For example, an AS can identify inbound traffic
  that it is willing to accept by filtering its
  outbound advertisements. Conversely, an AS can
  control what routes its outbound traffic uses by
  specifying the routes to accept from EBGP
  neighbors.

16
BGP Route Filtering

• Both the inbound and outbound filtering concepts
  can be applied between peers and between routing
  protocols running on a single router.
• At the peer level, inbound filtering indicates
  that the BGP speaker is filtering routing updates
  coming from other peers, and outbound filtering
  limits the routing updates advertised from this
  BGP speaker towards other peers.

17
BGP Route Filtering

• At the protocol level, inbound filtering limits
  the routing updates being redistributed into a
  protocol. Outbound filtering limits the routing
  updates being injected from this protocol.
• For example, inbound filtering limits the updates
  being redistributed from other protocols into
  BGP. Outbound filtering limits the updates being
  redistributed from BGP into an IGP.

18
Using Filters to Implement Routing Policy

• Two distinct steps are involved in manipulating a
  route or a set of routes
• Identify the network number and subnet mask of
  the route to which you would like the policies to
  be applied. For BGP, this information is called
  the network-layer reachability information
  (NLRI).

19
Using Filters to Implement Routing Policy

• Recall from Chapter 8 that the NLRI consists of a
  prefix and prefix-length pair. Throughout this
  section, the NLRI is referred to simply as the
  prefix.
• Implement the policies (which can be filtering
  prefixes out altogether or manipulating the
  attributes of a prefix to influence the routing
  decision).

20
Using Filters to Implement Routing Policy

• The identification process typically relies on a
  route map. Prefixes can be selected by their
  destination network number, the AS from which the
  prefix originated, the AS_Path, or another
  specific attribute value. Prefixes are identified
  using a route map's match statement.

21
Using Filters to Implement Routing Policy

• After a route map matches a given prefix, the
  actions specified by the route map will be
  executed, and processing will be considered
  complete.

22
Using Filters to Implement Routing Policy

• What actions can the route map take after it has
  identified a match?
• The simplest actions are either to permit the
  route to pass through or to filter it out by
  denying it. Actions that are more complex tweak
  the attributes of a prefix to influence the
  routing process in some way.

23
Using Filters to Implement Routing Policy

• Note that route map can match a prefix based on
  several criteria, such as network number or
  AS_Path information. Also note that once a route
  matches there are no further comparisons, the
  order in which the matches are configured in the
  route map is important. If a route map clause
  that permits all routes is put at the beginning
  of the list, it overrides all the other policies
  configured.

24
Using Distribute-list to Filter BGP Routes

• To restrict the routing information that the
  router learns or advertises, you can filter
  routing updates. You can apply route filters to
  or from a particular neighbor by using the
  distribute-list command.
• This can get confusing however and so Cisco came
  out with the ip prefix-list command in IOS 12.0.
  This command is described in the next section.

25
Prefix Lists

• You can use prefix lists as an alternative to
  access lists with many BGP route-filtering
  commands. The advantages of using prefix lists
  rather than access lists include the following
• Significant performance improvement in loading
  and route lookup of large lists.

26
Prefix Lists

• Support for incremental updates. Filtering via
  extended access lists does not support
  incremental updates.
• A more user-friendly command-line interface.
• Greater flexibility.

27
Prefix Lists

• You must define a prefix list before you can
  apply it as a route filter. The Cisco IOS allows
  a very flexible configuration procedure, where
  each statement can be assigned its own sequence
  numbers.
• To define a prefix list, use the ip prefix-list
  command.
• When using prefix lists, keep the following rules
  in mind

28
Prefix Lists

• An empty prefix list permits all prefixes.
• An implicit deny is assumed if a given prefix
  does not match any entries of a prefix list.
• When multiple entries of a prefix list match a
  given prefix, the sequence number of a prefix
  list entry identifies the entry with the lowest
  sequence number. In this case, the entry with the
  smallest sequence number is considered to be the
  "real" match.

29
Prefix Lists

• To display information about prefix tables,
  prefix table entries, the policy associated with
  a node, or specific information about an entry,
  use the show ip prefix-list command.

30
Community Attribute

• A BGP community is a group of destinations that
  share some common property. A community is not
  restricted to one network or one AS.
• Communities are used to simplify routing
  policies by identifying routes based on an easily
  configurable property rather than an IP prefix or
  an AS number.

31
Community Attribute

• A BGP speaker can use the Community attribute in
  conjunction with other attributes to control
  which routes to accept, prefer, and pass on to
  other BGP neighbors. A route map is configured to
  manipulate Community values.

32
Community Attribute

• The Community attribute (type code 8) is an
  optional transitive attribute. Some community
  values are well known - that is, they have a
  global meaning among all BGP routers. Well-known
  Community values include
• NO_EXPORT - A route carrying this community value
  should not be advertised to peers outside a
  confederation (or the AS, if it is the only AS in
  the confederation).

33
Community Attribute

• NO_ADVERTISE - A route carrying this community
  value, when received, should not be advertised to
  any BGP peer.
• Internet - A route carrying this community
  value, when received, should be advertised to all
  other routers.
• Local-as - A route carrying this community value,
  when received, should be advertised to peers
  within the AS, but not advertised to peers in an
  external system.

34
Community Attribute

• The figure shows a simple use of the community
  attribute.
• RTC updates RTB with three routes. Two of these
  routes (RouteX and RouteY) are sent with a
  NO_EXPORT Community attribute by RTC.

35
Community Attribute

• The third route, RouteZ is sent without a
  Community attribute. Thus, RTB will send only
  RouteZ to RTA in AS 100 RouteX and RouteY will
  not be sent because of the NO_EXPORT attribute.
• This example shows how the Community attribute
  can be used to dynamically influence the routing
  decisions of another AS.

36
(No Transcript)
37
Peer Groups

• A BGP peer group is a group of BGP neighbors that
  share the same update policies. Instead of
  defining the same policies for each individual
  neighbor, you can define a peer group and then
  assign policies to the peer group itself.

38
Peer Groups

• Not only do peer groups save you from having to
  repetitively configure each BGP peer, but they
  also save the BGP router from the effort of
  parsing the policies sequentially for each
  neighbor.
• With peer groups, the router formulates the
  update message once, based on the policies of the
  peer group, and then floods the same update to
  all the neighbors that fall within the group.

39
(No Transcript)
40
Peer Groups

• Because of the route update optimization that
  peer groups offer, some restrictions need to be
  followed for peer groups to work correctly with
  EBGP peers. The hub router (such as RTA in the
  figure) cannot be a transit router for the
  external autonomous systems. In other words,
  updates from one EBGP neighbor in the peer group
  should not be passed to other EBGP neighbors in
  the same peer group.

41
Redundancy, Symmetry, and Load Balancing

• Redundancy, symmetry, and load balancing are
  crucial needs facing anyone in the process of
  implementing a high-throughput connection to the
  Internet. ISPs and their large customers require
  adequate control over how traffic enters and
  exits their respective autonomous systems.

42
Redundancy, Symmetry, and Load Balancing

• Redundancy is achieved by providing multiple
  alternate paths for the traffic, usually by
  having multiple connections to one or more
  autonomous systems.
• Symmetry exists if traffic leaves the AS from a
  certain exit point and returns through the same
  point.
• Load balancing, as you have seen, results in the
  division of traffic optimally over multiple
  links.

43
Redundancy, Symmetry, and Load Balancing

• Together, these three requirements can be
  difficult to meet in a BGP environment because
  any provider between the source and destination
  of a packet can affect its path.
• The following sections examine the general design
  issues redundancy, symmetry, and load balancing,
  as well as configuration models for successful
  implementation.

44
Redundancy

• Although corporations and ISPs prefer
  uninterrupted connectivity, disruptions still
  occur for a variety of reasons. Connectivity is
  not the responsibility of one entity. A
  connection to the Internet may involve a router,
  a CSU/DSU, premises wiring, the provider's
  physical layer, the provider's switching
  equipment, and numerous administrators -- each
  with influence over different parts of the
  connection.

45
Redundancy

• At any time, end-to-end connectivity can be
  jeopardized by human error, software errors,
  physical errors, or adverse unforeseen conditions
  (such as bad weather or power outages).
• Redundancy and symmetry can be conflicting design
  goals the more redundant links a network has,
  the more unpredictable the entrance and exit
  points for a packet become

46
Redundancy

• If a customer has multiple connections -- for
  example, one to a point of presence (POP) in San
  Francisco and another to a POP in New York --
  traffic leaving San Francisco might come back
  through New York. Adding a third connection to a
  POP in Dallas makes connectivity even more
  reliable, but it also makes traffic symmetry more
  challenging.

47
(No Transcript)
48
Default Routing in BGP

• It is important to control default information in
  BGP because improper configuration can cause
  serious Internet routing problems.
• For example, a misconfigured BGP speaker could
  end up flooding a default route to all of its
  neighbors and quickly find itself consumed with
  default-routed traffic from surrounding
  autonomous systems.

49
Default Routing in BGP

• To protect against misadvertisements, the Cisco
  IOS provides a way to target default information
  at a specific neighbor by using the
  default-originate option with the neighbor
  command
• RTC(config)router bgp 3RTC(config-router)neighb
  or 172.16.20.1 remote-as 1RTC(config-router)neig
  hbor 172.16.20.1 default-originate

50
Default Routes in BGP

• If RTC is configured as shown above, it will send
  default information only to the specified
  neighbor. If you want to configure a BGP router
  to advertise a default to all of its peers, you
  can use the network command as shown below. Both
  neighbors -- 172.16.20.1 and 172.17.1.1 -- will
  receive a default route from RTC (if it has one
  to send).

51
Default Routes in BGP

• RTC(config)router bgp 3RTC(config-router)neighb
  or 172.16.20.1 remote-as 1RTC(config-router)neig
  hbor 172.17.1.1 remote-as 2RTC(config-router)net
  work 0.0.0.0.

52
Symmetry

• Symmetry is achieved when traffic leaving the AS
  from one exit point comes back through the same
  point. Symmetry always exists if an AS maintains
  a single connection to outside networks.
• However, the need for redundancy often results in
  multihoming an AS. If an AS has many different
  links to the outside world, traffic tends to flow
  asymmetrically.

53
Symmetry

• An asymmetrical traffic flow can result in
  increased delay and other routing problems. In
  general, customers and providers would like to
  see their traffic come back via the same, or
  close to the same, point that it left the AS.

54
Symmetry

• To promote symmetry, you should choose a primary
  path and configure routing policies that force
  traffic to flow along this path.
• A default route with a low administrative
  distance or a high Local Preference might serve
  to control the flow of outbound traffic, but
  inbound traffic can be trickier to manipulate.

55
Symmetry

• Through appropriate planning and use of BGP
  attributes (such as the Community attribute and
  route filters), an AS can control which paths the
  outside world finds most desirable. Thus, you can
  control how the outside world reaches networks
  within your AS by controlling your routers'
  advertisements.

56
Load Balancing

• Load balancing is the capability to divide data
  traffic over multiple connections. When a BGP
  speaker learns two identical EBGP paths for a
  prefix from a neighboring AS, it will choose the
  path with the lowest route ID as the best path.

57
Load Balancing

• If BGP multipath support is enabled and the EBGP
  paths are learned from the same neighboring AS,
  instead of picking one best path, multiple paths
  are installed in the IP routing table.
• To enable BGP load balancing over equal-cost
  paths, use the maximum-paths command, which has
  the following syntax
• Router(config-router) maximum-paths number

58
Load Balancing

• BGP supports a maximum of six paths per
  destination, but only if they are sourced from
  the same AS. By default, BGP will install only
  one path to the IP routing table.

59
(No Transcript)
60
(No Transcript)
61
(No Transcript)