While studying L3VPN Intra-AS, I had a reflection about the use of Route Targets (RTs)
In many configurations, we simply say:
“We configure the RTs to import and export routes between VRFs,”
but we rarely take the time to analyze how they are structured at the protocol level and why they behave the way they do.
To understand this properly, we need to go to the foundation:
RFC 4360 – BGP Extended Communities Attribute: RFC4360
This RFC defines Route Targets as a sub-type of the Extended Community attribute, identified by Type Code 0x10 (decimal 16).
Within this extended type, the most significant Type field defines how the RT is encoded. Sub-Type 0x02 is reserved for Route Targets and can be encoded in three formats:
0x00 → AS2:nn → 2-byte ASN followed by a 4-byte number
0x01 → IPv4:nn → 4-byte IPv4 address followed by a 2-byte number
0x02 → AS4:nn → 4-byte ASN followed by a 2-byte number
This flexibility allows RTs to be encoded according to the design needs and scalability of the BGP/MPLS domain.
Why is this relevant in Intra-AS environments?
Ensures unique and scalable RT identification within a single AS
Helps avoid overlap/conflicts when reusing values across formats
Enables precise import/export policies between VRFs
Critical for PE routers to propagate VPNv4 routes correctly using RTs
As RFC 4360 states:
"The BGP Extended Communities attribute provides a mechanism for tagging routes with information that can be used for policy decisions."
I’m sharing this insight as part of my deeper dive into design and architecture, combining theory with real-world lab testing.
I hope it helps other engineers on a similar path.
Daniel Fonque
