In some previous post we saw how we can manipulate BGP paths using attributes for outgoing traffic. Today we will see how to use another BGP attribute, but this time for manipulating inbound traffic. First I would like to ask you to have a look into the topology file and also to check the config files (if you have a basic idea about how BGP is configured that you don’t need the config files).
From the table above:
we see that the attributes needed for inbound traffic manipulation are AS-Path and MED. Today we will use AS-Path for traffic manipulation (MED sometime in closer future).
Beside using BGP attributes, there are other ways to manipulate traffic and paths in a BGP environment, but usually this need that the provider will support your actions. As an example to understand, you can do route tagging in your network (for example in MPLS on your CE) and your ISP will apply rules based on different tags (on PE side), but this is out of the scope of this tutorial and will be discussed maybe in another tutorial.
For our test environment, that you see in the topology, we advertise everything into BGP domain, exactly as draw, so there will be no problems of reachability.
Please see the tutorial and explanations below:
Before going further on, please download the topology and the initial configuration files and have a close look into them (mostly into topology drawing). Also, this tutorial is addressed to people that know what is BGP and how to do a basic configuration for peering establishing.
For modifying the BGP automate selection of the best path, we have to modify some of BGP attributes from the table below:
Since today we will deal with outgoing traffic, we are interested in Weight and Local preference attributes, which we have to modify to reach our desired result. For the incoming traffic I will make another tutorial in some days.
So, let assume that we have some networks in the LAN after R1 in the topology and we advertise this into the BGP network. On R3, we will learn this prefixes by the way of R1 as it is the shortest path. But in our case the shortest path does not mean the fastest one. As you can see the connection between R1 and R3 is a Serial connection (let’s assume E1). The connections between R1 – R2 and R2 – R3 are FastEthernet connections. Even if this a longer path, for us would be better to reach the LAN subnets in behind R1 through R2, as this is more faster (bigger bandwidth and lower latency). We will force the outgoing traffic through R2 by modifying the Weight and Local preference attribute.
Please see the tutorial below: