considered its "primary" Domain Identifier; this MUST be determinable
by configuration. If an OSPF instance has exactly one Domain
Identifier, this is of course its primary Domain Identifier. If an
OSPF instance has more than one Domain Identifier, the NULL Domain
Identifier MUST NOT be one of them.
If a route is installed in a VRF by a particular OSPF instance, the
primary Domain Identifier of that OSPF instance is considered the
route’s Domain Identifier.
Consider a route, R, that is installed in a VRF by OSPF instance I1,
then redistributed into BGP as a VPN-IPv4 route, and then installed
by BGP in another VRF. If R needs to be redistributed into OSPF
instance I2, associated with the latter VRF, the way in which R is
advertised in I2 will depend upon whether R’s Domain Identifier is
one of I2’s Domain Identifiers. If R’s Domain Identifier is not one
of I2’s Domain Identifiers, then, if R is redistributed into I2, R
will be advertised as an AS-external route, no matter what its OSPF
route type is. If, on the other hand, R’s Domain Identifier is one
of I2’s Domain Identifiers, how R is advertised will depend upon R’s
OSPF route type.
If two OSPF instances are in the same OSPF domain, then either:
1. They both have the NULL Domain Identifier, OR
2. Each OSPF instance has the primary Domain Identifier of the
other as one of its own Domain Identifiers.
If two OSPF instances are in different OSPF domains, then either:
3. They both have the NULL Domain Identifier, OR
4. Neither OSPF instance has the Primary Domain Identifier of the
other as one of its own Domain Identifiers.
(Note that if two OSPF instances each have the NULL Domain
Identifier, we cannot tell from the Domain Identifier whether they
are in the same OSPF Domain. If they are in different domains, and
if routes from one are distributed into the other, the routes will
appear as intra-network routes, which may not be what is intended.)
A Domain Identifier is an eight-byte quantity that is a valid BGP
Extended Communities attribute, as specified in Section 4.2.4. If a
particular OSPF instance has a non-NULL Domain Identifier, when
routes from that OSPF instance are distributed by BGP as VPN-IPv4
routes, the routes MUST carry the Domain Identifier Extended
Communities attribute that corresponds to the OSPF instance’s Primary
Domain Identifier. If the OSPF instance’s Domain Identifier is NULL,
the Domain Identifier Extended Communities attribute MAY be omitted
when routes from that OSPF instance are distributed by BGP;
alternatively, a value of the Domain Identifier Extended Communities
attribute that represents NULL (see Section 4.2.4) MAY be carried
with the route.
If the OSPF instances of an OSPF domain are given one or more non-
NULL Domain Identifiers, this procedure allows us to determine
whether a particular OSPF-originated VPN-IPv4 route belongs to the
same domain as a given OSPF instance. We can then determine whether
the route should be redistributed to that OSPF instance as an inter-
area route or as an OSPF AS-external route. Details can be found in
Sections 4.2.4 and 4.2.8.1.
4.2.5. Loop Prevention
4.2.5.1. The DN Bit
When a type 3 LSA is sent from a PE router to a CE router, the DN bit
[OSPF-DN] in the LSA Options field MUST be set. This is used to
ensure that if any CE router sends this type 3 LSA to a PE router,
the PE router will not redistribute it further.
When a PE router needs to distribute to a CE router a route that
comes from a site outside the latter’s OSPF domain, the PE router
presents itself as an ASBR (Autonomous System Border Router), and
distributes the route in a type 5 LSA. The DN bit [OSPF-DN] MUST be
set in these LSAs to ensure that they will be ignored by any other PE
routers that receive them.
There are deployed implementations that do not set the DN bit, but
instead use OSPF route tagging to ensure that a type 5 LSA generated
by a PE router will be ignored by any other PE router that may
receive it. A special OSPF route tag, which we will call the VPN
Route Tag (see Section 4.2.5.2), is used for this purpose. To ensure
backward compatibility, all implementations adhering to this
specification MUST by default support the VPN Route Tag procedures
specified in Sections 4.2.5.2, 4.2.8.1, and 4.2.8.2. When it is no
longer necessary to use the VPN Route Tag in a particular deployment,
its use (both sending and receiving) may be disabled by
configuration.
4.2.5.2. Use of OSPF Route Tags
If a particular VRF in a PE is associated with an instance of OSPF,
then by default it MUST be configured with a special OSPF route tag
value, which we call the VPN Route Tag. By default, this route tag
MUST be included in the Type 5 LSAs that the PE originates (as the
result of receiving a BGP-distributed VPN-IPv4 route, see Section
4.2.8) and sends to any of the attached CEs.
The configuration and inclusion of the VPN Route Tag is required for
backward compatibility with deployed implementations that do not set
the DN bit in type 5 LSAs. The inclusion of the VPN Route Tag may be
disabled by configuration if it has been determined that it is no
longer needed for backward compatibility.
The value of the VPN Route Tag is arbitrary but must be distinct from
any OSPF Route Tag being used within the OSPF domain. Its value MUST
therefore be configurable. If the Autonomous System number of the
VPN backbone is two bytes long, the default value SHOULD be an
automatically computed tag based on that Autonomous System number:
Tag = <Automatic = 1, Complete = 1, PathLength = 01>
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|1| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 _AS number of the VPN Backbone_
If the Autonomous System number is four bytes long, then a Route Tag
value MUST be configured, and it MUST be distinct from any Route Tag
used within the VPN itself.
If a PE router needs to use OSPF to distribute to a CE router a route
that comes from a site outside the CE router’s OSPF domain, the PE
router SHOULD present itself to the CE router as an Autonomous System
Border Router (ASBR) and SHOULD report such routes as AS-external
routes. That is, these PE routers originate Type 5 LSAs reporting
the extra-domain routes as AS-external routes. Each such Type 5 LSA
MUST contain an OSPF route tag whose value is that of the VPN Route
Tag. This tag identifies the route as having come from a PE router.
The VPN Route Tag MUST be used to ensure that a Type 5 LSA originated
by a PE router is not redistributed through the OSPF area to another
PE router.
4.2.5.3. Other Possible Loops
The procedures specified in this document ensure that if routing
information derived from a BGP-distributed VPN-IPv4 route is
distributed into OSPF, it cannot be redistributed back into BGP as a
VPN-IPv4 route, as long as the DN bit and/or VPN route tag is
maintained within the OSPF domain. This does not eliminate all
possible sources of loops. For example, if a BGP VPN-IPv4 route is
distributed into OSPF, then distributed into RIP (where all the
information needed to prevent looping is lost), and then distributed
back into OSPF, then it is possible that it could be distributed back
into BGP as a VPN-IPv4 route, thereby causing a loop.
Therefore, extreme care must be taken if there is any mutual
redistribution of routes between the OSPF domain and any third
routing domain (i.e., not the VPN backbone). If the third routing
domain is a BGP domain (e.g., the public Internet), the ordinary BGP
loop prevention measures will prevent the route from reentering the
OSPF domain.
4.2.6. Handling LSAs from the CE
This section specifies the way in which a PE router handles the OSPF
LSAs it receives from a CE router.
When a PE router receives, from a CE router, any LSA with the DN bit
[OSPF-DN] set, the information from that LSA MUST NOT be used by the
route calculation. If a Type 5 LSA is received from the CE, and if
it has an OSPF route tag value equal to the VPN Route Tag (see
Section 4.2.5.2), then the information from that LSA MUST NOT be used
by the route calculation.
Otherwise, the PE must examine the corresponding VRF. For every
address prefix that was installed in the VRF by one of its associated
OSPF instances, the PE must create a VPN-IPv4 route in BGP. Each
such route will have some of the following Extended Communities
attributes:
- The OSPF Domain Identifier Extended Communities attribute. If
the OSPF instance that installed the route has a non-NULL
primary Domain Identifier, this MUST be present; if that OSPF
instance has only a NULL Domain Identifier, it MAY be omitted.
This attribute is encoded with a two-byte type field, and its
type is 0005, 0105, or 0205. For backward compatibility, the
type 8005 MAY be used as well and is treated as if it were
0005. If the OSPF instance has a NULL Domain Identifier, and
the OSPF Domain Identifier Extended Communities attribute is
present, then the attribute’s value field must be all zeroes,
and its type field may be any of 0005, 0105, 0205, or 8005.
- OSPF Route Type Extended Communities Attribute. This attribute
MUST be present. It is encoded with a two-byte type field, and
its type is 0306. To ensure backward compatibility, the type
8000 SHOULD be accepted as well and treated as if it were type
0306. The remaining six bytes of the Attribute are encoded as
follows:
+-------+-------+-------+-------+-------+-------+
| Area Number | Route |Options|
| | Type | |
+-------+-------+-------+-------+-------+-------+
* Area Number: 4 bytes, encoding a 32-bit area number. For
AS-external routes, the value is 0. A non-zero value
identifies the route as being internal to the OSPF domain,
and as being within the identified area. Area numbers are
relative to a particular OSPF domain.
* OSPF Route Type: 1 byte, encoded as follows:
** 1 or 2 for intra-area routes (depending on whether the
route came from a type 1 or a type 2 LSA).
** 3 for inter-area routes.
** 5 for external routes (area number must be 0).
** 7 for NSSA routes.
Note that the procedures of Section 4.2.8 do not make any
distinction between routes types 1, 2, and 3. If BGP installs
a route of one of these types in the VRF, and if that route is
selected for redistribution into OSPF, it will be advertised by
OSPF in either a type 3 or a type 5 LSA, depending on the
domain identifier.
* Options: 1 byte. Currently, this is only used if the route
type is 5 or 7. Setting the least significant bit in the
field indicates that the route carries a type 2 metric.
- OSPF Router ID Extended Communities Attribute. This OPTIONAL
attribute specifies the OSPF Router ID of the system that is
identified in the BGP Next Hop attribute. More precisely, it
specifies the OSPF Router Id of the PE in the OSPF instance
that installed the route into the VRF from which this route was
exported. This attribute is encoded with a two-byte type
field, and its type is 0107, with the Router ID itself carried
in the first 4 bytes of the value field. The type 8001 SHOULD
be accepted as well, to ensure backward compatibility, and
should be treated as if it were 0107.
- MED (Multi_EXIT_DISC attribute). By default, this SHOULD be
set to the value of the OSPF distance associated with the
route, plus 1.
The intention of all this is the following. OSPF Routes from one
site are converted to BGP, distributed across the VPN backbone, and
possibly converted back to OSPF routes before being distributed into
another site. With these attributes, BGP carries enough information
about the route to enable the route to be converted back into OSPF
"transparently", just as if BGP had not been involved.
Routes that a PE receives in type 4 LSAs MUST NOT be redistributed to
BGP.
The attributes specified above are in addition to any other
attributes that routes must carry in accordance with [VPN].
The Site of Origin attribute, which is usually required by [VPN], is
OPTIONAL for routes that a PE learns from a CE via OSPF.
Use of the Site of Origin attribute would, in the case of a multiply
homed site (i.e., a site attached to several PE routers), prevent an
intra-site route from being reinjected into a site from the VPN
backbone. Such a reinjection would not harm the routing, because the
route via the VPN backbone would be advertised in a type 3 LSA, and
hence would appear to be an inter-area route; the real intra-area
route would be preferred. But unnecessary overhead would be
introduced. On the other hand, if the Site of Origin attribute is
not used, a partitioned site will find itself automatically repaired,
since traffic from one partition to the other will automatically
travel via the VPN backbone. Therefore, the use of a Site of Origin
attribute is optional, so that a trade-off can be made between the
cost of the increased overhead and the value of automatic partition
repair.
4.2.7. Sham Links
This section describes the protocol and procedures necessary for the
support of "Sham Links," as defined herein. Support for sham links
is an OPTIONAL feature of this specification.
4.2.7.1. Intra-Area Routes
Suppose that there are two sites in the same OSPF area. Each site is
attached to a different PE router, and there is also an intra-area
OSPF link connecting the two sites.
It is possible to treat these two sites as a single VPN site that
just happens to be multihomed to the backbone. This is in fact the
simplest thing to do and is perfectly adequate, provided that the
preferred route between the two sites is via the intra-area OSPF link
(a "backdoor link"), rather than via the VPN backbone. There will be
routes between sites that go through the PE routers, but these routes
will appear to be inter-area routes, and OSPF will consider them less
preferable than the intra-area routes through the backdoor link.
If it is desired to have OSPF prefer the routes through the backbone
over the routes through the backdoor link, then the routes through
the backbone must be appear to be intra-area routes. To make a route
through the backbone appear to be an intra-area route, it is
necessary to make it appear as if there is an intra-area link
connecting the two PE routers. This is what we refer to as a "sham
link". (If the two sites attach to the same PE router, this is of
course not necessary.)
A sham link can be thought of as a relation between two VRFs. If two
VRFs are to be connected by a sham link, each VRF must be associated
with a "Sham Link Endpoint Address", a 32-bit IPv4 address that is
treated as an address of the PE router containing that VRF. The Sham
Link Endpoint Address is an address in the VPN’s address space, not
the SP’s address space. The Sham Link Endpoint Address associated
with a VRF MUST be configurable. If the VRF is associated with only
a single OSPF instance, and if the PE’s router id in that OSPF
instance is an IP address, then the Sham Link Endpoint Address MAY
default to that Router ID. If a VRF is associated with several OSPF
instances, each sham link belongs to a single OSPF instance.
For a given OSPF instance, a VRF needs only a single Sham Link
Endpoint Address, no matter how many sham links it has. The Sham
Link Endpoint Address MUST be distributed by BGP as a VPN-IPv4
address whose IPv4 address prefix part is 32 bits long. The Sham
Link Endpoint Address MUST NOT be advertised by OSPF; if there is no
BGP route to the Sham Link Endpoint Address, that address is to
appear unreachable, so that the sham link appears to be down.
4.2.7.2. Creating Sham Links
Sham links are manually configured.
For a sham link to exist between two VRFs, each VRF has to be
configured to create a sham link to the other, where the "other" is
identified by its sham link endpoint address. No more than one sham
link with the same pair of sham link endpoint addresses will ever be
created. This specification does not include procedures for single-
ended manual configuration of the sham link.
Note that sham links may be created for any area, including area 0.
A sham link connecting two VRFs is considered up if and only if a
route to the 32-bit remote endpoint address of the sham link has been
installed in VRF.
The sham link endpoint address MUST NOT be used as the endpoint
address of an OSPF Virtual Link.
4.2.7.3. OSPF Protocol on Sham Links
An OSPF protocol packet sent on a Sham Link from one PE to another
must have as its IP source address the Sham Link Endpoint Address of
the sender, and as its IP destination address the Sham Link Endpoint
Address of the receiver. The packet will travel from one PE router
to the other over the VPN backbone, which means that it can be
expected to traverse multiple hops. As such, its TTL (Time to Live)
field must be set appropriately.
An OSPF protocol packet is regarded as having been received on a
particular sham link if and only if the following three conditions
hold:
- The packet arrives as an MPLS packet, and its MPLS label stack
causes it to be "delivered" to the local sham link endpoint
address.
- The packet’s IP destination address is the local sham link
endpoint address.
- The packet’s IP source address is the remote sham link endpoint
address.
Sham links SHOULD be treated by OSPF as OSPF Demand Circuits. This
means that LSAs will be flooded over them, but periodic refresh
traffic is avoided. Note that, as long as the backdoor link is up,
flooding the LSAs over the sham link serves no purpose. However, if
the backdoor link goes down, OSPF does not have mechanisms enabling
the routers in one site to rapidly flush the LSAs from the other
site. Therefore, it is still necessary to maintain synchronization
among the LSA databases at the two sites, hence the flooding over the
sham link.
The sham link is an unnumbered point-to-point intra-area link and is
advertised as a type 1 link in a type 1 LSA.
The OSPF metric associated with a sham link MUST be configurable (and
there MUST be a configurable default). Whether traffic between the
sites flows via a backdoor link or via the VPN backbone (i.e., via
the sham link) depends on the settings of the OSPF link metrics. The
metrics can be set so that the backdoor link is not used unless
connectivity via the VPN backbone fails, for example.
The default Hello Interval for sham links is 10 seconds, and the
default Router Dead Interval for sham links is 40 seconds.
4.2.7.4. Routing and Forwarding on Sham Links
If a PE determines that the next hop interface for a particular route
is a sham link, then the PE SHOULD NOT redistribute that route into
BGP as a VPN-IPv4 route.
Any other route advertised in an LSA that is transmitted over a sham
link MUST also be redistributed (by the PE flooding the LSA over the
sham link) into BGP. This means that if the preferred (OSPF) route
for a given address prefix has the sham link as its next hop
interface, then there will also be a "corresponding BGP route", for
that same address prefix, installed in the VRF. Per Section 4.1.2,
the OSPF route is preferred. However, when forwarding a packet, if
the preferred route for that packet has the sham link as its next hop
interface, then the packet MUST be forwarded according to the
corresponding BGP route. That is, it will be forwarded as if the
corresponding BGP route had been the preferred route. The
"corresponding BGP route" is always a VPN-IPv4 route; the procedure
for forwarding a packet over a VPN-IPv4 route is described in [VPN].
This same rule applies to any packet whose IP destination address is
the remote endpoint address of a sham link. Such packets MUST be
forwarded according to the corresponding BGP route.
4.2.8. VPN-IPv4 Routes Received via BGP
This section describes how the PE router handles VPN-IPv4 routes
received via BGP.
If a received BGP VPN-IPv4 route is not installed in the VRF, nothing
is reported to the CE. A received route will not be installed into
the VRF if the BGP decision process regards some other route as
preferable. When installed in the VRF, the route appears to be an
IPv4 route.
A BGP route installed in the VRF is not necessarily used for
forwarding. If an OSPF route for the same IPv4 address prefix has
been installed in the VRF, the OSPF route will be used for
forwarding, except in the case where the OSPF route’s next-hop
interface is a sham link.
If a BGP route installed in the VRF is used for forwarding, then the
BGP route is redistributed into OSPF and possibly reported to the CEs
in an OSPF LSA. The sort of LSA, if any, to be generated depends on
various characteristics of the BGP route, as detailed in subsequent
sections of this document.
The procedure for forwarding a packet over a VPN-IPv4 route is
described in [VPN].
In the following, we specify what is reported, in OSPF LSAs, by the
PE to the CE, assuming that the PE is not configured to do any
further summarization or filtering of the routing information before
reporting it to the CE.
When sending an LSA to the CE, it may be necessary to set the DN bit.
See Section 4.2.5.1 for the rules regarding the DN bit.
When sending an LSA to the CE, it may be necessary to set the OSPF
Route Tag. See Section 4.2.5.2 for the rules about setting the OSPF
Route Tag.
When type 5 LSAs are sent, the Forwarding Address is set to 0.
4.2.8.1. External Routes
With respect to a particular OSPF instance associated with a VRF, a
VPN-IPv4 route that is installed in the VRF and then selected as the
preferred route is treated as an External Route if one of the
following conditions holds:
- The route type field of the OSPF Route Type Extended Community