Withdrawn Routes

Withdrawn routes provide a list of routing updates that are not feasible, or that are no longer in service and need to be withdrawn (removed) from the BGP routing tables. The withdrawn routes have the same format as the NLRI: an IP address and the number of bits in the IP address counting from left, as illustrated in figure 4-19. Withdrawn routes are also represented by the tuple <length, prefix>. A tuple of the form <18,192.213.134.0> indicates a route to be withdrawn of the form 192.213.134.0 255.255.192.0 or 192.213.134.0/18 in the CIDR format.

Figure 4-19  General form of the Withdrawn Routes field.

The Unfeasible Routes Length is the length in bytes of the total withdrawn routes. An UPDATE message can list multiple routes to be withdrawn at the same time or no routes to be withdrawn. An Unfeasible Routes Length of 0 indicates that no routes are to be withdrawn. On the other hand, an UPDATE message can advertise at most one route, which can be described by multiple path attributes. An UPDATE message that has no NLRI or Path Attribute information is used to advertise only routes to be withdrawn from service.

Path Attributes

The BGP attributes are a set of parameters used to keep track of route-specific information such as path information, degree of preference of a route, next hop value of a route, and aggregation information. These parameters are used in the BGP filtering and route decision process. Every UPDATE message has a variable length sequence of path attributes. A path attribute is a triple of the form <attribute type, attribute length, attribute value> of variable length. The attribute type is a 2-byte field that consists of a 1-byte attribute flags and a 1-byte attribute type code. Figure 4-20 illustrates the general form of the path attribute type field.

Figure 4-20  Path attribute type format.

Path attributes fall under four categories: well-known mandatory, well-known discretionary, optional transitive, and optional nontransitive. These four categories are described by the first two bits of the path attribute flags field.

The first bit of the flags field indicates whether the attribute is optional (1) or well-known (0). The second bit indicates whether the optional attribute is transitive (1) or nontransitive (0). Well-known attributes are always transitive (second bit is always 1). The third bit indicates whether the information in the optional transitive attribute is partial (1) or complete (0). The fourth bit defines whether the attribute length is 1-byte (0) or 2-bytes (1). The other four bits in the flags field are always set to 0.

The following descriptions elaborate on the significance of each attribute category:

•  Well-known mandatory—An attribute that has to exist in the BGP UPDATE packet. It must be recognized by all BGP implementations. If a well-known attribute is missing, a notification error will be generated. This is to make sure that all BGP implementations agree on a standard set of attributes. An example of a well-known mandatory attribute is the AS_path attribute.

•  Well-known discretionary—An attribute that is recognized by all BGP implementations, but may or may not be sent in the BGP UPDATE message. An example of a well-known discretionary attribute is the LOCAL_PREF.

In addition to the well-known attributes, a path can contain one or more optional attributes. Optional attributes are not required to be supported by all BGP implementations. Optional attributes can be transitive or nontransitive.

•  Optional transitive—In case an optional attribute is not recognized by the BGP implementation, that implementation would look for a transitive flag to see whether it is set for that particular attribute. If the flag is set—that is, the attribute is transitive—the BGP implementation should accept the attribute and pass it along to other BGP speakers.

•  Optional nontransitive—When an optional attribute is not recognized and the transitive flag is not set—the attribute is nontransitive—the attribute should be quietly ignored and not passed along to other BGP peers.

The Attribute Type code byte contains the attribute code. Currently, the following attributes are defined:

•  1—ORIGIN (Well-known mandatory, Type code 1)

•  2—AS_path (Well-known mandatory, Type code 2)

•  3—NEXT_HOP (Well-known mandatory, Type code 3)

•  4—MULTI_EXIT_DISC (Optional nontransitive, Type code 4)

•  5—LOCAL_PREF (Well-known discretionary, Type code 5)

•  6—ATOMIC_AGGREGATE (Well-known discretionary, Type code 6)

•  7—AGGREGATOR (Optional transitive, Type code 7)

•  8—COMMUNITY (Optional transitive, Type code 8, Cisco-defined)

•  9—ORIGINATOR_ID (Optional nontransitive, Type code 9, Cisco- defined)

•  10—Cluster List (Optional nontransitive, Type code 10, Cisco-defined)

•  11—Destination Preference (MCI-defined)

•  12—Advertiser (Baynet-defined)

•  13—rcid_path (Baynet-defined)

•  255—Reserved for development

Attributes type 1 to type 10 are discussed in detail in the next chapter. Attributes 11, 12, and 13 are not implemented by Cisco because they do not add additional functionality. These attributes are not covered.