BGP and OSPF: BGP OSPF Interaction
The rules a border router follows when it passes routes between the protocol outside and the protocol inside.
Varadhan, K., "BGP OSPF Interaction", RFC 1403, DOI 10.17487/RFC1403, January 1993, <https://www.rfc-editor.org/info/rfc1403>.
@misc{rfc1403,
series = {Request for Comments},
number = 1403,
howpublished = {RFC 1403},
publisher = {RFC Editor},
doi = {10.17487/RFC1403},
url = {https://www.rfc-editor.org/info/rfc1403},
author = {K. Varadhan},
title = {{BGP OSPF Interaction}},
pagetotal = 17,
year = 1993,
month = jan,
} RFC text
Contents
Network Working Group K. Varadhan
Request for Comments: 1403 OARnet
Obsoletes: 1364 January 1993
BGP OSPF Interaction
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run BGP with other
ASBRs external to the AS and OSPF as its IGP. This is a
republication of RFC 1364 to correct some editorial problems.
Table of Contents
1. Introduction .................................................... 2
2. Route Exchange .................................................. 3
2.1. Exporting OSPF routes into BGP ................................ 3
2.2. Importing BGP routes into OSPF ................................ 4
3. BGP Identifier and OSPF router ID ............................... 5
4. Setting OSPF tags, BGP ORIGIN and AS_PATH attributes ............ 6
4.1. Semantics of the characteristics bits ......................... 8
4.2. Configuration parameters for setting the OSPF tag ............. 9
4.3. Manually configured tags ...................................... 10
4.4. Automatically generated tags .................................. 10
4.4.1. Routes with incomplete path information, PathLength = 0 ..... 10
4.4.2. Routes with incomplete path information, PathLength = 1 ..... 11
4.4.3. Routes with incomplete path information, PathLength >= 1 .... 11
4.4.4. Routes with complete path information, PathLength = 0 ....... 12
4.4.5. Routes with complete path information, PathLength = 1 ....... 12
4.4.6. Routes with complete path information, PathLength >= 1 ...... 13
4.5. Miscellaneous tag settings .................................... 13
4.6. Summary of the TagType field setting .......................... 14
5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 14
6. Security Considerations ......................................... 15
7. Acknowledgements ................................................ 15
8. Bibliography .................................................... 16
9. Author's Address ................................................ 17
1. Introduction
This document defines the various criteria to be used when designing
an Autonomous System Border Routers (ASBR) that will run BGP
[RFC1267] with other ASBRs external to the AS, and OSPF [RFC1247] as
its IGP.
This document defines how the following fields in OSPF and attributes
in BGP are to be set when interfacing between BGP and OSPF at an
ASBR:
OSPF cost and type vs. BGP INTER-AS METRIC
OSPF tag vs. BGP ORIGIN and AS_PATH
OSPF Forwarding Address vs. BGP NEXT_HOP
For a more general treatise on routing and route exchange problems,
please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist.
This document uses the two terms "Autonomous System" and "Routing
Domain". The definitions for the two are below:
The term Autonomous System is the same as is used in the BGP-3 RFC
[RFC1267], given below:
"The use of the term Autonomous System here stresses the fact
that, even when multiple IGPs and metrics are used, the
administration of an AS appears to other ASs to have a single
coherent interior routing plan and presents a consistent picture
of what networks are reachable through it. From the standpoint
of exterior routing, an AS can be viewed as monolithic:
reachability to networks directly connected to the AS must be
equivalent from all border gateways of the AS."
The term Routing Domain was first used in [ROUTE-LEAKING] and is
given below:
"A Routing Domain is a collection of routers which coordinate
their routing knowledge using a single (instance of) a routing
protocol."
This document follows the conventions embodied in the Host
Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST",
"SHOULD", and "MAY" for the various requirements.
2. Route Exchange
This section discusses the constraints that must be met to exchange
routes between an external BGP session with a peer from another AS
and internal OSPF routes.
BGP does not carry subnet information in routing updates. Therefore,
when referring to a subnetted network in the OSPF routing domain, we
consider the equivalent network route in the context of BGP.
Multiple subnet routes for a subnetted network in OSPF are collapsed
into one network route when exported into BGP.
2.1. Exporting OSPF routes into BGP
1. The administrator MUST be able to selectively export OSPF
routes into BGP via an appropriate filter mechanism.
This filter mechanism MUST support such control with the
granularity of a single network.
Additionally, the administrator MUST be able to filter based
on the OSPF tag and the various sub-fields of the OSPF tag.
The settings of the tag and the sub-fields are defined in
section 4 in more detail.
o The default MUST be to export no routes from OSPF into
BGP. A single configuration parameter MUST permit all
OSPF inter-area and intra-area routes to be exported
into BGP.
OSPF external routes of type 1 and type 2 MUST never be
exported into BGP unless they are explicitly configured.
2. When configured to export a network, the ASBR MUST advertise
a network route for a subnetted network, as long as at least
one subnet in the subnetted network is reachable via OSPF.
3. The network administrator MUST be able to statically
configure the BGP attribute INTER-AS METRIC to be used for
any network route.
o By default, the INTER_AS METRIC MUST not be set. This
is because the INTER_AS METRIC is an optional attribute
in BGP.
Explanatory text: The OSPF cost and the BGP INTER-AS METRIC
are of different widths. The OSPF cost is a two level
metric. The BGP INTER-AS METRIC is only an optional non-
transitive attribute. Hence, a more complex BGP INTER-AS
METRIC-OSPF cost mapping scheme is not necessary.
4. When an ASBR is advertising an OSPF route to network Y to
external BGP neighbours and learns that the route has become
unreachable, the ASBR MUST immediately propagate this
information to the external BGP neighbours.
5. An implementation of BGP and OSPF on an ASBR MUST have a
mechanism to set up a minimum amount of time that must elapse
between the learning of a new route via OSPF and subsequent
advertisement of the route via BGP to the external
neighbours.
o The default value for this setting MUST be 0, indicating
that the route is to be advertised to the neighbour BGP
peers instantly.
Note that [RFC1267] mandates a mechanism to dampen the
inbound advertisements from adjacent neighbours.
2.2. Importing BGP routes into OSPF
1. BGP implementations SHOULD allow an AS to control
announcements of BGP-learned routes into OSPF.
Implementations SHOULD support such control with the
granularity of a single network. Implementations SHOULD also
support such control with the granularity of an autonomous
system, where the autonomous system may be either the
autonomous system that originated the route or the autonomous
system that advertised the route to the local system
(adjacent autonomous system).
o The default MUST be to export no routes from BGP into
OSPF. Administrators must configure every route they
wish to import.
A configuration parameter MAY allow an administrator to
configure an ASBR to import all the BGP routes into the
OSPF routing domain.
2. The administrator MUST be able to configure the OSPF cost and
the OSPF metric type of every route imported into OSPF.
o The OSPF cost MUST default to 1; the OSPF metric type
MUST default to type 2.
3. Routes learned via BGP from peers within the same AS MUST not
be imported into OSPF.
4. The ASBR MUST never generate a default route into the OSPF
routing domain unless explicitly configured to do so.
A possible criterion for generating default into an IGP is to
allow the administrator to specify a set of (network route,
AS_PATH, default route cost, default route type) tuples. If
the ASBR learns of the network route for an element of the
set, with the corresponding AS_PATH, then it generates a
default route into the OSPF routing domain, with cost
"default route cost" and type, "default route type". The
lowest cost default route will then be injected into the OSPF
routing domain.
This is the recommended method for originating default routes
in the OSPF routing domain.
3. BGP Identifier and OSPF router ID
The BGP identifier MUST be the same as the OSPF router id at all
times that the router is up.
This characteristic is required for two reasons.
i Synchronisation between OSPF and BGP
Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3,
belong to the same autonomous system.
+-----+
| RT3 |
+-----+
|
Autonomous System running OSPF
/ \
+-----+ +-----+
| RT1 | | RT2 |
+-----+ +-----+
Both RT1 and RT2 have routes to an external network X and
import it into the OSPF routing domain. RT3 is advertising
the route to network X to other external BGP speakers. RT3
must use the OSPF router ID to determine whether it is using
RT1 or RT2 to forward packets to network X and hence build the
correct AS_PATH to advertise to other external speakers.
More precisely, RT3 must determine which ASBR it is using to
reach network X by matching the OSPF router ID for its route
to network X with the BGP Identifier of one of the ASBRs, and
use the corresponding route for further advertisement to
external BGP peers.
ii It will be convenient for the network administrator looking at
an ASBR to correlate different BGP and OSPF routes based on
the identifier.
4. Setting OSPF tags, BGP ORIGIN and AS_PATH attributes
The OSPF external route tag is a "32-bit field attached to each
external route . . . It may be used to communicate information
between AS boundary routers; the precise nature of such information
is outside the scope of [the] specification." [RFC1247]
OSPF imports information from various routing protocols at all its
ASBRs. In some instances, it is possible to use protocols other than
EGP or BGP across autonomous systems. It is important, in BGP, to
differentiate between routes that are external to the OSPF routing
domain but must be considered internal to the AS, as opposed to
routes that are external to the AS.
Routes that are internal to the AS and that may or may not be
external to the OSPF routing domain will not come to the various BGP
speakers from other BGP speakers within the same autonomous system
via BGP. Therefore, ASBRs running BGP must have knowledge of this
class of routes so that they can advertise these routes to the
various external AS without waiting for BGP updates from other BGP
speakers within the same autonomous system about these routes.
Additionally, in the specific instance of an AS intermixing routers
running EGP and BGP as exterior gateway routing protocols and using
OSPF as an IGP, then within the autonomous system, it may not be
necessary to run BGP with every ASBR running EGP and not running BGP,
if this information can be carried in the OSPF tag field.
We use the external route tag field in OSPF to intelligently set the
ORIGIN and AS_PATH attributes in BGP. Both the ORIGIN and AS_PATH
attributes are well-known, mandatory attributes in BGP. The exact
mechanism for setting the tags is defined below.
The tag is broken up into sub-fields shown below. The various sub-
fields specify the characteristics of the route imported into the
OSPF routing domain.
The high bit of the OSPF tag is known as the "Automatic" bit. When
this bit is set to 1, the following sub-fields apply:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|a|c|p l| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a is 1 bit called the Automatic bit, indicating that the
Completeness and PathLength bits have been generated
automatically by a router. The meaning of this characteristic
and its setting are defined below.
c is 1 bit of Completeness information. The meaning of this
characteristic and its settings are defined below.
pl are 2 bits of PathLength information. The meaning of this
characteristic and its setting are defined below.
ArbitraryTag
is 12 bits of tag information, which defaults to 0 but can be
configured to anything else.
AutonomousSystem (or ``AS'')
is 16 bits, indicating the AS number corresponding to the
route, 0 if the route is to be considered as part of the local
AS.
local_AS
The term `local_AS' refers to the AS number of the local
OSPF routing domain.
next_hop_AS
`next_hop_AS' refers to the AS number of an external BGP
peer.
When the Automatic bit is set to 0, the following sub-fields apply:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|a| LocalInfo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a is 1 bit called the Automatic bit, set to 0.
LocalInfo
is 31 bits of an arbitrary value, manually configured by the
network administrator.
The format of the tag for various values of the characteristics
bits is defined below.
4.1. Semantics of the characteristics bits
The Completeness and PathLength characteristics bits define the
characteristic of the route imported into OSPF from other ASBRs in
the autonomous system. This setting is then used to set the
ORIGIN and NEXT_HOP attributes when re-exporting these routes to
an external BGP speaker.
o The Automatic characteristic bit is set when the Completeness
and PathLength characteristics bits are automatically set by
a border router.
For backward compatibility, the Automatic bit must default to
0 and the network administrator must have a mechanism to
enable automatic tag generation. Nothing must be inferred
about the characteristics of the OSPF route from the tag
bits, unless the tag has been automatically generated.
o The Completeness characteristic bit is set when the source of
the incoming route is known precisely, for instance, from an
IGP within the local autonomous system or EGP at one of the
autonomous system's boundaries. It refers to the status of
the path information carried by the routing protocol.
o The PathLength characteristic sub-field is set depending on
the length of the AS_PATH that the protocol could have
carried when importing the route into the OSPF routing
domain. The length bits will indicate whether the AS_PATH
attribute for the length is zero, one, or greater than one.
Routes imported from an IGP will usually have an AS_PATH of
length of 0, routes imported from an EGP will have an AS_PATH
of length 1, BGP and routing protocols that support complete
path information, either as AS_PATHs or routing domain paths,
will indicate a path greater than 1.
The OSPF tag is not wide enough to carry path information
about routes that have an associated PathLength greater than
one. Path information about these routes will have to be
carried via BGP to other ASBRs within the same AS. Such
routes must not be exported from OSPF into BGP.
4.2. Configuration parameters for setting the OSPF tag
o There MUST be a mechanism to enable automatic generation of
the tag characteristic bits.
o Configuration of an ASBR running OSPF MUST include the
capability to associate a tag value, for the ArbitraryTag, or
LocalInfo sub-field of the OSPF tag, with each instance of a
routing protocol.
o Configuration of an ASBR running OSPF MUST include the
capability to associate an AS number with each instance of a
routing protocol.
Associating an AS number with an instance of an IGP is
equivalent to flagging those set of routes imported from the
IGP to be external routes outside the local autonomous
system.
Specifically, when the IGP is RIP [RFC1058, RFC1388], it
SHOULD be possible to associate a tag and/or an AS number
with every interface running RIP on the ASBR.
4.3. Manually configured tags
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| LocalInfo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This tag setting corresponds to the administrator manually setting
the tag bits. Nothing MUST be inferred about the characteristics
of the route corresponding to this tag setting.
For backward compatibility with existing implementations of OSPF
currently deployed in the field, this MUST be the default setting
for importing routes into the OSPF routing domain. There MUST be
a mechanism to enable automatic tag generation for imported
routes.
The OSPF tag to BGP attribute mappings for these routes MUST be
Automatic=0, LocalInfo=Arbitrary_Value =>
ORIGIN=<INCOMPLETE>, AS_PATH=<local_AS>
4.4. Automatically generated tags
4.4.1. Routes with incomplete path information, PathLength = 0.
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|0|0|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are routes imported from routing protocols with
incomplete path information and cannot or may not carry the
neighbour AS or AS path as part of the routing information.
The OSPF tag to BGP attribute mappings for these routes MUST be
Automatic=1, Completeness=0, PathLength=00, AS=0 =>
ORIGIN=<EGP>, AS_PATH=<local_AS>
4.4.2 Routes with incomplete path information, PathLength = 1.
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|0|0|1| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are routes imported from routing protocols with
incomplete path information. The neighbour AS is carried in
the routing information.
The OSPF tag to BGP attribute mappings for these routes MUST be
Automatic=1, Completeness=0, PathLength=01, AS=<next_hop_AS>
=> ORIGIN=<EGP>, AS_PATH=<local_AS, next_hop_AS>
This setting SHOULD be used for importing EGP routes into the
OSPF routing domain. This setting MAY also be used when
importing BGP routes whose ORIGIN=<EGP> and
AS_PATH=<next_hop_AS>; if the BGP learned route has no other
transitive attributes, then its propagation via BGP to ASBRs
internal to the AS MAY be suppressed.
4.4.3. Routes with incomplete path information, PathLength >= 1.
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|0|1|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are routes imported from routing protocols with truncated
path information.
The OSPF tag to BGP attribute mappings for these routes MUST be
Automatic=1, Completeness=0, PathLength=10, AS=don't care
These are imported by a border router, which is running BGP to
a stub domain, and not running BGP to other ASBRs in the same
AS. This causes a truncation of the AS_PATH. These routes
MUST not be re-exported into BGP at another ASBR.
4.4.4. Routes with complete path information, PathLength = 0.
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|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are routes imported from routing protocols with either
complete path information or are known to be complete through
means other than that carried by the routing protocol.
The OSPF tag to BGP attribute mappings for these routes MUST be
Automatic=1, Completeness=1, PathLength=00, AS=0
=> ORIGIN=<EGP>, AS_PATH=<local_AS>
This SHOULD be used for importing routes into OSPF from an IGP.
4.4.5. Routes with complete path information, PathLength = 1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are routes imported from routing protocols with either
complete path information, or are known to be complete through
means other than that carried by the routing protocol. The
routing protocol also has additional information about the
neighbour AS of the route.
The OSPF tag to BGP attribute mappings for these routes MUST be
Automatic=1, Completeness=1, PathLength=01, AS=next_hop_AS
=> ORIGIN=<IGP>, AS_PATH=<local_AS, next_hop_AS>
This setting SHOULD be used when the administrator explicitly
associates an AS number with an instance of an IGP. This
setting MAY also be used when importing BGP routes whose
ORIGIN=<IGP> and AS_PATH=<next_hop_AS>; if the BGP learned
route has no other transitive attributes, then its propagation
via BGP to other ASBRs internal to the AS MAY be suppressed.
4.4.6. Routes with complete path information, PathLength >= 1.
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|1|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are routes imported from routing protocols with complete
path information and carry the AS path information as part of
the routing information.
The OSPF tag MUST be set to
Automatic=1, Completeness=1, PathLength=10, AS=don't care
These routes MUST not be exported into BGP because these routes
are already imported from BGP into the OSPF RD. Hence, it is
assumed that the BGP speaker will convey this information to
other BGP speakers within the same AS via BGP. An ASBR
learning of such a route MUST wait for the BGP update from its
internal neighbours before advertising this route to external
BGP peers.
Note that an implementation MAY import BGP routes with a path
length of 1 and no other transitive attributes directly into
OSPF and not send these routes via BGP to ASBRs within the same
AS. In this situation, it MUST use tag settings corresponding
to 4.4.2, or 4.4.5.
4.5. Miscellaneous tag settings
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|x|1|1| Reserved for future use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of PathLength=11 is reserved during automatic tag
generation. Routers MUST not generate such a tag when importing
routes into the OSPF routing domain. ASBRs MUST ignore tags which
indicate a PathLength=11.
4.6. Summary of the tag sub-field setting
The following table summarises the various combinations of
automatic tag settings for the Completeness and PathLength sub-
field of the OSPF tag and the default behaviour permitted for each
setting.
Completeness := 0 | 1
PathLength := 00 | 01 | 10 | 11
ORIGIN := <INCOMPLETE> | <IGP> | <EGP>
AS_PATH := valid AS path settings as defined in BGP
PathLength ==> 00 01 10 11
Completeness
|| +--------------------------------------------------------------
vv |
= NO | <EGP> <EGP> never export reserved
| <local_AS> <local_AS,next_hop_AS>
|
= YES | <IGP> <IGP> out of band reserved
| <local_AS> <local_AS,next_hop_AS>
|
The "out of band" in the table above implies that OSPF will not be
able to carry everything that BGP needs in its routing
information. Therefore, some other means must be found to carry
this information. In BGP, this is done by running BGP to other
ASBRs within the same AS.
5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute
Forwarding addresses are used to avoid extra hops between multiple
routers that share a common network and that speak different routing
protocols with each other.
Both BGP and OSPF have equivalents of forwarding addresses. In BGP,
the NEXT_HOP attribute is a well-known, mandatory attribute. OSPF
has a Forwarding address field. We will discuss how these are to be
filled in various situations.
Consider the 4 router situation below:
RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another.
RT1 and RT3 are talking BGP with each other.
RT3 and RT4 are talking OSPF with each other.
+-----+ +-----+
| RT1 | | RT2 |
+-----+ +-----+
| | common network
---+-----------------------+--------------------------
<BGP> | |
+-----+ <OSPF> +-----+
| RT3 | | RT4 |
+-----+ +-----+
- Importing network X to OSPF:
Consider an external network X, learnt via BGP from RT1.
RT3 MUST always fill the OSPF Forwarding Address with the BGP
NEXT_HOP attribute for the route to network X.
- Exporting network Y to BGP:
Consider a network Y, internal to the OSPF routing domain,
RT3's route to network Y is via RT4, and network Y is to be
exported via BGP to RT1.
If network Y is not a subnetted network, RT3 MUST fill the
NEXT_HOP attribute for network Y with the address of RT4.
This is to avoid requiring packets to take an extra hop
through RT3 when traversing the AS boundary. This is similar
to the concept of indirect neighbour support in EGP [RFC888,
RFC827].
6. Security Considerations
Security issues are not discussed in this memo.
7. Acknowledgements
I would like to thank Yakov Rekhter, Jeff Honig, John Moy, Tony Li,
Dennis Ferguson, and Phil Almquist for their help and suggestions in
writing this document, without which I could not have written this
document. I would also like to thank them for giving me the
opportunity to write this document, and putting up with my
muddlements through various phases of this document.
I would also like to thank the countless number of people from the
OSPF and BGP working groups who have offered numerous suggestions and
comments on the different stages of this document.
Thanks also to Bob Braden, who went through the document thoroughly,
and came back with questions and comments, which were very useful.
These suggestions have also been carried over into the next version
of this document for dealing with BGP 4 and OSPF.
8. Bibliography
[RFC827] Rosen, E., "Exterior Gateway Protocol (EGP)", RFC 827,
BBN, October 1982.
[RFC888] Seamonson, L., and E. Rosen, "STUB Exterior Gateway
Protocol", RFC 888, BBN, January 1984.
[RFC1058] Hedrick, C., "Routing Information Protocol", STD 34,
RFC 1058, Rutgers University, June 1988.
[RFC1388] Malkin, G., "RIP Version 2 - Carrying Additional
Information", RFC 1388, Xylogics, Inc., January 1993.
[RFC1122] Braden, R., Editor, "Requirements for Internet Hosts -
Communication Layers, STD 3, RFC 1122,
USC/Information Sciences Institute, October 1989.
[RFC1123] Braden, R., Editor, "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
USC/Information Sciences Institute, October 1989.
[RFC1267] Lougheed, K., and Y. Rekhter, "A Border Gateway
Protocol 3 (BGP-3)", RFC 1267, cisco Systems,
T.J. Watson Research Center, IBM Corp., October 1991.
[RFC1268] Rekhter, Y., and P. Gross, Editors, "Application of the
Border Gateway Protocol in the Internet", RFC 1268,
T.J. Watson Research Center, IBM Corp., ANS, October 1991.
[RFC1247] Moy, J., "The OSPF Specification - Version 2:", RFC 1247,
Proteon, January 1991.
[ROUTE-LEAKING] Almquist, P., "Ruminations on Route Leaking",
Work in Progress.
[NEXT-HOP] Almquist, P., "Ruminations on the Next Hop",
Work in Progress.
9. Author's Address:
Kannan Varadhan
Internet Engineer, OARnet,
1224, Kinnear Road,
Columbus, OH 43212-1136.
Phone: (614) 292-4137
Email: kannan@oar.net
ISO Plain Language
On this page
§1What This Document Decides
The document defines the criteria to be used when designing an Autonomous System Border Router that will run BGP with other border routers external to the autonomous system, and OSPF as its interior gateway protocol. It defines how three pairs of fields and attributes are to be set when the two protocols meet at a border router: the OSPF cost and type against the BGP INTER-AS METRIC, the OSPF tag against the BGP ORIGIN and AS_PATH attributes, and the OSPF Forwarding Address against the BGP NEXT_HOP attribute.
The document uses two terms. An Autonomous System is the term used in the BGP specification, where the use of the term stresses that, even when multiple interior protocols and metrics are used, the administration of an autonomous system appears to other autonomous systems to have a single coherent interior routing plan and presents a consistent picture of what networks are reachable through it. From the standpoint of exterior routing, an autonomous system can be viewed as monolithic, so reachability to networks directly connected to it must be equivalent from all its border routers. A Routing Domain is a collection of routers which coordinate their routing knowledge using a single instance of a routing protocol.
The memo is a republication of RFC 1364 with some editorial problems corrected, and it follows the conventions of the Host Requirements RFCs when using the words MUST, SHOULD and MAY.
At the edge of a network, an outside protocol and an inside protocol have to agree on what a route means. This RFC sets out the three places where they have to line up: the cost, the path information, and the next hop.
§2Exporting and Importing Routes
BGP does not carry subnet information in routing updates, so when a subnetted network in the OSPF routing domain is referred to in BGP, the equivalent network route is used, and multiple subnet routes are collapsed into one network route when exported into BGP.
For exporting OSPF routes into BGP, the administrator must be able to export routes selectively through a filter mechanism that supports control down to a single network, and must be able to filter on the OSPF tag and its sub-fields. The default must be to export no routes from OSPF into BGP, while a single configuration parameter must permit all OSPF inter-area and intra-area routes to be exported. OSPF external routes of type 1 and type 2 must never be exported into BGP unless they are explicitly configured. When configured to export a network, the border router must advertise a network route for a subnetted network as long as at least one subnet in it is reachable via OSPF.
The network administrator must be able to configure the BGP INTER-AS METRIC statically for any network route, and by default it must not be set, because it is an optional attribute in BGP. The reason is that the two metrics are of different widths: the OSPF cost is a two level metric while the BGP INTER-AS METRIC is only an optional non-transitive attribute, so a more complex mapping between them is not necessary. When a route advertised to external BGP neighbours becomes unreachable, the information must be propagated to those neighbours immediately. An implementation must also have a mechanism setting a minimum time between learning a route via OSPF and advertising it via BGP; the default value is 0, meaning the route is advertised instantly.
For importing BGP routes into OSPF, implementations should allow an autonomous system to control the announcements of BGP-learned routes, with control down to a single network and also to an autonomous system, either the one that originated the route or the adjacent one that advertised it. The default must be to export no routes from BGP into OSPF, so administrators must configure every route they wish to import, though a configuration parameter may allow all BGP routes to be imported. The administrator must be able to configure the OSPF cost and metric type of every imported route; the cost must default to 1 and the metric type to type 2.
Routes learned via BGP from peers within the same autonomous system must not be imported into OSPF, and the border router must never generate a default route into the OSPF routing domain unless explicitly configured to do so. The recommended method for originating default routes is to let the administrator specify a set of network route, AS_PATH, default route cost and default route type tuples: if the router learns of the network route for an element of the set with the corresponding AS_PATH, it generates a default route into the OSPF routing domain with that cost and type, and the lowest cost default route is the one injected.
Nothing crosses the boundary unless the administrator asks for it. When something does cross, the inside cost and type can be set by hand, and the outside metric is usually left unset because it means something different on each side.
§3The BGP Identifier and the OSPF Router ID
The BGP identifier must be the same as the OSPF router ID at all times that the router is up, and the document gives two reasons for this.
The first is synchronisation between OSPF and BGP. Consider three border routers, RT1, RT2 and RT3, in the same autonomous system running OSPF. Both RT1 and RT2 have routes to an external network X and import it into the OSPF routing domain, while RT3 advertises the route to network X to other external BGP speakers. RT3 must use the OSPF router ID to determine whether it is using RT1 or RT2 to forward packets to network X, and hence build the correct AS_PATH to advertise to external speakers. More precisely, RT3 must determine which border router it is using to reach network X by matching the OSPF router ID for its route to network X with the BGP identifier of one of the border routers, and use the corresponding route for further advertisement to external peers.
The second reason is convenience: it is convenient for the network administrator looking at a border router to correlate different BGP and OSPF routes based on the identifier.
Give the router one number and use it for both protocols. Then a router that has to advertise a route to the outside can work out which of its internal neighbours will actually carry the traffic.
§4The OSPF Tag and the BGP Path Attributes
The OSPF external route tag is a 32-bit field attached to each external route, which may be used to communicate information between autonomous system boundary routers. OSPF imports information from various routing protocols at all its border routers, and in some instances it is possible to use protocols other than EGP or BGP across autonomous systems. It is important in BGP to differentiate between routes that are external to the OSPF routing domain but must be considered internal to the autonomous system, and routes that are external to the autonomous system. Routes that are internal to the autonomous system and that may or may not be external to the OSPF routing domain will not come to the various BGP speakers from other BGP speakers within the same autonomous system via BGP, so border routers running BGP must have knowledge of this class of routes in order to advertise them to external autonomous systems without waiting for BGP updates from other speakers inside the same autonomous system.
The document uses the external route tag field in OSPF to set the ORIGIN and AS_PATH attributes in BGP intelligently. Both are well-known, mandatory attributes in BGP. When the Automatic bit of the tag is set to 1, the tag holds a Completeness bit, a two-bit PathLength field, 12 bits of ArbitraryTag that default to 0, and 16 bits holding the autonomous system number of the route, which is 0 if the route is to be considered part of the local autonomous system. When the Automatic bit is 0, the remaining 31 bits are LocalInfo, an arbitrary value configured by the network administrator.
The Completeness bit is set when the source of the incoming route is known precisely, for instance from an interior protocol inside the local autonomous system or from EGP at one of the boundaries, and it refers to the status of the path information carried by the routing protocol. The PathLength field says whether the AS_PATH the protocol could have carried was of length zero, one, or greater than one: routes imported from an interior protocol usually have an AS_PATH of length 0, routes imported from EGP have one of length 1, and protocols that support complete path information indicate a path greater than one.
The OSPF tag is not wide enough to carry path information about routes with a path length greater than one, so that information has to be carried by BGP to the other border routers inside the same autonomous system, and such routes must not be exported from OSPF into BGP. The Automatic bit must default to 0 for backward compatibility, and nothing may be inferred about the characteristics of an OSPF route from the tag bits unless the tag was automatically generated. The value PathLength 11 is reserved, and routers must not generate such a tag; border routers must ignore tags that indicate it.
When a route comes in from outside, the inside protocol has nowhere to put the path information, so the tag field carries a summary of it instead. Three small bits in the tag say whether the path is known exactly, and how long it was, which is enough to rebuild the origin and the path when the route goes back out.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
AUTOMATIC | Automatic | 1 bits | Set to 1 when the router generated the other sub-fields itself. | |
COMPLETENESS | Completeness | 1 bits | Set when the source of the incoming route is known precisely. | |
PATH-LENGTH | PathLength | 2 bits | Whether the AS_PATH could have carried was of length zero, one, or greater than one; 11 is reserved. | |
ARBITRARY-TAG | ArbitraryTag | 12 bits | Twelve bits of tag information, defaulting to 0 but configurable. | |
AS | AutonomousSystem | 2 bytes | The AS number of the route, or 0 if the route is part of the local autonomous system. |
| Completeness | PathLength 00 | PathLength 01 | PathLength 10 | PathLength 11 |
|---|---|---|---|---|
| No | ORIGIN EGP, AS_PATH local_AS | ORIGIN EGP, AS_PATH local_AS and next_hop_AS | Never export | Reserved |
| Yes | ORIGIN IGP, AS_PATH local_AS | ORIGIN IGP, AS_PATH local_AS and next_hop_AS | Out of band | Reserved |
§5Forwarding Address and the NEXT_HOP Attribute
Forwarding addresses are used to avoid extra hops between multiple routers that share a common network and that speak different routing protocols with each other. Both BGP and OSPF have equivalents of forwarding addresses: in BGP it is the NEXT_HOP attribute, a well-known and mandatory attribute, and in OSPF it is a Forwarding address field.
The document works through a four-router situation. RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another, RT1 and RT3 speak BGP with each other, and RT3 and RT4 speak OSPF with each other, with RT1 and RT2 on a common network with the other two.
For importing a network X that was learnt via BGP from RT1, RT3 must always fill the OSPF Forwarding Address with the BGP NEXT_HOP attribute for the route to network X. For exporting a network Y that is internal to the OSPF routing domain, where RT3's route to network Y is via RT4 and network Y is to be exported via BGP to RT1, if network Y is not a subnetted network RT3 must fill the NEXT_HOP attribute for network Y with the address of RT4. That is to avoid requiring packets to take an extra hop through RT3 when traversing the autonomous system boundary, and it is similar to the concept of indirect neighbour support in EGP.
When a route is passed on, the next hop is written as the router that will really forward the packets, not as the router that learned the route. That saves a pointless detour across the boundary.
§6Security Considerations
The memo says in one line that security issues are not discussed in it. What it does contain are the administrative safeguards that surround the exchange: routes are only exported or imported when the administrator configures them, the default in both directions is to exchange nothing, and routes whose path information is too long for the tag field must not be exported from OSPF into BGP at all, because the information would be lost.
The RFC says nothing about security. Its own protections are administrative: nothing crosses the boundary by accident.