BGP4 Case Studies/Tutorial Sam Halabi-cisco SystemsThe purpose of IntroductionThe Border Gateway Protocol (BGP), defined in RFC. On-line BGP Resources and Information Routing Recommendations · Connect’s FAQ on multihoming and BGP · BGP4 Case Studies/Tutorials by Sam Halabi. BGP4 Case Studies/Tutorial. Sam Halabi-cisco Systems. The purpose of this paper is to introduce the reader to the latest in BGP4 terminology and design issues.
|Published (Last):||1 January 2012|
|PDF File Size:||2.13 Mb|
|ePub File Size:||1.62 Mb|
|Price:||Free* [*Free Regsitration Required]|
It is targeted to the novice as well as the experienced user. For any clarification or comments please send to Copyright Cisco Systems Inc.
An autonomous system 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. Two BGP speaking routers form a TCP connection between one another peer routers and exchange messages to open and confirm the connection parameters.
BGP routers will exchange network reachability information, this information is mainly an indication of the studiess paths BGP AS numbers that a route should take in order to reach the destination network. This information will help 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.
From then on incremental updates are sent as the routing table changes. The version number will change whenever BGP updates the table due to some 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. It is necessary to ensure reachability for networks within an AS before sending the information to other external ASs. We start by defining the router process and define the AS number that the routers belong to: The command used to enable BGP on a router is: The next step in the configuration process is to define BGP neighbors.
The neighbor definition indicates which routers we are trying to talk to with BGP. The next section will introduce you to what is involved halaabi forming a valid peer connection.
The TCP connection is essential in order for the two peer routers to start exchanging routing updates. Two BGP speaking routers trying to become neighbors will first bring up the TCP connection between one another and then send open messages in order to exchange values such as the AS number, the BGP version they are running version 3 or 4the BGP router ID and the keepalive hold time, etc.
After these values are confirmed and sttudies the neighbor connection will be established. Any state other than established is an studirs that the two routers did not become neighbors and hence the BGP updates will not be exchanged.
The neighbor command used to establish a TCP connection is: It is 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 caee 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. A special case for loopback interfaces is discussed later.
To prevent negotiations and force the Studied version used to caze with a neighbor, perform the following task in router configuration mode: IBGP routers do not have to be directly connected, as long as there is some IGP running that hslabi the two neighbors to reach one another.
The following is an example of the information that the command sh ip bgp neighbors will show you, pay special attention to the BGP state. Anything other than state established indicates that the peers are not up. You should also note the BGP is version 4, the remote router ID highest IP address on that box 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 will increase the version and a version that keeps incrementing indicates that some route is flapping causing routes to keep getting updated. Normally the loopback interface is used to make sure that the IP address of the neighbor stays up and is independent of an interface that might be flaky. In the case of EBGP, most of the time the peer routers are directly connected and loopback does not apply.
If the IP address of a loopback interface is used in the neighbor command, some extra configuration needs to be done on the neighbor router. The command used to indicate a loopback interface is: In this case EBGP multihop is used to allow the neighbor connection to be established between two non directly connected external peers.
The following example gives a better illustration of EBGP multihop. RTA needs to indicate that it will be using ebgp-multihop. On the other hand, RTB is indicating a neighbor that is directly connected and that is why it does not need the ebgp-multihop command.
On-line BGP Resources and Information
Some IGP or static routing should also be configured in order to allow the non directly connected neighbors to reach one another. This is a workaround in order to achieve load balancing between two EBGP speakers over parallel serial lines.
In normal situations, BGP will pick one of the lines to send packets on and load balancing would not take place. By introducing loopback interfaces, the next hop for EBGP will be the loopback interface. Static routes it could be some IGP also are used to introduce two equal cost paths to reach the destination.
RTA will have two choices to reach next hop: In the BGP context, 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: 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 I define two instances of the route map, let us call it MYMAP, the first instance will have a sequence-number of 10, and the second will have a sequence number of When applying route map MYMAP to incoming or outgoing routes, the first set of conditions will be applied via instance If the first set of conditions is not met then we proceed to a higher instance of the route map.
The conditions that we talked about are defined by the 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, I could define a route map that checks outgoing updates and if there is a match for IP address then the metric for that update will be set to 5.
The above can be illustrated by the following commands: 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 we finish the list without a match then the route we are looking at will not be accepted nor forwarded.
One restriction on route maps is that when used for filtering BGP updates as we will see later rather than when redistributing between protocols, you can NOT filter on the inbound when using a match on the ip address. Filtering on the outbound is OK. The related commands for match are: If RTA wants to redistribute to RTB routes about with a metric of 2 and all other routes with a metric of 5 then we might use the following configuration: 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. Suppose in the above example we did not want AS to accept updates about 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: There are multiple ways to send network information using BGP.
I will go through these methods one by one. 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 BGP4 can handle subnetting and supernetting.
BGP4 Case Studies/Tutorial Index
A maximum of 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: Note that we need the static route to get the router to generate because the static route will put a matching entry in the routing table.
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. RTC router eigrp 10 network redistribute bgp default-metric router bgp neighbor remote-as network mask this will limit the networks originated by your AS to If you use redistribution instead you will have: This is misleading because you are not the source of but AS 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 redistribute bgp default-metric router bgp neighbor remote-as neighbor distribute-list 1 out redistribute eigrp 10 access-list 1 permit The access-list is used to control what networks are to be originated from AS 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 redistribute bgp default-metric router bgp neighbor remote-as redistribute static ip route null0 The null 0 interface means to disregard the packet. So if I get the packet and there is a more specific match than 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.
Again the difference is that the network command will add an extra advertisement for these same networks indicating that AS 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.
RTA will notice that the update has originated from its own AS and will ignore it. 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.
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.