talked about how to modify incoming traffic. What about outbound traffic? Generally, for an enterprise the outbound traffic will be more than inbound. Situation may arise that one of your multihomed link starts clogging up and you will want to shift some traffic to the other link.
Remember, that for inbound traffic you might not have full control over the path which it should take (you can merely influence some amount of traffic). But for outbound it is really upto us as to how we want to shape our traffic. Again, it is because of the flexibility that BGP provides. Using one of its attribute known as local preference you can define which BGP session should be preferred for a particular route. Another way is to use AS path prepending. As you can see, AS path prepending is a very versatile technique as it allows you to shape both incoming as well as outgoing traffic. Although it is recommended that local preference attribute be tinkered since it is one of the first criterion in the BGP path selection algorithm. Continuing with the topology I used in the this
post, the only difference being that our router will be RTR5 this time.
 |
| Route advertisments by all routers to Rtr5 |
From the previous post it is clear that for different subnets different links will be preferred. What if I want all traffic for AS 100 to go via RTR2 (ASN 200)? And we will extend this concept to the global routing table which can have as many as 400,000 active routes.
If I can somehow tell my router that any route having AS 100 in its AS path and its next hop as AS 300 should be preferred than any other BGP route?
There are commands exactly for this purpose.
Configuration in a juniper router:
Assuming that you have configured all interface addresses and the bgp announcements are as shown in the above diagram. The additional commands you need to add, then are:
set policy-options policy-statement OUTBOUND-MODIFIER from as-path inbound-preference
set policy-options policy-statement OUTBOUND-MODIFER then local-preference 250
set policy-options policy-statement OUTBOUND-MODIFIER then accept
set policy-options as-path inbound-preference .*100.*
set protocols bgp group test neighbor 40.40.40.1/30 import OUTBOUND-MODIFIER
the first three statements define a routing policy OUTBOUND-MODIFIER (which will be applied on all the routes being received from neighbor 40.40.40.1). It will apply all rules defined in the as path policy inbound-preference .
All the routes having this property will have its local preference as 250.
The as-path policy inbound-preference basically has what is known as a regular expression. Readers from a linux background will understand this. A regular expression aka regex is a set of semantics which allows you to extract various pieces of information from a string.
This particular as path policy will search for AS path attribute in the bgp routes being received and select all having 200 *anywhere* in its AS Path. So an as path: [300 500 400 200 100], [200 400 300 100], [100] all will be selected. Exact documentation can be found
here.
Traffic shaping and failover
How does traffic shaping happen? Well in our scenario, even though all our routes received on 40.40.40.2 interface will still be preferred (even though ASN 100 is announcing those as prepended routes) because we have set the local preference as 250 while others have 100.
To make the example clearer, let us go step by step through the BGP path selection algorithm.
1. For each destination 100.100.100.0, 150.150.150.0 and 200.200.200.0 it has 3 routes each. All the next hops for these routes are reachable, therefore we have a tie.
2. Since all our BGP routes all have a route preference value of 170 (this is different than local preference which is a BGP attribute)
3. Through our policy we have modified the local preference value of neighbor 40.40.40.2 stating that any routes received from this neighbor and having ASN 100 should have its local preference value as 250. Since it is higher than all other routes received (default is 100), all these routes are installed in the routing table.
Therefore we have been able to engineer our traffic to go via the 40.40.40.1 interface, irrespective of the advertisement received.
Since RTR5 have 3 routes per subnet, if any link goes down the next best path is chosen and put in the forwarding table. Clearly we have outbound traffic redundancy as well.
The technique described above is a recommended and well known practice. You can also increase the local preference using route filters or prefix lists as well if you know an optimum route for that particular set of routes.
 |
| show route without local preference modification |
 |
| show route after local preference modificaiton |
There is another technique which I will discuss for the sake of completeness. This technique is used to make a particular route look undesirable by increasing its AS Path length. By applying an inbound routing policy and prepending our own ASN we cheat the bgp path selection algorithm by bloating the as path length.
Configuration in a juniper router:
set policy-options policy-statement OUTBOUND-MODIFIER from as-path inbound-preference
set policy-options policy-statement OUTBOUND-MODIFER then as-path-prepend 500
set policy-options policy-statement OUTBOUND-MODIFIER then accept
set protocols bgp group test neighbor 40.40.40.1/30 import OUTBOUND-MODIFIER
Outbound traffic sharing in a full routing table
In the above scenario we knew beforehand that we have to shape traffic for a particular subnet. In real world you may simply need to shift some traffic to load share your multihomed links. In such a case figure out with whom your ISPs are peering with. If you have no idea then pick some random Tier 1 ISPs. Being Tier 1 they will have a bulk of internet routes. Select all those routes using AS path policy and prefer them over the link which does not have much traffic.
For example, suppose I have TW-telecome as my ISP. Now if i want to shift traffic to my alternate link which is with Data foundry then I will probably search for some Tier 1 isps like Level 3 or TATA. By the way, to create a group of such AS policies we use what is known as AS path group.
Configuration
set policy-options policy-statement OUTBOUND-MODIFIER from as-path-group inbound-preference
set policy-options policy-statement OUTBOUND-MODIFER then local-preference 250
set policy-options policy-statement OUTBOUND-MODIFIER then accept
set policy-options as-path-group inbound-preference .*100.*
set policy-options as-path-group inbound-preference .*2000.*
set policy-options as-path-group inbound-preference .*3000.*
set protocols bgp group test neighbor 40.40.40.1/30 import OUTBOUND-MODIFIER
Here we have created a group of all such regular expressions and applied it to the neighbor. All routes having either 100 or 2000 or 3000 will have a higer local preference and will therefore be preferred via the neighbor to which this policy is applied.
Remember, we announce prepended subnets to shape incoming traffic for our own subnets, while we change local preference attribute value to favour one particular neighbor as the best hop, thus modifying outbound traffic behaviour.
As you can see BGP is a very flexible protocol and allows you to do a gamut of tweaking to suit your needs.
Conclusion
This fully covers the two basic tenets of network architecture- to have redundancy and flexibility of engineering traffic. What we have not discussed is what if the router itself goes down? My next post will cover this basic aspect and will talk more about how to build a robust and resilient network. Also some basic DDoS techniques using BGP as well as the basic principles involved while mitigating traffic using a third party vendor like Prolexic or Verisign.
Important links:
1.
Setting up basic BGP session in Juniper
2.
Setting policies in BGP in Juniper
3.
Incoming traffic shaping
4.
Juniper doc on Local preference
5.
Juniper doc on AS Path regular expressions
6.
AS path group
