As a precursor to an upcoming blog post on various MPLS PE-CE route exchange techniques, I wanted to touch on a somewhat important topic of BGP Extended Communities Attribute. Especially when it comes to MPLS, it is important to understand extended communities, their function etc. This particular post though, will be about two other things that are very important about this 8 octet value — its structure and how to enforce that structure in IOS and Junos respectively. There are many things that can be written even on this seemingly innocuous topic, but this blog post will be limited in its scope to cater to CCIE/JNCIE candidates.
The Structure and Contents
As a reference throughout the post, we will use the following diagram out of RFC 4360.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type high | Type low(*) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is very beneficial to study any extended community value as if it were a TLV. Notice that there is no length field defined in this structure, not in the traditional TLV sense anyway. The reason it is not needed is because the type field itself will provide all the information that the length field usually provides.
The first two octets of any extended community have no flexibility and always are as follows:
Octet 1 – The Type field (described in RFC 4360 as Type high). The value encoded in this field actually describes the structure/partition of the remaining 6 octets (After Type and Sub-Type octets)
Octet 2 – The Sub-Type field (described in RFC 4360 as Type Low). The value encoded in this field informs the BGP process of the function of the community itself.
So, together, the first two octets of Type and Sub-type inform a machine or a human being of two things:
1. How to partition and read the remaining 6 octets
2. How to interpret the information in the remaining 6 octets
The Defined Type Values
There are 4 important values of Type field that a CCIE/JNCIE candidate should be aware of.
The first three values divide the 6 remaining octets in the Value Field into a defined Global Administrator (GA) Field and Local Administrator (LA) Field. The difference lies in the number of octets allotted to each field and the nature of the value contained in that field. The fourth Type Field value describes a variable structure.
The values are:
1. 0x00 (RFC 4360) – 2-octet AS Specific Extended Community
Global Administrator – 2 octets representing the 2-byte AS number.
Local Administrator – 4 octets populated with a unique value that represents the community
2. 0x01 (RFC 4360) – IPv4 Address Specific Extended Community
Global Administrator – 4 octets representing an IPv4 Address.
Local Administrator – 2 octets populated with a unique value that represents the community
3. 0x02 (RFC 5668) – 4-octet AS Specific BGP Extended Community
Global Administrator – 4 octets but this time representing the 4-byte AS number.
Local Administrator – 2 octets populated with a unique value that represents the community
4. 0x03 (RFC 4360) – Opaque Extended Community
Note: The fourth value, the Opaque Extended Community, is a more flexible structure. The only two defined Octets are 1 and 2. The other 6 octets are essentially just called “Value”. The RFC reads “The value of the sub-type that should define the Value Field is to be assigned by IANA.” Thus, the structure of this type of community may vary from Sub-Type to Sub-Type.
At the Exam
Now for the most important CCIE/JNCIE candidate concern — where may one encounter this on the exam? The two answers that should come immediately to the mind of any well-prepared candidate are Route-Targets and OSPF Domain-IDs.
Before looking at the actual command line, it is useful to look at the community in human friendly form. Any extended community will be generally described in human friendly form as follows: –
<TYPE><SUBTYPE>:<GLOBAL_ADMINISTRATOR>:<LOCAL_ADMINISTRATOR>
The IOS and Junos software accept the values in the same format, though, as is par for the course, they both have their little intricacies involved which make them subtly different.
Note: The maximum possible values for each sub-field of the extended community will be used at the CLI to demonstrate the space division and structure of the various communities more clearly.
For the demonstration, purely for the interests of keeping the post at a manageable length, the Route-Target extended community is used. This is the most relevant extended community for a CCIE/JNCIE candidate and one they are most likely to encounter on the exam. In any case, once one learns the logic of the coding, the concepts can be extrapolated to other extended communities.
The Route-Target Extended Community
The route target community has a Subtype of 0x02 and can have a Type of 0x00, 0x01 and 0x02. Some older versions of IOS/Junos will that do not support 4-byte AS numbers will not have the ability to use Type 0x02. For the sake of clarity and completeness, the IOS/Junos (15.3/12.1) versions used for this blog post have support for the 4-byte AS numbers.
Both IOS and Junos try to decipher the user’s intention by the way the values for the community are entered. Each will, in turn, use the right Type and Sub-type to encode the extended community, depending on the user’s input. This takes the actual coding decision out of user’s hands while still allowing them to influence the coding. Thus, since the user does not have to supply the first two octets, the numerical value entered is for the last 6 octets although we will see Junos has a peculiar behavior to be aware of here.
In IOS the RT value can be configured at two places. For simple policies, the value can be configured inside a VRF. For more complex policies, route-maps can be utilized.
Similarly, the value can be configured at two places in Junos. For simple policies, inside the routing-instance (VRF) and for complex policies, inside a policy-statement.
Type 0x00 Route-Target
For Type 0x00, in either IOS or Junos, simply enter a value between 1 and 65535, a colon(:) and a value between 1 and 4294967295. As the astute will note, these are the ranges for 2-byte and 4-byte numbers respectively.
IOS
R1(config)#ip vrf TEST
R1(config-vrf)#route-target export ?
ASN:nn or IP-address:nn Target VPN Extended Community
R1(config-vrf)#route-target export 655?
ASN:nn or IP-address:nn
R1(config-vrf)#route-target both 65535:4294967296
^
% Invalid input detected at '^' marker.
R1(config-vrf)#route-target both 65535:4294967295
R1(config-vrf)#
First thing to note is that the route-target command is associating a Route-Target extended community with the VRF. The context sensitive help does provide a general clue as to the format of the community. But it does not provide the range of values that each section can fall within. As can be seen, the software initially generates an error for the Local Administrator (LA) value as it exceeds the 4-byte limit that is now imposed on it because of the Global Administrator (GA) value being interpreted as a 2-byte AS number. Only after the LA value is brought inline with the restrictions does the software accept the entry. The value encoded, if a packet dump was collected will be 0x0002FFFFFFFFFFFF.
Junos
[edit routing-instances TEST]
nbhasin@Merlot# set vrf-target 65535:4294967296
error: community: '65535:4294967296': Use format 'target:x:y' where 'x' is an <br>
AS number followed by an optional 'L' (To indicate 4 byte AS), or an IP address <br>
and 'y' is a number. e.g. target:123456L:100
[edit routing-instances TEST]
nbhasin@Merlot# set vrf-target target:65535:4294967296
[edit routing-instances TEST]
nbhasin@Merlot# commit
[edit routing-instances TEST]
'vrf-target'
invalid Extended community value at '4294967296' not in range 1 to 4294967295
error: configuration check-out failed
[edit routing-instances TEST]
nbhasin@Merlot# set vrf-target target:65535:4294967295
[edit routing-instances TEST]
nbhasin@Merlot# commit
commit complete
Once again, more or less the same as IOS except Junos demands that even with the vrf-target command, the user must supply the Sub-Type in the form of the keyword “target”. This was the peculiarity referenced to earlier. Thankfully for the JNCIE candidate, this is explicitly stated in the error message in the bold portion. Ignore the rest of the error message as the post will get to that shortly. And also once again, the LA value had to be brought inline with the range restriction for the software to perform a successful commit.
Type 0x01 Route-Target
Note: For this demonstration, the IOS route-map and Junos policy-statement structures will be utilized.
For Type 0x01, type an IP address in dotted-decimal format, a colon (:), and a value between 1 and 65535. The reasons are the same as the last demonstration.
IOS
R1(config)#route-map TEST
R1(config-route-map)#set extcommunity rt 255.255.255.255:65536
^
% Invalid input detected at '^' marker.
R1(config-route-map)#set extcommunity rt 255.255.255.255:65535
R1(config-route-map)#
Once again, IOS generates an error message if the value after the colon exceeds the 2-bytes it is now restricted to because of the first value being interpreted as a 4-byte IP address.
In Junos, the community is defined as a separate object within the policy-options. The object can then be called inside a policy-statement.
Junos
nbhasin@Merlot# set policy-options community RT_TEST members ?
Possible completions:
Community members
[ Open a set of values
[edit policy-options]
nbhasin@Merlot# set community RT_TEST members target:255.255.255.255:65536
[edit policy-options]
nbhasin@Merlot# commit
[edit policy-options community RT_TEST members]
'target:255.255.255.255:65536'
invalid community value value at '65536' not in range 0 to 65535
error: configuration check-out failed
[edit policy-options]
nbhasin@Merlot# delete community RT_TEST members target:255.255.255.255:65536
[edit policy-options]
nbhasin@Merlot# set community RT_TEST members target:255.255.255.255:65535
[edit policy-options]
nbhasin@Merlot# commit
commit complete
One thing that stands out here for a JNCIE candidate is that they should really try to memorize the keyword “target” (along with other important extended community keywords). As can be (rather cannot be) seen in the context sensitive help, the CLI does not provide the user with this hint. Other than that, the same exact error and remedy as IOS is seen.
Type 0x02 Route-Target
For Type 0x02, the methods are somewhat different in IOS and Junos. IOS is demonstrated first.
For this demonstration, it is important to be familiar with the asdot vs asplain notation for representing the 4-byte AS number described in RFC 5396. In the asdot notation, the 4-byte field is divided into 2 2-byte fields. They are then separated by a “.” If the complete decimal value of the AS is used, the notation is called asplain. There is also asdot+ notation which the reader can read about in RFC 5396.
For IOS, the demonstration is done using asdot notation.
R1(config)#ip vrf TEST
R1(config-vrf)#route-target both 65536.65536:65536
^
% Invalid input detected at '^' marker.
R1(config-vrf)#route-target both 65535.65536:65536
^
% Invalid input detected at '^' marker.
R1(config-vrf)#route-target both 65535.65535:65536
^
% Invalid input detected at '^' marker.
R1(config-vrf)#route-target both 65535.65535:65535
R1(config-vrf)#
Once again, the software imposes range limits on the basis of how it interprets the entry. The interesting thing is how this value is displayed in the configuration by default.
R1(config-vrf)#do sho run | sec ip vrf ip vrf TEST rd 1:1 route-target export 4294967295:65535 route-target import 4294967295:65535 R1(config-vrf)#
The entire 4-byte value is shown as a decimal number or in asplain notation and not in asdot notation. One could have entered those exact commands (as they appear in the configuration) if the need for asdot notation was optional. But if asdot notation is mandatory, it has to be enabled and essentially the BGP process on IOS will have to be instructed to display these values in asdot notation.
R1(config)#router bgp 4294967295 R1(config-router)#bgp asnotation dot R1(config-router)#do sho run | sec ip vrf ip vrf TEST rd 1:1 route-target export 65535.65535:65535 route-target import 65535.65535:65535 R1(config-router)#
One of those detail things that can trip up a CCIE candidate.
On Junos, no special care has to be taken to enter the value in asdot notation.
[edit routing-instances TEST]
nbhasin@Merlot# set vrf-target target:65536.65536:65536
[edit routing-instances TEST]
nbhasin@Merlot# commit
[edit policy-options community RT_TEST members]
'target:65536.65536:65536'
invalid Extended community value value at '65536'
not in range 0 to 65535
error: configuration check-out failed
[edit routing-instances TEST]
nbhasin@Merlot# set vrf-target target:65535.65536:65536
[edit routing-instances TEST]
nbhasin@Merlot# commit
[edit policy-options community RT_TEST members]
'target:65536.65536:65536'
invalid Extended community value value at '65536'
not in range 0 to 65535
error: configuration check-out failed
[edit routing-instances TEST]
nbhasin@Merlot# set vrf-target target:65535.65535:65536
[edit routing-instances TEST]
nbhasin@Merlot# commit
[edit policy-options community RT_TEST members]
'target:65536.65536:65536'
invalid Extended community value value at '65536'
not in range 0 to 65535
error: configuration check-out failed
[edit routing-instances TEST]
nbhasin@Merlot# set vrf-target target:65535.65535:65535
[edit routing-instances TEST]
nbhasin@Merlot# commit
commit complete
Once all the values are within the correct range, the commit is successful. Junos actually is fully aware of the asdot notation without any special commands. This can be seen in the output of the configuration below.
[edit routing-instances TEST]
nbhasin@Merlot# top show routing-instances
TEST {
instance-type vrf;
route-distinguisher 1:1;
vrf-target target:65535.65535:65535;
}
Now, for configuration of asplain notation in Junos, the error message Junos displayed earlier has the instructions.
[edit routing-instances TEST] nbhasin@Merlot# set vrf-target 65535:4294967296 error: community: '65535:4294967296': Use format 'target:x:y' where 'x' is an AS number followed by an optional 'L' (To indicate 4 byte AS), or an IP address and 'y' is a number. e.g. target:123456L:100
While the message helps to identify the format for the entry of the 4-Byte AS in asplain notation, the CLI seems to be using the same format for entry of an IP address in decimal notation and not dotted decimal notation. A CCIE/JNCIE candidate should always get queasy when such an ambiguity presents itself. From a few packet captures and from the Junos official documentation, it seems that Junos will use Type 0x02 and not Type 0x01 if the configuration is carried out with a trailing “L”.
“Note: In Junos OS Release 9.1 and later, you can specify 4-byte AS numbers as defined in RFC 4893, BGP Support for Four-octet AS Number Space, as well as the 2-byte AS numbers that are supported in earlier releases of the Junos OS. In plain-number format, you can configure a value in the range from 1 through 4,294,967,295. To configure a target or origin extended community that includes a 4-byte AS number in the plain-number format, append the letter “L” to the end of number. For example, a target community with the 4-byte AS number 334,324 and an assigned number of 132 is represented as target:334324L:132.
In Junos OS Release 9.2 and later, you can also use AS-dot notation when defining a 4-byte AS number for the target and origin extended communities. Specify two integers joined by a period: 16-bit high-order value in decimal.16-bit low-order value in decimal. For example, the 4-byte AS number represented in plain-number format as 65546 is represented in AS-dot notation as 1.10.”
So, the following configuration set can be used to enter the 4-byte AS in asplain notation.
[edit routing-instances TEST]
nbhasin@Merlot# set vrf-target target:65536L:65535
[edit routing-instances TEST]
nbhasin@Merlot# commit
commit complete
[edit routing-instances TEST]
nbhasin@Merlot# top show routing-instances
TEST {
instance-type vrf;
route-distinguisher 1:1;
vrf-target target:65535L:65535;
}
As visible in the output of the configuration, Junos configuration displays the 4-byte AS value as the user originally programmed it. Furthermore, as can be seen in the output of a configuration snippet below, Junos actually supports both asdot and asplain notations side by side (once the bgp asnotation dot command in IOS is applied, it only supports asdot notation).
nbhasin@Merlot# show policy-options community TEST members [ target:65535.65535:65535 target:65536L:100 ];
In conclusion, there are a plethora of tricky questions that can be concocted using the topics discussed in this post and it really becomes essential to be very familier with these topics and explore options on the CLI that may not have been covered here.
Following resources are invaluable in enhancing one’s understanding of this topic: –
1. RFC 4360
2. RFC 5668
3. JNCIS Study Guide by Joseph M. Soricelli
Excellent article on BGP extended communty. Thanks a lot.
Thanks a lot. Really helpful post !