When altering BGP path selection, it is a good idea to have the following table committed to memory:
| Method | Direction Applied | Direction Affected | Best Metric |
| Weight | Inbound | Outbound | Highest |
| Local Preference | Inbound | Outbound | Highest |
| AS Path | Outbound | Inbound | Shortest |
| MED (metric) | Outbound | Inbound | Lowest |
This table shows the four most common BGP path manipulation attributes in order of preference (here’s a mnemonic to memorize all of the BGP attributes). Whenever I am tasked with BGP path manipulation in the lab I quickly recreate the above table with the following mnemonic:
“When applying in London in April, make love.”
W = Weight
A = applied (April reminds me of showers which reminds me of London, so this helps recreate the mnemonic as well)
I = inbound
L = Local Preference
I = inbound
A = AS Path
M = MED (London makes me think of sex for reasons I’ll keep to myself
)
L = lowest
A = applied (April reminds me of showers which reminds me of London, so this helps recreate the mnemonic as well)
I = inbound
L = Local Preference
I = inbound
A = AS Path
M = MED (London makes me think of sex for reasons I’ll keep to myself
)L = lowest
You’re probably thinking “Nice. But that doesn’t look like the entire table to me is represented in that stupid phrase.” And you’re right.
I write out the table first with the headers only:
| Method | Direction Applied | Direction Affected | Best Metric |
Then I write ‘Weight’. The “applying” bit just reminds me that the second header should be “Direction Applied” and not “Direction Affected“. If you mix up those two headers, then you are in for a very bad experience.
| Method | Direction Applied | Direction Affected | Best Metric |
| Weight | |||
“In” means inbound (under Direction Applied). With just this bit of information I can fill in the rest of the “Direction” fields because I know that the first two attributes are applied inbound. That means the that the last two attributes are applied outbound. Since the “Direction Affected” is the opposite of the “Direction Applied”, it’s a snap to fill in that information as well.
| Method | Direction Applied | Direction Affected | Best Metric |
| Weight | Inbound | Outbound | |
| Inbound | Outbound | ||
| Outbound | Inbound | ||
| Outbound | Inbound |
So we’re left with ‘London in April, make love’. ‘London’ = local preference. ‘in’ is another reminder that Local_Pref is applied inbound (and it makes the goofy sentence flow better). ‘April’ = AS Path and ‘make’ = MED.
| Method | Direction Applied | Direction Affected | Best Metric |
| Weight | Inbound | Outbound | |
| Local Preference | Inbound | Outbound | |
| AS Path | Outbound | Inbound | |
| MED | Outbound | Inbound |
Now all we need is to fill in the ‘Best Metric’ column. I assume that the highest metric is always the best metric except in the case of the last two attributes. In this case, ‘love’ = lowest (for MED). I know that the shortest AS Path is the best (no need to memorize that as it’s pretty logical).
So now I have the whole table:
| Method | Direction Applied | Direction Affected | Best Metric |
| Weight | Inbound | Outbound | Highest |
| Local Preference | Inbound | Outbound | Highest |
| AS Path | Outbound | Inbound | Shortest |
| MED | Outbound | Inbound | Lowest |
So thanks for crawling into my mind. Pretty empty huh? The exit is through my ears.
You can create your own mnemonic (I’m sure that mine is not the best) and add more or less detail as needed. After you are able to recreate this table a couple of times, you’ll find that you won’t need to use the mnemonic, but it’s nice to have it in case you need it.
