BGP attributes is an interesting subject of study. BGP is a very flexible and extensible protocol and I like that, let’s see how flexible is that protocol when it comes to attributes handling. We all know that BGP has four types of attributes as listed:
- Well-known mandatory.
- Well-known discretionary.
- Optional transitive.
- Optional non-transitive.
I am not going to explain them in this post, they are explained everywhere over the internet. However, in short well-known attributes must be recognized by all BGP implementations, some of them are mandatory and must be included in all update messages, others are discretionary and may or may not exist in all BGP updates . Optional attributes do not have to be understood by all BGP implementations. Optional attributes are transited to peers or not, based on the setting of the transitive bit as we will show below.
I will focus on how BGP signals and handles these attributes in update messages. BGP path attributes are sent in BGP update messages; every attribute is a triple of variable length [attribute type, attribute length, attribute value ].
Attribute type is a two octet piece of information that consists of an Attribute Flag octet and an Attribute Type code octet. The Attribute type code speaks for itself and it carries the attribute code number for a specific attribute, for example the origin attribute has a type code number of 1 (see the example below).
And because a picture is worth a thousand words, I will start by a wireshark capture and comment on below.
The Attribute Flag:
The first high order bit (from the left) is the optional bit, setting this bit to 1 means the attribute is optional and to 0 defines a well-known attribute. Origin is a well-known mandatory attribute so this bit is set to zero as you can see.
The second high order bit is the transitive bit. It defines whether the attribute is transitive (value=1) or non-transitive (value=0). Well-known attributes are always transitive and therefore their transitive bit is always set to one.
The third bit is the partial bit, it defines whether the information in the optional transitive attribute is partial (value= 1) or complete (value = 0). Well-known and optional non-transitive are always set to complete. The partial bit is set to 1 in the following cases:
- Unrecognized optional transitive attribute that is passed to peers, the sender sets the partial bit.
- Optional transitive attribute attached by some router other than the originator or the route.
The fourth bit is the extended length bit and it defines whether the attribute length is one octet or more. The last four bits are not currently used.
The sender orders path attributes in an ascending order (according to attribute type code) within the update message as shown in the packet capture above.
You might want to review one of the following posts: