📄 rfc1163.txt
字号:
attribute flags octet is set to 1, and the attribute is retained for propagation to other BGP speakers. If an optional attribute is recognized, and has a valid value, then, depending on the type of the optional attribute, it is processed locally, retained, and updated, if necessary, for possible propagation to other BGP speakers. If the network and the path attributes associated with a route to that network 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 propagated via an UPDATE message to adjacent BGP speakers as follows: - If a route in the UPDATE was received over an internal link, it is not propagated over any other internal link. This restriction is due to the fact that all BGP speakers within a single AS form a completely connected graph (see above). - If the UPDATE message is propagated over an external link, then the local AS number is prepended to the AS_PATH attribute, and the NEXT_HOP attribute is updated with an IP address of the router that should be used as a next hop to the network. If the UPDATE message is propagated over an internal link, then the AS_PATH attribute is passed unmodified and the NEXT_HOP attribute is replaced with the sender's own IP address. Generally speaking, the rules for comparing routes among several alternatives are outside the scope of this document. There are two exceptions: - If the local AS appears in the AS path of the new route being considered, then that new route cannot be viewed as better than any other route. If such a route were ever used, a routing loop would result. - In order to achieve successful distributed operation, only routes with a likelihood of stability can be chosen. Thus, an AS must avoid using unstable routes, and it must not make rapid spontaneous changes to its choice of route. Quantifying the terms "unstable" and "rapid" in the previous sentence will require experience, but the principle is clear.10. Detection of Inter-AS Policy Contradictions Since BGP requires no central authority for coordinating routing policies among ASs, and since routing policies are not exchanged via the protocol itself, it is possible for a group of ASs to have a setLougheed & Rekhter [Page 23] RFC 1163 BGP June 1990 of routing policies that cannot simultaneously be satisfied. This may cause an indefinite oscillation of the routes in this group of ASs. To help detect such a situation, all BGP speakers must observe the following rule. If a route to a destination that is currently used by the local system is determined to be unreachable (e.g., as a result of receiving an UPDATE message for this route with the UNREACHABLE attribute), then, before switching to another route, this local system must advertize this route as unreachable to all the BGP neighbors to which it previously advertized this route. This rule will allow other ASs to distinguish between two different situations: - The local system has chosen to use a new route because the old route become unreachable. - The local system has chosen to use a new route because it preferred it over the old route. The old route is still viable. In the former case, an UPDATE message with the UNREACHABLE attribute will be received for the old route. In the latter case it will not. In some cases, this may allow a BGP speaker to detect the fact that its policies, taken together with the policies of some other AS, cannot simultaneously be satisfied. For example, consider the following situation involving AS A and its neighbor AS B. B advertises a route with a path of the form <B,...>, where A is not present in the path. A then decides to use this path, and advertises <A,B,...> to all its neighbors. B later advertises <B,...,A,...> back to A, without ever declaring its previous path <B,...> to be unreachable. Evidently, A prefers routes via B and B prefers routes via A. The combined policies of A and B, taken together, cannot be satisfied. Such an event should be noticed, logged locally, and brought to the attention of AS A's administration. The means to do this, however, lies outside the scope of this document. Also outside the document is a more complete procedure for detecting such contradictions of policy. While the above rules provide a mechanism to detect a set of routing policies that cannot be satisfied simultaneously, the protocol itself does not provide any mechanism for suppressing the route oscillation that may result from these unsatisfiable policies. The reason for doing this is that routing policies are viewed as external to the protocol and as determined by the local AS administrator.Lougheed & Rekhter [Page 24] RFC 1163 BGP June 1990Appendix 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 - Idle 2 - Connect 3 - Active 4 - OpenSent 5 - OpenConfirm 6 - Established BGP Events: 1 - BGP Start 2 - BGP Stop 3 - BGP Transport connection open 4 - BGP Transport connection closed 5 - BGP Transport connection open failed 6 - BGP Transport fatal error 7 - ConnectRetry timer expired 8 - Holdtime timer expired 9 - KeepAlive timer expired 10 - Receive OPEN message 11 - Receive KEEPALIVE message 12 - Receive UPDATE messages 13 - Receive NOTIFICATION message The following table describes the state transitions of the BGP FSM and the actions triggered by these transitions. Event Actions Message Sent Next State -------------------------------------------------------------------- Idle (1) 1 Initialize resources none 2 Start ConnectRetry timer Initiate a transport connection others none none 1Lougheed & Rekhter [Page 25] RFC 1163 BGP June 1990 Connect(2) 1 none none 2 3 Complete initialization OPEN 4 Clear ConnectRetry timer 5 Restart ConnectRetry timer none 3 7 Restart ConnectRetry timer none 2 Initiate a transport connection others Release resources none 1 Active (3) 1 none none 3 3 Complete initialization OPEN 4 Clear ConnectRetry timer 5 Close connection 3 Restart ConnectRetry timer 7 Restart ConnectRetry timer none 2 Initiate a transport connection others Release resources none 1 OpenSent(4) 1 none none 4 4 Close transport connection none 3 Restart ConnectRetry timer 6 Release resources none 1 10 Process OPEN is OK KEEPALIVE 5 Process OPEN failed NOTIFICATION 1 others Close transport connection NOTIFICATION 1 Release resources OpenConfirm (5) 1 none none 5 4 Release resources none 1 6 Release resources none 1 9 Restart KeepAlive timer KEEPALIVE 5 11 Complete initialization none 6 Restart Holdtime timer 13 Close transport connection 1 Release resources others Close transport connection NOTIFICATION 1 Release resourcesLougheed & Rekhter [Page 26] RFC 1163 BGP June 1990 Established (6) 1 none none 6 4 Release resources none 1 6 Release resources none 1 9 Restart KeepAlive timer KEEPALIVE 6 11 Restart Holdtime timer KEEPALIVE 6 12 Process UPDATE is OK UPDATE 6 Process UPDATE failed NOTIFICATION 1 13 Close transport connection 1 Release resources others Close transport connection NOTIFICATION 1 Release resources --------------------------------------------------------------------- The following is a condensed version of the above state transition table.Events| Idle | Active | Connect | OpenSent | OpenConfirm | Estab | (1) | (2) | (3) | (4) | (5) | (6) |-------------------------------------------------------------- 1 | 2 | 2 | 3 | 4 | 5 | 6 | | | | | | 2 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | 3 | 1 | 4 | 4 | 1 | 1 | 1 | | | | | | 4 | 1 | 1 | 1 | 3 | 1 | 1 | | | | | | 5 | 1 | 3 | 3 | 1 | 1 | 1 | | | | | | 6 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | 7 | 1 | 2 | 2 | 1 | 1 | 1 | | | | | | 8 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | 9 | 1 | 1 | 1 | 1 | 5 | 6 | | | | | |10 | 1 | 1 | 1 | 1 or 5 | 1 | 1 | | | | | |11 | 1 | 1 | 1 | 1 | 6 | 6 | | | | | |12 | 1 | 1 | 1 | 1 | 1 | 1 or 6 | | | | | |13 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | ---------------------------------------------------------------Lougheed & Rekhter [Page 27] RFC 1163 BGP June 1990Appendix 2. Comparison with RFC 1105 Minor changes to the RFC1105 Finite State Machine were necessary to accommodate the TCP user interface provided by 4.3 BSD. The notion of Up/Down/Horizontal relations present in RFC1105 has been removed from the protocol. The changes in the message format from RFC1105 are as follows: 1. The Hold Time field has been removed from the BGP header and added to the OPEN message. 2. The version field has been removed from the BGP header and added to the OPEN message. 3. The Link Type field has been removed from the OPEN message. 4. The OPEN CONFIRM message has been eliminated and replaced with implicit confirmation provided by the KEEPALIVE message. 5. The format of the UPDATE message has been changed significantly. New fields were add⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -