Chapter 11: Configuring Basic BGP Functions and

Attributes

I. Building Peering Sessions

1. An IBGP peering session is formed within AS3, between RTA's loopback
address and RTF's physical address. EBGP sessions are also formed between
AS3 and AS1 by using the two directly connected IP addresses of RTA and RTC.
Another EBGP session is formed between RTF in AS3 and RTD in AS2, using IP
addresses that are not on the same segment (multihop).
2. Important to remember that TCP is a transport layer protocol that relies on the
underlying layer (network) for connectivity. In this case RTF is relying on the
IGP to get to RTD.
1. EBGP has a default TTL of 1 for the IP packet headers for an EBGP peer
session. So in the case of RTF peering with RTD, you must use the ebgp-
multihop 2 neighbor command in order to change the ttl to 2 so that the ip packet
headers of the peering session can reach RTD before being dropped.
1. When issuing the show ip bpg neighbor command on RTF, you will see two
neighbors; one being internal to the local AS 172.16.2.254, and also the external
neighbor 192.68.12.1. Table version = how many times the bgp table has been
 updated. Notice that for the external neighbor it says "External BGP neighbor
may be up to 2 hops away," this is due to the ebgp-multihop 2 command
configured for the RTF to RTD peering.
II. Route Filtering and Attribute Manipulation
1. Route filtering and attribute manipulation are the basis of implementing BGP
policies
1. BGP route maps
2. Prefix lists
3. Identifying and filtering routes based on the NLRI
4. Identifying and filtering routes based on the AS_PATH
2. In order for policies to take affect, you must clear the bgp peering, either resting
the entire session or using soft reconfiguration.
1. clear ip bgp [* | address | peer-group] [soft [in|out]]
2. BGP Route Maps
1. Route maps are used to create policies for filtering and setting or modifying Path
Attributes.
1. route-map name [permit | deny] [sequence-number]
2. When BGP applies a route-map to routing updates, it applies the lowest instance
first (in this case, instance 10). If the first set of conditions is not met, the second
instance is applied, and so on, until either a set of conditions has been met or
there are no more sets of conditions to apply. The condition portion of a route
map is set by using the match and set commands. The match command
specifies criteria that must be matched, and the set command specifies an action
that is to be taken if the routing update meets the conditions defined by the
match command.
 3. Prefix Lists
1. Prefix lists can be named by an alphanumeric string and can also be configured
with a description. The description is configured like this:
1. ip prefix-list list-name description text
2. To add or remove entries from a prefix list, you would use the following syntax:
1. [no] ip prefix-list list-name seq seq-value deny | permit network/len [ge ge-
value] [le le-value]
3. list-name is an alphanumeric string. You could use a standard number scheme,
or perhaps something more intuitive
1. ip prefix-list CustomerA description <up to 80 characters, spaces
permitted

Filtering Specific Prefixes

Filtering Criteria Command to Execute
Permit exact prefix 192.68.0.0/16 ip prefix-list sample permit 192.68.0.0/16
Deny a default route ip prefix-list sample deny 0.0.0.0/0
Permit all ip prefix-list sample permit 0.0.0.0/0 le 32
Deny all ip prefix-list sample deny 0.0.0.0/0 le 32
Deny /25+ , in all address space ip prefix-list sample deny 0.0.0.0/0 ge 25
In 192.68.0.0/24 , deny /25+ i prefix-list sample deny 192.68.0.0/24 ge 25
Permit all addresses from /8 to /24 ip prefix-list sample permit 0.0.0.0/0 ge 8 le 24
4. Identifying and Filtering Routes Based on the NLRI

1. The above diagram shows how to stop AS3 from becoming a transit area.
2. In order to use an access-list to filter a specific prefix and a specific mask, you
could use a prefix-list which is the easiest and best method, as you can choose
the bits to match with any particular prefix-length.
3. As mentioned above, in order to match a specific prefix with a specific mask,
prefix lists are best but you can also do it with an ACL; but the ACL must be
extended.
1. Example: access-list 101 permit ip host 172.16.0.0 host 255.255.0.0
 4. At first you may think you can just use a standard access-list to do this; let's say
