Chapter 9: Controlling Large-Scale ASes

I. Route Reflectors - See CH12 Page 415

1. When - Use Route Reflectors on large scale IBGP full mesh networks
2. Benefits 1. Less peering; clients only need to peer with the local RR
2. RR could be optimized to copy UPDATE messages when sending to multiple
peers rather than generating unique messages per peer.
3. Drawbacks 1. More processing overhead for the RR
2. If configured incorrectly could cause loops.

2. Internal Peers Without Route Reflectors

1. Example of full IBGP mesh: required for RTA to advertise an EBGP originating
update to RTC, otherwise RTB would not forward the update to RTC due to the
IBGP rules.

3. f

4. Internal Peers with Route Reflectors

1. The below is a simple RR design with RTB being the RR. Updates from RTA and
processed by RTB and also reflected to RTC. RTA and RTC should not have a
peering session with one another.

5. Naming Conventions and Rules of Operation

1. A RR and clients make a cluster. Clients and non-clients have no notion of being
clients or non-clients for a route reflector; they are assigned from the prospective
of the Route Reflector only. Non-clients that peer with a route reflector must
abide by normal IBGP rules and therefore need to form a full mesh in order to
advertise all routes to each other.
2. Clients should only peer with the route reflector.
3. Non-clients should only peer with the RR of the cluster and not the clients.
2. Rules of Operation
1. If the route is received from a nonclient peer, reflect to clients only.
2. If the route is received from a client peer, reflect to all nonclient peers and also to
client peers.
3. If the route is received from an EBGP peer, reflect to all client and nonclient
peers.

6. f

7. Redundancy Issues and Multiple Route Reflectors in an AS

1. Below shows that if RR1 goes down or the link to RR1 from RTA goes down
then RTA becomes isolated if there's no physical redundancy to compliment the
logical redundancy... Logical redundancy must compliment physical
redundancy.

8. f

9. Route Reflection Topology Models

1. Below is an example of how one should design an RR topology; based on the
physical topology.
1. Route Reflectors should be the routers interconnecting sites/clusters.
2. Route Reflectors should be the routers that also have at least one physical
connection to each client if choosing one RR. If using two RR's per cluster
than a client should have at least one connection to at least one RR.
3. Route Reflectors should, if possible, be IBGP only routers. This will allow
the EBGP edge routers to concentrate processing and memory on the routing
table, while the IBGP route reflectors can concentrate on processing and
memory on Route Reflection and peering.

2. The Route Reflector Preserves IBGP Attributes

1. Route Reflectors shouldn't change IBGP attributes. As shown below, RTB is
acting as the Route Reflector for clients RTC and RTA. The default desired
behavior is that route 192.213.11.0/24 from RTC will be reflected to RTA with
the original next hop of 1.1.1.1. However what if RTB changed the next hop that
of it's own IP address of 2.2.2.2? A loop would be created for a couple reasons.
First RTB is not in the physical path that traffic will flow so RTB advertises the
next hop of itself, so when traffic reaches RTB it sends it back to RTA as RTA is
the one and only router in the path of traffic going to RTC.
2. Always build your RR topology based on the physical topology; and try not to
change the default behavior of Route Reflection unless necessary.

3.
4. Avoiding Loops
1. Loop avoidance between ASes uses the AS_PATH attribute, however with Route
Reflection comes possible loops, the below are methods to avoid loops using
Route Reflection.
2. Using an ORIGINATOR_ID
1. The ORIGINATOR_ID is a 4-byte, optional, nontransitive BGP attribute (type
code 9). This attribute carries the ROUTER_ID of the route's originator in the
local AS and is to be added to the UPDATE message by the route reflector. If
the update comes back to the originator because of poor configuration, the
originator should discard it.
3. The CLUSTER_LIST
1. The CLUSTER_LIST is like the AS_PATH list. The CLUSTER_ID is appended
when ever a RR sends an update from a client to a non-client; or it's created if
one doesn't exist (if the update was originated from the local cluster one doesn't
exist until it's created when the update is sent out to a non-client.)

10.Route Reflectors and Peer Groups

1. Recall from Chapter 6, Tuning BGP Capabilities, that a peer group is a group
of BGP neighbors that share similar routing policies. Previously, route reflectors
could be used only in conjunction with peer groups when all route reflector
clients within a cluster were fully meshed. The reason can best be described
through the following example. In a typical route reflection situation, Router A
learns a prefix from Router B. Subsequently, Router A sends an UPDATE
message containing WITHDRAWN ROUTES information back to Router B to
poison that route. In other words, Router A informs Router B that this prefix is
unreachable via A. This prevents a route loop situation in which A claims that a
prefix is reachable via B, and B claims it is reachable via A. In a peer group, the
same UPDATE message (with subsequent WITHDRAWN ROUTES
information) is sent to all members of the group. In a peer group/route reflector
situation, a route reflector that learns a prefix from one of the clients and
attempts to poison that route ends up withdrawing that prefix from all the other
clients. Because the clients are not talking to one another via BGP, that prefix is
lost. Therefore, an IBGP mesh between the clients of a route reflector is
necessary so that other clients will learn the prefix directly from the originator.
Even with this design, the network administrator avoids building a full IBGP
mesh between all IBGP routers in the AS by concentrating the mesh between
route reflectors and clients (versus between clients within a cluster). Fortunately,
IOS has removed the full-mesh requirement on route reflector clients. Currently,
clients of a route reflector configured under a peer group are not required to be
fully meshed. With the use of peer groups, the AS design would look like rings
of fully meshed BGP speakers. Route reflectors are fully meshed among each
other, and clients are only required to peer with the route reflectors. Figure 9-7
illustrates such an environment; each circled area represents a distinct peer group
and route reflector cluster. In contrast, Figure 9-8 demonstrates what would be
required without the use of route reflectors.

