The MULTI_EXIT_DISC (MED) Attribute

The MULTI_EXIT_DISC (MED) attribute is an optional nontransitive attribute (type code 4). It is a hint to external neighbors about the preferred path into an AS that has multiple entry points. The MED is also known as the external metric of a route. A lower MED value is preferred over a higher MED value.

---

Troubleshooting:  
Example: Ch. 10, pp. 337-340. The MULTI_EXIT_DISC (MED) Attribute

---

Unlike local preference, the MED attribute is exchanged between ASs, but a MED attribute that comes into an AS does not leave the AS. When an update enters the AS with a certain MED value, that value is used for decision making within the AS. When BGP passes on the routing update to another AS, the MED is reset to zero (unless the outgoing MED is set to a specific value).

When the route is originated by the AS itself, the MED value follows the internal IGP metric of the route. This becomes useful when a customer has multiple connections to the same provider. The IGP metric reflects how close or how far a network is to a certain exit point. A network that is closer to exit point A than to exit point B will have a lower IGP metric in the border router connected to A. When the IGP metric translates to MED, traffic coming into the AS can enter from the link closer to the destination because a lower MED is preferred for the same destination. This can be used both by providers and customers to balance the traffic over multiple links between two ASs.

Unless otherwise specified, the router compares MED attributes for paths from external neighbors that are in the same AS. MEDs from different ASs are not comparable because the MED associated with a route usually gives some indication of the AS's internal topology. Comparing MEDs from different ASs would be like comparing apples and oranges. Still, for administrators who have a reason to do so, Cisco offers the bgp always-compare-med router command.

In the local preference example illustrated in figure 5-19, an AS was shown how to influence its own outbound decision. In the example illustrated in figure 5-20, the MED shows how an AS can influence the outbound decison of another AS. In figure 5-20, ANET and YNET try to influence XNET's outbound by traffic by sending it different metric values.

Figure 5-20  Effects of the MED attribute.

XNET is receiving routing updates about 128.2130.0/16 from three different sources; SJ (metric 120), LA (metric 200), and NY (metric 50). SF will compare the two metric values coming from ANET and will prefer the SJ router because it is advertising a lower metric (120). When the bgp always-compare-med router configuration command is used on the SF router, it will then compare metric 120 with metric 50 coming from NY and will prefer NY to reach 128.213.0.0/16. Note that SF could have influenced its decision by using local preference inside XNET to override the metrics coming from outside ASs. Nevertheless, MED is still useful in case XNET prefers to base its BGP decisions on outside factors to simplify router configuration on its end. Customers that connect to the same provider in multiple locations could exchange metrics with their providers to influence each other's outbound traffic, which leads to better load balancing.

The Community Attribute

In the context of BGP, a community is a group of destinations that share some common property. A community is not restricted to one network or one autonomous system; it has no physical boundaries. An example is a group of networks that belong to the educational or government communities. These networks can belong to any autonomous system. Communities are used to simplify routing policies by identifying routes based on a logical property rather than an IP prefix or an AS number. A BGP speaker can use this attribute in conjunction with other attributes to control which routes to accept, prefer, and pass on to other BGP neighbors.

---

Troubleshooting:  
Example: Ch. 10, pp. 340-342. The Community Attribute

---

The community attribute (type code 8) is an optional transitive attribute that is of variable length and consists of a set of 4-byte values. Communities in the range 0x00000000 through 0x0000FFFF and 0xFFFFF0000 through 0xFFFFFFFF are reserved. These communities are well-known—that is, they have a global meaning. An example of well-known communities are:

•  NO_EXPORT (0xFFFFFF01): A route carrying this community value should not be advertised to peers outside a confederation (or the AS if it is the only AS in the confederation). Confederations are explained in Chapter 8.

•  NO_ADVERTISE (0xFFFFFF02): A route carrying this community value, when received, should not be advertised to any BGP peer.

Besides well-known community attributes, private community attributes can be defined for special uses. A common practice is to use the first two bytes of the community attribute for the AS number and the last two bytes to define a value in relation to that AS. A provider (AS256), for example, who wants to define a private community called "my-peer-routers" could use the community 256:1 represented in a decimal notation. The 256 indicates that this particular provider has defined the community, and the 1 has special meaning to the provider; in this case it is "my-peer-routers."

A route can have more than one community attribute. A BGP speaker that sees multiple community attributes in a route can act based on one, some, or all the attributes. A router has the option of adding or modifying community attributes before passing routes on to other peers.

Figure 5-21 shows a simple use of the community attribute. XNET is sending toward YNET routes X and Y with a NO_EXPORT community attribute, and route Z with no modification. The BGP router in YNET will propagate route Z only toward ZNET. Routes X and Y will not be propagated because of the NO_EXPORT community attribute.

Figure 5-21  See Simple application of community attribute.