you want to match exactly 192.168.0.0/16 (meaning be 192.168.0.0 and also
have the prefix-length of /16. So you write an ACL like the following: access-
list 1 permit ip 172.16.0.0 0.0.255.255
1. This however matches everything that starts with 172.16.0.0.

5. f
5. Identifying and Filtering Routes Based on the AS_PATH
1. Use an as-path access-list to permit routes that originate from the local AS using
a regular express. ^ means the beginning of the AS_PATH and $ means the end
of the AS_PATH. Together, it means no AS_PATH which is the same thing as
locally originated routes, as the AS_PATH is not attached to the route until it's
passed to an EBGP peer.
2. Use a filter-list router bgp sub-command in conjunction with an as-path access-
list to prevent AS3 from becoming a transit AS.
3. Use the following to verify that your regular expression works as intended;
displaying all the paths that match the specified regular expression.
1. show ip bgp regexp regular-expression

III. Peer Groups

1. You can create a peer group like you would a neighbor relationship. Once you
assigned filter-lists and route-maps to that peer-group, you can then assign that
peer group to any and all neighbors of which would be using the same policies
configured for that peer group.
2. For all members of a particular peer group, you can also assign additional
policies to a specific neighbor relationship; these route-maps/policies will
override the peer group configuration.
IV. Sources of Routing Updates
1. Routes can be injected dynamically or statically into BGP. The choice of method
depends on the number and stability of routes.
2. Injecting Information Dynamically into BGP

1. The above shows RTA and RTF connecting via OSPF for the IGP in AS3. RTF
has a customer (C1) connecting via RIP. C1 is pointing a default towards AS3
and advertising all routes to AS3 via RIP - RTF is then redistributing those RIP
routes into OSPF. RTA has an EBGP session with RTC, and RTA is injecting all
routes known via OSPF.

2. In the above configuration you can see that RTF configured s2/1 to be a passive-
interface. When passive-interface is used with RIP it stops RIP from sending
 updates on that interface, however RIP can still receive updates. Passive-
interface if used on EIGRP or OSPF stops hello packets and neighbor
adjacencies, and therefore stops routing advertisements.

3. Redistributing -
1. Subnets must be a parameter that accompanies the redistribute command
when redistributing into OSPF in order to redistribute classless networks.
2. default-metric is a useful router subcommand to use when redistributing
when granularity is not needed. Using a route-map to set metrics will
override the default-metric.
3. match external 1 external 2 part of the redistribute command above for ospf
being redistributed into BGP is used to redistribute not only the internal
OSPF routes, but also both types of external routes. By default, OSPF will
not redistribute external routes into BGP unless specified.
4. Above is an example of router RTA filtering outbound advertisements to
neighbor 172.16.20.1 using a route-map called BLOCKROUTES, which is using
access-list 1 as the criteria for the route map deny statement.

5. As shown above, instead of redistributing you can also use the network router
 subcommand. network network mask mask. For classful networks a mask isn't
necessary. Unlike IGPs, the network command must match the exact network
found in the local router's RIB in order for it to be advertised. The origin code is
included when using the network command, whereas redistributing leaves the
origin code incomplete marking it with a ?.

3. Injecting Information Statically into BGP

1. The below example illustrates the use of a static route being advertised by BGP
using the network command. Advertising static routes instead of routes from an
IGP translates to stable BGP, otherwise IGP instabilities translates to BGP
instabilities. The only drawback is that even if that network becomes
unavailable, it will still be advertised as being available unless the Ethernet
interface goes down.
2. If advertising an aggregate static route it's better to point it to the null0 interface
for loop prevention.
V. Overlapping Protocols: Backdoors
1. The below is an example of having a private OSPF link between two AS's and
BGP links going to AS3. OSPF AD is 110 by default, and EBGP is 20. So by
default, the BGP route will be preferred but the path is actually longer. In order
to prefer the OSPF route, one way to do this is to configure the route in question
as a backdoor under BGP router configuration by issuing network 192.68.10.0
backdoor. This makes the EBGP learned route go from AD of 20 to 200,
making the OSPF learned route more desirable. Note that the above network
command doesn't actually make BGP advertise it.
2. RTC's routing table before configuring the backdoor. Notice that 192.68.10.0/24
is learned via EBGP from RTA with an AD of 20. RTC will have to take the
long route through AS3 to get to AS2.

3. RTC now configures the backdoor changing the AD of the EBGP learned route
from 20 to 200, allowing the RTM to install the route because the OSPF learned
route (with an AD of 110) is now more desirable.

4. The route 192.68.10.0/24 is now learned via OSPF.

VI. BGP Attributes
1. Noticed the bgp subcommand filter-list 10 out. This subcommand in
combination with the ip as-path access-list 10 permit ^$ is what AS3 is using
on both routers to only advertised networks that have originated from AS3 and
no other networks in order to make AS3 a non-transit AS. the ^$ part of the as-
path access-list means that the as-path path attribute should be blank. So AS3 is
only advertising NLRI with a blank AS-PATH PA. The AS-PATH PA is blank
for routes that originate from the local AS.
2. The NEXT_HOP Attribute

1. (You may need to look at diagram 11-6 a few pages up to fully understand) Here
we have the bgp table of RTF (above) and RTA (below). RTF has learned about
192.68.11.0/24 with two possible paths with next hop 172.16.20.1 being the best.
It's important to ensure that you have ip reachability to the next-hop otherwise
the route would be unusable. In this example the EBGP NEXT-HOP (be default)
has been preserved. There's two ways to ensure you have connectivity to this
particular next hop. The first way; RTA is advertising the ISP link where the
EBGP NEXT-HOP is in OSPF, so RTF knows how to reach it that way. If you
look at the configuration examples above, you'll see that RTA made S0 a passive-
interface in OSPF configuration as there's no reason to send OSFP hello's to
RTC. The other method is to configure next-hop-self in RTA's BGP neighbor
command going to RTF to use RTA as the next-hop for 192.68.11.0/24 instead of
preserving the EBGP NEXT-HOP.

2. Notice that RTA's route to 192.68.11.0 has only one path while RTA has two
possible paths for 192.68.10.0. This is because RTF is using RTA's route to
192.68.11.0 as the best route and therefore is not advertising it's other path to
RTA. This is typical BGP behavior.
3. The AS_PATH Attribute

1. RTF's BGP table; in this example we look at the route for 192.68.11.0 with one
path being learned via IBGP and the other path learned via EBGP. The IBGP
learned route is best due to the path being shorter. The IBGP learned route only
has to get to AS1 and that's it, while the EBGP path would have to go through
AS2 to get to AS1 making it longer and therefore less desirable.
2. AS_PATH Manipulation

1. RTC has created a route map, prepending to the AS_PATH attribute being
advertised to RTA with two extra AS numbers. Specifically, looking at route
192.68.11.0 again, RTF now prefers the path through AS2. See below the BGP
table of RTF for route 192.68.11.0
3. Using Private ASs

1. RTA is using a private AS. RTC is able to remove the private AS information
from advertisements out to other ASes using the neighbor a.b.c.d remove-
private-AS command to keep the private information from leaking into the
internet. See the diagram above and the configurations and show commands
below.
4. The LOCAL_PREF Attribute

1. LOCAL_PREF is an AS-wide PA, meaning that when RTF (above) configures a

route-map to set the local-pref to 300 for all incoming advertisements from RTD
that the local-pref PA is advertised to all other bgp speakers within AS3; meaning
all other routers in AS3 (which in this case is only RTA) will go through RTF for
routes advertised from RTD. Below are some examples of the BGP table of RTF
and RTA after configuring the local-pref of 300 for routes advertised from RTD.
5. The MULTI_EXIT_DISC Attribute
1. Multi-Exit Discriminator, AKA metric is pretty much just like IGP metrics.
When advertised to a neighbor, the smaller the metric the more desirable.
Metrics influence incoming traffic; however metrics do not propagate farther
than then the AS you advertised them to.
2. The below diagram is an example of AS3, specifically RTA and RTF advertising
MED based on IGP metrics to to the neighboring AS: AS1. RTG is an IGP only
router.
1. Above and below are the configurations for RTA and RTF, with RTF specifically
setting MED for 170.16.1.0, setting it to 50. This means that for 172.16.1.0, that
AS1 will prefer the RTA link, as the MED advertised by RTA for this route is 0.
 1. Above is the BGP table of RTD of AS1, with metrics based on AS3's IGP
metrics. The above configurations don't show it, but in order for the BGP MED
values to be based on the IGP metrics, RTA and RTF would have had to
configure a route-map pointed towards AS1 with the set metric-type internal
command.

6. The COMMUNITY Attribute

1. In the diagram above, RTA configures a route-map that matches network

172.16.65.0/26 and sets the community no-export and advertises it to RTC.
This community will tell RTC not to advertise this route to any other AS.
2. The configuration example above shows how RTA sets the community attribute.
Notice that RTA also configures the send-community bgp neighbor command
for RTC. By default communities are not advertised to internal or external
neighbors so the send-community neighbor subcommand is necessary to
advertise the community attribute to RTC.

3. Above is RTC's bgp table entry for 172.16.65.0/26 showing the no-export
community has indeed been advertised to RTC; below is proof that RTD was not
advertised the route due to the no export community attribute.
VII. BGP-4 Aggregation
1. Aggregate Only, Suppressing the More-Specific

1. The above diagram is showing RTA and RTF both using the aggregate-address
172.16.0.0 255.255.0.0 summary-only bgp router subcommand in order to
aggregate their more specific routes, and only advertise the aggregate
suppressing the more specific routes.
2. RTA's bgp table, shown below, is showing that RTA has originated (NEXT-HOP
0.0.0.0) the aggregate, and also showing that the more specific routes are being
suppressed indicated by the "s" in front of the routes.

