|
In preparation of your CCNA exam, we want to make sure we cover the various concepts that we could see on your Cisco CCNA exam. So to assist you, below we will discuss on of the more difficult CCNA concepts; BGP Case Studies. As you progress through your CCNA exam studies, I am sure with repetition you will find this topic becomes easier. So even though it may be a difficult concept and confusing at first, keep at it as no one said getting your Cisco certification would be easy!
Prerequisites RequirementsThere are no specific requirements for this document. Components Used This document is not restricted to specific software and hardware versions.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
ConventionsFor more information on document conventions, refer to Cisco Technical Tips Conventions.
BGP Case Studies 1 The Border Gateway Protocol (BGP), defined in RFC 1771 , allows you to create loop-free interdomain routing between autonomous systems (AS). An AS is a set of routers under a single technical administration. Routers in an AS can use multiple interior gateway protocols to exchange routing information inside the AS and an exterior gateway protocol to route packets outside the AS. How Does BGP Work? BGP uses TCP as its transport protocol (port 179). Two BGP routers form a TCP connection between one another (peer routers) and exchange messages to open and confirm the connection parameters.
BGP routers exchange network reachability information. This information is mainly an indication of the full paths (BGP AS numbers) that a route should take in order to reach the destination network. This information helps in constructing a graph of ASs that are loop-free and where routing policies can be applied in order to enforce some restrictions on the routing behavior.
Any two routers that have formed a TCP connection in order to exchange BGP routing information are called peers, or neighbors. BGP peers initially exchange their full BGP routing tables. After this exchange, incremental updates are sent as the routing table changes. BGP keeps a version number of the BGP table, which should be the same for all of its BGP peers. The version number changes whenever BGP updates the table due to routing information changes. Keepalive packets are sent to ensure that the connection is alive between the BGP peers and notification packets are sent in response to errors or special conditions. eBGP and iBGP If an AS has multiple BGP speakers, it could be used as a transit service for other ASs. As you see below,
It is necessary to ensure reachability for networks within an AS before sending the information to external ASs. This is done by a combination of internal BGP (iBGP) peering between routers inside an AS and by redistributing BGP information to Internal Gateway Protocols (IGPs) running in the AS.
As far as this paper is concerned, when BGP is running between routers belonging to two different ASs, we call this exterior BGP (eBGP). When BGP is running between routers in the same AS, we call this iBGP.
Enabling BGP Routing Use these steps to enable and configure BGP.
Let us assume you want to have two routers, RTA and RTB, talk BGP. In the first example RTA and RTB are in different ASs and in the second example both routers belong to the same AS.
We start by defining the router process and the AS number to which the routers belong. Use this command to enable BGP on a router:
router bgp autonomous-system
RTA#
router bgp 100
RTB#
router bgp 200
The above statements indicate that RTA is running BGP and it belongs to AS100 and RTB is running BGP and it belongs to AS200.
The next step in the configuration process is to define BGP neighbors, which indicates the routers that are trying to talk BGP.
Forming BGP Neighbors Two BGP routers become neighbors once they establish a TCP connection between each other. The TCP connection is essential in order for the two peer routers to start exchanging routing updates.
Once the TCP connection is up, the routers send open messages in order to exchange values such as the AS number, the BGP version they're running, the BGP router ID and the keepalive hold time. After these values are confirmed and accepted the neighbor connection is established. Any state other than "established" is an indication that the two routers didn't become neighbors, and BGP updates won't be exchanged.
Use this neighbor command to establish a TCP connection: The remote-as number is the AS number of the router we're trying to connect to using BGP. The ip-address is the next hop directly-connected address for eBGP and any IP address on the other router for iBGP.
It's essential that the two IP addresses used in the neighbor command of the peer routers be able to reach one another. One sure way to verify reachability is an extended ping between the two IP addresses. The extended ping forces the pinging router to use as source the IP address specified in the neighbor command rather than the IP address of the interface the packet is going out from.
It is important to reset the neighbor connection in case any BGP configuration changes are made in order for the new parameters to take effect.
clear ip bgp address (where address is the neighbor address)
clear ip bgp * (clear all neighbor connections)
By default, BGP sessions begin using BGP version 4 and negotiating downward to earlier versions if necessary. To prevent negotiations and force the BGP version used to communicate with a neighbor, perform the following task in router configuration mode:
neighbor {ip address|peer-group-name}version value
RTA#
router bgp 100
neighbor 129.213.1.1 remote-as 200
RTB#
router bgp 200
neighbor 129.213.1.2 remote-as 100
neighbor 175.220.1.2 remote-as 200
RTC#
router bgp 200
neighbor 175.220.212.1 remote-as 200 In the above example RTA and RTB are running eBGP. RTB and RTC are running iBGP. The difference between eBGP and iBGP is manifested by having the remote-as number pointing to either an external or an internal AS. Also, the eBGP peers are directly connected while the iBGP peers are not. iBGP routers don't have to be directly connected, as long as there is some IGP running that allows the two neighbors to reach one another.
The following is an example of the information that the show ip bgp neighbors command displays. Pay special attention to the BGP state, since anything other than state "established" indicates the peers aren't up. You should also note the BGP version is 4, the remote router ID (highest IP address on the router or the highest loopback interface in case it exists) and the table version (this is the state of the table, any time new information comes in, the table increases the version and a version that keeps incrementing indicates that some route is flapping causing routes to continuously be updated).
# show ip bgp neighbors
BGP neighbor is 129.213.1.1, remote AS 200, external link
BGP version 4, remote router ID 175.220.12.1
BGP state = Established, table version = 3, up for 0:10:59
Last read 0:00:29, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 2828 messages, 0 notifications, 0 in queue
Sent 2826 messages, 0 notifications, 0 in queue
Connections established 11; dropped 10
BGP and Loopback Interfaces Using a loopback interface to define neighbors is common with iBGP, but not with eBGP. Normally the loopback interface is used to make sure the IP address of the neighbor stays up and is independent of hardware functioning properly. In the case of eBGP, peer routers are frequently directly connected and loopback does not apply.
If you use the IP address of a loopback interface in the neighbor command, you need some extra configuration on the neighbor router. The neighbor router needs to tell BGP it's using a loopback interface rather than a physical interface to initiate the BGP neighbor TCP connection. The command used to indicate a loopback interface is:
neighbor ip-address update-source interface
The following example illustrates the use of this command.
RTA#
router bgp 100
neighbor 190.225.11.1 remote-as 100
neighbor 190.225.11.1 update-source loopback 1
RTB#
router bgp 100
neighbor 150.212.1.1 remote-as 100
In the above example, RTA and RTB are running iBGP inside AS 100. RTB is using in its neighbor command the loopback interface of RTA (150.212.1.1); in this case RTA has to force BGP to use the loopback IP address as the source in the TCP neighbor connection. RTA does this by adding the update-source int loopback configuration (neighbor 190.225.11.1 update-source loopback 1) and this statement forces BGP to use the IP address of its loopback interface when talking to neighbor 190.225.11.1.
Note that RTA has used the physical interface IP address (190.225.11.1) of RTB as a neighbor, which is why RTB does not need any special configuration. Refer to Sample Configuration for iBGP and eBGP With or Without a Loopback Address for a complete network scenario sample configuration. eBGP Multihop In some cases, a Cisco router can run eBGP with a third party router that doesn't allow the two external peers to be directly connected. To achieve this, you can use eBGP multihop, which allows the neighbor connection to be established between two non-directly-connected external peers. The multihop is used only for eBGP and not for iBGP. The following example illustrates of eBGP multihop.
RTA#
router bgp 100
neighbor 180.225.11.1 remote-as 300
neighbor 180.225.11.1 ebgp-multihop
RTB#
router bgp 300
neighbor 129.213.1.2 remote-as 100 RTA is indicating an external neighbor that isn't directly connected. RTA needs to indicate that it's using ebgp-multihop. On the other hand, RTB is indicating a neighbor that is directly connected (129.213.1.2), which is why it doesn't need the ebgp-multihop command. You should also configure an IGP or static routing to allow the non-connected neighbors to reach each other.
The following example shows how to achieve load balancing with BGP in a particular case where we have eBGP over parallel lines. eBGP Multihop (Load Balancing)
RTA#
int loopback 0
ip address 150.10.1.1 255.255.255.0
router bgp 100
neighbor 160.10.1.1 remote-as 200
neighbor 160.10.1.1 ebgp-multihop
neighbor 160.10.1.1 update-source loopback 0
network 150.10.0.0
ip route 160.10.0.0 255.255.0.0 1.1.1.2
ip route 160.10.0.0 255.255.0.0 2.2.2.2
RTB#
int loopback 0
ip address 160.10.1.1 255.255.255.0
router bgp 200
neighbor 150.10.1.1 remote-as 100
neighbor 150.10.1.1 update-source loopback 0
neighbor 150.10.1.1 ebgp-multihop
network 160.10.0.0
ip route 150.10.0.0 255.255.0.0 1.1.1.1
ip route 150.10.0.0 255.255.0.0 2.2.2.1 The above example illustrates the use of loopback interfaces, update-source and ebgp-multihop. This is a workaround in order to achieve load balancing between two eBGP speakers over parallel serial lines. In normal situations, BGP picks one of the lines to send packets on, and load balancing wouldn't happen. By introducing loopback interfaces, the next hop for eBGP is the loopback interface. We use static routes (we could also use an IGP) to introduce two equal cost paths to reach the destination. RTA has two choices to reach next hop 160.10.1.1: one via 1.1.1.2 and the other one via 2.2.2.2, and the same for RTB. Route Maps Route maps are used heavily with BGP. In the BGP context, the route map is a method used to control and modify routing information. This is done by defining conditions for redistributing routes from one routing protocol to another or controlling routing information when injected in and out of BGP. The format of the route map follows:
route-map map-tag [[permit | deny] | [sequence-number]]
The map tag is just a name you give to the route map. Multiple instances of the same route map (same name-tag) can be defined. The sequence number is just an indication of the position a new route map is to have in the list of route maps already configured with the same name.
For example, if there are two instances of the route map defined, called MYMAP, the first instance will have a sequence-number of 10, and the second will have a sequence number of 20.
route-map MYMAP permit 10 (first set of conditions goes here.)
route-map MYMAP permit 20 (second set of conditions goes here.)
When applying route map MYMAP to incoming or outgoing routes, the first set of conditions will be applied via instance 10. If the first set of conditions is not met then we proceed to a higher instance of the route map. match and set Configuration Commands Each route map will consist of a list of match and set configuration. The match will specify a match criteria and set specifies a set action if the criteria enforced by the match command are met.
For example, you could define a route map that checks outgoing updates and if there is a match for IP address 1.1.1.1 then the metric for that update will be set to 5. The above can be illustrated by the following commands:
match ip address 1.1.1.1
set metric 5
Now, if the match criteria are met and we have a permit then the routes will be redistributed or controlled as specified by the set action and we break out of the list.
If the match criteria are met and we have a deny then the route will not be redistributed or controlled and we break out of the list.
If the match criteria are not met and we have a permit or deny then the next instance of the route map (instance 20 for example) will be checked, and so on until we either break out or finish all the instances of the route map. If we finish the list without a match then the route we are looking at will not be accepted nor forwarded.
In Cisco IOS® software releases earlier than 11.2, when you use route maps for filtering BGP updates (as we will see later), rather redistributing between protocols, you cannot filter on the inbound when using a match command on the IP address. Filtering on the outbound is acceptable. This restriction is lifted in Cisco IOS Software Release 11.2 and later.
The related commands for match are:
match as-path
match community
match clns
match interface
match ip address
match ip next-hop
match ip route-source
match metric
match route-type
match tag
The related commands for set are:
set as-path
set clns
set automatic-tag
set community
set interface
set default interface
set ip default next-hop
set level
set local-preference
set metric
set metric-type
set next-hop
set origin
set tag
set weight
Let us look at some route map examples:
Example 1:
Assume RTA and RTB are running RIP; RTA and RTC are running BGP. RTA is getting updates via BGP and redistributing them to RIP. If RTA wants to redistribute to RTB routes about 170.10.0.0 with a metric of 2 and all other routes with a metric of 5 then we might use the following configuration:
RTA#
router rip
network 3.0.0.0
network 2.0.0.0
network 150.10.0.0
passive-interface Serial0
redistribute bgp 100 route-map SETMETRIC
router bgp 100
neighbor 2.2.2.3 remote-as 300
network 150.10.0.0
route-map SETMETRIC permit 10
match ip-address 1
set metric 2
route-map SETMETRIC permit 20
set metric 5
access-list 1 permit 170.10.0.0 0.0.255.255
In the above example if a route matches the IP address 170.10.0.0 it will have a metric of 2 and then we break out of the route map list. If there is no match then we go down the route map list which says, set everything else to metric 5. It is always very important to ask the question, what will happen to routes that do not match any of the match statements, because they will be dropped by default. Example 2:
Suppose in the above example we did not want AS100 to accept updates about 170.10.0.0. Since route maps cannot be applied on the inbound when matching based on an IP address, we have to use an outbound route map on RTC:
RTC#
router bgp 300
network 170.10.0.0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map STOPUPDATES out
route-map STOPUPDATES permit 10
match ip address 1
access-list 1 deny 170.10.0.0 0.0.255.255
access-list 1 permit 0.0.0.0 255.255.255.255
Now that you feel more comfortable with how to start BGP and how to define a neighbor, let us look at how to start exchanging network information.
There are multiple ways to send network information using BGP. The following sections will go through these methods one-by-one. Network Command The format of the network command follows:
network network-number [mask network-mask]
The network command controls what networks are originated by this box. This is a different concept from what you are used to configuring with IGRP and RIP. With this command we are not trying to run BGP on a certain interface, rather we are trying to indicate to BGP what networks it should originate from this box. The mask portion is used because BGP version 4 (BGP4) can handle subnetting and supernetting. A maximum of 200 entries of the network command are accepted.
The network command will work if the network you are trying to advertise is known to the router, whether connected, static or learned dynamically.
An example of the network command follows:
RTA#
router bgp 1
network 192.213.0.0 mask 255.255.0.0
ip route 192.213.0.0 255.255.0.0 null 0
The above example indicates that router A, will generate a network entry for 192.213.0.0/16. The /16 indicates that we are using a supernet of the class C address and we are advertizing the first two octets (the first 16 bits).
Note that we need the static route to get the router to generate 192.213.0.0 because the static route will put a matching entry in the routing table. Redistribution The network command is one way to advertise your networks via BGP. Another way is to redistribute your IGP (IGRP, OSPF, RIP, EIGRP, and so on) into BGP. This sounds scary because now you are dumping all of your internal routes into BGP, some of these routes might have been learned via BGP and you do not need to send them out again. Careful filtering should be applied to make sure you are sending to the internet only routes that you want to advertise and not everything you have. Let us look at the example below.
RTA is announcing 129.213.1.0 and RTC is announcing 175.220.0.0. Look at RTC's configuration:
If you use a network command you will have:
RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote-as 300
network 175.220.0.0 mask 255.255.0.0
!--- This will limit the networks
!--- originated by your AS to 175.220.0.0
If you use redistribution instead you will have:
RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote-as 300
redistribute eigrp 10
!--- EIGRP will inject 129.213.1.0 again into BGP
This will cause 129.213.1.0 to be originated by your AS. This is misleading because you are not the source of 129.213.1.0 but AS100 is. So you would have to use filters to prevent that network from being sourced out by your AS. The correct configuration would be:
RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote-as 300
neighbor 1.1.1.1 distribute-list 1 out
redistribute eigrp 10
access-list 1 permit 175.220.0.0 0.0.255.255
The access-list command is used to control what networks are to be originated from AS200.
Redistribution of OSPF into BGP is slightly different than for other IGPs. The simple configuration of redistribute ospf 1 under router bgp does not work. Specific keywords such as internal, external, and nssa-external are required to redistribute respective routes. Refer to Understanding Redistribution of OSPF Routes into BGP for more details. Static Routes and Redistribution You could always use static routes to originate a network or a subnet. The only difference is that BGP will consider these routes as having an origin of incomplete (unknown). In the above example the same could have been accomplished by doing:
RTC#
router eigrp 10
network 175.220.0.0
redistribute bgp 200
default-metric 1000 100 250 100 1500
router bgp 200
neighbor 1.1.1.1 remote-as 300
redistribute static
...
ip route 175.220.0.0 255.255.255.0 null0
....
The null 0 interface means disregard the packet. So if I get the packet and there is a more specific match than 175.220.0.0 (which exists of course) the router will send it to the specific match otherwise it will disregard it. This is a nice way to advertise a supernet.
We have discussed how we can use different methods to originate routes out of our autonomous system. Please remember that these routes are generated in addition to other BGP routes that BGP has learned via neighbors (internal or external). BGP passes on information that it learns from one peer to other peers. The difference is that routes generated by the network command, or redistribution or static, will indicate your AS as the origin for these networks.
Injecting BGP into IGP is always done by redistribution.
Example:
RTA#
router bgp 100
neighbor 150.10.20.2 remote-as 300
network 150.10.0.0
RTB#
router bgp 200
neighbor 160.10.20.2 remote-as 300
network 160.10.0.0
RTC#
router bgp 300
neighbor 150.10.20.1 remote-as 100
neighbor 160.10.20.1 remote-as 200
network 170.10.00
Note that you do not need network 150.10.0.0 or network 160.10.0.0 in RTC unless you want RTC to also generate these networks on top of passing them on as they come in from AS100 and AS200. Again the difference is that the network command will add an extra advertisement for these same networks indicating that AS300 is also an origin for these routes.
An important point to remember is that BGP will not accept updates that have originated from its own AS. This is to insure a loop free interdomain topology.
For example, assume AS200 above had a direct BGP connection into AS100. RTA will generate a route 150.10.0.0 and will send it to AS300 then RTC will pass this route to AS200 with the origin kept as AS100, RTB will pass 150.10.0.0 to AS100 with origin still AS100. RTA will notice that the update has originated from its own AS and will ignore it. iBGP iBGP is used if an AS wants to act as a transit system to other ASs. You might ask, why can't we do the same thing by learning via eBGP redistributing into IGP and then redistributing again into another AS? We can, but iBGP offers more flexibility and more efficient ways to exchange information within an AS; for example iBGP provides us with ways to control what is the best exit point out of the AS by using local preference (will be discussed later).
RTA#
router bgp 100
neighbor 190.10.50.1 remote-as 100
neighbor 170.10.20.2 remote-as 300
network 150.10.0.0
RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
neighbor 175.10.40.1 remote-as 400
network 190.10.50.0
RTC#
router bgp 400
neighbor 175.10.40.2 remote-as 100
network 175.10.0.0
Note: An important point to remember, is that when a BGP speaker receives an update from other BGP speakers in its own AS (IBGP), the receiving BGP speaker will not redistribute that information to other BGP speakers in its own AS. The receiving BGP speaker will redistribute that information to other BGP speakers outside of its AS. That is why it is important to sustain a full mesh between the IBGP speakers within an AS.
In the above diagram, RTA and RTB are running iBGP and RTA and RTD are running iBGP also. The BGP updates coming from RTB to RTA will be sent to RTE (outside of the AS) but not to RTD (inside of the AS). This is why an iBGP peering should be made between RTB and RTD in order not to break the flow of the updates. The BGP Decision Algorithm After BGP receives updates about different destinations from different autonomous systems, the protocol will have to decide which paths to choose in order to reach a specific destination. BGP will choose only a single path to reach a specific destination.
The decision process is based on different attributes, such as next hop, administrative weights, local preference, the route origin, path length, origin code, metric and so on.
BGP will always propagate the best path to its neighbors. Refer to BGP Best Path Selection Algorithm for more information.
The following sections will try to explain these attributes and show how they are used. BGP Case Studies 2 AS_PATH Attribute
Whenever a route update passes through an AS, the AS number is prepended to that update. The AS_PATH attribute is actually the list of AS numbers that a route has traversed in order to reach a destination. An AS_SET is an ordered mathematical set {} of all the ASs that have been traversed. An example of AS_SET is given later.
In the above example, network 190.10.0.0 is advertised by RTB in AS200, when that route traverses AS300 and RTC will append its own AS number to it. So when 190.10.0.0 reaches RTA it will have two AS numbers attached to it: first 200 then 300. So as far as RTA is concerned the path to reach 190.10.0.0 is (300,200).
The same applies for 170.10.0.0 and 180.10.0.0. RTB will have to take path (300,100), such as traverse AS300 and then AS100 in order to reach 170.10.0.0. RTC will have to traverse path (200) in order to reach 190.10.0.0 and path (100) in order to reach 170.10.0.0. Origin Attribute The origin is a mandatory attribute that defines the origin of the path information. The origin attribute can assume three values:
IGP: Network Layer Reachability Information (NLRI) is interior to the originating AS. This normally happens when we use the bgp network command or when IGP is redistributed into BGP, then the origin of the path info will be IGP. This is indicated with an "i" in the BGP table.
EGP: NLRI is learned via EGP (Exterior Gateway Protocol). This is indicated with an "e" in the BGP table.
INCOMPLETE: NLRI is unknown or learned via some other means. This usually occurs when we redistribute a static route into BGP and the origin of the route will be incomplete. This is indicated with an "?" in the BGP table.
RTA#
router bgp 100
neighbor 190.10.50.1 remote-as 100
neighbor 170.10.20.2 remote-as 300
network 150.10.0.0
redistribute static
ip route 190.10.0.0 255.255.0.0 null0
RTB#
router bgp 100
neighbor 150.10.30.1 remote-as 100
network 190.10.50.0
RTE#
router bgp 300
neighbor 170.10.20.1 remote-as 100
network 170.10.0.0
RTA will reach 170.10.0.0 via: 300 i (which means the next AS path is 300 and the origin of the route is IGP). RTA will also reach 190.10.50.0 via: i (which means, the entry is in the same AS and the origin is IGP). RTE will reach 150.10.0.0 via: 100 i (the next AS is 100 and the origin is IGP). RTE will also reach 190.10.0.0 via: 100 ? (the next AS is 100 and the origin is incomplete "?", coming from a static route). BGP Next Hop Attribute 
The BGP next hop attribute is the next hop IP address that is going to be used to reach a certain destination.
For eBGP, the next hop is always the IP address of the neighbor specified in the neighbor command. In the above example, RTC will advertise 170.10.0.0 to RTA with a next hop of 170.10.20.2 and RTA will advertise 150.10.0.0 to RTC with a next hop of 170.10.20.1. For IBGP, the protocol states that the next hop advertised by EBGP should be carried into IBGP. Because of that rule, RTA will advertise 170.10.0.0 to its IBGP peer RTB with a next hop of 170.10.20.2. So according to RTB, the next hop to reach 170.10.0.0 is 170.10.20.2 and not 150.10.30.1.
You should make sure that RTB can reach 170.10.20.2 via IGP, otherwise RTB will drop packets destined to 170.10.0.0 because the next hop address would be inaccessible. For example, if RTB is running IGRP you could also run igrp on RTA network 170.10.0.0. You would want to make IGRP passive on the link to RTC so BGP is only exchanged.
RTA#
router bgp 100
neighbor 170.10.20.2 remote-as 300
neighbor 150.10.50.1 remote-as 100
network 150.10.0.0
RTB#
r outer bgp 100
neighbor 150.10.30.1 remote-as 100
RTC#
router bgp 300
neighbor 170.10.20.1 remote-as 100
network 170.10.0.0
*RTC will advertise 170.10.0.0 to RTA with a next hope = 170.10.20.2
*RTA will advertise 170.10.0.0 to RTB with a next hope = 170.10.20.2 (The eBGP next hop is carried in iBGP.)
Special care should be taken when dealing with multiaccess and NBMA networks as described in the following sections. BGP Next Hop (Multiaccess Networks)
The following example shows how the next hop will behave on a multiaccess network such as Ethernet.
Assume that RTC and RTD in AS300 are running OSPF. RTC is running BGP with RTA. RTC can reach network 180.20.0.0 via 170.10.20.3. When RTC sends a BGP update to RTA regarding 180.20.0.0 it will use as next hop 170.10.20.3 and not its own IP address (170.10.20.2). This is because the network between RTA, RTC and RTD is a multiaccess network and it makes more sense for RTA to use RTD as a next hop to reach 180.20.0.0 rather than making an extra hop via RTC.
*RTC will advertise 180.20.0.0 to RTA with a next hop 170.10.20.3.
If the common media to RTA, RTC and RTD was not multiaccess, but NBMA (Non Broadcast Media Access) then further complications will occur. BGP Next Hop (NBMA) 
If the common media as you see in the shaded area above is a frame relay or any NBMA cloud then the exact behavior will occur as if we were connected via Ethernet. RTC will advertise 180.20.0.0 to RTA with a next hop of 170.10.20.3.
The problem is that RTA does not have a direct PVC to RTD, and cannot reach the next hop. In this case routing will fail.
In order to remedy this situation a command called next-hop-self is created.
The next-hop-self Command
Because of certain situations with the next hop as we saw in the previous example, a command called next-hop-self is created. The syntax is:
neighbor {ip-address|peer-group-name} next-hop-self
The next-hop-self command allows us to force BGP to use a specified IP address as the next hop rather than letting the protocol choose the next hop.
In the previous example, the following configuration solves our problem:
RTC#
router bgp 300 neighbor 170.10.20.1 remote-as 100
neighbor 170.10.20.1 next-hop-self
RTC advertises 180.20.0.0 with a next hop = 170.10.20.2 BGP Backdoor
Consider the above diagram, RTA and RTC are running eBGP, and RTB and RTC are running eBGP. RTA and RTB are running some kind of IGP (RIP, IGRP, and so on). By definition, eBGP updates have a distance of 20 which is lower than the IGP distances. Default distance is 120 for RIP, 100 for IGRP, 90 for EIGRP, and 110 for OSPF.
RTA will receive updates about 160.10.0.0 via two routing protocols: eBGP with a distance of 20 and IGP with a distance higher than 20.
By default, BGP has the following distances, but that could be changed by the distance command:
distance bgp external-distance internal-distance local-distance
external-distance:20
internal-distance:200
local-distance:200
RTA will pick eBGP via RTC because of the lower distance.
If we want RTA to learn about 160.10.0.0 via RTB (IGP), then we have two options: - Change eBGP's external distance or IGP's distance, which is not recommended.
- Use BGP backdoor.
BGP backdoor makes the IGP route the preferred route.
Use the following network address backdoor command.
The configured network is the network that we would like to reach via IGP. For BGP this network will be treated as a locally assigned network except it will not be advertised in BGP updates.
RTA#
router eigrp 10
network 160.10.0.0
router bgp 100
neighbor 2.2.2.1 remote-as 300
network 160.10.0.0 backdoor
Network 160.10.0.0 is treated as a local entry, but is not advertised as a normal network entry.
RTA learns 160.10.0.0 from RTB via EIGRP with distance 90, and also learns it from RTC via eBGP with distance 20. Normally eBGP is preferred, but because of the backdoor command EIGRP is preferred. Synchronization 
Before we discuss synchronization let us look at the following scenario. RTC in AS300 is sending updates about 170.10.0.0. RTA and RTB are running iBGP, so RTB will get the update and will be able to reach 170.10.0.0 via next hop 2.2.2.1 (remember that the next hop is carried via iBGP). In order to reach the next hop, RTB will have to send the traffic to RTE.
Assume that RTA has not redistributed network 170.10.0.0 into IGP, so at this point RTE has no idea that 170.10.0.0 even exists.
If RTB starts advertising to AS400 that he can reach 170.10.0.0 then traffic coming from RTD to RTB with destination 170.10.0.0 will flow in and get dropped at RTE.
Synchronization states: If your autonomous system is passing traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS have learned about the route via IGP. BGP will wait until IGP has propagated the route within the AS and then will advertise it to external peers. This is called synchronization.
In the above example, RTB will wait to hear about 170.10.0.0 via IGP before it starts sending the update to RTD. We can fool RTB into thinking that IGP has propagated the information by adding a static route in RTB pointing to 170.10.0.0. Care should be taken to make sure that other routers can reach 170.10.0.0 otherwise we will have a problem reaching that network. Disabling Synchronization In some cases you do not need synchronization. If you will not be passing traffic from a different autonomous system through your AS, or if all routers in your AS will be running BGP, you can disable synchronization. Disabling this feature can allow you to carry fewer routes in your IGP and allow BGP to converge more quickly.
Disabling synchronization is not automatic, if you have all your routers in the AS running BGP and you are not running any IGP, the router has no way of knowing that, and your router will be waiting forever for an IGP update about a certain route before sending it to external peers. You have to disable synchronization manually in this case for routing to work correctly:
router bgp 100
no synchronization
(Make sure you do a clear ip bgp address to reset the session.)
RTB#
router bgp 100
network 150.10.0.0
neighbor 1.1.1.2 remote-as 400
neighbor 3.3.3.3 remote-as 100
no synchronization
!-- RTB puts 170.10.0.0 in its IP routing table and advertises it to
RTD#
router bgp 400
neighbor 1.1.1.1 remote-as 100
network 175.10.0.0
RTA#
router bgp 100
network 150.10.0.0
neighbor 3.3.3.4 remote-as 100 Weight Attribute 
The weight attribute is a Cisco defined attribute. The weight is used for a best path selection process. The weight is assigned locally to the router. It is a value that only makes sense to the specific router and which is not propagated or carried through any of the route updates. A weight can be a number from 0 to 65535. Paths that the router originates have a weight of 32768 by default and other paths have a weight of zero.
Routes with a higher weight are preferred when multiple routes exist to the same destination. Let us study the above example. RTA has learned about network 175.10.0.0 from AS4 and will propagate the update to RTC. RTB has also learned about network 175.10.0.0 from AS4 and will propagate it to RTC. RTC has now two ways for reaching 175.10.0.0 and has to decide which way to go. If on RTC we can set the weight of the updates coming from RTA to be higher than the weight of updates coming from RTB, then we will force RTC to use RTA as a next hop to reach 175.10.0.0. This is achieved by using multiple methods: - Using the neighbor command:
neighbor {ip-address|peer-group} weight weight
- Using AS_PATH access lists:
ip as-path access-list access-list-number {permit|deny} as-regular-expression neighbor ip-address filter-list access-list-number weight weight
- Using route maps.
RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 weight 200
!-- Route to 175.10.0.0 from RTA has 200 weight
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 weight 100
!-- Route to 175.10.0.0 from RTB will have 100 weight
Routes with higher weight are preferred when multiple routes exist to the same destination. RTA is preferred as the next hop.
The same outcome can be achieved using IP AS_PATH and filter lists.
RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 filter-list 5 weight 200
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 filter-list 6 weight 100
...
ip as-path access-list 5 permit ^100$
!-- This only permits path 100
ip as-path access-list 6 permit ^200$
...
The same outcome as above can be achieved by using route maps.
RTC#
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-map setweightin in
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 route-map setweightin in
...
ip as-path access-list 5 permit ^100$
...
route-map setweightin permit 10
match as-path 5
set weight 200
!-- Anything that applies to access-list 5, such as packets from AS100, have weight 200
route-map setweightin permit 20
set weight 100
!-- Anything else would have weight 100 Local Preference Attribute 
Local preference is an indication to the AS about which path is preferred to exit the AS in order to reach a certain network. A path with a higher local preference is more preferred. The default value for local preference is 100.
Unlike the weight attribute which is only relevant to the local router, local preference is an attribute that is exchanged among routers in the same AS.
Local preference is set via the bgp default local-preference value command or with route maps as will be demonstrated in the following example:
The bgp default local-preference command will set the local preference on the updates out of the router going to peers in the same AS. In the above diagram, AS256 is receiving updates about 170.10.0.0 from two different sides of the organization. Local preference will help us determine which way to exit AS256 in order to reach that network. Let us assume that RTD is the preferred exit point. The following configuration will set the local preference for updates coming from AS300 to 200 and those coming from AS100 to 150.
RTC#
router bgp 256
neighbor 1.1.1.1 remote-as 100
neighbor 128.213.11.2 remote-as 256
bgp default local-preference 150
RTD#
router bgp 256
neighbor 3.3.3.4 remote-as 300
neighbor 128.213.11.1 remote-as 256
bgp default local-preference 200
In the above configuration RTC will set the local preference of all updates to 150. The same RTD will set the local preference of all updates to 200. Since local preference is exchanged within AS256, both RTC and RTD will realize that network 170.10.0.0 has a higher local preference when coming from AS300 rather than when coming from AS100. All traffic in AS256 addressed to that network will be sent to RTD as an exit point.
More flexibility is provided by using route maps. In the above example, all updates received by RTD will be tagged with local preference 200 when they reach RTD. This means that updates coming from AS34 will also be tagged with the local preference of 200. This might not be needed. This is why we can use route maps to specify what specific updates need to be tagged with a specific local preference as shown below:
RTD#
router bgp 256
neighbor 3.3.3.4 remote-as 300
neighbor 3.3.3.4 route-map setlocalin in
neighbor 128.213.11.1 remote-as 256
....
ip as-path access-list 7 permit ^300$
...
route-map setlocalin permit 10
match as-path 7
set local-preference 200
route-map setlocalin permit 20
set local-preference 150
With this configuration, any update coming from AS300 will be set with a local preference of 200. Any other updates such as those coming from AS34 will be set with a value of 150. Metric Attribute 
The metric attribute which is also called MULTI_EXIT_DISCRIMINATOR, MED (BGP4) or INTER_AS (BGP3) is a hint to external neighbors about the preferred path into an AS. This is a dynamic way to influence another AS on which way to choose in order to reach a certain route given that we have multiple entry points into that AS. A lower value of a metric is more preferred.
Unlike local preference, metric is exchanged between ASs. A metric is carried into an AS but does not leave the AS. When an update enters the AS with a certain metric, that metric is used for decision making inside the AS. When the same update is passed on to a third AS, that metric will be set back to 0 as shown in the above diagram. The Metric default value is 0.
Unless otherwise specified, a router will compare metrics for paths from neighbors in the same AS. In order for the router to compare metrics from neighbors coming from different ASs the special configuration command bgp always-compare-med should be configured on the router.
Note: There are two BGP configuration commands that can influence the Multi Exit Discriminator (MED)-based path selection, the bgp deterministic-med and the bgp always-compare-med commands. Enabling the bgp deterministic-med command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system (AS). Enabling the bgp always-compare-med command ensures the comparison of the MED for paths from neighbors in different autonomous systems. The bgp always-compare-med command is useful when multiple service providers or enterprises agree on a uniform policy for setting MED. Refer to How the bgp deterministic-med Command Differs from the bgp always-compare-med Command to understand how BGP path selection is influenced by these commands.
In the above diagram, AS100 is getting information about network 180.10.0.0 via three different routers: RTC, RTD and RTB. RTC and RTD are in AS300 and RTB is in AS400.
Assume that we have set the metric coming from RTC to 120, the metric coming from RTD to 200 and the metric coming from RTB to 50. Given that by default a router compares metrics coming from neighbors in the same AS, RTA can only compare the metric coming from RTC to the metric coming from RTD and will pick RTC as the best next hop because 120 is less than 200. When RTA gets an update from RTB with metric 50, he can not compare it to 120 because RTC and RTB are in different ASs (RTA has to choose based on some other attributes).
In order to force RTA to compare the metrics we have to add bgp always-compare-med to RTA. This is illustrated in the configs below:
RTA#
router bgp 100
neighbor 2.2.2.1 remote-as 300
neighbor 3.3.3.3 remote-as 300
neighbor 4.4.4.3 remote-as 400
....
RTC#
router bgp 300
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map setmetricout out
neighbor 1.1.1.2 remote-as 300
route-map setmetricout permit 10
set metric 120
RTD#
router bgp 300
neighbor 3.3.3.2 remote-as 100
neighbor 3.3.3.2 route-map setmetricout out
neighbor 1.1.1.1 remote-as 300
route-map setmetricout permit 10
set metric 200
RTB#
router bgp 400
neighbor 4.4.4.4 remote-as 100
neighbor 4.4.4.4 route-map setmetricout out
route-map setmetricout permit 10
set metric 50
With the above configs, RTA will pick RTC as next hop, considering all other attributes are the same. In order to have RTB included in the metric comparison, we have to configure RTA as follows:
RTA#
router bgp 100
neighbor 2.2.21 remote-as 300
neighbor 3.3.3.3 remote-as 300
neighbor 4.4.4.3 remote-as 400
bgp always-compare-med
In this case RTA will pick RTB as the best next hop in order to reach network 180.10.0.0.
Metric can also be set while redistributing routes into BGP using the default-metric number command.
Assume in the above example that RTB is injecting a network via static into AS100 then the following configs:
RTB#
router bgp 400
redistribute static
default-metric 50
ip route 180.10.0.0 255.255.0.0 null 0
!--- Causes RTB to send out 180.10.0.0 with a metric of 50 Community Attribute The community attribute is a transitive, optional attribute in the range 0 to 4,294,967,200. The community attribute is a way to group destinations in a certain community and apply routing decisions (accept, prefer, redistribute, etc.) according to those communities.
We can use route maps to set the community attributes. The route map set command has the following syntax:
set community community-number [additive]
A few predefined well known communities (community-number) are: - no-export (Do not advertise to EBGP peers; keep this route within an AS)
- no-advertise (Do not advertise this route to any peer, internal or external)
- internet (Advertise this route to the internet community, any router belongs to it)
- local-AS (Use in confederation scenarios to prevent sending packets outside the local AS).
An example of route maps where community is set is:
route-map communitymap
match ip address 1
set community no-advertise
or
route-map setcommunity
match as-path 1
set community 200 additive
If the additive keyword is not set, 200 replaces any old community that already exits; if we use the keyword additive then the 200 is added to the community. Even if we set the community attribute, this attribute is not sent to neighbors by default. In order to send the attribute to our neighbor we have to use the following:
neighbor {ip-address|peer-group-name} send-community
Here's an example:
RTA#
router bgp 100
neighbor 3.3.3.3 remote-as 300
neighbor 3.3.3.3 send-community
neighbor 3.3.3.3 route-map setcommunity out
In Cisco IOS Software release 12.0 and later, you can configure communities in three different formats: decimal, hexadecimal, and AA:NN. By default, IOS uses the older decimal format. To configure and display in AA:NN, where the first part is the AS number and the second part is a 2-byte number, use the ip bgp-community new-format global configuration command.
Here's an example.
Without the ip bgp-community new-format command in global configuration, the show ip bgp 6.0.0.0 command below displays the community attribute value in decimal format (6553620).
Router# show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/8, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
1
10.10.10.1 from 10.10.10.1 (200.200.200.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 6553620
Let us configure the ip bgp-community new-format command globally on this router.
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# ip bgp-community new-format
Router(config)# exit
With the ip bgp-community new-format global configuration command, the community value is displayed in AA:NN format (100:20) in the output of the show ip bgp 6.0.0.0 command below.
Router# show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/8, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
1
10.10.10.1 from 10.10.10.1 (200.200.200.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 100:20 BGP Case Studies 3 BGP Filtering Sending and receiving BGP updates can be controlled by using a number of different filtering methods. BGP updates can be filtered based on route information, on path information or on communities. All methods will achieve the same results, choosing one over the other depends on the specific network configuration. Route Filtering 
In order to restrict the routing information that the router learns or advertises, you can filter BGP based on routing updates to or from a particular neighbor. In order to achieve this, an access-list is defined and applied to the updates to or from a neighbor. Use the following command in the router configuration mode:
neighbor {ip-address|peer-group-name} distribute-list access-list-number {in|out}
In the following example, RTB is originating network 160.10.0.0 and sending it to RTC. If RTC wanted to stop those updates from propagating to AS100, we would have to apply an access-list to filter those updates and apply it when talking to RTA:
RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 distribute-list 1 out
access-list 1 deny 160.10.0.0 0.0.255.255
access-list 1 permit 0.0.0.0 255.255.255.255
!-- Filter out all routing updates about 160.10.x.x
Using access lists is a bit tricky when you are dealing with supernets that might cause some conflicts.
Assume in the above example that RTB has different subnets of 160.10.X.X and our goal is to filter updates and advertise only 160.0.0.0/8 (this notation means that we are using 8 bits of subnet mask starting from the far left of the IP address; this is equivalent to 160.0.0.0 255.0.0.0).
The command access-list 1 permit 160.0.0.0 0.255.255.255 permits 160.0.0.0/8,160.0.0.0/9 and so on. In order to restrict the update to only 160.0.0.0/8 we have to use an extended access list of the following format: access-list 101 permit ip 160.0.0.0 0.255.255.255 255.0.0.0 0.0.0.0. This list permits 160.0.0.0/8 only.
Refer to How to Block One or More Networks From a BGP Peer for sample configurations on how to filter networks from BGP peers using distribute-list with standard and extended ACLs, as well as prefix list filtering.
Another type of filtering is path filtering, which is described in the next section. Path Filtering  You can specify an access list on both incoming and outgoing updates based on the BGP autonomous system paths information. In the above figure we can block updates about 160.10.0.0 from going to AS100 by defining an access list on RTC that prevents any updates that have originated from AS200 from being sent to AS100. To do this use the following statements.
ip as-path access-list access-list-number {permit|deny} as-regular-expression
neighbor {ip-address|peer-group-name} filter-list access-list-number {in|out}
The following example stops RTC from sending RTA updates about 160.10.0.0
RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 filter-list 1 out
!-- The 1 is the access list number below
ip as-path access-list 1 deny ^200$
ip as-path access-list 1 permit .*
In the above example, access-list 1 states: deny any updates with path information that start with 200 (^) and end with 200 ($). The ^200$ is called a regular expression, with ^ meaning "starts with" and $ meaning "ends with". Since RTB sends updates about 160.10.0.0 with path information startin
We hope you found this Cisco certification article helpful. We pride ourselves on not only providing top notch Cisco CCNP exam information, but also providing you with the real world Cisco CCNP skills to advance in your networking career.
|
Lab Certification Kits
