Creating a BGP Neighbor and twicking its attributes
Certain requirement needs to be factored in before we can establish a complete BGP session with our ISP/enterprise client. This includes manual configuration of the BGP neighbor, the reachability using TCP 179, session requirement on the neighbor (1 session/neighbor) except for loopback and by using the neighbor command.
BGP will use four (4) types of packets:
1. OPEN - is sent when you manually configure a neighbor. This packet is sent one time only.
2. UPDATE - is everything that BGP sent. ie. routing table
3. KEEPALIVE - is sent by BGP to check if the neighbor is still present.
4. NOTIFICATION - is a BGP indication that there is a problem on the neighbor relationship.
Below states are the transition of BGP neighbor relationship:
1. IDLE - state when a neighbor is configured but haven't established yet the relationship.
2. ACTIVE - state when BGP is trying to start the communicating but haven't receive the confirmation from the neighbor.
3. OPENSENT - state when the BGP neighbor confirms the communication.
4. OPENCONFIRM - state when the BGP waits for keepalives from the peer for the confirmation of a complete neighbor relationship.
ESTABLISHED - state when the BGP has the complete neighbor relationship.
Note: Configured authentication is happening during the OPENSENT and OPENCONFIRM state.
Basing from the diagram, our location is in AS 500 and our objective is to establish neighbor relationship to ISP1 and ISP2.
ISP1, ISP2 and R1's IP address has been defined in its interfaces.
Now we start the configuration of the BGP on R1 by going to the global configuration mode and issue router bgp followed by the AS number <500>. Then we will tell the BGP who will be the neighbor and its corresponding AS number.
Now the BGP went from the IDLE to ACTIVE state and vice versa since RI has BGP has started communicating already but haven't receive anything from its defined neighbor because BGP hasn't started yet.
To verify the state, on R1 issue a show ip bgp summary to show the state. This command will also show among others the AS number, UP/DOWN status of the remote BGP.
The state is in idle because R1 is telling you that there is no route for that particular neighbor. In order for R1 to know the route, we need to define the BGP process on ISP1 and ISP2 and tell them that R1 will be their neighbor.
The step is the same but you should be on the ISP1 and ISP2's perspective.
Now let's verify the state of the BGP on R1 after creating the BGP process and neighbor on ISP1 and ISP2.
This shows that we have established the BGP relationship with the ISP neighbor. Having the basic setup, the value of 0 on the state is expected.
Now Let's do a debug ip bgp all on R1 to verify what is happening behind the scene upon establishing BGP neighbor relationship on ISP1. Assuming your configuration is correct, you should also see this state change on your ISP2.
Here you can see the states that the BGP process went through and you should see Established as the final state for a successful BGP neighbor relationship.
ADVERTISING THE ROUTES
Now going to R1 perspective in regards to BGP process receiving routes from ISP1/ISP2; R1 will get the entire internet routing table coming from both of the ISP. Upon receiving the internet route, It will initially put it in its topology table then it will choose the best routes before finally putting it in its routing table.
In order to see the topology table, you can issue show ip bgp on the command-line. Right now, we don't have anything yet on the topology table because we haven't advertise any network on the BGP. To do this, go to the router BGP then advertise the internal network by issuing network <network> mask <subnet mask>
Notice that you will see an output now when you check the BGP topology.
On R1, BGP topology now has an entry for the network being advertised by ISP1 and ISP2 as well as the locally advertised network. They are reachable via the next hop. Since they are the only routes going to ISP1/ISP2, it will be chosen to be the best path and it will be shown on the routing table of R1.
Note: In a real-world scenario, doing a show ip bgp will output a relative large amount of information.
Basing from the output of BGP topology, notice that the routes has *>, which means that it is the best and valid route to go to that network. Put in mind that there will be a scenario wherein you will have a topology containing only the valid routes. It could mean that the BGP topology table has an alternative route to go to a particular network and is implying that it is not the best route to use. We will deal with that on a separate topic.
How does BGP select the best route?
Let's assume that the ISP1 and ISP2 is connected to another Autonomous System and both of the ISP has has the route for it. How will the BGP topology look in this case?
Note: For this scenario, i created a loopback 0 and loopback 1 inside ISP1.
I created a loopback to simulated 155.1.1.0/24 and 155.2.2.0/24 network and have it advertised on BGP using network command.
Since BGP is now advertising the routes learned from ISP1, The BGP topology of R1 should have an output below.
The best and valid route going to 155.1.1.0/24 and 155.2.2.0/24 is via the next hop 10.10.1.1. So by default R1 will put this route in its routing table.
Now i created the same loopback having the same network and have it advertised in ISP2's BGP.Then output on the BGP topology on R1 now looks like this.
The BGP now has 2 routes available for 155.1.1.0/24 and 155.2.2.0/24 via next hop 10.10.1.5 tagged as a valid and 10.10.1.1 tagged as valid and best.
By default, BGP chooses the best path based on the metric or what cisco calls the path-selection process. This selection process has 10 criteria which are:
1. Largest weight
2. Highest local preference
3. Locally originated
4. Shortest AS path
5. Lowest origin type (i < e < ?)
6. Lowest MED (metric)
7. eBGP over iBGP
8. Lowest IGP metric to neighbor
9. Older route
10. Lowest router ID
The selection process being done by the BGP is from top - down until it reaches a criteria wherein the BGP decides to choose that path based on that selected criteria.
In summary;
Criteria 1 and 2 can be define by administrator and will be applied on the local device only.
Criteria 3 - the route is located locally
Criteria 4 - number of AS path it takes (this is by default the strongest attribute how BGP decides on the route selection)
Criteria 5 - internal < external < unknown
Criteria 6 - metric calculation
Criteria 7 - external over internal
Criteria 8 - also a metric calculation
Criteria 9 - first learned route
Criteria 10 - lowest router ID
We'll have a separate topic on this but for now the reason why BGP chooses that route is simply because of criteria 9: Older path. This means that ISP1 is already advertising that network on the BGP before ISP2 start to advertised the same network on the BGP.
Assigning weight on the BGP process
It is important to keep in mind that in order to implement a change of weight on a BGP route, you have to use a cisco router on both ends because this criteria is cisco-proprietary. Weight is implemented locally on the router you are configuring. It will not influence the weight of the neighbor router.
Lets assign a weight on the neighbor 10.10.1.5.
Currently the BGP selected the next hop 10.10.1.1 as best and valid route to the network 155.1.1.0/24 and 155.2.2.0/24. Now, We would like to incorporate a weight on the 10.10.1.5 to be selected as a best and valid route.
To do this, go BGP process of R1 then specify the weight of the neighbor 10.10.1.5 to be greater that 0 which is the default.
Verifying the BGP route.
Note: You may have to clear the session beforehand by issuing clear ip bgp 10.10.1.5. Please do this with caution and consult with service provider if in real-world scenario.
10.10.1.5 is now selected by the BGP as the best and valid hop to get to network 155.1.1.0/24 and 155.2.2.0/24.
Redistributing route
Normally, the amount of routes you can see in BGP process is relatively huge due to the fact that it is based from the entire internet. Suppose we create a scenario wherein ISP1 and ISP2 has multiple routes going to other network.
ISP1:
200.10.0.0/16
200.20.0.0/16
200.40.0.0/16
ISP2:
22.10.46.0/24
22.10.47.0/24
22.10.48.0/24
Imagine in a real-world wherein the routes being generated from the ISP will be atleast a 1000 times greater that our example. How will the ISP efficiently advertise the routes without putting it on the BGP process one by one and without using the network command? With this we can use the redistribution method wherein all of routes learned will be automatically put in the BGP topology.
On our example I created a loopback interface for our dummy network and assigned the network stated above. We will advertise this on the BGP process via redistribution.
On the ISP1, go to the router BGP process and enable the redistribution. Also do this on the ISP2.
Verify if it is being redistributed on the BPG topology table.
Now you have successfully redistributed the routes to your BGP process.
Filtering the route using ACL
Filtering is one of the method to allow only the required routes you want to pass through on your router. It basically hides the routes that you doesn't want to advertised. This is a necessary option to perform especially if for example you don't want to allow your private network for the BGP routing process.
In our example, ISP1 and ISP2 has a route network on a loopback representing the outside network and our objective is to suppress the internal network of ISP1 100.10.0.0/16 from being advertised and allow the 200.10.0.0/16, 200.20.0.0/16, 200.40.0.0/16 and 10.10.1.0/30 on the AS 1200.
To do this, we will be defining a filter on ISP1 and since we are specifying the IP address and the subnet mask of the outside network, we can use an Access-list.
The command distribute-list will perform the the access-list 1 being defined by permitting the specified network to be advertised out the bgp process.
To verify on the ISP1. Notice that BGP topology for100.10.0.0/16 has already been filtered out.
Therefore R1 should not received any BGP advertisement of 100.10.0.0/16 topology coming from ISP1.
Note: You can issue issue a clear ip bgp * to reset the update the BGP topology. Do this with caution if you are in a production environment.
Filtering route using route-map
Route-maps are the most common approach in BGP attribute filtering. It is very flexible simply because it can modify the entire attributes of a BGP selection process. The behavior of Route-map if used, will initially look for a matched network via match keyword and after matching, it will tend to do necessary action using the keyword set. The set action then will allow the administrator to modify any BGP attributes that he wants.
Because of its flexibility, we can even change the origin of a path. Like in the example below wherein on our ISP2, let's assume that we are advertising the following network:
INTERNAL:
12.10.46.0/24
LEARNED ROUTES:
22.10.46.0/24
22.10.47.0/24
22.10.48.0/24
155.1.1.0/24
155.2.2.0/24
Going back to redistributing routes, we issued the redistribute connected command in order to advertise all the BGP topology on ISP2. Doing this, by default, will put the origin in the unknown state as shown:
Now with this, we would like to create a route-map that will advertise the internal network as internal (i) since that BGP route is local to the ISP2. Our objective is to implement a route-map filter that will allow the advertisement of the internal network 12.10.46.0/24 on the BGP routing topology and should reflect the network created local on ISP2. We will also should not allow the advertisement of the learned BGP routes as stated above to the client R1.
To make this work, let's create an access-list to allow the internal network (12.10.46.0/24) only.
NOTE: at the bottom of every ACL is an implicit deny all.
We then proceed on the creation of route-map filter.
Origin can be set either local IGP or unknown heritage. Local IGP reflects the value i and on other hand, the unknown heritage signifies that the BGP route came from a different AS thus having the value ?.
You have created the route-map and is now ready for implementation on ISP2. You can apply it on the router BGP process using the following command:
The command will check for the route-map filter before it will distribute all learned routes to the BGP topology. Since we allow only the internal network, the filter should only permit the internal network for advertisement on the BGP topology and with the origin IGP (i).
We can verify on the BGP topology if the route-map worked using show ip bgp on ISP2 and R1.
Now you have successfully created a route-map filter for specifying origin of a route in BGP.
Doing a summarization using aggregate address
In a vast network we are in right now, like for instance the internet, we will always encounter a multiple network entry haven't been summarized yet. This scenario by default will tend to eat up the amount of memory of your router and thus making it vulnerable to system/memory failure due to the tremendous amount of data that it needs to process on its routing table.
BGP has the ability to aggregate the routes into a simpler form. This functionality can therefore address the scenario stated above.
In order to accomplish this, I created a multiple dummy network on R1 using the loopback. It also has an internal network 9.2.86.0/24. Our objective is to suppress by summarizing the network in red box into 90.2.0.0/16.
In order to do summarization, we need to go to the router bgp process then tell it to create an aggregate entry tobe summarized into 90.2.0.0/16.
The BGP process will then look for the possible match of the aggregate entry and will suppress it for summarization purpose.
Looking on the BGP topology of R1, you can see that there is an aggregate entry for the suppressed, s>. The BGP should advertise the 90.2.0.0/16 on its BGP topology table.
Go to the ISP1 and ISP2 BGP topology to verify if summarization took place.
You should now see the summarized network of 90.2.0.0/16 on ISP1 and ISP2 BGP topology table.
Manual Summary
Another way of aggregating network is by implementing a manual summary. In routing, always keep in mind that, routes should always be specific. BGP will try look on the exact match of the route before checking the summarize network. To explain further, let's use the scenario above as R1 is having a multiple entry of network under the 90.2.0.0/16.
Manual summarization in BGP process by default should not redistribute the learned BGP routes since we will be manually putting the network inside it.
Main requirement of manual summary is to create a static route entry for the 90.2.0.0/16 and forward it to nothing.
Then network 90.2.0.0/16 should be advertised in the router BGP process.
What's happening is, as i've mentioned, BGP will look first on the exact route match of the summarized network being advertised on the BGP topology and since ISP1 and ISP2 has the BGP topology table for the summarized network, it will know where to forward it. Routing the summary network to nothing will do no harm to the BGP perse.
R1 will route first the exact match of the routing coming from the summarized 90.2.0.0/16 and if it doesn't find the match, it will then put it to null 0.
You should now able to communicate to any network of the summarized network 90.2.0.0/16 coming from ISP1 and ISP2.