3. RTC's BGP table is showing that it has received the aggregate, and no other
specific routes, and is showing that it has two paths to the aggregate due to RTF's
advertisement of the aggregate as well.

4. RTC's is showing the bgp table entry specifically for the 172.16.0.0 aggregate.
The numbers in front of both paths are showing the AS-PATH. The best entry is
showing a 3 for the AS-PATH, and the entry right below it is showing a 2 and 3.
The line "aggregated by 3 172.16.2.254" shows the AS and the Router-ID of the
router that originated the aggregate. Also notice the atomic-aggregate PA,
meaning that the aggregate has lost all it's subordinate AS-PATH PA information
and the only AS-PATH information left is that of the aggregate itself, revealing
only where the aggregate came from and not where the subordinate routes came
from, if any of the routes came from varying ASes.
5. The above and below configuration snippet shows RTA and RTF advertising an
aggregate based off of a static route going to the null0 interface. This is another
way of advertising an aggregate; however one would have to manually suppress
the subordinate routes if needed by filtering them.
2. Aggregate Plus More-Specific Routes

1. The above diagram is showing AS3 routers RTA and RTF is advertising an
aggregate along with more specific routes. The two configuration examples
below are showing that RTA and RTF are configured with aggregate-address
172.16.0.0 255.255.0.0 with no summary-only command.
2. Below is RTC's BGP table showing that the AS3 routers are not only advertising
the aggregate but also the subordinate routes.
3. Here you see RTF is now configuring a route-map. Sequence 10 of the route-
map is matching access-list 101 which is permitting the aggregate address
172.16.0.0. Sequence 20 of the route map is matching all over routes and setting
the community no-export to tell the neighboring AS not to advertise the
subordinate routes to any other AS.

