- Highest Weight
- Highest Local preference
- Locally originated
- Shortest AS_Path
- Origin; prefer IGP, before EGP, before Incomplete
- Lowest MED
- eBGP paths over iBGP paths
- Lowest IGP metric to the next hop
- For eBGP prefixes prefer first received route
- Lowest router ID
- Shortest cluster list length
- Lowest neighbor address
The BGP Best path
selection algorithm for BGP looks at several path attributes and evaluates
them in the following order of preference:
Enabling the
always-compare-med option in BGP ensures the comparison of the MED attribute
for paths from peers in different autonomous systems. In our lab today we have
an enterprise (R1) that peers with two different ISP's which is receiving
identical length paths to a third autonomous systems (R4) prefixes. Our job is
to make the path to 4.4.4.0/24 go through R3 using only the MED attribute.
Tasks:
-BGP peering has
been configured for you
-loopback network
have been configured for you.
-Modifying the BGP
MED attribute and related configuration only, ensure traffic from AS 10
prefers
the path to R3 for traffic destined for
networks originating in AS 40
-Do not modify any
configuration on R4 to accomplish this
-Do not use
redistribution or route-maps to accomplish this
-Do not modify any
other path attributes other than MED to accomplish this
Topology
GNS3 files: Link
Solution
In our lab peering
has already been established so we just need to focus on understanding the
problem and resolving it. Let's begin by looking at the path selection on R1.
R1#sh ip bgp
<snip>
Network Next Hop Metric LocPrf
Weight Path
*>
1.1.1.0/24 0.0.0.0 0 32768 i
*
4.4.4.0/24
192.168.13.3 0 30 40 i
*> 192.168.12.2
0 20 40 i
So currently R1
prefers the path through R2 for the 4.4.4.0/24 prefix. All things being equal
the best path algorithm is choosing the path with the lowest router ID because
all the higher priority attributes are equal, i.e. weight, local preference,
as_path, origin, etc.
So the solution
should be easy, we just modify the MED attribute so that R3 is prefered and we
should be all set.
R2(config)#route-map
SET_METRIC permit 10
R2(config-route-map)#set
metric 1000
R2(config-router)#neighbor
192.168.12.1 route-map SET_METRIC out
So with our MED
configured on R2 which should be R2 less preferred we should our path change
once we clear the BGP process to speed things along.
R2#clear ip bgp *
soft
R1#sh ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*>
1.1.1.0/24 0.0.0.0 0 32768 i
*
4.4.4.0/24
192.168.13.3 0 30 40 i
*> 192.168.12.2 0 20 40 i
Wait nothing
changed, our preferred path is still through R2, what happened. We by default
the MED attribute is only evaluated from peers in the same autonomous system.
Because R2 and R3 are in different AS's the MED values are ignored and the
next tie breaker is the router ID. Now our lab tell us we must solve this
problem using the MED attribute so we need to tell R1 to look at the MED
value. This is where the bgp always-compare-med command comes in. It tells the
local BGP process to evaluate the MED value even if those values are from
different autonomous systems. Let's apply this command now and see what
happens.
R1(config)#router
bgp 10
R1(config-router)#bgp
always-compare-med
R1#clear ip bgp *
soft
R1#sh ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*>
1.1.1.0/24 0.0.0.0 0 32768 i
*>
4.4.4.0/24
192.168.13.3 0 30 40 i
* 192.168.12.2 1000 0 20 40 i
There we go, now
that looks much better.
Sources
No comments:
Post a Comment