11.f

12.f

13.Confederations - See CH12 Page 419

1. When an AS is made into a confederation, this means that groups of routers are
made into Sub-ASes, and are interconnected with the AS via EBGP. Even
though they are interconnected via EBGP, routing within the confederation still
behaves the same as IBGP, meaning next-hop, MED and local preference
information is preserved when crossing the sub-AS boundaries.
2. Within each sub-AS, the routers must be an IBGP full mesh, (otherwise all
routers won't get all routes due to IBGP rules).
3. The outside world views the confederation as a single AS.
4. Loop avoidance is easy with confederations, as the AS_PATH is used as EBGP is
used between sub-ASes.

14. f

15.Confederation Drawbacks
1. Within a confederation, the AS_PATH reflects the sub-ASes for loop avoidance,
however Sub-ASes don't affect the overall path length, and therefore configuring
policies manually will be required to create optimal routing within the
confederation.
2. ASes external to the confederation will only see the one AS and will select it as
the best path to get to AS200, even though it may actually be suboptimal.

16.f
17.Route Exchange and BGP Decisions with Confederations
1. Even though you use an EBGP connection between sub-ASes, IBGP rules still
apply within the confederation.
2. The only difference is that a new type of route is now created using
confederations.
1. EBGP routes to outside the confederation > confederation exterior routes >
IBGP routes

18.Recommended Confederation Design

1. Best design is to use a Central Sub-AS backbone; this will make it so each subAS only interacts with one other sub-AS (central).

19.
20.Confederations Versus Route Reflectors
1. Cisco recommends the use of RRs to solve the full IBGP mesh issue... However:
1. RR's are flexible and scalable, and can be implemented into an existing
design easily.
2. Confederations can be used to run an IGP in one sub-AS independently of
IGPs in other sub-ASes to control the instability of large IGPs.
3. RR's could be run within a confederation inside each sub-AS.

II. Controlling IGP Expansion

1. Segmenting the AS with Multiple Regions Separated by IBGP
1. Below you will see each region separated by IBGP. Each regional IBGP router
injects a default into the IGP (region). Only problem here is internet
connectivity.

2. Below is an example of a bad design for internet connectivity. Reason it's bad is
because internet connectivity is based on a default route sent by the ISP which is
sent to an internal (non-bgp) router within region 2. This same router also
receives a default injected by the IBGP router for region 2... Two defaults will
not work! You COULD use this design, but you would have to stop injecting a
default from the IBGP router into region 2, and inject IBGP routes into the IGP
for region 2; possible some aggregate routes from the other regions to minimize
the injection from IBGP to IGP.

3. Better design below allowing the injection of defaults routes into each region by
the IBGP boarder routers, and internet access is taken care of by separate IBGP
routers enabling the use of BGP policies to control internet traffic.
4. There is still an issue with configuring BGP policies as the regional network is
still one autonomous system, prefixes from each region cannot be easily
differentiated from those in another region by BGP. Designs that are more
complex could utilize the "community" attribute to differentiate prefixes between
regions. This could be used in conjunction with the hierarchical route reflection
configuration to create large virtual private networks, as you will see later.

2. f

3. Segmenting the AS with Multiple Regions Separated by EBGP

1. Below is the best way to segregate an IGP into multiple regions. Because we are
using separate ASes for each region, we can use EBGP between regions and
easily configure policies. Problem is that it is next to impossible to obtain more
than a single AS number as AS numbers are being depleted and an RIR will most
likely never allow you more than one.

4. f

1. Using Private AS Numbers

1. The below is a way to use private AS numbers to allow EBGP between regions,
and to have multi-provider internet connectivity while enabling the administrator
to strip the private-ASes from the AS_PATH when advertised to the providers.

2.
3. Using Confederations to Control IGP Expansion
1. Using a centralized confederation backbone interconnecting all other sub-ASes
could work to split up an IGP, but the drawback is that the whole AS, even
though the sub-ASes are separated by EBGP, still acts like IBGP, therefore you
won't be able to configure policies as if separated by real EBGP links. Also
confederations, if not centralized in design, could introduce complications such
as suboptimal routes that indiscriminately direct traffic within the confederation.