4. Below, RTC has been configured with the send-community bgp neighbor
command pointing towards RTD, so that RTC advertises the no-export
community coming from AS3, otherwise the routes going from RTC to RTD
would not have the no-export community and would therefore advertise the
subordinate routes to all other ASes.
5. As a best practice, the send-community neighbor command should be
configured on RTD pointing to RTC as well... even though RTC is not
connecting directly to any other AS so the only router we need to worry about in
this situation is RTD, so RTD is getting the community advertised from both
RTC and RTF.

6. As you can see below the subordinate route has no-export from both paths, and
the aggregate can be advertised normally to any other AS.

7. Lastly, you can see that RTG has only received the advertisement the aggregate
from AS3.
3. Aggregate with a Subset of the More-Specific Routes
1. The below diagram in this example is showing that the AS3 routers, RTA and
RTF, are both advertising the aggregate 172.16.0.0/16, but also are both
advertising a subset of subordinate routes. RTA will suppress subordinate route
172.16.220.0 and advertise all of the other subordinate routes, while RTF will
only advertise the subordinate route 172.16.220.0 with the aggregate, but no
other subordinate routes. See the configurations below to see how this is
accomplished.
2. As mentioned above, RTA and RTF are advertising a subset of subordinate routes
along with the aggregate. This is accomplished by creating a suppress-map; an
option for the router bgp aggregate subcommand. RTA creates access-list 1 to
match 172.16.220.0 for the route-map SUPPRESS, and then uses the route-map
on the aggregate-address 172.16.0.0 255.255.0.0 suppress-map SUPPRESS in
order to suppress 172.16.220.0 and advertise all other subordinate routes to AS1.

