BGP Path Attribute MED

[parthrawat979]

I learned that MED is applied to outbound updates , dictating the best inbound traffic into the AS, but I saw the vice-versa is also true like you can apply med for indbound updates also and it works the same right??

[julian.bendix]

Hello there..

Yes and no..

MED is a value that is announced to neighbors, influencing inbound traffic.

But BGP is so flexible, you can manipulate inbound announcements and act as if the neighbor would have set a MED. Like this:

ip prefix-list PL-IN seq 5 permit x.x.x.x/xx

route-map RM-IN permit 10
match ip address prefix-list PL-IN
set metric 60

router bgp xxx
neighbor x.x.x.x route-map RM-IN in

[parthrawat979]

Yeah, I got it now from another thread that MED can be used in both direction but it should be applied in out direction because if you want to influence inbound updates why don't simply use weight or local prefrence right??

[julian.bendix]

Well this is a BGP Design question where the answer might be different in each network.

Weight ... this is a Cisco-proprietary thing, which is always only local to a single router, steering outbound traffic flow. Weight can never steer inbound traffic flow from a router's point of view.

Local Preference ... similar to Weight it is steering outbound traffic flow, but this attribute is propagated within the same AS, meaning if you configure Local Pref on a router, it will announce this to iBGP peers. From a whole AS perspective, Local Pref can only steer outbound traffic flow, never inbound traffic flow.

Now MED ... MED is different, MED is designed to influence INBOUND traffic flow. By design a value in the MED attribute is announced to neighbors to influence how traffic is sent to us.
But you can manipulate incoming BGP announcements by setting a MED value .. technically you are then influencing outbound traffic flow with MED, but only by manipulating announcements from neighbors to make them look like as if the neighbor announces a MED value. You just need to be very careful here... the default MED on routes where no MED is set, is 0 ... and moreover, MED is only compared for routes received from the same AS per default. Keeping that in mind - if you want to use MED for steering outbound traffic, you really need to be sure that you set a MED (preferably a different value) to each and every route that needs to be compared. Otherwise the one without MED will win. You'll also want "bgp deterministic-med" to be enabled, and if you want to compare routes announced from different AS' also "bgp always-compare-med"!

At the end of the day, yes, you can use all three methods to influence outbound traffic flow. 
MED is just most likely the most inconvenient one to do so, since weight and local-pref both are easier to configure (for outbound traffic control) as well as they come before MED in the BGP Best Path Selection.

Hope this helps!!

[Cristian Matei]

Hi,

    You're absolutely right. Look at it from both angles, customer side and service provider side. It is being said that you as a customer would set MED values to your outbound updates towards service provider in order to influence ingress traffic / on which path traffic enters customer AS; at the same time, the service provider could set MED values on inbound updates from the customer in order to influence egress traffic / on which path traffic enters customer AS. So, same BGP attribute, used to achieve same purpose, but applied in different directions and on different BGP peering side.

  When you hear the statement, MED is supposed to be used in outbound updates to influence ingress path towards your AS and local preference is supposed to be used in inbound updates to influence egress traffic from your AS, both statements have been made from customer perspective, so that you as a customer decide the egress / ingress traffic paths, without any involvement from service provider side.

   Considering the above statement, where we as the customer want to influence both egress and ingress traffic paths by doing BGP configurations on our side, without any involvement from the service provider, let's answer some questions:

1. Why is weight and local preference used to influence egress traffic from your AS, via inbound policies? Because weight is the first criteria in best path selection and local preference is the second criteria, so you want to use BGP attributes (weight is not a BGP attribute but for the sake of the explanation we consider it to be) that are at the top at the decision making process, to guarantee the outcome you're looking for.

2. Why is weight and local preference NOT used to influence ingress traffic to your AS, via outbound policies? Because weight is not a BGP attribute, is not attached to BGP updates, it's just a value locally significant to the router in its BGP RIB; because local preference, although it is a BGP attribute, so it gets attached to BGP updates, it is never attached to eBGP updates, only to iBGP, and as your customer to service provider BGP peering is of type eBGP, you can't use this attribute.

3. What are the next steps in BGP best path selection? Locally originated or not (and as we speak about manipulating egress or ingress traffic paths) this step is just ignored, as none of the BGP prefixes match this statement. AIGP, which is a big brother of MED, less known by engineers since it came later in the BGP development phases; it is called the big brother of MED because it's basically a simpler version of MED which gets applied higher in the BGP best path selection algorithm

4. Why is AS path and MED (mostly AS-path, MED is rarely used) used to influence ingress traffic towards your AS? Because these are the first BGP attributes, after AIGP (considering BGP best path selection algorithm) the can be used for this purpose, as AS-path is a well-known mandatory BGP attribute present in all BGP updates, while MED is an optional non-transitive BGP attribute which can be attached to both iBGP and eBGP updates.

Hope this make much more sense.

Thanks,

Cristian.

[M02@rt37]

Hello @parthrawat979 

MED can be modified either inbound or outbound, but the effect is not symmetrical !!!

If you want site A to prefer one link over another, the correct method is to set the med outbound on site B for routes advertised to site A, since med is meant to influence the neighbor’s path selection...

While you can change med inbound on site A, that only affects site A’s local decision process and any re-advertisement of the route ; it does not truly replace the outbound use case.

So for that reason, setting med attribute in outbound is the standart and recommended approach.

[Stefan Mihajlov]

@parthrawat979 MED is set on outbound BGP updates to influence how external neighbors choose an entry path into your AS-when you “apply MED inbound,” you are actually modifying the received MED locally for your own path selection—it does not influence the remote AS.

[parthrawat979]

I don't know a lot but it worked as expected. Like if I set the higher value of med for a certain neighbor with a route-map in the inbound direction then the router receiving the update will no longer choose the router with higher med as best path.

[julian.bendix]

I also had a quick re-visit to the lab before writing my comments. You can achieve the desired outcome of influencing outbound traffic flow with MED set on inbound direction.

But the others here in the thread are also right ... it is not recommended and if you choose to do it, be very careful.

For outbound traffic flow steering, both Weight and Local Pref are easier to handle and also recommended to use.

[Stefan Mihajlov]

@parthrawat979  Correct — inbound MED changes work because you are modifying the MED locally before the BGP best-path decision, so your router prefers a lower MED. This affects only your router’s path selection and does not influence how the remote AS chooses paths.

[balaji.bandi]

Agree with some of the comments and my views. It all depends on the use case and requirements.(where you can apply)

BGP MED can technically be applied to inbound updates (Influence outbound traffic leaving your AS). Still, it does not work the "same way" as the outbound application because the direction of traffic influence is reversed.