Metric Attribute
The metric attribute which is also called Multi_exit_discriminator, MED (BGP4) or Inter−As (BGP3) is a hint to external neighbors about the preferred path into an AS. This is a dynamic way to influence another AS on which way to choose in order to reach a certain route given that we have multiple entry points into that AS. A lower value of a metric is more preferred.
Unlike local preference, metric is exchanged between ASs. A metric is carried into an AS but does not leave the AS. When an update enters the AS with a certain metric, that metric is used for decision making inside the AS. When the same update is passed on to a third AS, that metric will be set back to 0 as shown in the above diagram. The Metric default value is 0.
Unless otherwise specified, a router will compare metrics for paths from neighbors in the same AS. In order for the router to compare metrics from neighbors coming from different ASs the special configuration command "bgp always−compare−med" should be configured on the router.
In the above diagram, AS100 is getting information about network 180.10.0.0 via three different routers: RTC, RTD and RTB. RTC and RTD are in AS300 and RTB is in AS400.
Assume that we have set the metric coming from RTC to 120, the metric coming from RTD to 200 and the metric coming from RTB to 50. Given that by default a router compares metrics coming from neighbors in the same AS, RTA can only compare the metric coming from RTC to the metric coming from RTD and will pick RTC as the best next hop because 120 is less than 200. When RTA gets an update from RTB with metric 50, he can not compare it to 120 because RTC and RTB are in different ASs (RTA has to choose based on some other attributes).
In order to force RTA to compare the metrics we have to add bgp always−compare−med to RTA. This is illustrated in the configs below:
With the above configs, RTA will pick RTC as next hop, considering all other attributes are the same. In order to have RTB included in the metric comparison, we have to configure RTA as follows:
In this case RTA will pick RTB as the best next hop in order to reach network 180.10.0.0.
Metric can also be set while redistributing routes into BGP using the default−metric number command.
Assume in the above example that RTB is injecting a network via static into AS100 then the following configs:
The metric attribute which is also called Multi_exit_discriminator, MED (BGP4) or Inter−As (BGP3) is a hint to external neighbors about the preferred path into an AS. This is a dynamic way to influence another AS on which way to choose in order to reach a certain route given that we have multiple entry points into that AS. A lower value of a metric is more preferred.
Unlike local preference, metric is exchanged between ASs. A metric is carried into an AS but does not leave the AS. When an update enters the AS with a certain metric, that metric is used for decision making inside the AS. When the same update is passed on to a third AS, that metric will be set back to 0 as shown in the above diagram. The Metric default value is 0.
Unless otherwise specified, a router will compare metrics for paths from neighbors in the same AS. In order for the router to compare metrics from neighbors coming from different ASs the special configuration command "bgp always−compare−med" should be configured on the router.
In the above diagram, AS100 is getting information about network 180.10.0.0 via three different routers: RTC, RTD and RTB. RTC and RTD are in AS300 and RTB is in AS400.
Assume that we have set the metric coming from RTC to 120, the metric coming from RTD to 200 and the metric coming from RTB to 50. Given that by default a router compares metrics coming from neighbors in the same AS, RTA can only compare the metric coming from RTC to the metric coming from RTD and will pick RTC as the best next hop because 120 is less than 200. When RTA gets an update from RTB with metric 50, he can not compare it to 120 because RTC and RTB are in different ASs (RTA has to choose based on some other attributes).
In order to force RTA to compare the metrics we have to add bgp always−compare−med to RTA. This is illustrated in the configs below:
RTA#
router bgp 100
neighbor 2.2.2.1 remote−as 300
neighbor 3.3.3.3 remote−as 300
neighbor 4.4.4.3 remote−as 400
....
RTC#
router bgp 300
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 route−map setmetricout out
neighbor 1.1.1.2 remote−as 300
route−map setmetricout permit 10
set metric 120
RTD#
router bgp 300
neighbor 3.3.3.2 remote−as 100
neighbor 3.3.3.2 route−map setmetricout out
neighbor 1.1.1.1 remote−as 300
route−map setmetricout permit 10
set metric 200
RTB#
router bgp 400
neighbor 4.4.4.4 remote−as 100
neighbor 4.4.4.4 route−map setmetricout out
route−map setmetricout permit 10
set metric 50
With the above configs, RTA will pick RTC as next hop, considering all other attributes are the same. In order to have RTB included in the metric comparison, we have to configure RTA as follows:
RTA#
router bgp 100
neighbor 2.2.21 remote−as 300
neighbor 3.3.3.3 remote−as 300
neighbor 4.4.4.3 remote−as 400
bgp always−compare−med
In this case RTA will pick RTB as the best next hop in order to reach network 180.10.0.0.
Metric can also be set while redistributing routes into BGP using the default−metric number command.
Assume in the above example that RTB is injecting a network via static into AS100 then the following configs:
RTB#
router bgp 400
redistribute static
default−metric 50
ip route 180.10.0.0 255.255.0.0 null 0
!−− Causes RTB to send out 180.10.0.0 with a metric of 50