3. RTA's bgp table blow showing that the suppress-map worked in suppressing
192.16.220.0 indicated by the "s" next do 172.16.220.0
4. RTF's configuration below is showing the same type of configuration, except in
this case RTF is suppressing ALL subordinate routes except for 192.16.220.0.

5. Below is the bgp table of RTF showing that the suppress map is doing what it's
supposed to be doing which is to suppress all of the subordinate routes except for
192.16.220.0
6. Below is the BGP table of RTD showing that there is only one path for
172.16.220.0 which is next-hop 192.68.5.1 (RTF). If for some reason one of the
links to AS1 is broken, the aggregate route will backup the subordinate routes.

7. After suppressing certain routes and you then decide that one or some of the
suppressed routes should actually be advertised to AS1, instead of editing the
suppress map you could instead use an unsuppress-map. The unsuppress map is
configured the same way using an access-list or some other list to permit the
route(s) and then configure a route-map to match the routes based on the access
list. The only difference aside from the fact that this is meant for unsuppressing
is the fact that the unsuppress map is configured on a neighbor instead of
configured under the aggregate-address command.
4. Loss of Information Inside Aggregates
1. In the diagram below, AS3 router, RTA, is aggregating AS1's and AS2's routes of
192.68.11.0 and 192.68.10.0, and advertising this aggregate to AS5.

2. The problem with aggregating is that the aggregate loses the subordinate routing
information, specifically the AS-PATH information of the subordinate routes.
Below is RTA's configuration for aggregating AS2 and AS2's routes.
3. Below is AS5's router, RTK's BGP table, showing the aggregate 192.68.0.0/16.
Notice that the AS-PATH PA is only showing AS3. This is an example of the
loss of the AS-PATH information of the subordinate routes.

4. In order to remedy the missing AS-PATH problem, when configuring an

aggregate, use the as-set parameter at the end of the aggregate command as
shown below in RTA's revised configuration.

5. After revising RTA's configuration using the as-set command, as shown below in
RTK's BGP table, it is now showing an as-set, a summary of the AS-PATH
information from the other ASes as part of the AS-PATH information in the
aggregate. This is an important consideration as the AS-PATH PA is used for
EBGP's loop prevention. However, another fact to consider is that every time
there's an update in any of the subordinate ASes, the aggregate will be updated.
So, if there's many subordinate ASes, the aggregate could be updated many times
in a short amount of time causing there to be instability in the aggregate.
6. One other consideration with AS-SET: all PAs will be carried over...
5. Changing the Aggregate's Attributes
1. Based on the diagram above, RTC is sending the community no-export for route
192.68.11.0, of which is one of the routes that RTA is aggregating.

2. Below is RTA's current configuration which poses a problem in that the

aggregate is using the as-set parameter which carries over all the subordinate
PAs, including the community no-export.
3. Below is RTA's BGP table, specifically the entry for the aggregate 192.68.0.0.
As shown below, the community from the subordinate route from RTC has been
carried over, which will not allow the aggregate to be advertised.

4. To remedy this situation, RTA has now been configured with an attribute map;
another form of a route-map, changing the community from no-export to none.

5. RTA's BGP table entry for aggregate 192.68.0.0 is now showing no community
and can now be advertised.
6. Forming the Aggregate Based on a Subnet of Specific Routes
1. In the diagram below, AS3 is forming the aggregate 192.68.0.0. In normal
operation the aggregate would be automatically formed based on all subordinate
routes that fit into 192.68.0.0, including AS1's route to 192.68.11.0 and AS2's
route to 192.68.10.0. However, AS3 wants to be able to advertise the aggregate
to AS1, and therefore needs to form the aggregate on AS2's route only.

2. Below is an example on how you would configure the aggregate only on AS2's
route, which is called an advertise-map, another form of a route-map. Access-
list 1 is permitting 192.68.10.0, which is used for the route-map
SELECT_MORE_SPECIF_ROUTES. The route map is then used as the
advertise-map for the creation of the aggregate.
3. Below you can see RTA's BGP table for entry 192.68.0.0, the aggregate. As you
can see the path information only shows AS 2. When this is advertised to AS1,
the EBGP loop prevention will not drop the aggregate, as planned.