According to the BGP best route decision, best route will be chosed base on the the the sequence attributes ( Weight, Local preference, AS-Path, ). But I want to know do that attributes control the flow of inbound Traffic or outbound traffic or both directions?
1. Local Preference is used to manipulate traffic going out of your Autonomous System. This attribute is only exchanged with IBGP peers and therefore has local significance to your Autonomous System.
2. The Weight attribute is also used to manipulate traffic going out of your Autonomous System but this attribute is local to the router on which it is configured and is not exchanged with any IBGP or EBGP peers.
3. A router uses the AS_PATH attribute in case of ties between the weight and local preference attributes and the route not being locally originated. When this attribute is used to select a particular route you are basically controlling traffic going out of your Autonomous System.
When you are multi homed to two different providers it is sometimes required to prefer one provider’s link for some incoming traffic. In such cases a normal practise is to manipulate the AS_PATH attribute thereby making one path seem more attractive than the other (shorter AS_PATH). So in such circumstances you are using AS_PATH to manipulate traffic coming into your AS.
4. Another attribute that is used to manipulate incoming traffic is called MED (Multi-Exit Discriminator). However, an EBGP peer receiving it will only share it with IBGP peers and will not forward it to another AS. This means that you can basically use this attribute for influencing traffic between two directly connected autonomous systems.
With point number 3 i was trying to convey the message that AS_PATH attribute can influence both traffic coming into and going out of your autonomous system. Lets consider two situations:
Situation 1:
You have two edge routers each talking EBGP to a different service provider and talking IBGP to each other. You are receiving full internet routes from both providers. In this situation each edge router will have to decide on which route to install (for each internet destination), one available via an EBGP peer and the other via an IBGP peer. Assuming Local Preference and Weights are left at default the decision will come down to AS_PATH attribute. The routers will choose the route with the shortest AS_PATH and this will influence traffic leaving outside your autonomous system.
Situation 2:
In this scenario we again have two edge routers speaking EBGP to two different providers and talking IBGP to eachother. The routers are configured to advertise the prefix assigned to your AS. Without any special configuration traffic destined to your AS will take the best route (shortest AS_PATH). So there is really no way of knowing how your inbound traffic flow will be. However, you might want to force all inbound traffic through one link and use the other as a backup. For this to work across two different providers you can manipulate the AS_PATH attribute in updates from one of your edge routers so that to the outside world it seems that this path is longer than the one through the other link.
MED is useful when you have two or more links to the same provider and you want to control how traffic coming in should behave. You advertise MED to your EBGP peers so your internal IBGP configuration is more or less independent of this attribute unless you are a provider and are receiving MED but in that case I do not see why you will not have IBGP configured.
Hope that makes things clearer.
BGP – Understanding Inbound Traffic Engineering
In this document I aim to explain the various options that you as a Network Operator can use to influence your inbound traffic flow via BGP. This topic is critical to understand for the CCNP ROUTE exam and introduces you to some good theory with regards to BGP policy enforcement.
Prerequisite knowledge
- Understanding of basic BGP operations
- Understanding of BGP neighbour types (iBGP/eBGP)
- Understanding of common BGP attributes (NEXT-HOP; ORIGIN; AS-PATH/SET; MED; LOCAL_PREFERENCE…etc)
- Understanding of the BGP Best-Path selection process
In order to show the various options that you have to try an manipulate how traffic enters your network I will be using the following topology.
In this scenario we will be controlling the attributes associated with our public subnet 169.254.0.0/16. This is because we influence our INBOUND traffic flows by tweaking our OUTBOUND NLRI (Network Layer Reachability Information)’s attributes. Some side notes to understand is that all internal connections to form the iBGP connection have already been completed and the eBGP neighbourships are formed via the physical link address as opposed to loopback interfaces. How the neighbours are formed will not affect your ability to influence inbound traffic flows.
Current Scenario
Before we can review about how to manipulate our traffic flows we first need to identify what the default routing is if the network is setup and both R3 and R4 are advertising our public subnet to the ISP.
Firstly, lets have a look at the BGP table on both R1 and R2 and perform a trace to a loopback on R3…
As you can see from the output, R1 is preferring the eBGP route from R3 over the iBGP route received from R2. Therefore when performing a trace, the traffic comes in directly via the link between R1 and R3.
Equally, if we look at R2 we should see that it is preferring the eBGP path over the iBGP path…
Now that we know the normal traffic patterns from the ISP (Use the nearest exit point – This is also known as hot potato routing), we can now try and manipulate this.
AS-PATH Prepending
One of the most common methods for influencing the path selection is to affect the AS-PATH attribute on our route as we advertise it OUTBOUND. Since this is the 4th tie breaker in the BGP best-path selection process it means that it’s effectiveness can be fairly strong in influencing the path. As a side note, it is also one of the few methods can be used where multihomed providers exist.
So how does it work? Essentially when we advertise our route out we will prepend our AS number multiple times on the route going out the least preferred path. Consider the following topology…
Now to implement this desired change. In order to do this we need to call a route-map that calls a prefix-list referencing the prefix we wish to change. Then from there we can set the as-path prepend and finally apply to the neighbour. Remember, after applying a routing policy change a route-refresh or clearing of the BGP neighbour is needed. Since the attributes are already the same on R4 we only need to make the change on R3.
Configuration:
R3#show run | section bgp|route-map|prefix-list
router bgp 64512
neighbor 192.0.2.1 route-map POLICY out
!
ip prefix-list AS-PATH-PL seq 5 permit 169.254.0.0/16
!
route-map POLICY permit 10
match ip address prefix-list AS-PATH-PL
set as-path prepend 64512 64512
route-map POLICY permit 20
Configuration:
R3#show run | section bgp|route-map|prefix-list
router bgp 64512
neighbor 192.0.2.1 route-map POLICY out
!
ip prefix-list MED-PL seq 5 permit 169.254.0.0/16
!
route-map POLICY permit 10
match ip address prefix-list MED-PL
set metric 50
route-map POLICY permit 20
With that configuration applied we can then verify this on R1. As before, because we did not modify the attributes going OUT toR2 the path that R2 picks should be no different than before. Again, because we have changed our routing policy we need to perform a route-refresh or reset the neighbour.
As you can see above, the path has now changed! The route with the lower metric is now more preferred. From a data-plane perspective however, no change has happened as both the MED and the AS-PATH prepend has completed the same job.
Advanced Techniques
Above were the more popular methods of influencing inbound flows however the issue is that the ISP router or some other AS on the Internet could overwrite your policy and make it ineffective. This can then affect your desired outcome. Some more advanced techniques that can be used to ensure a complete active/standby uplink fashion is conditional NLRI advertisement. This is where a prefix is only advertised when a certain condition is met. We can use this so that if the primary link goes down then advertise the route out the backup link. From the ISP perspective they wouldn’t be able to override this policy as they will only be receiving a single route at any one point in time. This though is a CCIE topic so slightly out of the topic domain for CCNP candidates. If you want to get more information on this then Cisco has some good documentation for this. http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/irg-basic-net.html#GUID-FB7CAC3E-0E43-4B25-85AD-FEC19F5229EE
There are other techniques out there that could be covered however most of them involve community tags and some involvement with the ISP. These methods discussed allow you to try and influence your traffic flows without having to contact the ISP. Remember however that your inbound routing policy can be easily overridden and that you cannot tell another AS how to route their traffic to you. This is where the more advanced techniques come into play. Also remember, that in order to affect our inbound traffic flows we need to enforce our policy outbound.
Hope This Helps,
Josh