rfc1364.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 787 行 · 第 1/3 页
TXT
787 行
Network Working Group K. Varadhan
Request for Comments: 1364 OARnet
September 1992
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
Autonomous System Border Routers (ASBR) that will run BGP with other
ASBRs external to the AS and OSPF as its IGP.
Table of Contents
1. Introduction ................................................. 2
2. Route Exchange ............................................... 2
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 ......... 5
4.1. Semantics of the characteristics bits ...................... 7
4.2. Configuration parameters for setting the OSPF tag .......... 8
4.3. Manually configured tags ................................... 9
4.4. Automatically generated tags ................................ 9
4.4.1. Routes with incomplete path information, pl = 0 ........... 9
4.4.2. Routes with incomplete path information, pl = 1 ........... 9
4.4.3. Routes with incomplete path information, pl >= 1 ..........10
4.4.4. Routes with complete path information, pl = 0 .............10
4.4.5. Routes with complete path information, pl = 1 .............11
4.4.6. Routes with complete path information, pl >= 1 ............11
4.5. Miscellaneous tag settings ..................................12
4.6. Summary of the TagType field setting ........................12
5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ....12
6. Security Considerations .......................................13
7. Acknowledgements ..............................................13
8. Bibliography ..................................................14
9. Author's Address ..............................................14
Varadhan [Page 1]
RFC 1364 BGP OSPF Interaction September 1992
1. Introduction
This document defines the various criteria to be used when designing
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."
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.
Varadhan [Page 2]
RFC 1364 BGP OSPF Interaction September 1992
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 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 By default, no routes must be exported from OSPF into
BGP. A single mechanism 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 default to 1.
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 propogate 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
Varadhan [Page 3]
RFC 1364 BGP OSPF Interaction September 1992
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 By default, no routes must be imported from BGP into
OSPF. Administrators must configure every route they
wish to import.
A mechanism 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 IBGP 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
Varadhan [Page 4]
RFC 1364 BGP OSPF Interaction September 1992
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. Consider the scenario in which 3 routers, 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.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?