Chapter 8: Controlling Routing Inside the AS

I. Interaction of Non-BGP Routers with BGP Routers

1. Non-BGP routers inside the AS can reach the outside world by using the
following two methods:
1. Injecting BGP into the IGP
2. Following default routes inside the AS

2. Injecting BGP into the IGP

1. Generally it's not recommended to inject BGP routes into an IGP... IGPs weren't
designed to handle the large amounts of BGP routes. However it may be
appropriate to inject certain routes into the IGP to better direct outbound traffic
to the appropriate exit point.
2. Considerations:
1. memory
2. cpu resources for calculating paths and processing routing updates
3. link utilization from routing control traffic
4. impact on convergence
5. IGP limitations
6. network topology
3. CIDR will be lost if injecting into a classful IGP
4. Instabilities of the external routes will cause instabilities in the IGP.

3. Following Defaults Inside an AS - See CH12 Page 397

1. The more practical solution is to inject a default route from each AS Boarder
router and allow the IGP to determine which exit has the shortest path.

4.

II. BGP Policies Conflicting with Internal Defaults - See CH12 Page 411
1. Loops could occur when a default points traffic to a boarder router, and then due
to the boarder router's policy sends the traffic back into the AS.
2. Scenarios when a loop may occur:
1. Defaults inside the AS in conjunction with a primary/backup BGP policy
2. Defaults inside the AS in conjunction with other BGP policies.

2. Defaults Inside the AS: Primary/Backup BGP Policy

1. RTC and RTD are IBGP neighbors and each has an external link to a separate
provider. Both edge routers are advertising a default route to the IGP routers
(RTA and RTB) RTD sets the local preferences to a higher value for all
incoming routing updates and therefore makes RTD's link to the internet the
primary link. When RTA sends traffic destined to the internet it follows the IGP
metrics for the best path to the default route, which goes to RTC... This is where
the problem starts, as RTC sends the traffic back to RTA to be diverted to RTD,
however RTA only has a default route for all internet based routes, and therefore
sends it back to RTC causing a loop. Below are the scenarios that can be used to
avoid these loops based on the current design.

2. Scenario 1: Manipulating the IGP Metric - Have RTC advertise the default route with
a much higher IGP metric than RTD, so RTD's default is always preferred by any
internal router.
3. Scenario 2: The IBGP Path Is Shorter Than the IGP Path - Create a physical link
between IBGP routers so as to not redirect the traffic back over the IGP.
4. Scenario 3: Running BGP on Transit Routers - Full IBGP mesh between all routers
shown.
5. Scenario 4: Who Generates the Default, and How Is It Generated? - Have the
Primary edge router stop advertising it's default route if it's external link fails. Also have
the backup router START advertising it's default route only if the preferred default route
is that of it's external link, and not the one coming from RTD. See CH12 Page 395

1. RIP-Generated Default
1. When using RIP for the IBGP you can achieve a loop free backup/primary
design. RIP AD is 120, therefore when RTC receives the RIP advertised default
from RTD, RTC will insert that default into the routing table and not advertise
it's own default that was advertised by another AS. If RTD's external link goes
down, RTD will stop advertising it's default and RTC will start advertising it's
own external default.

2. OSPF-Generated Default - See CH12 Page 400

1. More configuration needs to be done with OSPF. RTD will advertise the default
route that was learned via EBGP (or statically created) and advertise this via
IBGP and OSPF, setting the local preference higher than the default learned via
EBGP (or static) on RTC.
2. RTC will use RTD's default route via IBGP, and not even advertise it's own
external default route due to a route-map configured to only advertise based on
whether it's a default route 0/0, and the next hop is from the external AS edge
router. RTD will have the same configuration, the only difference in
configuration is the next-hop on the route map configuration, and of course the
local preference.

3. Defaults Inside the AS: Other BGP Policies

1. RTC and RTD are both advertising defaults within their AS; and have configured
them in such a way as to not advertise them if their external links go down. All
is well until AS2 (the provider) starts to advertise MED based on AS2's internal
metrics. AS1 receives these path attributes along with the corresponding NLRI
and now some internet routes for outbound traffic prefer RTC and some prefer
RTD based on those MED values. This causes a loop when, due to the
advertised defaults, traffic is sent to RTC to exit to the internet, but RTC sends
the traffic back to be rerouted to RTD. In this scenario RTA and RTB our
internal only, and have no knowledge of the internet routes, only the default
routes.

III.

2. Solutions to this problem would be to do the following:

1. Ignore the MED and base the routing on a primary/backup scenario
2. Have a shorter path connection between RTC and RTD so that traffic is
redirected between exit points follows the shortest path between the IBGP
routers.
3. Run an IBGP mesh between RTA, RTB, RTC, and RTD.
Policy Routing - See CH12 Page 412
1. Policy Routing is a glorified type of static routing. However static routing is
based of the destination; while Policy Routing is based of the source, or a
combination of source and destination.

2. Policy Routing Based on Traffic Source

1. In this scenario AS1 is being provided two networks, and in this case these
networks are what's called Provider Allocated (PA) networks. 10.10.10.0 is
allocated by AS3, and 11.11.11.0 is allocated from AS4. AS1 wants outbound
traffic to be sent based on the source network, sending 10.10.10.0 to AS3, and
11.11.11.0 to AS4. This can be done by configuring policy routing based on the
source network, regardless of the final destination.
1. Next-hop 1.1.1.1 for source 10.10.10.0
2. Next-hop 2.2.2.2 for source 11.11.11.0
1. Recursive route lookup

3. Policy Routing Based on Traffic Source/Destination

1. Policy routing has been configured so that source network (RTA) 10.10.10.0
with a destination of 12.12.12.0 goes through the SF link to NY.
2. Also source 10.10.10.0 with a destination of 13.13.13.0 goes through the SJ link.
1. Set next hop of 1.1.1.1 for the S 10.10.10.0 D 12.12.12.0
2. Set next hop of 2.2.2.2 for the S 10.10.10.0 D 13.13.13.0

4. Policy Routing Defaults to Dynamic Routing

1. Static routing becomes problematic when backup is needed. Fortunately Cisco
implemented Policy Based Routing with the ability to configure multiple next
hops, as well as being able to configure if all the next-hops are unavailable to
rely on default dynamic routing.

5. Other Applications of Policy Routing

1. It may be applicable to use Policy based routing to divert traffic to a firewall
before going out to the internet, for example the diagram below.

2. Policy routing can also be useful for traffic balancing. Shown below dial up
users from one region; traffic can be sent to Provider 1, and the other region can
be sent to Provider 2.

3. Policy routing should not replace dynamic routing, but instead should
complement it. Policy routing has it's own set of drawbacks:
1. Extra static configuration is needed to identify sources of traffic or a
combination of source and destination. Care should be taken not to disrupt
other traffic and to specify other alternatives for traffic in case of backup
situations.
2. Policy routing is CPU-intensive because it is based on the source IP address,
unlike dynamic and static routing, which are based on the destination IP
address. Sophisticated caching and switching techniques have been
implemented all along based on the traffic's destination. Most

implementations have not yet optimized routing and caching techniques

based on the source of the IP packet. As such, policy routing takes additional
CPU cycles to detect source addresses. This behavior should change as
implementations attain a better understanding of IP traffic flows that let
caches keep track of source and destination information. This new caching
methodology would alleviate routers from disruptive processing on matching
sources of IP traffic and make policy routing much more effective and
practical.