rfc1105.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 955 行 · 第 1/3 页
TXT
955 行
If one of the Direction fields in the AS route list is not defined, a
BGP NOTIFICATION message is with subcode 2 (invalid direction code).
If one of the AS Number fields in the AS route list is incorrect, a
BGP NOTIFICATION message is sent with subcode 3 (invalid autonomous
system).
If either a EGP_LINK or a INCOMPLETE_LINK link type occurs at other
than the end of the AS path, a BGP NOTIFICATION message is sent with
subcode 4 (EGP_LINK or INCOMPLETE_LINK link type at other than the
end of the AS path list).
If none of the above tests failed, the full AS route is checked for
AS loops.
AS loop detection is done by scanning the full AS route and checking
that each AS in this route occurs only once. If an AS loop is
detected, a BGP NOTIFICATION message is sent with subcode 5 (routing
loop).
If any of the above errors are detected, no further processing is
done. Otherwise, the complete AS path is correct and the rest of the
UPDATE message is processed.
If the Net Count field is incorrect, a BGP NOTIFICATION message is
sent with subcode 7 (invalid Net Count field).
Each network and metric pair listed in the BGP UPDATE message is
checked for a valid network number. If the Network field is
incorrect, a BGP Notification message is sent with subcode 8 (invalid
network field). No checking is done on the metric field. It is up
Lougheed & Rekhter [Page 12]
RFC 1105 BGP June 1989
to a particular implementation to decide whether to continue
processing or terminate it upon the first incorrect network.
If the network, its complete AS path, and the gateway are correct,
then the route is compared with other routes to the same network. If
the new route is better than the current one, then it is flooded to
other BGP peers as follows:
- If the BGP UPDATE was received over the INTERNAL link, it is not
propagated over any other INTERNAL link. This restriction is
due to the fact that all BGP gateways within a single AS
form a completely connected graph (see above).
- Before sending a BGP UPDATE message over the non-INTERNAL links,
check the AS path to insure that doing so would not cause a
routing loop. The BGP UPDATE message is then propagated (subject
to the local policy restrictions) over any of the non-INTERNAL
link of a routing loop would not result.
- If the BGP UPDATE message is propagated over a non-INTERNAL link,
then the current AS number and link type of the link over which
it is going to be propagated is prepended to the full AS path
and the AS count field is incremented by 1. If the BGP UPDATE
message is propagated over an INTERNAL link, then the full AS
path passed unmodified and the AS count stays the same. The
Gateway field is replaced with the sender's own address.
6. Acknowledgements
We would like to express our thanks to Len Bosack (cisco Systems),
Jeff Honig (Cornell University) and all members of the IWG task force
for their contributions to this document.
Lougheed & Rekhter [Page 13]
RFC 1105 BGP June 1989
Appendix 1
BGP FSM State Transitions and Actions.
This Appendix discusses the transitions between states in the BGP FSM
in response to BGP events. The following is the list of these states
and events.
BGP States:
1 - BGP_Idle
2 - BGP_Active
3 - BGP_OpenSent
4 - BGP_OpenConfirm
5 - BGP_Established
BGP Events:
1 - BGP Start
2 - BGP Transport connection open
3 - BGP Transport connection closed
4 - BGP Transport connection open failed
5 - Receive OPEN message
6 - Receive OPEN CONFIRM message
7 - Receive KEEPALIVE message
8 - Receive UPDATE messages
9 - Receive NOTIFICATION message
10 - Holdtime timer expired
11 - KeepAlive timer expired
12 - Receive CEASE message
13 - BGP Stop
The following table describes the state transitions of the BGP FSM
and the actions triggered by these transitions.
Lougheed & Rekhter [Page 14]
RFC 1105 BGP June 1989
Event Actions Message Sent Next State
--------------------------------------------------------------------
BGP_Idle (1)
1 Initialize resources none 2
BGP_Active (2)
2 Initialize resources OPEN 3
4 none none 2
13 Release resources none 1
BGP_OpenSent(3)
3 none none 1
5 Process OPEN is OK OPEN CONFIRM 4
Process OPEN Message failed NOTIFICATION 1
11 Restart KeepAlive timer KEEPALIVE 3
13 Release resources none 1
BGP_OpenConfirm (4)
6 Complete initialization none 5
3 none none 1
10 Close transport connection none 1
11 Restart KeepAlive timer KEEPALIVE 4
13 Release resources none 1
BGP_Established (5)
7 Process KEEPALIVE none 5
8 Process UPDATE is OK UPDATE 5
Process UPDATE failed NOTIFICATION 5
9 Process NOTIFICATION none 5
10 Close transport connection none 1
11 Restart KeepAlive timer KEEPALIVE 5
12 Close transport connection NOTIFICATION 1
13 Release resources none 1
--------------------------------------------------------------------
All other state-event combinations are considered fatal errors and
cause the termination of the BGP transport connection (if necessary)
and a transition to the BGP_Idle state.
Lougheed & Rekhter [Page 15]
RFC 1105 BGP June 1989
The following is a condensed version of the above state transition
table.
Events|BGP_Idle BGP_Active BGP_OpenSent BGP_OpenConfirm BGP_Estab
| (1) | (2) | (3) | (4) | (5)
|-------------------------------------------------------------
1 | 2 | | | |
| | | | |
2 | | 3 | | |
| | | | |
3 | | | 1 | 1 |
| | | | |
4 | | 2 | | |
| | | | |
5 | | | 4 or 1 | |
| | | | |
6 | | | | 5 |
| | | | |
7 | | | | | 5
| | | | |
8 | | | | | 5
| | | | |
9 | | | | | 5
| | | | |
10 | | | | 1 | 1
| | | | |
11 | | | 3 | 4 | 5
| | | | |
12 | | | | | 1
| | | | |
13 | | 1 | 1 | 1 | 1
| | | | |
--------------------------------------------------------------
Lougheed & Rekhter [Page 16]
RFC 1105 BGP June 1989
References
[1] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC
904, BBN, April 1984.
[2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
Backbone", RFC 1092, T. J. Watson Research Center, February 1989.
[3] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
MERIT/NSFNET Project, February 1989.
[4] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.
[5] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC
1045, Stanford University, February 1988.
Authors' Addresses
Kirk Lougheed
cisco Systems, Inc.
1360 Willow Road, Suite 201
Menlo Park, CA 94025
Phone: (415) 326-1941
Email: LOUGHEED@MATHOM.CISCO.COM
Jacob Rekhter
T.J. Watson Research Center
IBM Corporation
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
Email: YAKOV@IBM.COM
Lougheed & Rekhter [Page 17]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?