At the beginning of this chapter, we learned that BGP uses the path attributes to ensure protocol reliability and routing information accuracy. In addition to being used to select the best path to a destination prefix, path attributes are also used to prevent BGP loops and ensure that the next hop IP address for a specified BGP prefix is reachable before BGP uses the next hop address to forward packets to that destination prefix.
Later in this chapter, we also learned that each BGP UPDATE message contains a single set of attributes and all of the routes using those attributes. Within the BGP UPDATE message, the variable length Path Attributes field contains the BGP attributes assigned to the path. Each BGP attribute is encoded as a TLV triplet, which includes the Attribute Type, Attribute Length, as well as the Attribute Value. The Attribute Type portion of this TLV is a 2-byte field comprised of the Attribute Flags octet followed by the Attribute Type Code byte. Figure 6-13 shows the format of the Attribute Type field:
Fig. 6-13. The BGP Attribute Type Field
Bit 0 (the high-order bit) of the Attribute Flags field is the Optional bit. If this bit is set to 1, the attribute is optional. If this bit is set to 0, then the attribute is well-known.
Bit 1 (the second high-order bit) of the Attribute Flags field is the Transitive bit. This bit is used to specify whether the optional attribute is transitive (set to 1) or non-transitive (set to 0). If the high-order bit is set to 0 (well-known attribute) this field must be set to 1.
NOTE: Transitive attributes are those that transit different autonomous systems, while non-transitive attributes are locally significant within an autonomous system.
Bit 2 (the third high-order bit) is the Partial bit. If this bit is set to 1, it indicates that information in the optional transitive attribute is optional. It is therefore not mandatory for routers to understand or recognize this attribute. Additionally, a value of 1 also indicates that at least one BGP router along the path did not recognize the attribute. For well-know and optional non-transitive attributes, this bit must be set to 0. A value of 0 indicates that each BGP router along the path recognized this attribute.
Bit 3 is the Extended Length bit. This bit is used to set the size of the TLV Length portion to one byte, which is indicated by a value of 0, or two bytes which is indicated by a value of 1. Bits 4 through 7 are unused and must be set to a value of 0.
The Attribute Type Code byte contains the Attribute Type Code. BGP path attributes fall into four separate categories, which are:
- Well-known mandatory
- Well-known discretionary
- Optional transitive
- Optional non-transitive
All BGP speakers must recognize all of the well-known mandatory attributes, which must be included for all prefixes. However, discretionary attributes may or may not be included for a particular prefix. Discretionary attributes may be used based on the decision of the network administrator; however, their use is not mandatory.
BGP speakers do not have to understand optional attributes but must re-advertise them based on their transitive setting. Transitive attributes are advertised to all BGP peers, while non-transitive attributes may be discarded if the local router doesn’t recognize them.
Because BGP is first and foremost a routing policy tool, BGP makes extensive use of these path attributes in selecting the best path to a destination. A solid understanding of these path attributes is required in order to both design and implement an effective BGP routing architecture. However, while Cisco IOS software support many different BGP attributes, only those that within the scope of the ROUTE exam are described in this section. These are:
- The ORIGIN attribute
- The AS_PATH attribute
- The NEXT_HOP attribute
- The MULTI_EXIT_DISC attribute
- The LOCAL_PREF attribute
- The ATOMIC_AGGREGATE and AGGREGATOR attributes
- The COMMUNITY attribute
- The ORIGINATOR_ID attribute
- The CLUSTER_LIST attribute
- The Cisco-proprietary WEIGHT attribute
These attributes are described in the following sections.
The ORIGIN attribute (Type Code 1)
The ORIGIN attribute is a well-known mandatory attribute. The ORIGIN attribute is generated by the autonomous system that originates the routing information. This attribute is automatically defined when a route or prefix is injected into BGP, but may be modified using a route-map in Cisco IOS software. There are three possible Origin values. These values are:
- IGP
- EGP
- INCOMPLETE
An ORIGIN of IGP indicates that the prefix was injected into BGP using the network command in Cisco IOS software. Prefixes with this ORIGIN code are displayed with the letter ‘I’ and are encoded as a value of 0. These routes are internal to the originating AS.
An ORIGIN code of EGP indicates that the prefix originated from the Exterior Gateway Protocol (EGP). Prefixes with this ORIGIN code are displayed with the letter ‘E’ and are encoded as a value of 1. EGP is beyond the scope of the ROUTE exam and is not described within this guide.
And finally, an ORGIN code of INCOMPLETE indicates that the original source or the prefix is not known to the router injecting the route into BGP. This code is used for prefixes that are redistributed into BGP using theredistribute command. In Cisco IOS software, prefixes with the INCOMPLETE attribute code are displayed with the question mark, i.e. ‘?’ and are encoded as a value of 2. Table 6-5 summarizes the BGP ORIGIN attribute codes, the Cisco IOS software representation for prefixes using the specific code and the description of the code:
|
Attribute Code |
Cisco IOS Representation |
Description |
|---|---|---|
|
0 |
I |
The prefix is internal to the originating AS |
|
1 |
E |
The prefix is received from External Gateway Protocol |
|
2 |
? |
The prefix has been learned via another means – the most common being redistribution |
Tab.6-5. ORIGIN Attribute Codes
The AS_PATH attribute (Type Code 2)
AS_PATH, Attribute Type Code 2, is a well-known mandatory attribute. The attribute contains a reverse order sequenced list of AS numbers that represent the domains the prefix has transited. The first AS listed in the AS_PATH attribute is the last AS traversed, while the last AS listed in the AS_PATH attribute list is the originating AS. For example, if the AS_PATH for a prefix is 10, 20, 30, 40, 50, it means that the prefix originated in AS 50, traversed ASes 40, 30, 20, and finally 10 before it was received by the local router. This is illustrated in Figure 6-14:
Fig. 6-14. The BGP AS_PATH List
It is extremely important to remember that the AS_PATH attribute is changed only when an UPDATE is sent to an eBGP neighbor, but never to an iBGP peer. In other words, an iBGP speaker will never change the AS_PATH attribute when advertising a prefix to another iBGP speaker; however, an eBGP speaker will change the AS_PATH attribute when advertising a prefix to another eBGP speaker. This concept is illustrated in Figure 6-15:
Fig.6-15. External and Internal BGP AS_PATH Updates
Referencing Figure 6-18, R1 in AS 50 originates the 150.254.0.0/16 prefix. The prefix is advertised to R2, which is an eBGP neighbor. This attribute is changed from a Null value to 50 in the UPDATE message because R2 is an eBGP neighbor. The AS_PATH for this prefix from router R2s perspective is 50.
AS 40 is peered to AS 30 and R2 advertises this prefix to R3. Because router R3 is an eBGP peer, the AS_PATH attribute is changed in the UPDATE message sent by R2 to R3 to also include AS 40 (its own AS number). The AS_PATH for this prefix from router R3s perspective is 40, 50.
R3 is peered to R4, which is an iBGP peer. In this case, R3 does not add its own AS number to the UPDATE it sends to R4 for the 150.254.0.0/16 prefix. From the perspective of R4, the AS_PATH remains 40, 50 for the 150.254.0.0/16 prefix.
R4 is peered to R5, which is an eBGP peer. Because the neighbor is external to the AS, R4 adds its own AS, AS 30, to the list of ASes for the 150.254.0.0/16 prefix and includes that in the UPDATE message sent to R5. The AS_PATH for this prefix from R3s perspective is 30, 40, 50.
Finally, R5 is peered to R6, which is also an eBGP peer. Again, because the neighbor is external to the local AS, R5 adds its own AS number to the list of ASes for the 150.254.0.0/16 prefix and includes that in the UPDATE message sent to R6. The AS_PATH for this prefix from R6s perspective is 20, 30, 40, 50.
The AS_PATH segment is represented by a TLV triplet, which includes the Path Segment Type, Path Segment Length, and Path Segment Value. The Path Segment Type is a 1-byte field which can contain the following AS segments, all of which are supported in Cisco IOS software:
- AS_SET
- AS_SEQUENCE
- AS_CONFED_SEQUENCE
- AS_CONFED_SET
The AS_SET is an unordered set of autonomous systems that a route in the UPDATE message has traversed. The AS_SEQUENCE is an ordered set of autonomous systems that a route in the UPDATE message has traversed.
The AS_CONFED_SEQUENCE is an ordered set of member autonomous systems in the local Confederation that the UPDATE message has traversed. The AS_CONFED_SET is an unordered set of member autonomous systems in the local Confederation that the UPDATE message has traversed. BGP Confederations will be described in detail in the following chapter; however, the primary emphasis in this section should be placed on remembering that the difference between the SET and SEQUENCE segments is that within the SET segments, the list of autonomous systems traversed is unordered, while within the SEQUENCE segments, the list of autonomous systems traversed is ordered.
The AS_PATH attribute serves two primary functions. These two functions are:
- BGP Path Selection
- Loop Prevention
By default, BGP will always prefer the path that has the shortest AS_PATH list to a destination prefix when comparing two or more UPDATES for the same destination prefix. The use of the AS_PATH attribute in prevent loops will be described in detail in the following section of this chapter, which delves into BGP loop prevention mechanisms.
The NEXT_HOP attribute (Type Code 3)
The NEXT_HOP attribute, Attribute Type Code 3, is a well-known mandatory attribute that is used to define the next hop IP address to the destination prefix from the BGP perspective. Unlike with traditional IGPs, the next hop for a BGP prefix does not have to be directly connected. In such cases, the local router performs a recursive lookup in the routing table to locate a route to the BGP next hop. The result of this recursive lookup is the physical next hop assigned to the BGP route in the routing and forwarding tables.
It is important to understand that there are variable ways in which the NEXT_HOP for a prefix is determined and set. These variable ways include:
- When the prefix is first injected into BGP
- When the prefix is advertised via eBGP
- When the next hop is manually changed
When a prefix is first injected into BGP, then the BGP speaker on which the prefix is injected will be responsible for setting the NEXT_HOP attribute. The actual value, i.e. the actual IP address specified, depends on how the prefix is injected into BGP. If the prefix is injected into BGP using the network command and the prefix is a directly connected subnet, the NEXT_HOP address will be 0.0.0.0 on the local BGP speaker. The BGP speaker will then use its own IP address before sending the UPDATE to peers. As an example, a router (R2) has been configured with a Loopback interface on the 150.254.2.0/24 subnet. The show ip route command for this prefix shows the following entry:
| R2#show ip route 150.254.2.0 255.255.255.0 Routing entry for 150.254.2.0/24 Known via “connected”, distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via Loopback0 Route metric is 0, traffic share count is 1 |
The same prefix is then advertised via BGP using the network command. Because the prefix is directly connected, the NEXT_HOP on the local router shows 0.0.0.0, which can be validated using the show ip bgp command as illustrated in the following output:
| R2#show ip bgp BGP table version is 4, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 150.254.2.0/24 0.0.0.0 0 32768 i |
However, if a prefix is injected into BGP using the network command and that prefix is known via an IGP, such as OSPF, then the NEXT_HOP contains the IP address of the IGP next hop router. As another example, the same router used in the previous example is receiving routing information for the 153.254.0.0/16 via OSPF as illustrated in the following output:
| R2#show ip route 153.254.0.0 255.255.0.0 Routing entry for 153.254.0.0/16 Known via “ospf 2”, distance 110, metric 65, type intra area Last update from 10.0.3.3 on Serial0/1, 00:09:05 ago Routing Descriptor Blocks: * 10.0.3.3, from 3.3.3.3, 00:09:05 ago, via Serial0/1 Route metric is 65, traffic share count is 1 |
The next hop address for this prefix is 10.3.3.3. If the same prefix was advertised via BGP using the network command, the NEXT_HOP would be set to the OSPF next hop address by the local router on which the prefix is injected into BGP as illustrated in the following output:
| R2#show ip bgp BGP table version is 6, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 153.254.0.0 10.0.3.3 65 32768 i |
NOTE: The configuration and advertisement of prefixes using BGP will be described in detail later in this chapter. Primary emphasis at this point should be placed on understanding the setting of the NEXT_HOP attribute.
And finally, when BGP route summarization is configured using the aggregate-address router configuration command, the NEXT_HOP is set to the address of the router that is performing the summarization when an UPDATE message is sent. BGP route summarization will be described in detail in the following chapter on advanced BGP implementation.
In regards to the second point made about how the NEXT_HOP is determined, when the prefix is advertised via eBGP, the NEXT_HOP will automatically be set to the IP address of the eBGP speaker that is sending the UPDATE message for the prefix. However, if more than two eBGP peers reside on the same multi-access segment, the BGP speaker that is advertising the prefix sets the NEXT_HOP address in the UPDATE to the original BGP speaker on the same segment rather than to itself. To further clarify this point, we will use the BGP topology in Figure 6-16:
Fig.6-16. External BGP NEXT_HOP on Multi-Access SegmentsReferencing Figure 6-16, routers R1, R2, and R3 reside on the multi-access 10.0.0.0/24 segment. These three routers are all BGP speakers. R1 resides in AS 1 and has an eBGP neighbor relationship with R2 in AS 2. R2 is also peered with R3 is AS 3. R3 is advertising the 30.30.30.0/24 prefix via BGP. R1 and R3 are not directly peered with each other. Focusing only on the NEXT_HOP attribute at this point, R3 shows the following entry for the 30.30.30.0/24 prefix that is injected into BGP on this router using the network command:
| R3#show ip bgp BGP table version is 1, local router ID is 153.254.0.3 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path * 30.30.30.0/24 0.0.0.0 0 32768 i |
Moving onto R2, this router shows the following entry for the 30.30.30.0/24 received from R1:
| R2#show ip bgp BGP table version is 2, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 30.30.30.0/24 10.0.0.3 0 0 3 i |
R2 in turn advertises this to eBGP neighbor R1. Under normal circumstances, R2 would set the NEXT_HOP address in the UPDATE message to its own IP address; however, because the routers reside on the same multi-access segment, this default method of operation is forgone. Instead, R2 simply retains the IP address of R3 in this field as can be seen on R1:
| R1#show ip bgp BGP table version is 2, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 30.30.30.0/24 10.0.0.3 0 2 3 i |
And finally, in regards to the third point made on how the NEXT_HOP attribute is set, the next hop can also be manually changed by using the next-hop-self neighbor configuration command for an iBGP peer or using a route map to change the NEXT_HOP attribute for an eBGP peer. Because this is an important concept, we will take a moment to further explain it.
By default, the NEXT_HOP is not changed when a prefix is advertised by a BGP speaker to an iBGP peer. Consider the topology illustrated in Figure 6-17 for example:
Fig.6-17. Understanding iBGP default NEXT_HOP behaviorFigure 6-17 shows a basic routed network. R3 resides in AS 3 and is peered to R2 is AS 2. R2 is in turn also peered to R1, which is in the same AS. R3 is advertising the 30.30.30.0/24 prefix. Focusing exclusively on the NEXT_HOP attribute, the BGP Table on R2 shows the following:
| R2#show ip bgp 30.30.30.0 255.255.255.0 BGP routing table entry for 30.30.30.0/24, version 6 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 3 10.0.3.3 from 10.0.3.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, valid, external, best |
This prefix is advertised by R2 to iBGP peer R1. The BGP Table on R1 shows the following:
| R1#show ip bgp 30.30.30.0 255.255.255.0 BGP routing table entry for 30.30.30.0/24, version 0 Paths: (1 available, no best path) Not advertised to any peer 3 10.0.3.3 (inaccessible) from 10.0.0.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal |
In the output above, the prefix is marked as being inaccessible. This is due to the following:
- The NEXT_HOP attribute was not changed when R2 advertised this prefix to R1
- R1 does not have a route to the 10.0.3.3 address specified in the NEXT_HOP
The recommended solution is to configure R2 to change the NEXT_HOP attribute and insert its IP address instead of that of the eBGP peer instead using the next-hop-self command. This is implemented as follows on R2:
| R2(config)#router bgp 2 R2(config-router)#neighbor 10.0.0.1 next-hop-self R2(config-router)#exit |
Following this configuration, the BGP Table on R1 now shows the following for the prefix:
| R1#show ip bgp 30.30.30.0 255.255.255.0 BGP routing table entry for 30.30.30.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 3 10.0.0.2 from 10.0.0.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal, best |
The second solution would be to use an IGP to dynamically advertise the 10.0.3.0/24 subnet between R2 and R3 or configure a static route to this address on R3. While both options are valid, the next-hop-self configuration is the recommended solution.
NOTE: BGP neighbor configuration is illustrated in detail later in this chapter.
For eBGP peers, to set the NEXT_HOP IP address to a value other than that of the local BGP speaker, a route map must be used. This configuration is illustrated in the following chapter.
The MULTI_EXIT_DISC attribute (Type Code 4)
The MULTI_EXIT_DISC (MED) attribute Discriminator attribute is a 32-bit positive integer that is defined as Attribute Type Code 4. In addition to this, MED is an optional non-transitive attribute. MED is typically used on inter-AS links and allows BGP to choose among multiple exit points to the same neighboring AS.
In other words, MED, which is expressed as a metric value, is used as a suggestion to the peer external AS regarding the preferred route into the local AS that is advertising the metric. The term ‘suggestion’ is used because it is not mandatory for the neighboring AS to adhere to the values specified using this attribute. Figure 6-18 depicts the use of the MED attribute in BGP:
Fig.6-18. Understanding the MULTI_EXIT_DISC Attribute
Referencing Figure 6-18, AS 1 is peered to AS 2. AS 1 is advertising the 150.253.0.0/16 as well as the 150.254.0.0/16 prefixes to AS 2. Leveraging the policy control capabilities of BGP, R1 has been configured to advertise the 150.253.0.0/16 prefix to AS 2 with a MED (metric) of 10, while advertising the 150.254.0.0/16 prefix with a MED (metric) of 20. R3 has been configured to advertise the 150.253.0.0/16 prefix to AS 2 with a MED (metric) of 20, while also advertising the 150.254.0.0/16 prefix, but with a MED (metric) of 10.
The result of this implementation is that the lower MED values influence AS to forward traffic destined to the 150.253.0.0/16 prefix via R1 and the traffic destined to the 150.254.0.0/16 prefix via R3. The alternate paths will be used when the primary (preferred) paths are unavailable.
In addition to understanding the use of the MED attribute, it is also important to understand Cisco IOS software rules on MED setting and advertisement. These rules apply to the following:
- Assigning a MED value to a prefix
- Advertising prefixes to iBGP peers
- Advertising prefixes to eBGP peers
The MED value for a prefix is determined by the manner in which that prefix has been injected into BGP on the local BGP speaker. If the prefix is for a directly connected network and the network or redistribute command is used to inject the prefix into BGP, then the BGP MED value is set to 0. As an example, assume that the local router has the 150.254.2.0/24 subnet directly connected:
| R2#show ip route 150.254.2.0 255.255.255.0 Routing entry for 150.254.2.0/24 Known via “connected”, distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via Loopback0 Route metric is 0, traffic share count is 1 |
If this prefix is injected into BGP using the network or redistribute command, the MED value will be set to 0 as illustrated in the following output:
| R2#show ip bgp BGP table version is 4, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 150.254.2.0/24 0.0.0.0 0 32768 i |
However, if the prefix is received from an IGP, such as OSPF or EIGRP, when it is injected into BGP using either thenetwork or redistribute command, the MED value is set to the IGP metric. As an example, a router is receiving the 153.254.0.0/16 prefix via a OSPF:
| R2#show ip route 153.254.0.0 255.255.0.0 Routing entry for 153.254.0.0/16 Known via “ospf 2”, distance 110, metric 65, type intra area Last update from 10.0.3.3 on Serial0/1, 00:09:05 ago Routing Descriptor Blocks: * 10.0.3.3, from 3.3.3.3, 00:09:05 ago, via Serial0/1 Route metric is 65, traffic share count is 1 |
In the output above, the prefix has an IGP route metric of 65. When the prefix is injected into R2 using either thenetwork or redistribute command, the MED value reflects the IGP metric:
The next hop address for this prefix is 10.3.3.3. If the same prefix was advertised via BGP using the network command, the NEXT_HOP would be set to the OSPF next hop address by the local router on which the prefix is injected into BGP as illustrated in the following output:
| R2#show ip bgp BGP table version is 6, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 153.254.0.0 10.0.3.3 65 32768 i |
And finally, if the prefix is injected into BGP using the aggregate-address command, i.e. it is a summary prefix; then the MED value is not set. As was stated earlier, BGP summarization will be described in detail in the following chapter.
In regards to the second rule, advertising prefixes to iBGP peers, a BGP speaker will advertise prefixes with the same metric to another iBGP peer. This is illustrated in Figure 6-19:
Fig.6-19. Understanding iBGP default NEXT_HOP behavior
Referencing Figure 6-19, R1 and R2 reside within AS 2. R2 is receiving some routes via EIGRP as verified and illustrated in the following output:
| R1#show ip route eigrp 10.0.0.0/24 is subnetted, 5 subnets D 10.20.20.0 [90/409600] via 192.168.1.5, 00:08:45, FastEthernet0/0 D 10.10.10.0 [90/409600] via 192.168.1.5, 00:08:45, FastEthernet0/0 |
Both EIGRP prefixes have a route metric of 409600. These prefixes are then injected into BGP on R2 using theredistribute eigrp command. Because the routes are received from an IGP, BGP retains the IGP metric and sets that as the MED value. R1 then advertises the prefixes to its iBGP peer, R2. Because this is an iBGP peer relationship, the MED value is unchanged:
| R2#show ip bgp BGP table version is 10, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *>i10.10.10.0/24 192.168.1.5 409600 100 0 ? *>i10.20.20.0/24 192.168.1.5 409600 100 0 ? |
Continuing with this scenario and moving to the third rule, which pertains to the advertising of prefixes to eBGP peers, R2 in turn advertises these received prefixes to eBGP peer R3. By default, if the prefix is learned from an iBGP peer, the edge router (R2) will remove the MED value before advertising the prefix to an eBGP peer. Therefore, the same prefixes that R2 received from R1 with the metric value of 409600, will be advertised to R3, the eBGP peer with no metric value, as illustrated in the following output on R3:
| R3#show ip bgp BGP table version is 6, local router ID is 3.3.3.3 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 10.10.10.0/24 10.0.3.2 0 2 ? *> 10.20.20.0/24 10.0.3.2 0 2 ? |
NOTE: While the MED value is only compared for prefixes received from the same AS, Cisco IOS software does allow MED values to be compared for prefixes received from different ASes using the bgp always-compare-medrouter configuration command. This is beyond the scope of the ROUTE exam requirements and will not be illustrated in this chapter or this guide.
The LOCAL_PREF attribute (Type Code 5)
The LOCAL_PREF attribute is a 32-bit positive integer that defines a preference over one exit point in an AS. This attribute is a well-known discretionary BGP attribute, defined as Attribute Type Code 5. The LOCAL_PREF attribute is used only within an AS for path selection manipulation. If an iBGP speaker receives an UPDATE for the same destination from multiple iBGP peers, it will prefer the path with the highest LOCAL_PREF value.
In Cisco IOS software, the default LOCAL_PREF value is 100; however, this value can be changed to any value between 0 and 4294967295. Influencing path selection using the LOCAL_PREF attribute will be illustrated and described in detail in the following chapter.
The ATOMIC_AGGREGATE and AGGREGATOR attributes (Type Codes 6 and 7)
Both the ATOMIC_AGGREGATE and AGGREGATOR attributes are used when BGP routing information is summarized. The ATOMIC_AGGREGATE is Type Code 6 and is a well-known discretionary attribute. This attribute is used to alert other routers that some BGP attribute information has been lost as a result of route aggregation.
The AGGREGATOR attribute is defined as type code 7 and is an optional, transitive attribute. This attribute type identifies the BGP router that performed the route aggregation. Both attributes will be illustrated in the following chapter when we delve into BGP summarization.
The COMMUNITY attribute (Type Code 8)
The COMMUNITY attribute, Attribute Type Code 8, is an optional transitive attribute that is used to group destinations, called communities. Once the destination prefixes have been grouped, routing decisions, such as acceptance, preference, and redistribution, can be applied. Route maps are used in conjunction with BGP to set the community attribute.
The attribute is encoded as a four-octet value where the first two octets represent an AS number and the remaining two octets represent a locally defined value. There are two types of communities that exist. These two types are:
- Well-known Communities
- Private Communities
Well-known communities are communities that have predefined meanings. Cisco IOS software supports four well-known communities which are:
- NO_EXPORT
- NO_ADVERTISE
- INTERNET
- LOCAL_AS
The NO_EXPORT well-known community prevents BGP prefixes that are specifically assigned this predefined community attribute value from being advertised to any eBGP peers. The prefixes, however, will continue to be advertised to all other BGP speakers within the local AS. In other words, prefixes assigned this community value will remain local to the AS.
The NO_ADVERTISE community prevents any prefixes that are assigned this predefined community attribute from being advertised to any peer – internal or external.
The INTERNET community allows all prefixes assigned to this community to be advertised to any and all BGP peers (assuming no filtering, etc, is in place). In Cisco IOS software, all BGP prefixes belong to the INTERNET community by default.
And finally, the LOCAL_AS community is used in a somewhat similar manner to another of the previously described communities: the NO_EXPORT community. If used in a Confederation, the LOCAL_AS community prevents all prefixes assigned this community from being advertised out of the local sub autonomous system. When Confederations are not implemented, the LOCAL_AS community is applied in the same manner as the NO_EXPORT community.
NOTE: BGP Confederations are described in detail in the following chapter.
Unlike the well-known communities, private communities must be manually defined by the network administrators and actions for prefixes assigned those communities must also be explicitly defined. Private communities are typically configured using the AA:NN format, where AA represents the AS Number and NN is a randomly selected number. The following chapter on advanced BGP implementation includes community configuration examples.
The ORIGINATOR_ID attribute (Type Code 9)
The ORIGINATOR_ID attribute, specified in RFC 4456 as Attribute Type Code 9, is 4 bytes in length and is used to prevent routing loops in iBGP implementations that are using Route Reflectors. A Route Reflector (RR) is a special type of BGP speaker that reflects routes received from client routers to other routers, negating the need to implement a fully meshed iBGP topology. Think of the RR as somewhat being like the DR used in OSPF. Non-DR routers will establish an adjacency only with the DR (and BDR). The DR then updates all other non-DR routers, negating the need for the routers on the multi-access segment to establish an adjacency with every other router on the segment.
Likewise, when an RR is implemented in an iBGP deployment, all non-RR routers, referred to as RR Clients are configured such that they peer only with the RR, or RRs if more than one exists for redundancy. The RR then reflects routing information received from one client to all other clients with which it has an adjacency. This negates the need for iBGP routers to be fully meshed. Route reflection is described further in the following chapter.
Continuing with the discussion on the ORIGINATOR_ID attribute, this attribute should only be received from iBGP peers. The ORIGINATOR_ID is created or set by the RR to the either the address of the iBGP speaker that originated the route within the local AS, or to the address of the iBGP speaker that learned the route via eBGP, i.e. the edge router. The ORIGINATOR_ID is an optional, non-transitive BGP attribute.
The CLUSTER_LIST attribute (Type Code 10)
The CLUSTER_LIST attribute is an optional, non-transitive BGP attribute of Type Code 10. It is a sequence of CLUSTER_ID values representing the reflection path that the prefix has traversed. In other words, this attribute is also used when RRs have been implemented.
When the RR reflects a route, it must prepend the local CLUSTER_ID to the CLUSTER_LIST. If the UPDATE has an empty CLUSTER_LIST, the RR must create a new one. Like the ORIGINATOR_ID attribute, the CLUSTER_LIST attribute is also used for to prevent loops in iBGP implementations. BGP loop prevention is described in the following section.
The Cisco-proprietary WEIGHT attribute
The final BGP attribute we are going to learn about is the Cisco-proprietary WEIGHT attribute. Unlike all other attributes that have been described in the previous sections, the WEIGHT attribute is not an open-standard attribute, but rather a Cisco-proprietary attribute. In other words, this attribute cannot be used on non-Cisco devices.
The WEIGHT attribute is used in a manner similar to the LOCAL_PREF attribute. That is, this attribute is used to define a preference over one exit point in an AS over another. However, unlike the LOCAL_PREF attribute, which is propagated to other routers in the AS, the Cisco WEIGHT attribute is locally significant to the device on which it is configured – much like administrative distance values. This attribute, therefore, does not the routing policy of other neighbor routers, nor will it be sent to other routers.
The WEIGHT is a 4-byte integer between 0 and 65,535. While this attribute is proprietary, it has priority over all other attributes in the BGP path selection process, which is described later in this chapter. By default, all prefixes injected into BGP on the local BGP speaker are assigned a WEIGHT of 32,768. Because this attribute is locally significant, this default value is not set in the UPDATES sent to any other neighbors. In Cisco IOS software, the higher the WEIGHT, the more preferred the path. This is illustrated in detail in the following chapter.
In conclusion, Table 6-6 summarizes the different attributes described in this section, their Type Codes, as well as their category:
| ATTRIBUTE | TYPE CODE | CATEGORY |
| ORIGIN | 1 | Well-known Mandatory |
| AS_PATH | 2 | Well-known Mandatory |
| NEXT_HOP | 3 | Well-known Mandatory |
| MULTI_EXIT_DISC | 4 | Optional, Non-Transitive |
| LOCAL_PREF | 5 | Well-known Discretionary |
| ATOMIC_AGGREGATE | 6 | Well-known Discretionary |
| AGGREGATOR | 7 | Optional, Transitive |
| COMMUNITY | 8 | Optional, Transitive |
| ORIGINATOR_ID | 9 | Optional, Non-Transitive |
| CLUSTER_LIST | 10 | Optional, Non-Transitive |
| WEIGHT | N/A | Proprietary |
Tab.6-6. Summary of BGP Attributes