Finite state machine error bgp

BGPv4 — Border Gateway Protocol v.4 — The Finite State Machine

This section discusses how the BGP router system communicates between
itself and other BGP peers. We start by looking specifically at it’s
state machine, and the different things it does at each state. Then we
look at how it sends messages between peers (types of packets) at the
different states. Then finally, we look at the basic BGP timers and how
they relate to the different states.

Tbl of Contents

1. BGP Overview:

Routers
that run the BGP process are called BGP Speakers. BGP Speakers that
talk directly with each others are called neighbors or peers.

BGP uses TCP port 179 for communication between routers. It
does not by itself know how to route traffic to its peers, instead uses
another routing protocol for this, like static routes or another
protocol (ie OSPF).

Watching BGP peers communicate with each other, we see these following common steps:

(1) When peers first attempt to connect, they exchange open messages to determine the connection parameters.

(1.1) BGP can also gracefully close a connection with a peer, allowing
all error messages to be sent between peers before the connection is
closed. This prevents the peer who was disconnected, from spending
cycles trying to reconnect with a router that will refuse all future
connections.

(2) When the BGP peers first establish a session, all the bgp routes are exchanged via an update message.

After that point only incremental updates are sent, still with the update message. So if a new network is added or one goes down, only that specific change is sent.

(3) While the peers are not sending routing information, keepalive messages’s
are regularly sent between them. This keeps the BGP session up,
allowing the peers to know that the routes are still valid. If the
session goes down (and stays down), then the router must assume that
the routes it learned from that neighbor are no longer valid. The
keepalive messages are small, not causing a strain on the routers or
the network.

BGP peers go through different finite states before a connection is
fully made. At each state, different BGP messages are sent back and
forth. Below is listed the different states, and at what states the
different BGP messages are sent.

The following states are:

• Idle:
  BGP is waiting for a start event such as the admin enabling or
  resetting a BGP router. After the start event, BGP initializes its
  resources, resets the ConnectRetry timer,
  initiates a TCP connection, and listens for a connection from its peer.
  It then either switches to a Connect State, or falls back to the Idle
  State.
• Connect: BGP is waiting for the TCP session to complete. If the connection is successful, the Open message
  is sent, and the state switches to OpenSent. If the session is not
  successful, then the state switches to Active. If nothing happens
  within the time that the ConnectRetry timer
  times out, then the TCP session is restarted, and the state stays the
  same. Other events will set the state back to the Idle State.
• Active: BGP is still waiting for the TCP session to complete. Like the Connect State, once the connection is made, the Open message is sent, and the state switches to the OpenSent State. If ConnectRetry timer
  times out without a TCP session being made, the timer is reset and the
  state is switched to Connect (BGP still listens for a connection from
  the peer). Other events (such as the Stop event) will bring the state
  back to the Idle State. If the state is switching between Connect and
  Active, then it is a sign that there are reachability issues.
• OpenSent: BGP has sent an Open message, and is waiting for one from the peer. When the peers Open Message is received, if it is ok it sends a Keepalive message, and resets the keepalive counter,
  and goes to the OpenConfirm state. If a TCP transport disconnect is
  received, the state will fall back to the Active state. If there are
  problems with the senders Open message, (bad BGP version, or bad AS),
  or the Holddown timer expires, or any other errors, then the system
  sends out an error notification, and resets to the Idle State.
  BGP figures out a bunch of things by comparing the two valid Open
  messages. First it looks at each holdtime fields, to come up with the
  value for the keepalive timer. If the values are not the same, the
  lowest of the two is chosen for both. It also looks at the two messages
  «My AS» field. If the values are the same, then the peer is an iBGP peer, and if they are different, it’s a eBGP peer.

• OpenConfirm: BGP has just sent a Keepalive message, and is waiting for one back from its peer. Once the message arrives, the HoldTimer is reset, and Keepalives are sent as per the Keepalive timer.
  If a notification message, TCP transport disconnect message, or any
  other error is received, the state is switched to Idle, and sends a
  Notification message if neccessary. (All other error messages produce a
  Notification message with the error code as «finite state machine
  error»).
• Established: The state is switched to established as soon as a Update message is sent or received. The HoldTimer is reset after each Update message or Keepalive message.
  The state will change to Idle if the system receives a Notification
  message. It will also switch to idle, and send out a Notification
  message, if any errors are found in a received Update message, the
  Holddown time expires, or the router receives any other errors.

3. BGP Message Type

3.1 BGP Message Header

All BGP messages are encapsulated within the BGP Message Header.

Packet Overview:

• Marker: Used to either authenticate incoming BGP
  messages, or detect loss of synchronization. If type=open, then the
  marker has no authentication and it is all ones. If not, then the
  marker uses an MD5 sig to authenticate the bgp packets.
• Length: length of the bgp message. min 19 bytes (header with no message), and max of 4,096 bytes.
• Type: messages purpose, (See RFC 1771)
  • 1: open
  • 2: update
  • 3: notification
  • 4: keepalive
• Message Contents:
  One of the messages outlined in the following sections. Note that the
  keepalive has no message size, so when it is sent there is no message
  content.

3.2 Open Message

Packet Overview:

• Version: [1-byte] This should be 4. All other
  versions of bgp (1-3) are considered obsolete and not used. Though this
  is currently set statically to 4, the standard says that the two peers
  will decide which is the highest version that they can both do, and
  then set to that version automatically.
• My AS #: [2-byte] The Senders AS number.
• Hold Time:
  [2-byte] The max number of seconds the session can be idle before it is
  torn down. If the bgp peers do not have the same hold time, then the
  lowest is used between the two of them. The minimum time is 3 seconds,
  the max is ???. A hold time of zero means the session will never time out. New incoming keepalive or update messages are what reset the holddown timer, which counts from 0 to the holddown time.
• Identifier:
  [4-byte] aka: BGP Identifier, BGP ID, and Router ID (RID). The highest
  IP address for the router, or it’s highest loopback address.
• Par Length: [1-byte] aka: Optional Parameter Length,
  Opt Parm Len. Length of the optional parameters field. A zero value
  indicates no optional parameters.
• Optional Parameters: [variable length] Used in the
  BGP negotiation, and other extended capabilities like multiprotocol
  extensions and route refresh. An example would be the Authentication
  Information Parameter (type 1) which is used to authenticate the
  session with a BGP peer. It is made up of the Parameter Type, Parameter
  Length, and Parameter Value fields.

  

3.3 Update Message

The update message adds and/or removes routes.

There are three sections to the Update message; the unreachable routes,
the path attributes, and the NLRI (network layer reachability
information).

The first is the unreachable routes section. It sends
information about routes that have become unreachable or withdrawn. The
second section lists the path attributes of new or known routes. An
example to a path attribute would be for a specific path . The last
section is the network layer reachability information (NLRI) which
lists the networks being advertised.

Packet Overview:

• Unreachable Routes: This is the list of routes (which
  have been advertised earlier) that are no longer available. The first
  field in this group states how large the group is, and the following
  repeated fields specify what prefix (with mask) should be removed. The
  format of the repeating fields are as such:
  • UR Length (2 bytes): Unfeasible Route Length
    specifies how much space (in BYTES) the repeating length/prefix fields
    will take up (but it also includes its own two bytes???). A zero value means that there is no routes to withdraw.
  • Withdraw Routes (variable): The list of routes to be removed. It is comprised of two repeating fields; length and prefix.

    

    • Length (1 byte): The masking of the network being advertised.
    • Prefix (variable): The network that is being advertised.
• Path Attributes:
  This used by BGP to keep track of route specific information (ie: route
  path). Every update message has a variable length sequence of path
  attributes and NRLIs. The path attribute is a repeated set of frames
  that describe the attribute type, its length, and its value. The type
  info is further broken down into two parts; the attribute flag and type
  codes. These path attributes are used to find the best route for each
  advertised network.

  

  • PA Length (2 bytes): Defines the length of the Path Attribute section, and the NRLI section
  • Attribute flags
    (1 byte): Define the importance of the following attribute value. The
    first 4 bits are defined as follows, and the final 4 bits are unused
    and reserved.
    • a (bit 0): Well-known (0=well-known, 1=optional).
      A well-known attribute is one that is understood by all BGP routers,
      and must be included for update message to be understood. Examples
      would be next hop, or as-path information.
    • b (bit 1): Transitive (0=non-transitive, 1= transitive).
      Transitive attributes are ones that should be passed to the next BGP
      router, where non-transitive ones can be dropped. (Well-known
      attributes are always transitive.)
    • c (bit 2): Transitive Completness (0=complete, 1=partial). Explains how complete the transitive or non-transitive information is.
    • d (bit 3): Attribute Length (0=1byte, 1=2bytes). Defines how long the following Attribute length field is.
    • e (bits 4-7): Unused with value 0000
  • Attribute type codes (1 byte): Explains what type of information is described within the attribute value. The codes are defined as such:
    

    #	Attribute Name	Catagory/Type Code	Related RFC
    1	ORIGIN	Well-known manadatory, Type code 1	RFC 1771
    2	AS_PATH	Well-known manadatory, Type code 2	RFC 1771
    3	NEXT_HOP	Well-known manadatory, Type code 3	RFC 1771
    4	MULTI_EXIT_DIST	Optional nontransitive, Type code 4	RFC 1771
    5	LOCAL_PREF	Well-known discretionry, Type code 5	RFC 1771
    6	ATOMIC_AGGREGATE	Well-known discretionry, Type code 6	RFC 1771
    7	AGGREGATOR	Optional transitive, Type code 7	RFC 1771
    8	COMMUNITY	Optional transitive, Type code 8	RFC 1997
    9	ORIGINATOR_ID	Optional nontransitive, Type code 9	RFC 1966
    10	Cluster List	Optional nontransitive, Type code 10	RFC 1966
    11	DPA	Destination Point Attribute for BGP	Expired Internet Draft
    12	Advertiser	BGP/IDRP Route Server	RFC 1863
    13	RCID_PATH/CLUSTER_ID	BGP/IDRP Route Server	RFC 1863
    14	Multiprotocol Reachable NRLI	Optional nontransitive, Type code 14	RFC 2283
    15	Multiprotocol Unreachable NRLI	Optional nontransitive, Type code 15	RFC 2283
    16	Extended comunities		work in progress
    255	Reserved for development

  • Attribute length (1-2 bytes): Lenght of the attribute value. It’s size is specified by the fourth bit in the attribute flag.
  • Attribute value
    (?): The data that keeps track of route specific info such as path
    information, degree of preference of a route, or the NEXT_HOP value to
    name a few.
• NLRI: Network Layer Reachability
  Information. This group contains two repeating fields. They specify the
  Prefix and its mask that is being advertised. The repeating field is in
  the same format as the repeating withdrawn routes above:

  

  • Length (1 byte): The masking of the network being advertised.
  • Prefix (variable): The network that is being advertised.

  For an example of this, say we are advertising the entire Class B
  network 128.164.0.0. This would have a subnet of 255.255.0.0, or in
  CIDR speak, it could be writen as 128.164.0.0/16. Thus the Length would
  be «16», and the Prefix would be «128.164.0.0».

3.4 Notification Message

A notification message is always sent when an error is detected, and these errors switch the BGP state to idle. Monitoring these messages is a good way to troubleshoot problems between your bgp peers.

Packet Overview:

• Error: Code of what kind of error occured.
• Error Subcode: Code to more specific details of that error.
• Data: Data relevent to the error, like bad AS numbers, or bad header.

Possible BGP Error Codes:

Error Code	Error Subcode
1- Message Header Error	1- Connection Not Synchronized
2- Bad Message Length
3- Bad Message Type
2- Open Message Error	1- Unsupported Version Number
2- Bad Peer AS
3- Bad BGP Identifier
4- Unsupported Optional Parameter
5- Authentication Failure
6- Unacceptable Hold Timer
7- Unsupported Capability
3- Update Message Error	1- Malformed Attribute List
2- Unrecognized Well-Known Attribute
3- Missing Well-Known Attirbute
4- Attribute Flags Error
5- Attribute Length Error
6- Invalid Origin Attribute
7- AS Routing Loop
8- Invalid NEXT_HOP Attribute
9- Optional Attribute Error
10- Invalid Network Field
11- Malformed AS_PATH
4- Hold Timer Expired	N/A
5- Finite State Machine Error (for errors detected by the FSM)	N/A
6- Cease (for fatal errors besides the ones already listed)	N/A

3.5 Keepalive Message

Keepalive messages are sent between peers regularly to ensure that the peer is reachable. The Hold timer counts the maximum amount or time allowed between Keepalive Messages (or Update messages).
BGP peers normaly send Keepalive messages 1/3 the amount of time as the
Hold time value. If the holdtime is set to 0 (infinite uptime), then
keepalives are not sent.

The Keepalive message has no body, thus it is comprised of only the BGP Header (with no body).

4. BGP Timers

BGP employs five timers. An implementation of BGP MUST allow these timers to be configurable. see:RFC 1771, section 6.4.

The timers are:

• Holdtime Timer
• Keepalive Timer
• Connect Retry Timer
• MinASOriginationInterval Timer
• MinRouteAdvertisementInterval Timer

4.1 Holdtime and Keepalive Timers:

These timers are used during the established state
to ensure that the state should stay established. The BGP router
expects to recieve a keepalive message (or update message) within the
Hold timer. If none are received, then the state is considered dead.

• KeepAlive Timer
  (def: 30s) How much time between sending keepalive packets to the hosts
  bgp peer. It does this to let the neighbor that it is alive and well.
• Hold Time Timer (def: 90s)
  The number of seconds this BGP speaker waits for a keepalive, update,
  or notification message before deciding that the peer is dead, and
  terminating its connection. This is normaly set to 3 times the
  keepalive time, so that the peer is given three chances to recieve a
  keepalive message before assuming the peer is dead.

4.2 Connect Retry Timer

When
the state first switches to connect, a tcp connect with the peer is
attempted. If the connection is not created by the connectRetry timer,
then the state is switched back to idle. If the connection is made,
then the state is switched to opensent.

• ConnectRetry Timer
  (120s) Only after this time passes will the BGP process check to see if
  the passive TCP session is established. If the passive TCP session is
  not established, then the BGP process starts a new active TCP attempt
  to connect to the remote BGP speaker. During this idle 120 seconds of
  the ConnectRetry timer, the remote BGP peer can establish a BGP session
  to it. Presently the Cisco IOS ConnectRetry timer cannot be changed
  from its default of 120 seconds.

4.3 Controlling Routing Traffic Overhead: MAOI and MRAI Timers Timers

Both of these timers are designed to keep a bgp routers overhead low, and to keep unneccessary traffic on the line.

MinASOriginationInterval Timer (MAOI)	MinRouteAdvertisementInterval Timer (MRAI)

• MinASOriginationInterval Timer {MAOI} (def: 15s)
  The parameter MinASOriginationInterval is the minimum time between
  consecutive advertisements of UPDATE messages by an AS border router
  that reports changes in its AS.
• MinRouteAdvertisementInterval Timer {MRAI} (def: 30s)
  Prevent a flapping network from sending repeated route advertisements
  within a specified amount of time. In other words, if Crazy Joe’s ISP
  is flapping every few seconds a few AS’s away you should only
  send/receive an update message for their NLRI every
  MinRouteAdvertisementInterval seconds instead of every few seconds if
  you did not have damping already
  setup. This is a good thing, because it keeps traffic on the line
  lower, but the router does have to keep track of each NLRI route
  update, thus adding a higher load on it’s memory.

Appendix A. References:

• Internet Routing Architectures, Second Edition. Sam Halabi, Cisco Press ©2001
• Cisco BGP-4 Command and Configuration Handbook. William R. Parkhurst © 2001
• BGP. Iljitsch van Beijnum, O’Reilly & Associates, Inc. ©2002
• RFC 1771, A Border Gateway Protocol 4 (BGP-4)

The following list summarizes the key states in the FSM example illustrated in Figure 5-8:

1. Idle— This is the first stage of the connection. BGP is waiting for a Start event, which is initiated by an operator or the BGP system. An administrator establishing a BGP session through router configuration or resetting an already existing session usually causes a Start event. After the Start event, BGP initializes its resources, resets a ConnectRetry timer, initiates a TCP transport connection, and starts listening for a connection that may be initiated by a remote peer. BGP then transitions to a Connect state. In case of errors, BGP falls back to the Idle state.

2. Connect— BGP is waiting for the transport protocol connection to be completed. If the TCP transport connection is successful, the state transitions to OpenSent (this is where the OPEN message is sent). If the transport connection is unsuccessful, the state transitions to Active. If the ConnectRetry timer expires, the state remains in the Connect stage, the timer is reset, and a transport connection is initiated. In case of any other event (initiated by system or operator), the state goes back to Idle.

3. Active— BGP tries to acquire a peer by initiating a transport protocol connection. If the transport connection is established, it transitions to OpenSent (an OPEN message is sent). If the ConnectRetry timer expires, BGP restarts the ConnectRetry timer and falls back to the Connect state. In addition, BGP continues to listen for a connection that might be initiated from another peer. The state might go back to Idle in case of other events, such as a Stop event initiated by the system or the operator.

In general, a neighbor state that is oscillating between Connect and Active indicates that something is wrong with the TCP transport connection. It could be because of many TCP retransmissions or the inability of a neighbor to reach the IP address of its peer.

4. OpenSent— BGP is waiting for an OPEN message from its peer. The OPEN message is checked for correctness. In case of errors, such as a bad version number or an unacceptable AS, the system sends an error NOTIFICATION message and goes back to Idle. If there are no errors, BGP starts sending KEEPALIVE messages and resets the KEEPALIVE timer. At this stage, the hold time is negotiated, and the smaller value is taken. In case the negotiated hold time is 0, the Hold Timer and the KEEPALIVE timer are not restarted.

At the OpenSent state, the BGP recognizes, by comparing its AS number to the AS number of its peer, whether the peer belongs to the same AS (Internal BGP) or to a different AS (External BGP).

When a TCP transport disconnect is detected, the state falls back to the Active state. For any other errors, such as an expiration of the Hold Timer, the BGP sends a NOTIFICATION message with the corresponding error code and falls back to the Idle state. Also, in response to a stop event initiated by the system or the operator, the state falls back to the Idle state.

5. OpenConfirm— BGP waits for a KEEPALIVE message. If a KEEPALIVE is received, the state goes to Established, and the neighbor negotiation is complete. If the system receives a KEEPALIVE message, it restarts the Hold Timer (assuming that the negotiated Hold Time is not 0). If a NOTIFICATION message is received, the state falls back to the Idle state. The system sends periodic KEEPALIVE messages at the rate set by the KEEPALIVE timer. In case of any transport disconnect notification or in response to any stop event (initiated by the system or the operator), the state falls back to Idle. In response to any other event, the system sends a NOTIFICATION message with an FSM (Finite State Machine) error code and returns to the Idle state.

6. Established— This is the final stage in the neighbor negotiation. At this stage, BGP starts exchanging UPDATE packets with its peers. Assuming that it is nonzero, the Hold Timer restarts at the receipt of an UPDATE or KEEPALIVE message. If the system receives any NOTIFICATION message (if an error has occurred), the state falls back to Idle.

The UPDATE messages are checked for errors, such as missing attributes, duplicate attributes, and so on. If errors are found, a NOTIFICATION message is sent to the peer, and the state falls back to Idle. If the Hold Timer expires, or a disconnect notification is received from the transport protocol, or a Stop event is received, or in response to any other event, the system falls back to the Idle state.

NOTIFICATION Message

From the preceding examination of the Finite State Machine, it should be apparent that many opportunities exist among the various states for errors to be detected. A NOTIFICATION message is always sent whenever an error is detected. After that, the peer connection is closed. Network administrators need to evaluate these NOTIFICATION messages to determine the specific nature of errors that emerge in the routing protocol. Figure 5-9 illustrates the general message format.

Figure 5-9. NOTIFICATION Message Format

0 7 15 23 31

The NOTIFICATION message is composed of the Error code (1 byte), the Error subcode (1 byte), and the Data field (variable).

The Error code indicates the type of the notification, and the Error subcode provides more specific information about the nature of the error. The Data field contains data relevant to the error, such as a bad header, an illegal AS number, and so on. Table 5-1 lists possible errors and their subcodes.

Continue reading here: TCP MD5 Signature Option

Was this article helpful?

Сегодня ночью обнаружилось, что один из апстрим каналов начал играть в «ванька-встанька».

BGP сессия падала, поднималась, снова падала, снова поднималась и так до бесконечности.

В логах BGP читалось:

Sep  9 00:26:59.219845 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer XX.XX.XX.141 (External AS XXXX) changed state from Established to Idle (event RecvUpdate)
Sep  9 00:27:03.460183 bgp_read_v4_update:8189: NOTIFICATION sent to XX.XX.XX.141 (External AS XXXX): code 3 (Update Message Error) subcode 11 (AS path attribute problem)
Sep  9 00:27:39.219859 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer XX.XX.XX.141 (External AS XXXX) changed state from OpenConfirm to Established (event RecvKeepAlive)

В messages:

Sep  9 00:27:33  rpd[1153]: XX.XX.XX.141 (External AS XXXX) Received BAD update for family inet-unicast(1), prefix 212.118.142.0/24

Полез разбираться, читаем:
BGP Notification Message Error Codes and Error Subcodes

Такс… приехали…

При помощи своего апстрима удалось выяснить что действительно мне и многим другим другим поднасрал Saudi Telecom и анонсируемый им префикс 212.118.142.0/24.
О чем свидетельствуют мои логи, рассказ апстрима о проблемах и у других его клиентов, а так же:  Saudi Telecom sending route with invalid attributes 212.118.142.0/24:

anyone else getting a route for 212.118.142.0/24 with invalid
attributes? Seems this is (again) causing problems with some (older)
routers/software.

Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
6-Resolve tree 2
AS path: 6453 39386 25019 I Unrecognized Attributes: 39
bytes
AS path: Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
00 00 00 64
Accepted Multipath

-Jonas

Ответ:

Exactly the same here.

Sep 8 20:24:04 BBD-RC02 rpd[1334]: Received BAD update from
94.228.128.57 (External AS 41887), aspath_attr():3472
PA4_TYPE_ATTRSET(128) => 1 times IGNORED, family inet-unicast(1), prefix
212.118.142.0/24

Bye,
Raymond.

Смотрим инфу в RIPE:

% Information related to '212.118.140.0/22AS25019'
route: 212.118.140.0/22
descr: Saudi Arabia backbone and local registry address space / STC
remarks: for any Abuse or Spamming Please send an e-mail to abuse@saudi.net.sa
origin: AS25019
mnt-by: saudinet-stc
source: RIPE # Filtered

% Information related to '212.118.140.0/22AS39891'
route: 212.118.140.0/22
descr: Saudi Arabia backbone and local registry address space / STC
origin: AS39891
mnt-by: saudinet-stc
source: RIPE # Filtered

О как, за двумя ASками данный префикс числится. Красавцы, чего тут сказать.

Отфильтровав этот префикс к чертям собачьим, BGP сессия сразу же перестала падать. Вечером та же участь постигла и другого апстрима.

Т.к. к вечеру я уже реально задолбался, то взял отфильтровал нафиг по as-path обе аски  AS39891 и AS25019. Пусть саудовский телеком идет лесом и уже научится пользоваться BGP фильтрами.

Вот так один «олень» может доставить гемороя многим во всем мире.

З.Ы. Junos:

JUNOS Base OS Software Suite [9.4R1.8]
JUNOS Kernel Software Suite [9.4R1.8]

Пролеме точно подвержены Junos`ы версии 9.4 и ниже, update JunOS`а ждет меня и не только меня 🙂

Похожие статьи:

Не найдено

• Administrative Events: Events that either start or stop the process.
• Timer Events: Expiration of HoldTimer, KeepaliveTimer or ConnectRetryTimer trigger this event.
• TCP connection based events: These events describe the different state of the TCP three-way handshake.
• BGP message based events: Receiving or sending BGP messages: OPEN, KEEPALIVE, UPDATE and NOTIFICATION launch this event.

A Complete list can be found in Appendix A.

Figure 1-1 shows the map of different states and related event numbers. Timers and counters are excluded from both the text part and picture to keep things as clear as possible.

Figure 1-1: Overview of BGP-FSM.

Start negotiation of the TCP connection

Idle

In the Idle state, the local BGP speaker is waiting for the Start-event. It does not accept incoming BGP connection from the peer, nor allocate any BGP resources to the peer.  For the reaction to the Start-event, the local BGP speaker will start initialization of TCP connection either actively or passively.

Connect

• ManualStart (event 1): an administrator starts BGP peer connection manually. After that, the local system starts sending and listening TCP SYN from/to port 179. This event can be started e.g. with basic BGP neighbor configuration under the BGP process.
• AutomaticStart (event 3): Same as Event 1, except the event starts automatically. This could happen for example if the administrator of the remote BGP speaker clears the BGP peering with the local system.

For the reaction to the event 1 “ManualStart” and event 3, “AutomaticStart”, the BGP-FSM changes state from Idle to Connect, where the local system is waiting for the TCP-connection to be completed.

Active

• ManualStart_with_PassiveTcpEstablishment (event 4): BGP connection started manually by an administrator, but the local system waits for a TCP SYN packet to port 179 from the remote BGP speaker. This can be done e.g. by setting transport mode to passive (1) or by using BGP Dynamic Neighbor solution (2). 

(1) neighbor 2001:DB8::915:9 transport connection-mode passive

(2) bgp listen range 10.15.9.0/24 peer-group DynNeigh_from_AS64502

• AutomaticStart_with_PassiveTcpEstablihment (event 5): The local system waits passively the TCP connection from a remote peer as in event 4. The start event happens automatically like in event 3.  

Reaction to either “ManualStart_with_PassiveTcpEstablishment” or “AutomaticStart_ with_PassiveTcpEstablishment” the state is changed from Idle to Active where local system is passively waiting for a TCP-connection to be completed.

If the local BGP speaker receives a TCP FIN packet (event-18 “TcpConnectionFail”) in Connect state, the state is changed either to Active or back to Idle depending on the DelayOpenTimer. If the DelayOpenTimer is running, the state will be changed to Active, otherwise back to Idle. If the ConnectRetryTimer expires (event “ConnectRetryTimer_Expires”) in Connect state, the state does not change. As a response to” “ConnectRetryTimer_Expires” event in the Active state, the state will be changed to Connect.

The reaction for the error/stop event or a NOTIFICATION message, the locals system will change BGP FSM state to Idle from Connect/Active states.

Figure 1-2: Moving from Idle either to Connect/Active.

Finalizing negotiation of the TCP connection

Finalizing the TCP connection from either Connect/Active state follows the same procedure. In our example there are four events related to the TCP three-way handshake:

• TcpConnection_Valid (Event 14): This event occurs when the local system receives a TCP Connection Request (TCP SYN) from the peer BGP speaker with a valid source address (configured as a neighbor) and it is destined to the address that the local system uses as a source in BGP negotiation. In addition, the destination TCP port should be 179.
• Tcp_CR_Invalid (Event 15): This event occurs when the local system receives a TCP Connection Request (TCP SYN) from the remote BGP speaker and the validity check does not pass.
• Tcp_CR_Acked (Event 16): This event indicates that the local system has sent ACK message to the remote peer as a confirmation of SYN ACK message sent by the remote peer.
• TcpConnectionConfirmed (Event 17): This event indicates that the local system has received ACK messages from the peer BGP speaker.

There is also BGP “Message Based Event” (event 20) and “Timer Event” (event 12) involving in these states:

• BGPOpen with DelayOpenTimer running (Event 20): This event happens if the local system received valid BGP OPEN message from the remote BGP speakers, while local systems own DelayOpenTimer is still running.
• DelayOpenTimer_Expires (Event 12): After TCP initialization, BGP speaker sends an OPEN message. If the DelayOpen -session attribute is set to TRUE, it can delay the sending of a BGP OPEN message by the time specified in DelayOpenTimer.

Figure 1-3: Moving to OpenSent or OpenConfirm.

When the local system receives a TCP SYN messages, it validates the packet. If the validity check is ok (event 14, “TcpConnection_Valid”), the local system will send the SYN ACK message to the remote peer. If the packet is not valid, (event 15, “Tcp_CR_Invalid”), the local system sends a TCP RST message and stays in the current state. When the remote peer receives the SYN ACK, it finalizes the TCP three-way handshake by replying with an ACK message (event 16“Tcp_CR_Acked”). When the local system receives the ACK message (event 17, “TcpConnectionConfirmed”), the TCP three-way handshake is complete.

After successful TCP negotiation, BGP peers will exchange BGP OPEN messages either right away or with a short delay defined by the time of DelayOpenTimer. If the timer is not running, the local system sends an OPEN message right away and the BGP FSM state will be changed to OpenSent. If the DelayOpenTimer is running and the local system has not yet received BGP OPEN message from the remote peer, the local host waits for the DelayOpenTimer expiration, (event 12, “DelayOpenTimer_Expires”). Then it will send an OPEN message to peer and the BGP-FSM state is changed to OpenSent.

If the local system receives an OPEN message while DelayOpenTimer is running (event 20 “BGPOpen with DelayOpenTimer running”), it sends both OPEN and KEEPALIVE messages to peer and BGP-FSM change state to OpenConfirm.

Validation of the BGP neighbor

After successful TCP negotiation, the BGP speakers exchange BGP OPEN messages to ensure that, they use the same version of BGP, their BGP identifiers do not overlap and they support the same set of capabilities. They also compare the HoldTime values and they choose the smaller one if values are not the same. If everything goes well, the state will be changed to OpenConfirm or Established. If the OPEN message check does not pass, the state will change to either Active or Idle.

In addition to previously introduced events, there are two BGP related events:

• BGPOpen (Event 19): When BGP speaker receives BGP OPEN messages, it validates the messages (BGP version has to be the same, correct AS number, BGP RID do not overlap, the same set of supported capabilities).
• KeepAliveMsg (Event 26): This event indicates that local system has received KEEPALIVE from the peer.

There is also two Timer based (11 and 12) events and one TCP Connection based event (18) related to this chapter:

• KeepaliveTimer_Expires (Event 11): As the name indicates, this event indicates that Keepalive timer has been expired.
• DelayOpenTimer_Expires (Event 12): This event is caused by the expiration of the DelayOpenTimer.
• TcpConnectionFail (Event 18): This event occurs if the local system receives a TCP FIN message from the remote BGP speaker or if the existing TCP connection is timed out and DelayOpenTimer is not running.

Following two events are related to the Established state.

• UpdateMsg (Event 27): This event occurs as a response to the valid update message.
• UpdateMsgErr (Event 28): This event occurs as a response to the invalid UPDATE message.

OpenSent and OpenConfirm

When the local system receives an OPEN message, while in the OpenSent state, the local system validates remote peers’ AS number, BGP Router-ID and supported capabilities. If everything is ok (event 19, “BGPOpen”), the local system sends OPEN and KEEPALIVE messages, after that it changes BGP-FSM state to OpenConfirm.

When the local system receives any TCP based events (14, 16 or 17), while in the OpenSent state, the second connection may be in progress. Then the local system will track the connection until it receives an OPEN message. If the local system receives a TCP SYN message during this state, it goes through the normal TCP three-way handshake process. If the local system receives a TCP FIN message from the remote peer, event 18 occurs and state is changed to Active.

When the BGP FSM of local system is in the OpenConfirm state, it sends a KEEPALIVE messages to the remote peer. After receiving KEEPALIVE message from the remote peer as a response (event 26 “KeepAliveMsg”), the local system finalizes the BGP connection and moves BGP-FSM state to Established. If the Keepalive timer expires (event 11 “KeepaliveTimer_Expires”) before the local system receives an OPEN message from the remote peer, the BGP-FSM state does not change. Reaction to the TCP based events 14, 16 or 17 is same than in OpenSent state.

Established

In Establish state, BGP FSM reacts to event14 “TcpConnection_Valid” in the same way as in the OpenSent or OpenConfirm state, the local system will track the connection until it receives an OPEN message. In this state, BGP peering is up and running and BGP neighbors can send and receive UPDATE, KEEPALIVE and NOTIFICATION messages.

In Established state, the local system validates all received UPDATE messages. An example of the validation is a next-hop reachability checking. The Next-hop address must be other than the receiving BGP speakers’ address. If peers are directly connected eBGP neighbors, the next-hop address has to be either senders IP- address that is used in BGP neighbor negotiation or it has to be from the same network segment than receivers IP-address (e.g. in the case of BGP redirect). Event 27 “UpdateMsg” indicates valid UPDATE message and while event 28 “UpdateMsgErr” indicates invalid UPDATE message.

Reaction to error/stop event or a NOTIFICATION message, the locals system will change BGP FSM state to Idle from OpenSent/OpenConfirm states.

When the local system receives a BGP message from the remote peer (not shown in the flow chart), it validates the header of the message by checking that all bits in the Marker field are set to one and the length field is in between 19 – 2096. Failure in either condition will cause event 21 “BGPHeaderErr”. Another check is only related to the OPEN message, if the length field is under minimum requirement 29 octets, event 22 “BGPOpenMsgErr” occurs. Both events, BGPHeaderErr” and “BGPOpenMsgErr” change the BGP FSM state to Idle.

Figure 1-4: Finalizing BGP neighbor negotiation.

Appendix A: List of additional NOTIFICATION message events and error events

Administrative Events:

Event 1. ManualStart

Event 2. ManualStop

Event 3. AutomaticStart

Event 4. ManualStart_with_PassiveTcpOpen

Event 5. AutomaticStart_with_PassiveTcpOpen

Event 6. AutomaticStart_with_DampPeerOscillations

Event 7. AutomaticStart_with_DampPeerOscillations_andPassiveTcpEstablishment

Event 8. AutomaticStop

Timer Events:

Event 9. ConnectRetryTimer_Expires

Event 10. HoldTimer_Expires

Event 11. KeepaliveTimer_Expires

Event 12. DelayOpenTimer_Expires

Event 13. IdleHoldTimer_Expires

TCP Connection-based Events

Event 14. TcpConnection_Valid

Event 15. Tcp_CR_Invalid

Event 16. Tcp_CR_Acked

Event 17. TcpConnectionConfirmed

Event 18. TcpConnectionFails

BGP Message-Based events:

Event 19. TcpConnection_Valid

Event 20. BGPOpen with DelayOpenTimer running

Event 21. BGPHeaderErr

Event 22. BGPOpenMsgErr

Event 23. OpenCollisionDump

Event 24. NotiMsgVerErr

Event 25. NotiMsg

Event 26. KeepAliveMsg

Event 27. UpdateMsg

Event 28. UpdateMsgErr

Оригинал статьи: https://rfc2.ru/4271.rfc/print

RFC: 4271

Оригинал: A Border Gateway Protocol 4

Предыдущие версии: RFC 1654, RFC 1771

Категория: Проект стандарта

Дата публикации: Январь 2006

Авторы: Yakov Rekhter, Tony Li, Susan Hares

Перевод: Николай Малых

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться без ограничений.

Тезисы

Этот документ посвящен обсуждению протокола BGP (Border Gateway Protocol — протокол граничного шлюза), который является протоколом маршрутизации между автономными системами (inter-Autonomous System routing protocol).

Основной функцией поддерживающей протокол BGP системы является обмен информацией о доступности сетей с другими системами BGP. Информация о доступности сетей включает список автономных систем (AS), через которые проходит эта информация. Этих сведений достаточно для построения графа связности AS, из которого могут исключаться маршрутные петли (routing loop), а также для принятия некоторых решений на уровне политики AS.

BGP-4 обеспечивает новые механизмы поддержки бесклассовой междоменной маршрутизации (CIDR — Classless Interdomain Routing). Эти механизмы включают поддержку анонсирования группы адресатов с помощью префикса IP и позволяют обойтись без концепции «класса» сетей в рамках протокола BGP. BGP-4 также добавляет механизм объединения маршрутов, включающий объединение путей AS.

Этот документ прекращает действие RFC 1771.

Оглавление

• 1. Введение
• 1.1. Определения основных терминов
• 1.2. Уровни требований
• 2. Благодарности
• 3. Основы работы протокола
• 3.1. Маршруты — анонсирование и хранение
• 3.2. База маршрутной информации RIB
• 4. Формат сообщений
• 4.1. Формат заголовка
• 4.2. Формат сообщения OPEN
• 4.3. Формат сообщения UPDATE
• 4.4. Формат сообщения KEEPALIVE
• 4.5. Формат сообщения NOTIFICATION
• 5. Атрибуты пути
• 5.1. Использование атрибутов пути
• 5.1.1. ORIGIN
• 5.1.2. AS_PATH
• 5.1.3. NEXT_HOP
• 5.1.4. MULTI_EXIT_DISC
• 5.1.5. LOCAL_PREF
• 5.1.6. ATOMIC_AGGREGATE
• 5.1.7. AGGREGATOR
• 6. Обработка ошибок BGP
• 6.1. Отработка ошибок в заголовках сообщений
• 6.2. Отработка ошибок в сообщениях OPEN
• 6.3. Отработка ошибок в сообщениях UPDATE
• 6.4. Отработка ошибок в сообщениях NOTIFICATION
• 6.5. Отработка значений Hold Timer
• 6.6. Обработка ошибок машины конечных состояний
• 6.7. Обработка Cease
• 6.8. Детектирование конфликтов в соединениях BGP
• 7. Согласование версий BGP
• 8. Машина конечных состояний BGP
• 8.1. События BGP FSM
• 8.1.1. Дополнительные события, связанные с дополнительными атрибутами сессии
• 8.1.2. События административного плана
• 8.1.3. События, связанные с таймерами
• 8.1.4. События, связанные с соединениями TCP
• 8.1.5. События, связанные с сообщениями BGP
• 8.2. Описание FSM
• 8.2.1. Определение FSM
• 8.2.1.1. Термины «активный» и «пассивный»
• 8.2.1.2. FSM и детектирование конфликтов
• 8.2.1.3. FSM и дополнительные атрибуты сессий
• 8.2.1.4. Номера событий FSM
• 8.2.1.5. Действия FSM, зависящие от реализации
• 8.2.2. Машина конечных состояний
• 9. Обработка сообщений UPDATE
• 9.1. Процесс выбора маршрутов (Decision Process)
• 9.1.1. Фаза 1: Расчет предпочтений (Calculation of Degree of Preference)
• 9.1.2. Фаза 2: Выбор маршрута (Route Selection)
• 9.1.2.1. Возможность преобразования маршрута
• 9.1.2.2. «Отбрасывание лишнего» (фаза 2)
• 9.1.3. Фаза 3: Распространение маршрутов (Route Dissemination)
• 9.1.4. Перекрывающиеся маршруты
• 9.2. Процесс передачи обновлений (Update-Send)
• 9.2.1. Контроль за избыточным трафиком
• 9.2.1.1. Частота анонсирования маршрутов
• 9.2.1.2. Частота обновления из исходной AS
• 9.2.2. Эффективная организация маршрутных данных
• 9.2.2.1. Снижение объема информации
• 9.2.2.2. Агрегирование маршрутной информации
• 9.3. Критерии выбора маршрута
• 9.4. Порождение маршрутов BGP
• 10. Таймеры BGP
• Приложение A. Сравнение с RFC 1771
• Приложение B. Сравнение с RFC 1267
• Приложение C. Сравнение с RFC 1163
• Приложение D. Сравнение с RFC 1105
• Приложение E. Опции TCP, которые могут использоваться с BGP
• Приложение F. Рекомендации для разработчиков
• Приложение F.1. Множество префиксов сетей в одном сообщении
• Приложение F.2. Снижение числа переключений маршрутов
• Приложение F.3. Упорядочение атрибутов пути
• Приложение F.4. Сортировка AS_SET
• Приложение F.5. Контроль за согласованием версий
• Приложение F.6. Комплексное агрегирование AS_PATH
• Вопросы безопасности
• Согласование с IANA
• Нормативные документы
• Дополнительная литература

1. Введение

Протокол граничного шлюза (BGP) является протоколом маршрутизации между автономными системами (AS).

Основной функцией поддерживающей протокол BGP системы является обмен информацией о доступности сетей с другими системами BGP. Информация о доступности сетей включает список автономных систем (AS), через которые проходит эта информация. Этих сведений достаточно для построения графа связности AS, из которого могут исключаться маршрутные петли (routing loop), а также для принятия некоторых решений на уровне политики AS.

BGP-4 обеспечивает новые механизмы поддержки бесклассовой междоменной маршрутизации (CIDR) [RFC1518, RFC1519]. Эти механизмы включают поддержку анонсирования группы адресатов с помощью префикса IP и позволяют обойтись без концепции «класса» сетей в рамках протокола BGP. BGP-4 также добавляет механизм объединения маршрутов, включающий объединение путей AS.

Маршрутная информация, передаваемая с использованием BGP поддерживает только парадигму пересылки на основе адреса получателя (destination-based forwarding paradigm), которая предполагает, что маршрутизатор пересылает пакеты, опираясь лишь на адрес получателя, содержащийся в заголовке IP-пакета. Это, в свою очередь, отражает набор правил политики, которые могут быть применены (или не применены) с использованием BGP. Протокол BGP может поддерживать только правила, соответствующие парадигме пересылки по адресу получателя.

1.1. Определения основных терминов

В этом разделе приводятся определения основных терминов, имеющих специфическое толкование в контексте протокола BGP и встречающихся в данном документе.

• Adj-RIB-In
• Необработанная маршрутная информация, которая анонсируется локальному узлу BGP его партнерами.
• Adj-RIB-Out
• Adj-RIBs-Out содержит маршруты, анонсируемые указанным партнерам BGP с помощью сообщений UPDATE, передаваемых локальным узлом BGP.
• Autonomous System (AS) — автономная система
• В соответствии с классическим определением автономная система представляет собой набор маршрутизаторов, находящихся под единым административным управлением, использующих один протокол внутридоменной маршрутизации (interior gateway protocol или IGP) и общую метрику для определения маршрутизации пакетов внутри AS, а также использующих протокол междоменной маршрутизации для определения маршрутов пересылки пакетов в другие AS. С момента создания этого определения для AS стало общепринятым использование нескольких протоколов IGP, а в некоторых случаях и нескольких наборов метрик. Использование термина AS в таких случаях подчеркивает, что даже при наличии нескольких IGP и метрик администрирование AS с точки зрения других автономных систем представляет собой единый согласованный план маршрутизации и согласованную картину адресатов, доступных через данную AS.
• BGP Identifier — идентификатор BGP
• 4-октетное целое число без знака, идентифицирующее узел BGP, отправляющий сообщение BGP. Данный узел BGP устанавливает в качестве значения BGP Identifier адрес IP, присвоенный узлу. Значение идентификатора BGP задается при старте системы и совпадает для всех локальных интерфейсов и самого узла BGP.
• BGP speaker — узел BGP
• Маршрутизатор, поддерживающий протокол BGP.
• EBGP
• External BGP (BGP-соединение с внешним партнером).
• External peer — внешний партнер
• Партнер BGP, относящийся к другой (внешней по отношению к локальной системе) AS.
• Feasible route — подходящий маршрут
• Анонсируемый маршрут, который пригоден для использования получателем.
• IBGP
• Internal BGP (BGP-соединение с внутренним партнером).
• Internal peer — внутренний партнер
• Партнер BGP, относящийся к той же AS, что и локальная система.
• IGP — протокол внутреннего шлюза
• Interior Gateway Protocol — протокол маршрутизации, используемый для обмена маршрутной информацией между маршрутизаторами одной AS.
• Loc-RIB
• Loc-RIB содержит маршруты, выбранные процессом принятия решений (Decision Process) локального узла BGP.
• NLRI
• Network Layer Reachability Information — информация о доступности на сетевом уровне.
• Route — маршрут
• Единица информации, связывающая набор адресатов с атрибутами пути к этим адресатам. Набор адресатов представляет собой системы, чьи адреса IP содержатся в одном префиксе IP, передаваемом в поле NLRI сообщения UPDATE. Путь представляет собой информацию, содержащуюся в поле атрибутов пути того же сообщения UPDATE.
• RIB
• Routing Information Base — база маршрутной информации.
• Unfeasible route — неподходящий маршрут
• Анонсированный ранее подходящий маршрут, который утратил доступность.

1.2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

2. Благодарности

Первый вариант этого документа был опубликован в RFC 1267 (октябрь 1991), который подготовили Kirk Lougheed (Cisco Systems) и Yakov Rekhter (IBM).

Авторы выражают свою благодарность Guy Almes (ANS), Len Bosack (Cisco Systems) и Jeffrey C. Honig (Cornell University) за их вклад в подготовку предварительных вариантов документа.

Отдельно отметим Bob Braden (ISI) за обзор предварительных вариантов документа и конструктивные замечания.

Благодарим также Bob Hinden (директор по маршрутизации в IESG) и команду специалистов, подготовивших обзор предыдущей версии документа (BGP-2). Эта команда, в состав которой входят Deborah Estrin, Milo Medin, John Moy, Radia Perlman, Martha Steenstrup, Mike St. Johns и Paul Tsuchiya, показала в работе высокий уровень профессионализма, упорство и такт.

Некоторые фрагменты этого документа были заимствованы из протокола IDRP [IS10747], являющегося аналогом BGP в OSI. В связи с этим следует отметить работу группы ANSI X3S3.3 под руководством Lyman Chapin и Charles Kunzinger, который также был редактором IDRP в этой группе.

Авторы также выражают свою признательность Benjamin Abarbanel, Enke Chen, Edward Crabbe, Mike Craren, Vincent Gillet, Eric Gray, Jeffrey Haas, Dimitry Haskin, Stephen Kent, John Krawczyk, David LeRoy, Dan Massey, Jonathan Natale, Dan Pei, Mathew Richardson, John Scudder, John Stewart III, Dave Thaler, Paul Traina, Russ White, Curtis Villamizar, Alex Zinin за их комментарии.

Отдельной благодарности заслуживает Andrew Lange за его помощь в подготовке окончательного варианта этого документа.

И, наконец, благодарим всех членов группы IDR за их идеи и поддержку в процессе создания этого документа.

3. Основы работы протокола

Протокол граничного шлюза BGP является протоколом маршрутизации между автономными системами. Он создан на основе опыта, полученного при разработке протокола EGP (определен в [RFC904]) и его использовании в магистралях NSFNET ([RFC1092] и [RFC1093]). Дополнительную информацию о протоколе BGP можно найти в документах [RFC1772], [RFC1930], [RFC1997] и [RFC2858].

Основной функцией поддерживающей протокол BGP системы является обмен информацией о доступности сетей с другими системами BGP. Информация о доступности сетей включает список автономных систем (AS), через которые проходит эта информация. Этих сведений достаточно для построения графа связности AS, из которого могут исключаться маршрутные петли (routing loop), а также для принятия некоторых решений на уровне политики AS.

В контексте этого документа предполагается, что узел BGP анонсирует своим партнерам только те маршруты, которые он сам использует (т. е., узел BGP говорит, что он «использует» маршрут BGP, если тот является наиболее предпочтительным из BGP-маршрутов и применяется для пересылки пакетов). Рассмотрение прочих случаев не входит в задачи данного документа.

В контексте этого документа термин «IP-адрес» относится к адресам IP версии 4 [RFC791].

Маршрутная информация, передаваемая с использованием BGP, поддерживает только парадигму пересылки на основе адреса получателя, которая предполагает, что маршрутизатор пересылает пакет исключительно на основе адреса получателя, содержащегося в заголовке IP-пакета. Это, в свою очередь, отражает набор правил политики, которые могут быть применены (или не применены) при использовании BGP. Протокол BGP может поддерживать только правила, соответствующие парадигме пересылки по адресу получателя. Отметим, что некоторые правила не могут поддерживаться в рамках парадигмы пересылки на основе адреса получателя и требуют использования иных методов типа маршрутизации, задаваемой отправителем (source routing или explicit routing). Такие правила не могут быть реализованы в рамках BGP. Например, BGP не позволяет одной AS, передающей трафик в соседнюю AS для пересылки тому или иному адресату (достижимому через эту AS, но не относящемуся к ней), предполагать, что этот трафик будет доставляться адресату иным путем, нежели трафик, исходящий из соседней AS (для того же адресата). С другой стороны, BGP может поддерживать любую политику, согласующуюся с парадигмой пересылки на основе адреса получателя.

BGP-4 обеспечивает новые механизмы поддержки бесклассовой междоменной маршрутизации (CIDR) [RFC1518, RFC1519]. Эти механизмы включают поддержку анонсирования набора адресатов в форме префикса IP и позволяют обойтись без концепции «класса» сетей в рамках BGP. BGP-4 также включает механизм объединения маршрутов, включающий объединение путей AS.

В этом документе используется термин «автономная система» (AS). По классическому определению автономная система представляет собой множество маршрутизаторов с единым техническим администрированием, использующих один протокол внутренней маршрутизации (IGP) и единую метрику для маршрутизации пакетов внутри AS, а для передачи пакетов в другие автономные системы применяющих протокол внешней маршрутизации (exterior gateway protocol или EGP). Со временем классическое определение AS было расширено и в современном понимании AS может использовать несколько протоколов внутренней маршрутизации, а в некоторых случаях даже несколько наборов метрик в рамках одной AS. Использование термина AS в таких случаях обусловлено тем, что даже при использовании множества метрик и протоколов IGP администрирование такой AS с точки зрения других автономных систем выглядит как единый план внутренней маршрутизации и показывает согласованную картину доступности адресатов через данную AS.

BGP использует в качестве транспортного протокол TCP [RFC793]. Это избавляет от необходимости реализации явного фрагментирования уведомлений, повторной передачи и порядковых номеров. BGP слушает протокол TCP через порт 179. Механизм уведомлений об ошибках, используемый в BGP, предполагает, что TCP поддерживает аккуратное завершение соединений (т. е., все остающиеся данные будут доставлены прежде, чем соединение будет закрыто).

Между парой систем организуется соединение TCP. После этого системы обмениваются между собой стандартными сообщениями для согласования и подтверждения параметров соединения.

Первоначальный поток данных является частью таблицы маршрутизации BGP, которая разрешена политикой экспорта, и называется Adj-Ribs-Out (см. параграф 3.2). В дальнейшем при при изменении таблицы маршрутов передаются нарастающие обновления. BGP не требует периодического обновления таблицы маршрутизации. Чтобы локальные изменения политики могли вступать в силу без сброса соединений, узлу BGP следует (a) сохранять текущую версию маршрутов, анонсированных ему всеми партнерами в течение работы соединения или (b) использовать расширение Route Refresh [RFC2918].

Для обеспечения сохранности соединения периодически передаются сообщения KEEPALIVE. Сообщения NOTIFICATION передаются в ответ на ошибки или при возникновении особых условий. При возникновении ошибок в соединении передается сообщение NOTIFICATION и соединение закрывается.

Партнер в другой AS называется внешним партнером (external peer), а партнер из той же AS называется внутренним (internal peer). Для внутренних и внешних соединений BGP обычно используются аббревиатуры IBGP и EBGP, соответственно.

Если отдельная AS имеет множество узлов BGP и обеспечивает транзит для других AS, внутри этой системы должна обеспечиваться согласованная картина маршрутизации, обеспечиваемая протоколом внутренней маршрутизации (IGP) данной AS. В целях данного документа принимается допущение, что согласованная картина путей за пределы AS обеспечивается за счет организации каждым узлом BGP внутри данной AS соединений IBGP всеми остальными узлами BGP в этой AS.

Данный документ задает поведение протокола BGP. Это поведение может быть изменено (и изменяется) дополнительными спецификациями. При расширении протокола новое поведение полностью документируется в спецификациях расширения.

3.1. Маршруты — анонсирование и хранение

В целях данного протокола маршрут определяется как единица информации, связывающая набор адресатов с путем к этим адресатам. Набором адресатов являются системы, чьи адреса IP содержатся в одном префиксе IP, указываемом полем NLRI сообщения UPDATE, а путь представляет собой информацию, задаваемую в поле атрибутов пути того же сообщения UPDATE.

Маршруты анонсируются между узлами BGP в сообщениях UPDATE. Множество маршрутов с одинаковыми атрибутами пути может быть объединено в одном сообщении UPDATE путем включения множества префиксов в поле NLRI сообщения UPDATE.

Маршруты хранятся в базах маршрутных данных (RIB) Adj-RIBs-In, Loc-RIB и Adj-RIBs-Out, описанных в параграфе 3.2.

Если узел BGP решает анонсировать полученный ранее маршрут, он может добавить или изменить атрибуты пути перед анонсированием маршрута партнерам.

Протокол BGP обеспечивает механизмы, позволяющие узлам BGP информировать своих партнеров о том, что анонсированный ранее маршрут перестал быть доступным. Существует три метода, которые данный узел BGP может использовать для указания отзываемых маршрутов.

• Префикс IP, указывающий адресата ранее анонсированного маршрута, может быть анонсирован в поле WITHDRAWN ROUTES сообщения UPDATE и соответствующий маршрут будет помечен как недоступный для дальнейшего использования.

• Замена маршрута с сохранением ранее анонсированного значения NLRI.

• Узел BGP может закрыть соединение, что приведет к удалению всех маршрутов, которые данная пара узлов анонсировала друг другу.

Изменение одного или нескольких атрибутов маршрута сопровождается анонсированием замены. Анонсируемый измененный маршрут содержит иные атрибуты, но имеет такой же префикс, как и ранее анонсированный маршрут.

3.2. База маршрутной информации RIB

База маршрутной информации (RIB) узла BGP состоит из трех отдельных частей.

• Adj-RIBs-In — маршрутные данные, полученные из входящих сообщений UPDATE, которые были приняты от других узлов BGP. Эта база представляет маршруты, которые могут использоваться как входные данные для процесса принятия решения (Decision Process).

• Loc-RIB — локальная маршрутная информация узла BGP, выбранная путем применения локальной политики к маршрутам, содержащимся в Adj-RIBs-In. Эти маршруты будут использоваться локальным узлом BGP. Значения next hop для каждого из этих маршрутов должны быть преобразуемыми с помощью таблицы маршрутизации (Routing Table) локального узла BGP.

• Adj-RIBs-Out — информация локального узла BGP, выбранная им для анонсирования своим партнерам. Маршрутные данные из Adj-RIBs-Out будут передаваться от локального узла BGP в сообщениях UPDATE для анонсирования партнерам.

Таким образом, Adj-RIBs-In содержит необработанные маршрутные данные, которые были анонсированы локальному узлу BGP его партнерами, Loc-RIB содержит маршруты, которые выбраны в процессе принятия решения локальным узлом BGP, Adj-RIBs-Out содержит маршруты для анонсирования заданным партнерам (в передаваемых локальным узлом сообщениях UPDATE).

Хотя концептуальная модель различает базы Adj-RIBs-In, Loc-RIB и Adj-RIBs-Out это не требует от реализации протокола поддержки трех отдельных копий маршрутной информации. Выбор способа хранения маршрутных данных (например в 3 копиях или 1 копии с указателями) не задается протоколом.

Маршрутная информация, которую узел BGP использует для пересылки пакетов (или для создания таблицы, используемой для пересылки пакетов) сохраняется в таблице маршрутизации. Таблица маршрутизации включает маршруты в непосредственно подключенные сети, статические маршруты, маршруты, полученные от протоколов IGP, и маршруты, полученные от BGP. Включение того или иного маршрута BGP в таблицу маршрутизации или замена маршрута, полученного из других источников, маршрутом BGP определяются локальной политикой, а не спецификациями данного документа. В дополнение к пересылке пакетов таблица маршрутизации используется для преобразования адресов next-hop, заданных в обновлениях BGP (см. параграф 5.1.3).

4. Формат сообщений

В этой главе описан формат сообщений BGP.

Сообщения BGP передаются через соединения TCP. Обработка сообщений производится только после того, как сообщение будет принято полностью. Максимальный размер сообщения составляет 4096 октетов. Все реализации протокола должны поддерживать сообщения максимального размера. Наименьшее сообщение, которое может быть передано, содержит заголовок BGP (19 октетов) без поля данных.

Многооктетные поля передаются с использованием сетевого порядка байтов.

4.1. Формат заголовка

Каждое сообщение BGP имеет заголовок фиксированного размера, за которым может (но не обязано) следовать поле данных, зависящих от типа сообщения. Схема заголовка показана на рисунке.

0                   1                   2                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                           Marker                              |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Length               |      Type     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Marker — маркер
• Это 16-октетное поле включено для обеспечения совместимости и должно содержать 1 в каждом бите.
• Length — размер
• Это 2-октетное целое число без знака показывает общий размер сообщения, (включая заголовок) в октетах. По этому значению можно найти следующее сообщение (начало поля Marker) в потоке TCP. Значение поля Length должно быть не менее 19 и не более 4096. В зависимости от типа сообщения на значение поля размера могут накладываться дополнительные ограничения. Заполнение сообщения дополнительными октетами («padding») после данных не допускается. Следовательно, значение поля Length должно быть наименьшим числом, которое позволит включить оставшуюся часть сообщения.
• Type — тип

• Это 1-октетное целое число без знака содержит код типа сообщения. В данном документе определяются следующие коды типов сообщений:

  • 1 — OPEN
  • 2 — UPDATE
  • 3 — NOTIFICATION
  • 4 — KEEPALIVE

  В [RFC2918] определен один дополнительный код типа.

4.2. Формат сообщения OPEN

После организации соединения TCP первое сообщение от каждой из сторон соединения имеет тип OPEN. После восприятия сообщения OPEN узел BGP возвращает подтверждающее сообщение KEEPALIVE.

В дополнение к стандартному заголовку BGP сообщение OPEN содержит следующие поля:

0                   1                   2                   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
+-+-+-+-+-+-+-+-+
|    Version    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     My Autonomous System      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Hold Time           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         BGP Identifier                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|             Optional Parameters (variable)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Version — версия
• 1-октетное целое число без знака, показывающую номер версии протокола. Текущая версия BGP имеет номер 4.
• My Autonomous System — моя АС
• Это 2-октетное целое число без знака показывает номер AS отправителя сообщения.
• Hold Time — время удержания
• Это 2-октетное целое число без знака показывает число секунд, которое отправитель предлагает установить для таймера удержания (Hold Timer). При получении сообщения OPEN узел BGP должен рассчитать значение Hold Timer, используя меньшее из значений Hold Time в локальной конфигурации и принятом сообщении OPEN. Значение Hold Time должно быть нулевым или не менее 3 секунд. Реализация может отвергать соединения по значению поля Hold Time. Рассчитанное значение показывает максимальное время (в секундах), которое может проходить между получением от партнера сообщений KEEPALIVE и/или UPDATE.
• BGP Identifier — идентификатор BGP
• Это 4-октетное целое число без знака показывает идентификатор BGP отправителя сообщения. Узел BGP устанавливает в качестве идентификатора BGP адрес IP, присвоенный этому узлу BGP. Значение идентификатора BGP определяется при старте узла и совпадает для всех локальных интерфейсов и самого узла BGP.
• Optional Parameters Length — размер дополнительных параметров
• Это 1-октетное целое число без знака показывает общий размер поля Optional Parameters в октетах. Нулевое значение этого поля говорит об отсутствии дополнительных параметров.
• Optional Parameters — дополнительные параметры

• Это поле содержит список дополнительных параметров, представленных в формате <Parameter Type, Parameter Length, Parameter Value>.

  0                   1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
  |  Parm. Type   | Parm. Length  |  Parameter Value (variable)
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

  Однооктетное поле типа (Parameter Type) обеспечивает однозначную идентификацию параметра. Однооктетное поле размера (Parameter Length) показывает размер поля Parameter Value в октетах. Значение параметра (Parameter Value) имеет переменный размер и интерпретируется в соответствии с типом параметра (поле Parameter Type).

  В [RFC3392] определен дополнительный параметр Capabilities (возможности).

Минимальный размер сообщения OPEN составляет 29 октетов (с учетом заголовка).

4.3. Формат сообщения UPDATE

Сообщения UPDATE используются для передачи маршрутной информации между партнерами BGP. Данные из сообщений UPDATE могут использоваться для построения графа, описывающего связи между различными AS. Применение обсуждаемых в этом документе правил позволяет избавиться от петель и некоторых других аномалий в маршрутизации между AS.

Сообщение UPDATE служит для анонсирования доступных маршрутов с общими атрибутами пути узлу-партнеру или для отзыва группы анонсированных ранее маршрутов (см. 3.1). Сообщение UPDATE может одновременно анонсировать доступный маршрут и отзывать группу недоступных более маршрутов. Сообщения UPDATE всегда включают заголовок BGP фиксированного размера, а также другие поля, показанные на рисунке (отметим, что некоторые из этих полей являются необязательными).

+-----------------------------------------------------+
|   Withdrawn Routes Length (2 octets)                |
+-----------------------------------------------------+
|   Withdrawn Routes (variable)                       |
+-----------------------------------------------------+
|   Total Path Attribute Length (2 octets)            |
+-----------------------------------------------------+
|   Path Attributes (variable)                        |
+-----------------------------------------------------+
|   Network Layer Reachability Information (variable) |
+-----------------------------------------------------+

• Withdrawn Routes Length — размер аннулируемых маршрутов

• Это 2-октетное целое число без знакa указывает общий размер поля Withdrawn Routes в октетах. Значение этого поля должно позволять определение размера поля Network Layer Reachability Information в соответствии с приведенным ниже описанием.

  Нулевое значение говорит об отсутствии отзываемых маршрутов и поля Withdrawn Routes в сообщении UPDATE.

• Withdrawn Routes — отзываемые маршруты

• Это поле переменной длины содержит список префиксов IP-адресов для маршрутов, которые отзываются. Каждый префикс представляется парой <length, prefix> в формате, показанном на рисунке.

  Ниже описано назначение полей.

  +---------------------------+
  |   Length (1 octet)        |
  +---------------------------+
  |   Prefix (variable)       |
  +---------------------------+

  • Length — размер

    Поле Length показывает размер адресного префикса IP в битах. Нулевое значение размера указывает на префикс, которому соответствуют все адреса IP (сам префикс содержит 0 октетов).

  • Prefix — префикс

    Поле Prefix содержит префикс адресов IP, за которым следует минимально возможное количество битов заполнения, служащих для выравнивания по границе октета. Отметим, что значения битов заполнения не принимаются во внимание.

• Total Path Attribute Length — общий размер атрибутов пути.

• Это 2-октетное целое число без знака показывает общий размер поля Path Attributes в октетах. Данное значение позволяет определить размер поля Network Layer Reachability Information, как описано ниже.

  Нулевое значение поля говорит об отсутствии полей Network Layer Reachability Information и Path Attribute в данном сообщении UPDATE.

• Path Attributes — атрибуты пути

• Последовательность переменной длины с атрибутами пути присутствует в каждом сообщении UPDATE за исключением тех сообщений, которые служат только для отзыва маршрутов. Каждый атрибут пути представляется триплетом <attribute type, attribute length, attribute value> переменной длины.

  Поле типа (Attribute Type) является двухоктетным и состоит из октета флагов (Attribute Flags), за которым следует октет кода типа (Attribute Type Code).

  0                   1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Attr. Flags  |Attr. Type Code|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Старший бит (бит 0) октета Attribute Flags является флагом Optional и показывает относится данный атрибут к числу дополнительных (1) или общеизвестных (0).

  Следующий по старшинству бит (бит 1) октета Attribute Flags является флагом транзитивности (Transitive), который определяет является атрибут транзитивным (1) или нетранзитивным (0).

  Для общеизвестных (well-known) атрибутов флаг Transitive должен устанавливаться в 1 (см. обсуждение транзитивных атрибутов в разделе 5).

  Следующий бит (бит 2) октета Attribute Flags является флагом Partial и показывает, является информация, содержащаяся в дополнительном транзитивном атрибуте частичной (1) или полной (0). Для общеизвестных атрибутов и дополнительных непереходных атрибутов флаг Partial должен иметь значение 0.

  Четвертый по старшинству бит (бит 3) октета Attribute Flags является флагом расширенного размера (Extended Length) и определяет размер поля Attribute Length — 1 октет (0) или 2 октета (1).

  Четыре младших бита октета Attribute Flags не используются. Отправитель должен устанавливать для них нулевые значения, а получатель должен игнорировать эти биты.

  Октет Attribute Type Code содержит код типа атрибута. Определенные в настоящий момент коды типов перечислены в разделе 5.

  Если бит Extended Length октета Attribute Flags имеет значение 0, третий октет Path Attribute содержит значение размера данных атрибута в октетах. При значении бита Extended Length = 1 третий и четвертый октеты атрибута пути содержат размер данных атрибута в октетах.

  Остальные октеты поля Path Attribute представляют собой значение атрибута и интерпретируются в соответствии со значениями октетов Attribute Flags и Attribute Type Code. Коды поддерживаемых типов (Attribute Type Code) и значения их атрибутов описаны ниже.

  • ORIGIN (тип 1):

    Атрибут ORIGIN относится к числу общеизвестных и обязательных, определяя источник маршрутной информации. Октет данных может содержать значения, приведенные в таблице:

    Значение	Описание
    0	IGP — данные NLRI являются внутренними для исходной AS
    1	EGP — данные NLRI получены от протокола EGP [RFC904]
    2	INCOMPLETE — данные NLRI получены из иных источников.

    Использование этого атрибута рассматривается в параграфе 5.1.1.

  • AS_PATH (тип 2):

    Общеизвестный обязательный атрибут AS_PATH состоит из последовательности сегментов AS path. Каждый сегмент представляется триплетом <path segment type, path segment length, path segment value>.

    Тип сегмента пути (path segment type) представляет собой 1-октетное поле, для которого определены следующие значения:

    Значение	Тип сегмента
    1	AS_SET — неупорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE.
    2	AS_SEQUENCE — упорядоченный набор AS (последовательность), через которые проходит маршрут из сообщения UPDATE.

    Размер сегмента пути (path segment length) представляет собой 1-октетное поле, в котором указывается число номеров AS (не число октетов) в поле path segment value. Поле сегмента пути (path segment value) содержит один или множество номеров AS, каждый из которых представляется 2-октетным полем. Использование этого атрибута рассматривается в параграфе 5.1.2.

  • NEXT_HOP (тип 3):

    Этот общеизвестный обязательный атрибут определяет (индивидуальный) IP-адрес маршрутизатора, который следует использовать в качестве следующего этапа на пути к адресатам, указанным в поле NLRI сообщения UPDATE.

    Использование этого атрибута рассматривается в параграфе 5.1.3.

  • MULTI_EXIT_DISC (тип 4):

    Этот необязательный, непереходный атрибут представляет собой 4-октетное целое число без знака. Значение атрибута может использоваться узлом BGP в процессе выбора маршрутов (Decision Process) для разделения множества точек входа в соседнюю АС.

    Использование этого атрибута рассматривается в параграфе 5.1.4.

  • LOCAL_PREF (тип 5):

    Общеизвестный атрибут LOCAL_PREF представляет собой 4-октетное целое число без знака. Узел BGP использует этот атрибут для информирования своих внутренних партнеров, показывая свой уровень предпочтения для анонсируемого маршрута.

    Использование этого атрибута рассматривается в параграфе 5.1.5.

  • ATOMIC_AGGREGATE (тип 6)

    ATOMIC_AGGREGATE является общеизвестным необязательным атрибутом нулевой длины.

    Использование этого атрибута рассматривается в параграфе 5.1.6.

  • AGGREGATOR (тип 7)

    Необязательный транзитивный атрибут AGGREGATOR имеет размер 6 октетов. Этот атрибут содержит номер последней AS, формирующей агрегированный маршрут (2 октета), после которого указан IP-адрес узла BGP, создавшего агрегированный маршрут (4 октета). Для этого поля следует устанавливать тот же адрес, который используется для поля BGP Identifier узла, создавшего агрегированный маршрут.

    Использование этого атрибута рассматривается в параграфе 5.1.7.

• Network Layer Reachability Information

• Это поле переменной длины содержит список адресных префиксов IP. Число октетов в поле Network Layer Reachability Information не задается явно, но может быть вычислено по формуле:

  Поле Length сообщения UPDATE — 23 — Total Path Attributes Length — Withdrawn Routes Length

  Значение поля Length для сообщения UPDATE указано в постоянной части заголовке BGP, Значения полей Total Path Attribute Length и Withdrawn Routes Length указываются в переменной части сообщения UPDATE, а 23 представляет собой суммарный размер постоянного заголовка BGP и полей Total Path Attribute Length, Withdrawn Routes Length.

  Информация о доступности представляется в форме одной или множества пар <length, prefix>.

  +---------------------------+
  |   Length (1 octet)        |
  +---------------------------+
  |   Prefix (variable)       |
  +---------------------------+

  Назначение полей пары описано ниже:

  • Length — размер

    Поле Length показывает размер адресного префикса IP в битах. Нулевое значение размера указывает на префикс, которому соответствуют все адреса IP (сам префикс содержит 0 октетов).

  • Prefix — префикс

    Поле Prefix содержит префикс адресов IP, за которым следует минимально возможное количество битов заполнения, служащих для выравнивания по границе октета. Отметим, что значения битов заполнения не принимаются во внимание.

Минимальный размер сообщения UPDATE составляет 23 октета; 19 занимает постоянный заголовок BGP, 2 октета — поле Withdrawn Routes Length и 2 октета — Total Path Attribute Length (поля Withdrawn Routes Length и Total Path Attribute Length в этом случае содержат значение 0).

Сообщение UPDATE может анонсировать не более одного набора атрибутов пути, но этому пути может соответствовать множество адресатов, путь к которым описывается общим набором атрибутов. Все атрибуты пути, содержащиеся в данном сообщении UPDATE, применимы к каждому из адресатов, соответствующих значению поля NLRI в сообщении UPDATE.

Сообщение UPDATE может содержать множество аннулируемых маршрутов. Каждый из таких маршрутов идентифицируется своим адресатом (указывается префиксом IP), однозначно определяющим маршрут в контексте соединения между парой узлов BGP, для которого ранее этот маршрут был анонсирован.

Сообщение UPDATE может анонсировать только отзываемые маршруты — в таких случаях сообщение не будет включать атрибутов пути и поля NLRI. Если же сообщение анонсирует только доступные маршруты, в него не требуется включать поле WITHDRAWN ROUTES.

В сообщениях UPDATE не следует указывать один и тот же префикс в полях WITHDRAWN ROUTES и NLRI. Однако узел BGP должен быть способен к обработке сообщений такого типа. Узлу BGP следует трактовать такие сообщения UPDATE, как будто они не содержат адресного префикса в поле WITHDRAWN ROUTES.

4.4. Формат сообщения KEEPALIVE

BGP не использует на уровне TCP каких-либо механизмов для проверки доступности других узлов. Вместо этого используются сообщения KEEPALIVE, которыми партнеры обмениваются достаточно часто, чтобы между двумя сообщениями не истекло время, заданное таймером удержания (Hold Timer). Разумным значением максимального интервала между передачей двух последовательных сообщений KEEPALIVE является треть интервала, заданного значением Hold Time. Недопустимо передавать сообщения KEEPALIVE чаще одного раза в секунду. Разработчики могут установить интервал между передачей сообщений KEEPALIVE, как функцию значения Hold Time.

Если Hold Time = 0, периодическая передача сообщений KEEPALIVE недопустима.

Сообщение KEEPALIVE состоит только из заголовка, следовательно, размер такого сообщения равен 19 октетам.

4.5. Формат сообщения NOTIFICATION

Сообщения NOTIFICATION передаются в случаях обнаружения ошибок. Соединение BGP незамедлительно закрывается после передачи такого сообщения.

В дополнение к постоянному заголовку BGP сообщения NOTIFICATION содержат описанные ниже поля.

0                   1                   2                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code    | Error subcode |   Data (variable)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Error Code — код ошибки

• Это 1-октетное целое число без знака показывает тип сообщения NOTIFICATION. Коды типов перечислены в таблице.

  Код	Символьное имя	Описание
  1	Message Header Error — ошибка в заголовке сообщения	параграф 6.1
  2	OPEN Message Error — ошибка в сообщении OPEN	параграф 6.2
  3	UPDATE Message Error — ошибка в сообщении UPDATE	параграф 6.3
  4	Hold Timer Expired — истекло время удержания	параграф 6.5
  5	Finite State Machine Error — ошибка машины конечных состояний	параграф 6.6
  6	Cease — разрыв соединения	параграф 6.7

• Error subcode — субкод ошибки

• Это 1-октетное целое число без знака содержит более конкретную информацию о природе ошибки. С каждым кодом ошибки (Error Code) может быть связан один или несколько субкодов (Error Subcode). При отсутствии субкода для ошибки в поле Error Subcode помещается нулевое значение.

  • Субкоды для Message Header Error

  • 1 — Connection Not Synchronized — соединение не синхронизировано.
  • 2 — Bad Message Length — некорректный размер сообщения.

  • 3 — Bad Message Type -некорректный тип сообщения.

  • Субкоды для OPEN Message Error

  • 1 — Unsupported Version Number — неподдерживаемый номер версии.
  • 2 — Bad Peer AS — некорректный номер AS у партнера.
  • 3 — Bad BGP Identifier — некорректный идентификатор BGP.
  • 4 — Unsupported Optional Parameter — неподдерживаемый дополнительный параметр.
  • 5 — [Не используется, см. Приложение A].

  • 6 — Unacceptable Hold Time — недопустимое значение времени удержания.

  • Субкоды для UPDATE Message Error

  • 1 — Malformed Attribute List — некорректно сформированный список атрибутов.
  • 2 — Unrecognized Well-known Attribute — нераспознанный общеизвестный атрибут.
  • 3 — Missing Well-known Attribute — отсутствует обязательный атрибут.
  • 4 — Attribute Flags Error некорректные флаги атрибута.
  • 5 — Attribute Length Error — некорректный размер атрибута.
  • 6 — Invalid ORIGIN Attribute — некорректный атрибут ORIGIN.
  • 7 — [Не используется, см. Приложение A].
  • 8 — Invalid NEXT_HOP Attribute — некорректный атрибут NEXT_HOP.
  • 9 — Optional Attribute Error — ошибка в дополнительном атрибуте.
  • 10 — Invalid Network Field некорректное указание сети.

  • 11 — Malformed AS_PATH — некорректный формат AS_PATH.

• Data — данные

• Это поле переменной длины служит для диагностики причины генерации сообщений NOTIFICATION. Содержимое поля данных зависит от значений полей Error Code и Error Subcode. Дополнительная информация приведена в главе 6.

  Отметим, что размер поля Data можно определить на основании значения поля Length в заголовке сообщения по формуле:

  Message Length = 21 + Data Length

  Минимальный размер сообщений NOTIFICATION составляет 21 октет (с учетом заголовка).

5. Атрибуты пути

В этой главе рассматриваются атрибуты пути, используемые в сообщениях UPDATE.

Атрибуты делятся на 4 категории:

1. Well-known mandatory — общеизвестные, обязательные.
2. Well-known discretionary — общеизвестные, необязательные.
3. Optional transitive — дополнительные, транзитивные (переходные).
4. Optional non-transitive — дополнительные, непереходные.

Реализации BGP должны распознавать все общеизвестные атрибуты. Некоторые из этих атрибутов являются обязательными и должны включаться в каждое сообщение UPDATE, содержащее поле NLRI. Остальные атрибуты являются необязательными и могут включаться или не включаться в сообщения UPDATE.

После того, как узел BGP обновит значения любого из общеизвестных атрибутов, он должен сообщить измененные атрибуты своим партнерам в передаваемых обновлениях.

Кроме общеизвестных атрибутов каждый путь может содержать один или несколько дополнительных атрибутов. Поддержка дополнительных атрибутов не является обязательной для каждой реализации BGP. Обработка нераспознанных дополнительных атрибутов определяется значением бита Transitive в октете флагов атрибута. Пути с нераспознанными переходными дополнительными атрибутами следует принимать. Если путь с нераспознанными дополнительными переходными атрибутами принят и передается другим узлам BGP, нераспознанные атрибуты этого пути должны передаваться другим узлам BGP с установленным (1) битом Partial в поле Attribute Flags. Если путь с распознанным переходным атрибутом воспринят и передается другим узлам BGP, а бит Partial октета Attribute Flags имеет значение 1, установленное какой-либо из предыдущих AS, данная автономная система не должна сбрасывать этот бит в 0. Нераспознанные дополнительные непереходные атрибуты следует просто игнорировать, не передавая их другим узлам BGP. Если путь с распознанными транзитивными атрибутами передается другим партнерам BGP и значение бита Partial в поле Attribute Flags уже установлено в 1 какой-либо из предшествующих AS, для текущей AS недопустимо сбрасывать этот бит в 0. Нераспознанные нетранзитивные дополнительные атрибуты должны игнорироваться без каких-либо действий и передачи другим партнерам BGP.

Новые дополнительные переходные атрибуты могут добавляться в конце пути исходным отправителем (originator) или любым узлом BGP на пути. Если эти атрибуты не добавлены исходным отправителем, для бита Partial в октете Attribute Flags устанавливается значение 1. Правила присоединения новых непереходных дополнительных атрибутов зависят от природы конкретного атрибута. Предполагается, что документация к каждому новому дополнительному непереходному атрибуту будет включать такие правила (описание атрибута MULTI_EXIT_DISC может служить примером). Все дополнительные атрибуты (переходные и непереходные) могут обновляться (если это допустимо) узлами BGP в пути.

Отправителю сообщения UPDATE следует размещать атрибуты пути в сообщениях UPDATE в порядке возрастания типа атрибутов. Получатель сообщения UPDATE должен быть готов к обработке неупорядоченных атрибутов пути из сообщения UPDATE.

Один и тот же атрибут (несколько экземпляров одного типа) не может включаться несколько раз в поле Path Attributes сообщения UPDATE.

Обязательные атрибуты должны присутствовать в сообщениях, передаваемых в IBGP и EBGP, если сообщение UPDATE включает поле NLRI. Использование дополнительных атрибутов может определяться по собственному усмотрению, требоваться или запрещаться в зависимости от контекста.

5.1. Использование атрибутов пути

Ниже описывается использование всех атрибутов пути BGP.

5.1.1. ORIGIN

Атрибут ORIGIN является общеизвестным и обязательным. Этот атрибут генерируется автономной системой, которая является исходным отправителем маршрутной информации. Другим узлам BGP не следует изменять значение этого атрибута.

5.1.2. AS_PATH

AS_PATH относится к общеизвестным обязательным атрибутам и служит для идентификации автономных систем, через которые передается информация в данном сообщении UPDATE. Компонентами списка автономных систем являются поля AS_SET или AS_SEQUENCE.

Когда узел BGP распространяет маршрут, который был получен из сообщения UPDATE от другого узла BGP в сообщении UPDATE, он должен изменить в маршруте атрибут AS_PATH с учетом размещения узла BGP, которому передается маршрут:

• Когда узел BGP анонсирует маршрут внутреннему партнеру, анонсирующему узлу не следует изменять связанный с этим маршрутом атрибут AS_PATH.

• Когда узел BGP анонсирует маршрут внешнему партнеру, анонсирующий узел обновляет атрибут AS_PATH, как показано ниже:

  1. Если первый сегмент пути в AS_PATH имеет тип AS_SEQUENCE, локальному узлу следует поместить свой номер AS в качестве последнего элемента списка (в крайнюю левую позицию со смещением вправо остальных октетов протокольного сообщения). Если такое включение будет приводить к переполнению сегмента AS_PATH (т. е., число AS превысит 255 ), следует добавить впереди (prepend) новый сегмент, указав в нем свой номер AS.

  2. Если первый сегмент пути в AS_PATH имеет тип AS_SET, локальная система добавляет впереди (prepend) новый сегмент типа AS_SEQUENCE, включая в него свой номер AS.

  3. При пустом AS_PATH локальная система создает сегмент пути типа AS_SEQUENCE, помещает в него свой номер AS и включает этот сегмент в AS_PATH.

Когда узел BGP является источником маршрута:

• этот узел включает свой номер AS в сегмент пути типа AS_SEQUENCE атрибута AS_PATH всех сообщений UPDATE, передаваемых внешним партнерам. В таких случаях номер AS являющегося источником маршрута узла будет единственным элементом сегмента пути, а данный сегмент будет единственным в атрибуте AS_PATH.

• этот узел включает пустой атрибут AS_PATH во все сообщения UPDATE, передаваемые внутренним партнерам (пустой атрибут AS_PATH имеет нулевое значение в поле размера).

Всякий раз, когда изменение атрибута AS_PATH связано с включением или добавлением впереди номера AS локальной системы, эта система может включать/добавлять впереди более одного экземпляра своего номера AS в атрибут AS_PATH. Этот процесс определяется параметрами локальной конфигурации.

5.1.3. NEXT_HOP

Общеизвестный обязательный атрибут NEXT_HOP определяет IP-адрес маршрутизатора, который следует использовать в качестве следующего интервала на пути к адресатам, указанным в сообщении UPDATE. Атрибут NEXT_HOP определяется следующим образом:

1. При передаче сообщения внутреннему партнеру, если маршрут имеет нелокальное происхождение, узлу BGP не следует изменять значение NEXT_HOP за исключением тех случаев, когда он явно настроен на анонсирование своего адреса IP в качестве NEXT_HOP. При анонсировании внутренним партнерам маршрутов локального происхождения, узлу BGP следует использовать в качестве NEXT_HOP адрес внутреннего интерфейса, через который анонсируемая сеть доступна для принимающего анонс узла. Если маршрут непосредственно соединен с анонсирующим узлом или адрес интерфейса, через который узлу доступна анонсируемая сеть, является адресом внутреннего партнера, узлу BGP следует использовать свой адрес IP (адрес интерфейса, через который доступен партнер) в качестве значения атрибута NEXT_HOP.

2. При передаче сообщения внешнему партнеру X, когда тот находится на расстоянии одного интервала IP от данного узла:

   • Если анонсируемый маршрут получен от внутреннего партнера или имеет локальное происхождение, узел BGP может использовать в качестве атрибута NEXT_HOP адрес интерфейса внутреннего партнера (или внутреннего маршрутизатора), через который анонсируемая сеть доступна для данного узла. В этом случае партнер X будет иметь общую подсеть с указанным адресом. Этот случай является вариантом NEXT_HOP из «третьих рук» (third party).

   • В остальных случаях, если анонсируемый маршрут получен от внешнего партнера, узел BGP может использовать в атрибуте NEXT_HOP адрес IP любого смежного маршрутизатора (известный из принятого атрибута NEXT_HOP), который данный узел использует для локального определения маршрута, В таких случаях X имеет с указанным адресом общую подсеть. Этот случай является вариантом NEXT_HOP из «третьих рук».

   • В противном случае, если внешний партнер, для которого анонсируется маршрут, имеет общую подсеть с одним из интерфейсов анонсирующего узла, последний может использовать связанный с таким интерфейсом адрес IP в качестве значения атрибута NEXT_HOP. Этот случай является вариантом NEXT_HOP из «первых рук» (first party).

   • По умолчанию (если не выполняется ни одно из перечисленных выше условий), узлу BGP следует использовать в качестве атрибута NEXT_HOP IP-адрес интерфейса, который служит данному узлу для организации соединения BGP с партнером X.

3. При передаче сообщения внешнему партнеру X, находящемуся на расстоянии нескольких интервалов IP от данного узла (multihop EBGP):

   • Узел может быть настроен на распространение атрибута NEXT_HOP. В таких случаях при анонсировании полученного от одного из партнеров маршрута узел должен указывать в качестве атрибута NEXT_HOP в анонсируемом маршруте значение NEXT_HOP, полученное в анонсе маршрута от партнера (т. е, узел не изменяет значение NEXT_HOP).

   • По умолчанию узлу BGP следует использовать IP-адрес интерфейса, который узел указывает в атрибуте NEXT_HOP для организации соединения BGP с узлом X.

Обычно значение атрибута NEXT_HOP выбирается так, чтобы принимался кратчайший из возможных путей. Узел BGP должен обеспечивать возможность запрета анонсирования атрибутов NEXT_HOP, полученных «из третьих рук» для работы в сетях с несовершенными мостами.

Маршрут, порожденный узлом BGP, не следует анонсировать партнеру с использованием в качестве атрибута NEXT_HOP адреса этого партнера. Узлу BGP не следует устанавливать маршруты со своим адресом в качестве NEXT_HOP.

Атрибут NEXT_HOP используется узлами BGP для определения реального выходного интерфейса и адреса ближайшего маршрутизатора (immediate next-hop address), по которому следует пересылать транзитные пакеты для связанных с маршрутом адресатов.

Адрес ближайшего маршрутизатора определяется путем рекурсивного просмотра маршрутов для IP-адреса из атрибута NEXT_HOP, использования содержимого таблицы маршрутизации (Routing Table) и выбора одной записи, если существует множество равноценных путей. Запись таблицы маршрутизации, которая соответствует IP-адресу из атрибута NEXT_HOP, всегда будет задавать выходной интерфейс. Если запись таблицы маршрутизации указывает подключенную подсеть, но не задает адрес next-hop, тогда адрес из атрибута NEXT_HOP следует использовать в качестве адреса ближайшего маршрутизатора. Если запись в таблице также содержит адрес next-hop, этот адрес следует использовать в качестве адреса ближайшего маршрутизатора для пересылки пакетов.

5.1.4. MULTI_EXIT_DISC

Дополнительный непереходный атрибут MULTI_EXIT_DISC предназначен для использования на внешних (между AS) соединениях при выборе из множества путей в одну смежную AS. Значение атрибута MULTI_EXIT_DISC представляет собой 4-октетное целое число без знака, которое называют метрикой. При прочих равных из нескольких маршрутов следует выбирать тот, у которого меньше значение метрики. При получении через EBGP атрибут MULTI_EXIT_DISC можно распространять через IBGP другим узлам BGP в данной AS (см. также параграф 9.1.2.2). Атрибут MULTI_EXIT_DISC, полученный из соседней AS, недопустимо распространять в другие соседние AS.

Узел BGP должен обеспечивать механизм, позволяющий в соответствии с локальной конфигурацией удалять из маршрутов атрибут MULTI_EXIT_DISC. Если узел BGP настроен на удаление атрибута MULTI_EXIT_DISC из маршрутов, такое удаление должно выполняться до того, как будет определяться предпочтительный маршрут или происходить выбор маршрута (фазы 1 и 2 Decision Process).

Реализация может также в соответствии с локальной конфигурацией изменять значение атрибутов MULTI_EXIT_DISC, полученных через EBGP. Если узел BGP настроен на изменение значений атрибута MULTI_EXIT_DISC, принятых через EBGP, такое изменение должно выполняться до того, как будет определяться предпочтительный маршрут или происходить выбор маршрута (фазы 1 и 2 Decision Process). Некоторые ограничения описаны в параграфе 9.1.2.2.

5.1.5. LOCAL_PREF

Атрибут LOCAL_PREF относится к числу общеизвестных необязательных. Это атрибут следует включать во все сообщения UPDATE, которые данный узел BGP передает внутренним партнерам (узлам BGP, расположенным в той же автономной системе). Узлу BGP следует рассчитать уровень предпочтения для каждого внешнего маршрута на основе локальной политики и включать этот уровень в анонсы для внутренних партнеров. Предпочтение должно отдаваться маршрутам с более высоким уровнем. Узел BGP использует уровень предпочтения из LOCAL_PREF, в процессе выбора маршрутов (см. параграф 9.1.1).

Для узлов BGP недопустимо включение этого атрибута в сообщения UPDATE, передаваемые внешним партнерам, за исключением случаев использования конфедераций BGP [RFC3065]. Если атрибут содержится в сообщении UPDATE, полученном от внешнего партнера, принимающий узел должен игнорировать этот атрибут, за исключением случаев использования конфедераций BGP [RFC3065].

5.1.6. ATOMIC_AGGREGATE

Атрибут ATOMIC_AGGREGATE относится к числу общеизвестных, но не обязательных.

Когда узел BGP объединяет (агрегирует) несколько маршрутов с целью анонсирования отдельному партнеру, значение AS_PATH агрегированного маршрута обычно включает сегмент AS_SET из набора AS, для которых выполняется объединение маршрутов. Во многих случаях администратор сети может определить возможность агрегирования маршрутов без анонсирования AS_SET, чтобы при этом не возникало маршрутных петель.

Если агрегирование не включает по крайней мере некоторые AS из атрибутов AS_PATH объединяемых маршрутов, в создаваемый агрегированный маршрут при анонсировании его партнеру следует включать атрибут ATOMIC_AGGREGATE.

Узлу BGP, получившему маршрут с атрибутом ATOMIC_AGGREGATE, не следует удалять этот атрибут при распространении маршрута другим узлам.

Для узла BGP, получившего маршрут с атрибутом ATOMIC_AGGREGATE, недопустимо указание каких-либо NLRI из этого маршрута как более специфичных (в соответствии с определением параграфа 9.1.4) при анонсировании данного маршрута другим узлам BGP.

Узлу BGP, получившему маршрут с атрибутом ATOMIC_AGGREGATE, следует отдавать себе отчет в том, что актуальный путь к адресату, указанному в NLRI этого маршрута, хотя и не содержит петель, может не совпадать с путем, заданным в атрибуте AS_PATH этого маршрута.

5.1.7. AGGREGATOR

Дополнительный транзитивный атрибут AGGREGATOR может включаться в обновления, формируемые при объединении маршрутов (см. параграф 9.2.2.2). Узел BGP, выполняющий агрегирование, может добавлять атрибут AGGREGATOR, в который при этом следует включать свой номер AS и адрес IP. Адрес IP следует указывать тот же, который используется для поля BGP Identifier данного узла.

6. Обработка ошибок BGP

В этой главе рассматриваются действия, предпринимаемые при обнаружении ошибок в процессе обработки сообщений BGP.

При выполнении любого из описанных здесь условий передается сообщение NOTIFICATION с соответствующими значениями кода (Error Code) и субкода (Error Subcode) ошибки, а также полем Data и соединение BGP закрывается (если явно не указано, что передается сообщение NOTIFICATION, но соединение BGP не закрывается). Если субкод ошибки не указан, должно использоваться нулевое значение.

Фраза «соединение BGP разрывается» означает, что закрывается соединение TCP, очищается связанная с соединением BGP база Adj-RIB-In и удаляются все ресурсы, выделенные данному соединению BGP. Записи в базе Loc-RIB, связанные с удаленным партнером, помечаются как некорректные. Локальная система заново рассчитывает наилучшие маршруты для адресатов, маршруты к которым помечены как некорректные. До удаления некорректных маршрутов из таблицы они анонсируются партнерам путем отзыва ставших некорректными маршрутов или задания новых маршрутов взамен некорректных.

Если явно не указано иное, поле Data сообщений NOTIFICATION, передаваемых для индикации ошибок, остается пустым.

6.1. Отработка ошибок в заголовках сообщений

Все ошибки, обнаруживаемые при обработке заголовка сообщения, должны указываться путем передачи сообщений NOTIFICATION с кодом ошибки Message Header Error (ошибка в заголовке сообщения). Поле Error Subcode указывает природу ошибки более точно.

Ожидаемое в заголовке сообщения значение поля Marker состоит только из единиц. Если поле Marker в заголовке сообщения содержит неожиданное значение, возникает ошибка синхронизации и в поле Error Subcode должно указываться значение Connection Not Synchronized (соединение не синхронизировано).

Если выполняется хотя бы одно из перечисленных здесь условий:

• поле Length в заголовке сообщения содержит значение меньше 19 или больше 4096;
• значение поля Length в заголовке сообщения OPEN меньше минимального размера сообщения OPEN;
• значение поля Length в заголовке сообщения UPDATE меньше минимального размера сообщения UPDATE;
• значение поля Length в заголовке сообщения KEEPALIVE не равно 19;
• значение поля Length в заголовке сообщения NOTIFICATION меньше минимального размера сообщения NOTIFICATION,

для поля Error Subcode должно устанавливаться значение Bad Message Length (некорректный размер сообщения). Поле Data в таких случаях должно содержать ошибочное значение поля Length.

Если не распознано поле Type в заголовке сообщения, в поле Error Subcode должно помещаться значение Bad Message Type (некорректный тип сообщения). Поле Data в таких случаях должно содержать ошибочное значение поля Type.

6.2. Отработка ошибок в сообщениях OPEN

Все ошибки, детектируемые в процессе обработки сообщений OPEN, должны указываться сообщениями NOTIFICATION с Error Code = OPEN Message Error. Значение Error Subcode уточняет природу ошибки.

Если версия протокола, указанная в поле Version полученного сообщения OPEN, не поддерживается, должно устанавливаться значение Error Subcode = Unsupported Version Number. Поле Data в таких случаях представляет собой 2-октетное целое число без знака, которое показывает (в старшем октете) насколько наибольший номер версии, поддерживаемой локально, меньше номера версии, предложенного удаленным партнером BGP (показан в принятом сообщении OPEN) или (в младшем октете) насколько наименьший локально поддерживаемый номер версии больше предложенного удаленным партнером BGP.

Если поле My Autonomous System в сообщении OPEN содержит неприемлемое значение, в поле Error Subcode должно помещаться значение Bad Peer AS. Определение допустимости номеров AS выходит за пределы спецификации данного протокола.

Если значение поля Hold Time в принятом сообщении OPEN неприемлемо, должно устанавливаться значение Error Subcode = Unacceptable Hold Time. Реализация должна отвергать значения Hold Time в одну или две секунды. Реализация может отвергнуть любое предложенное значение Hold Time. Реализация, принявшая значение Hold Time, должна использовать согласованное значение параметра Hold Time.

Если поле BGP Identifier в принятом сообщении OPEN синтаксически некорректно, должно устанавливаться значение Error Subcode = Bad BGP Identifier. Синтаксическая корректность означает, что поле BGP Identifier содержит допустимый индивидуальный (unicast) IP-адрес хоста.

Если не распознано поле Optional Parameters в принятом сообщении OPEN, должно устанавливаться Error Subcode = Unsupported Optional Parameters.

Если один из дополнительных параметров принятого сообщения OPEN распознан, но имеет некорректный формат, должно устанавливаться значение Error Subcode = 0.

6.3. Отработка ошибок в сообщениях UPDATE

Все ошибки, детектируемые при обработке сообщений UPDATE, должны приводить к генерации сообщения NOTIFICATION с Error Code = UPDATE Message Error. Субкод ошибки уточняет ее природу.

Проверка ошибок в сообщении UPDATE начинается с атрибутов пути. Если значение поля Withdrawn Routes Length или Total Attribute Length слишком велико (т. е., Withdrawn Routes Length + Total Attribute Length + 23 превосходит значение поля Length в заголовке сообщения), в поле Error Subcode должно устанавливаться значение Malformed Attribute List.

Если в любом распознанном атрибуте возникает конфликт флагов (Attribute Flags) и типа атрибута (Attribute Type Code), должно устанавливаться значение Error Subcode = Attribute Flags Error. В поле Data должен включаться связанный с ошибкой атрибут (тип, размер и значение).

Если в любом распознанном атрибуте размер (Attribute Length) конфликтует с ожидаемым (на основе кода типа) значением, должно устанавливаться значение Error Subcode = Attribute Length Error. В поле Data должен включаться связанный с ошибкой атрибут (тип, размер и значение).

При отсутствии любого из общеизвестных обязательных атрибутов, должен устанавливаться субкод Missing Well-known Attribute, а в поле Data должен включаться код типа (Attribute Type Code) пропущенного атрибута.

Если не распознан любой из общеизвестных обязательных атрибутов, должно устанавливаться значение Error Subcode = Unrecognized Well-known Attribute, а в поле Data должен включаться нераспознанный атрибут (тип, размер и значение).

Если атрибут ORIGIN имеет неопределенный тип, в поле Error Subcode должно указываться значение Invalid Origin Attribute, а в поле Data должен включаться нераспознанный атрибут (тип, размер и значение).

Если поле атрибута NEXT_HOP синтаксически некорректно, для поля Error Subcode должно устанавливаться значение Invalid NEXT_HOP Attribute. Поле Data должно содержать некорректный атрибут (тип, размер и значение). Синтаксическая корректность означает, что атрибут NEXT_HOP содержит допустимый IP-адрес хоста.

Семантически корректный адрес IP в поле NEXT_HOP должен соответствовать двум критериям:

• недопустимо включать в это поле IP-адрес принимающего узла;
• в случае EBGP, когда отправитель и получатель расположены на расстоянии одного интервала (one IP hop), IP-адрес в поле NEXT_HOP должен быть IP-адресом отправителя, использованным для организации соединения BGP, или интерфейс, связанный с адресом из поля NEXT_HOP, должен находиться в одной подсети с принимающим узлом BGP.

Если атрибут NEXT_HOP семантически некорректен, следует записать информацию об этом в журнальный файл системы, маршрут следует игнорировать. В таких случаях передавать сообщение NOTIFICATION и разрывать соединение не следует.

Проверяется синтаксическая корректность атрибута AS_PATH. При наличии синтаксических ошибок в пути должно устанавливаться значение Error Subcode = Malformed AS_PATH.

Если сообщение UPDATE получено от внешнего партнера, локальная система может проверить совпадение расположенного слева (по порядку октетов протокольного сообщения) номера AS в атрибуте AS_PATH с номером автономной системы партнера, передавшего сообщение. Если номера не совпадают, должно устанавливаться значение Error Subcode = Malformed AS_PATH.

Если дополнительный атрибут распознан, его значение должно быть проверено. При обнаружении ошибки атрибут должен быть отброшен и требуется установить Error Subcode = Optional Attribute Error. Поле Data в таком случае должно содержать связанный с ошибкой атрибут (тип, размер и значение).

Если тот или иной атрибут неоднократно встречается в сообщении UPDATE, в поле Error Subcode должно устанавливаться значение Malformed Attribute List.

Проверяется синтаксическая корректность поля NLRI в сообщении UPDATE. При обнаружении ошибки должно устанавливаться значение Error Subcode = Invalid Network Field.

Если префикс в поле NLRI семантически некорректен (например, содержит неожиданный групповой адрес IP), информацию об ошибке следует записать в локальный журнальный файл, а префикс следует игнорировать.

Сообщения UPDATE с корректными атрибутами пути, но без NLRI следует трактовать как корректные.

6.4. Отработка ошибок в сообщениях NOTIFICATION

Если узел передает сообщение NOTIFICATION и получатель этого сообщения детектирует в нем ошибку, получатель не может использовать сообщение NOTIFICATION для уведомления своего партнера об ошибке. Все ошибки этого типа (например, нераспознанное значение Error Code или Error Subcode) должны локально протоколироваться с передачей уведомления администратору узла, отправившего ошибочное сообщение. Способы такого протоколирования и уведомления не рассматриваются в данном документе.

6.5. Отработка значений Hold Timer

Если система не получает сообщений KEEPALIVE, UPDATE или NOTIFICATION в течение периода, заданного полем Hold Time в сообщении OPEN, передается сообщение NOTIFICATION с кодом ошибки Hold Timer Expired и соединение BGP закрывается.

6.6. Обработка ошибок машины конечных состояний

Любая ошибка, обнаруженная машиной конечных состояний (FSM) BGP (например, неожиданное событие), указывается путем передачи сообщения NOTIFICATION с Error Code = Finite State Machine Error.

6.7. Обработка Cease

При отсутствии каких-либо критических ошибок (из числа описанных выше) узел BGP может в любой момент закрыть соединение BGP, передав партнеру сообщение NOTIFICATION с Error Code = Cease. Однако такие сообщения недопустимо использовать при возникновении какой-либо из перечисленных выше критических ошибок.

Узел BGP может обеспечивать возможность вносить задаваемый параметрами локальной конфигурации верхний предел для числа адресных префиксов, принимаемых от соседа. В случае превышения порога, заданного параметрами локальной конфигурации (a) новые префиксы от этого соседа отбрасываются (с сохранением соединения с данным соседом) или (b) закрывается соединение BGP с этим соседом. Если узел BGP принимает решение о разрыве соединения BGP со своим соседом в результате получения от того избыточного числа префиксов, этот узел должен передать соседу сообщение NOTIFICATION с Error Code = Cease. Узел может также записать информацию об этом в журнальный файл.

6.8. Детектирование конфликтов в соединениях BGP

Если пара узлов BGP пытается одновременно организовать соединение TCP друг с другом, между узлами такой пары могут возникнуть два параллельных соединения. Если IP-адрес отправителя в одном из таких соединений совпадает с IP-адресом получателя в другом соединении и наоборот, возникает конфликт при соединении. При возникновении такого конфликта одно из соединений должно быть закрыто.

Выбор одного из пары соединений для закрытия базируется на соглашении об идентификаторах BGP. При возникновении конфликта сравниваются значения BGP Identifier вовлеченных в конфликт узлов и сохраняется только то соединение, которое было инициировано узлом BGP с большим значением BGP Identifier.

При получении сообщения OPEN локальная система должна проверить все свои соединения, находящиеся в состоянии OpenConfirm. Узел BGP может также проверить соединения, которые находятся в состоянии OpenSent, если он имеет информацию о значении BGP Identifier узла на противоположной стороне соединения (эта информация получается с помощью других протоколов). Если какое-либо из этих соединений относится к удаленному узлу BGP, идентификатор которого совпадает со значением BGP Identifier в сообщении OPEN, локальные система выполняет следующие процедуры разрешения конфликта:

1. Значение BGP Identifier локальной системы сравнивается с идентификатором удаленного узла BGP, указанным в сообщении OPEN. Сравнение производится с преобразованием значений BGP Identifier к принятому для хостов порядку байтов (host byte order) и трактовкой полученных значений как 4-октетных целых чисел без знака.

2. Если значение BGP Identifier для локального узла меньше соответствующего значения для удаленного узла, локальная система закрывает существующее соединение BGP с этим узлом (это соединение находится в состоянии OpenConfirm) и принимает соединение BGP от удаленного партнера.

3. В противном случае локальная система закрывает недавно созданное соединение BGP (связанное с недавно полученным сообщением OPEN) и продолжает использовать существующее соединение с этим партнером (то, которое уже находится в состоянии OpenConfirm).

Если конфигурационные параметры не задают иного, конфликт с существующим соединением BGP, которое находится в состоянии Established, приводит к разрыву недавно созданного соединения.

Отметим, что конфликт соединений не может быть детектирован для состояний Idle, Connect и Active.

Разрыв соединения BGP (в результате процедуры разрешения конфликта) осуществляется путем передачи сообщения NOTIFICATION с Error Code = Cease.

7. Согласование версий BGP

Узлы BGP могут согласовать версию протокола путем повторных попыток организации соединения BGP, используя в первой попытке высший номер, поддерживаемый локальной стороной. Если при попытке организации соединения возникает ошибка с Error Code = OPEN Message Error и Error Subcode = Unsupported Version Number, узел BGP имеет информацию о номере версии, который был использован при неудачной попытке, номере версии, которую пытался использовать партнер, номере версии, переданном партнером в сообщении NOTIFICATION, и номере версии, которую тот поддерживает. Если номера одной или более версий из числа поддерживаемых обоими партнерами совпадают, имеющаяся информация позволяет быстро определить максимальный поддерживаемый номер версии. Для поддержки согласования версии BGP в будущих версиях протокола должен сохраняться формат сообщений OPEN и NOTIFICATION.

8. Машина конечных состояний BGP

Структуры данных и FSM, описанные в данном документе, являются концептуальными моделями и не реализуются в точном соответствии с приведенными описаниями. Если реализация поддерживает описанную функциональность, она будет демонстрировать соответствующее описанному здесь поведение.

В этой главе описывается работа BGP в терминах машины конечных состояний (FSM). Глава разбита на две части:

1. Описание событий для машины состояний (параграф 8.1)
2. Описание FSM (параграф 8.2)

Обязательными атрибутами каждого соединения являются:

1. State — состояние;
2. ConnectRetryCounter — счетчик числа попыток организации соединения;
3. ConnectRetryTimer — таймер повторов для соединения;
4. ConnectRetryTime — время ожидания для повтора;
5. HoldTimer — таймер удержания;
6. HoldTime — время удержания;
7. KeepaliveTimer — таймер сохранения;
8. KeepaliveTime — время сохранения.

Атрибуты состояния сессии показывают текущее состояние BGP FSM. Счетчик ConnectRetryCounter показывает число попыток узла BGP организовать соединение с партнером.

Обязательные атрибуты, связанные с таймерами, описаны в главе 10. Для каждого таймера существуют значения «timer» и «time» (начальное значение).

Ниже перечислены дополнительные атрибуты сессий. Эти атрибуты могут поддерживаться для соединений или для локальной системы в целом:

1. AcceptConnectionsUnconfiguredPeers
2. AllowAutomaticStart
3. AllowAutomaticStop
4. CollisionDetectEstablishedState
5. DampPeerOscillations
6. DelayOpen
7. DelayOpenTime
8. DelayOpenTimer
9. IdleHoldTime
10. IdleHoldTimer
11. PassiveTcpEstablishment
12. SendNOTIFICATIONwithoutOPEN
13. TrackTcpState

Дополнительные атрибуты сессий определяют различные параметры BGP, оказывающие влияние на смену состояний BGP FSM. Две группы атрибутов, связанных с таймерами, включают:

• Группа 1: DelayOpen, DelayOpenTime, DelayOpenTimer
• Группа 2: DampPeerOscillations, IdleHoldTime, IdleHoldTimer

Первый параметр (DelayOpen, DampPeerOscillations) является дополнительным атрибутом, который показывает, что функция Timer активна. Значение «Time» указывает начальное состояние таймера (DelayOpenTime, IdleHoldTime). «Timer» задает реальный таймер.

Описание взаимодействия между дополнительными атрибутами и состояниями, передаваемыми FSM, приведено в параграфе 8.1.1. Параграф 8.2.1.3 содержит краткий обзор двух различных типов дополнительных атрибутов (флаги и таймеры).

8.1. События BGP FSM

8.1.1. Дополнительные события, связанные с дополнительными атрибутами сессии

Входной информацией для BGP FSM являются события, которые могут относиться к числу обязательных (mandatory) и необязательных (optional). Некоторые из дополнительных событий связаны с дополнительными атрибутами сессии. Дополнительные атрибуты сессий включают несколько групп функций FSM.

Связи между функциями FSM, событиями и дополнительными атрибутами сессий описаны ниже:

• Группа 1: Автоматические административные события (старт/стоп)

• Дополнительные атрибуты сессии:

  AllowAutomaticStart, AllowAutomaticStop, DampPeerOscillations, IdleHoldTime, IdleHoldTimer

  Опция 1:	AllowAutomaticStart
  Описание	Соединение с партнером BGP может быть инициировано или разорвано административными средствами. Такая операция может выполняться вручную с участием оператора или автоматически под управлением встроенной логики реализации BGP. Термин «автоматически» говорит о том, что соединение с партнером BGP организуется тогда, когда логика определяет, что соединение BGP следует перезапустить. Атрибут AllowAutomaticStart указывает, что данное соединение BGP поддерживает автоматический запуск соединения BGP. Если реализация BGP поддерживает AllowAutomaticStart, рестарт соединения с партнером может повторяться. Опции DampPeerOscillations, IdleHoldTime, IdleHoldTimer управляют скоростью организации повторных соединений. Опция DampPeerOscillations определяет использование дополнительной логики для подавления осцилляций BGP в форме последовательности автоматически повторяющихся процедур старта и остановки. Параметр IdleHoldTime задает продолжительность периода сохранения партнером BGP состояния Idle перед тем, как будет возможен новый автоматический рестарт. Таймер IdleHoldTimer управляет сохранением состояния Idle. Примером логики DampPeerOscillations является рост значения IdleHoldTime в тех случаях, когда BGP-партнер порождает периодические осцилляции (организация/разрыв соединения) в течение некоторого интервала времени. Для включения этой логики партеру достаточно организовать 10 соединений и их разрывов в течение 5 минут. Значение IdleHoldTime будет сменено с нуля на 120 секунд.
  Значения:	TRUE или FALSE
  Опция 2:	AllowAutomaticStop
  Описание:	Этот дополнительный атрибут сессии BGP показывает, что для соединения BGP разрешено «автоматическое» прерывание. Автоматическим называется прерывание сессии под управлением поддерживаемой реализацией логики. Рассмотрение такой логики не входит в задачи данной спецификации.
  Значения:	TRUE или FALSE
  Опция 3:	DampPeerOscillations
  Описание	Дополнительный атрибут сессии DampPeerOscillations показывает, что соединение BGP использует логику подавления осцилляций в состоянии Idle.
  Значения:	TRUE или FALSE
  Опция 4:	IdleHoldTime
  Описание	IdleHoldTime принимает значение, установленное для IdleHoldTimer.
  Значение:	Время в секундах.
  Опция 5:	IdleHoldTimer
  Описание	Таймер IdleHoldTimer служит для контроля осцилляций BGP за счет сохранения партнера BGP в состоянии Idle в течение заданного интервала времени. Событие IdleHoldTimer_Expires описано в параграфе 8.1.3.
  Значение:	Время в секундах.

• Группа 2: Не указанные в конфигурации партнеры

• Дополнительные атрибуты сессии:

  AcceptConnectionsUnconfiguredPeers

  Опция 1:	AcceptConnectionsUnconfiguredPeers
  Описание	Машина состояний BGP FSM может позволять восприятие соединений BGP от неуказанных в конфигурации соседей. Дополнительный атрибут сессии AcceptConnectionsUnconfiguredPeers позволяет FSM поддерживать переходы состояний, которые позволяют реализации принимать или отвергать соединения от таких партнеров. Атрибут AcceptConnectionsUnconfiguredPeers влияет на безопасность. Детальное описание можно найти в документе «Уязвимости BGP» [RFC4272].
  Значения:	TRUE или FALSE

• Группа 3: Обработка TCP

• Дополнительные атрибуты сессии:

  PassiveTcpEstablishment, TrackTcpState

  Опция 1:	PassiveTcpEstablishment
  Описание	Эта опция показывает, что BGP FSM будет пассивно ожидать вызова от удаленного партнера BGP для организации соединения TCP.
  Значения:	TRUE или FALSE
  Опция 2:	TrackTcpState
  Описание	BGP FSM обычно отслеживает конечный результат попытки организации соединения TCP, а не отдельные сообщения TCP. Опционально BGP FSM может поддерживать дополнительное взаимодействие с системой согласования параметров соединений TCP. Учет событий TCP может увеличить объем записей в журнальных файлах и число смен состояний BGP FSM.
  Значения:	TRUE или FALSE

• Группа 4: Обработка сообщений BGP

• Дополнительные атрибуты сессии:

  DelayOpen, DelayOpenTime, DelayOpenTimer, SendNOTIFICATIONwithoutOPEN, CollisionDetectEstablishedState

  Опция 1:	DelayOpen
  Описание	Дополнительный атрибут сессии DelayOpen позволяет реализации настроить задержку передачи сообщения OPEN на заданное время. Такая задержка позволяет удаленному партнеру BGP первым отправить сообщение OPEN.
  Значения:	TRUE или FALSE
  Опция 2:	DelayOpenTime
  Описание	DelayOpenTime — начальное значение таймера DelayOpenTimer.
  Значение:	Время в секундах.
  Опция 3:	DelayOpenTimer
  Описание	Дополнительный атрибут сессии DelayOpenTimer используется для задержки передачи сообщения OPEN в данном соединении. Событие DelayOpenTimer_Expires (Событие 12) описано в параграфе 8.1.3.
  Значение:	Время в секундах.
  Опция 4:	SendNOTIFICATIONwithoutOPEN
  Описание	SendNOTIFICATIONwithoutOPEN позволяет партнеру передать сообщение NOTIFICATION без отправки сначала сообщения OPEN. Без этого дополнительного атрибута соединение BGP предполагает, что сообщение OPEN должно быть отправлено партнером до того, как ему будет передаваться сообщение NOTIFICATION.
  Значения:	TRUE или FALSE
  Опция 5:	CollisionDetectEstablishedState
  Описание	Обычно Detect Collision (см. параграф 6.8) игнорируется для состояния Established. Этот дополнительный атрибут сессии показывает, что данное соединение BGP обрабатывает конфликты и в состоянии Established.
  Значения:	TRUE или FALSE
  Примечание:	Дополнительные сеансовые атрибуты проясняют описание BGP FSM для имеющихся возможностей реализации BGP. Эти атрибуты могут быть предопределенными для реализации и недоступными через интерфейс управления, поддерживаемый реализацией. Если поддерживается новая (2 и выше) версия BGP MIB, эти поля будут доступны через интерфейс управления.

8.1.2. События административного плана

К числу административных относятся те события, при которых операторский интерфейс машины политики BGP сигнализирует машине конечных состояний BGP о необходимости запуска или остановки машины состояний BGP. Базовые средства индикации запуска и остановки дополняются необязательными атрибутами соединения, которые передают сигналы о некоторых типах запуска и остановки BGP FSM. Примером такой комбинации может служить Событие 5 — AutomaticStart_with_PassiveTcpEstablishment. С помощью такого события реализация BGP сигнализирует BGP FSM об использовании Automatic Start с опцией для применения процедуры Passive TCP Establishment. В свою очередь Passive TCP establishment сигнализирует, что BGP FSM будет ждать вызова удаленной стороны для организации соединения TCP.

Отметим, что только Событие 1 (ManualStart) и Событие 2 (ManualStop) относятся к числу обязательных административных событий. Все остальные события административного типа (События 3 — являются дополнительными. Каждое из описанных ниже событий имеет номер, определение, статус (обязательное или дополнительное), а также дополнительные атрибуты сессии, которые следует устанавливать на каждой стадии. При генерации Событий 1 — 8 для BGP FSM проверяются условия, заданные в поле «Статус дополнительных атрибутов». Если любое из этих условий не выполняется, локальной системе следует записать в журнальный файл сведения об ошибке FSM.

В некоторых реализациях установка дополнительных атрибутов сессии может быть неявной и, следовательно, эти атрибуты не могут явно устанавливаться оператором. В параграфе 8.2.1.5 описаны такие неявные установки дополнительных сеансовых атрибутов. Описанные ниже административные события также могут быть в некоторых реализациях неявными и недоступными для оператора.

• Событие 1: ManualStart

• • Определение: администратор локальной системы вручную инициирует соединение с партнером.

  • Статус: обязательный.

  • Статус дополнительных атрибутов: для атрибута PassiveTcpEstablishment следует установить значение FALSE.

• Событие 2: ManualStop

• • Определение: администратор локальной системы вручную останавливает соединение с партнером.

  • Статус: обязательный.

  • Статус дополнительных атрибутов: взаимодействие с дополнительными атрибутами отсутствует.

• Событие 3: AutomaticStart

• • Определение: локальная система автоматически организует соединение BGP.

  • Статус: дополнительный, зависит от локальной системы.

  • Статус дополнительных атрибутов:

    1. для атрибута AllowAutomaticStart следует установить значение TRUE, если происходит данное событие;
    2. если поддерживается дополнительный атрибут сессии PassiveTcpEstablishment, для него следует установить значение FALSE;
    3. если поддерживается DampPeerOscillations, следует установить значение FALSE, когда произойдет данное событие.
• Событие 4: ManualStart_with_PassiveTcpEstablishment

• • Определение: локальный администратор вручную инициирует соединение с партнером при включенном режиме PassiveTcpEstablishment; дополнительный сеансовый атрибут PassiveTcpEstablishment показывает, что будут прослушиваться вызовы партнера прежде, чем соединение будет организовано.

  • Статус: дополнительный, зависит от локальной системы.

  • Статус дополнительных атрибутов:

    1. для атрибута PassiveTcpEstablishment следует установить значение TRUE, если это событие происходит;
    2. после завершения события для атрибута DampPeerOscillations следует установить значение FALSE.
• Событие 5: AutomaticStart_with_PassiveTcpEstablishment

• • Определение: локальная система автоматически инициирует соединение BGP при включенном режиме PassiveTcpEstablishment; дополнительный сеансовый атрибут PassiveTcpEstablishment показывает, что будут прослушиваться вызовы партнера прежде, чем соединение будет организовано.

  • Статус: дополнительный, зависит от локальной системы.

  • Статус дополнительных атрибутов:

    1. для атрибута AllowAutomaticStart следует установить значение TRUE;
    2. для атрибута PassiveTcpEstablishment следует установить значение TRUE;
    3. если поддерживается атрибут DampPeerOscillations, для него следует установить значение FALSE.
• Событие 6: AutomaticStart_with_DampPeerOscillations

• • Определение: локальная система автоматически инициирует соединение BGP при включенном режиме подавления осцилляций; конкретный метод подавления осцилляций определяется реализацией и его рассмотрение выходит за пределы данной спецификации.

  • Статус: дополнительный, зависит от локальной системы.

  • Статус дополнительных атрибутов:

    1. для атрибута AllowAutomaticStart следует установить значение TRUE;
    2. для атрибута DampPeerOscillations следует установить значение TRUE;
    3. для атрибута PassiveTcpEstablishment следует установить значение TRUE.
• Событие 7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment

• • Определение: локальная система автоматически инициирует соединение BGP при включенном режиме подавления осцилляций и PassiveTcpEstablishment; конкретный метод подавления осцилляций определяется реализацией и его рассмотрение выходит за пределы данной спецификации.

  • Статус: дополнительный, зависит от локальной системы.

  • Статус дополнительных атрибутов:

    1. для атрибута AllowAutomaticStart следует установить значение TRUE;
    2. для атрибута DampPeerOscillations следует установить значение TRUE;
    3. для атрибута PassiveTcpEstablishment следует установить значение TRUE.
• Событие 8: AutomaticStop

• • Определение: локальная система автоматически останавливает соединение BGP; примером автоматической остановки может служить избыточное число префиксов от данного партнера и автоматический разрыв локальной системой соединения с этим партнером.

  • Статус: дополнительный, зависит от локальной системы.

  • Статус дополнительных атрибутов: для атрибута AllowAutomaticStop следует установить значение TRUE.

8.1.3. События, связанные с таймерами

• Событие 9: ConnectRetryTimer_Expires

• • Определение: событие генерируется при завершении отсчета таймера ConnectRetryTimer.

  • Статус: обязательное.

• Событие 10: HoldTimer_Expires

• • Определение: событие генерируется при завершении отсчета таймера HoldTimer.

  • Статус: обязательное.

• Событие 11: KeepaliveTimer_Expires

• • Определение: событие генерируется при завершении отсчета таймера KeepaliveTimer.

  • Статус: обязательное.

• Событие 12: DelayOpenTimer_Expires

• • Определение: событие генерируется при завершении отсчета таймера DelayOpenTimer.

  • Статус: дополнительное.

  • Статус дополнительных атрибутов: если произошло данное событие

    1. для атрибута DelayOpen следует установить значение TRUE;
    2. следует поддерживать атрибут DelayOpenTime;
    3. следует поддерживать атрибут DelayOpenTimer.
• Событие 13: IdleHoldTimer_Expires

• • Определение: это событие генерируется при завершении отсчета таймера IdleHoldTimer, которое показывает, что для соединения BGP завершился период ожидания (back-off), служащий для предотвращения осцилляции BGP.

    Таймер IdleHoldTimer используется только в тех случаях, когда разрешено постоянное использование функции подавления осцилляций путем установки DampPeerOscillations = TRUE.

    Реализации, не поддерживающие функцию постоянного подавления осцилляций, могут не поддерживать таймер IdleHoldTimer.

  • Статус: дополнительное.

  • Статус дополнительных атрибутов: если происходит данное событие:

    1. для атрибута DampPeerOscillations слебует установить значение TRUE;
    2. следует дождаться завершения отсчета таймера IdleHoldTimer.

8.1.4. События, связанные с соединениями TCP

• Событие 14: TcpConnection_Valid

• • Определение: событие, показывающее прием локальной системой запроса на соединение TCP с корректным адресом и номером порта TCP для отправителя и получателя; принятие решение о корректности IP-адресов отправителя и получателя является прерогативой реализации.

    В качестве порта получателя BGP следует использовать значение 179, заданное IANA.

    Запросы на организацию соединений TCP фиксируются локальной системой при получении пакетов TCP SYN.

  • Статус: дополнительное.

  • Статус дополнительных атрибутов: для атрибута TrackTcpState следует установить значение TRUE, если происходит данное событие.

• Событие 15: Tcp_CR_Invalid

• • Определение: событие, показывающее получение локальной системой запроса на организацию соединения TCP с некорректным значением адреса или номера порта для отправителя или получателя.

    В качестве порта получателя BGP следует использовать значение 179, заданное IANA.

    Запросы на организацию соединений TCP фиксируются локальной системой при получении пакетов TCP SYN.

  • Статус: дополнительное.

  • Статус дополнительных атрибутов: для атрибута TrackTcpState следует установить значение TRUE, если происходит данное событие.

• Событие 16: Tcp_CR_Acked

• • Определение: событие, показывающее, что локальная система запросила организацию соединения TCP с удаленным партнером.

  • Локальная система передала пакет TCP SYN, приняла отклик TCP SYN/ACK и передала подтверждение TCP ACK.

  • Статус: обязательное.

• Событие 17: TcpConnectionConfirmed

• • Определение: событие, показывающее, что локальная система получила от удаленного узла подтверждение организации соединения TCP.

  • Модуль TCP удаленного партнера передал пакет TCP SYN; локальный модуль передал в ответ SYN, ACK и получил завершающее подтверждение ACK.

  • Статус: обязательное.

• Событие 18: TcpConnectionFails

• • Определение: событие, показывающее, что локальная система получила информацию об отказе при попытке организации соединения TCP.

  • Модуль TCP удаленного партнера BGP мог передать пакет FIN, на который локальный узел ответил пакетом FIN-ACK. Другим вариантом является детектирование тайм-аута для соединения TCP и прекращения попытки организации соединения.

  • Статус: обязательное.

8.1.5. События, связанные с сообщениями BGP

• Событие 19: BGPOpen

• • Определение: это событие генерируется при получении корректного сообщения OPEN.

  • Статус: обязательное.

  • Статус дополнительных атрибутов:

    1. для атрибута DelayOpen следует установить значение FALSE;
    2. таймер DelayOpenTimer следует выключить.
• Событие 20: BGPOpen with DelayOpenTimer running

• • Определение: это событие генерируется при получении корректного сообщения OPEN для партнера, который уже имеет организованное транспортное соединение и в настоящее время задерживает передачу сообщения BGP OPEN.

  • Статус: дополнительное.

  • Статус дополнительных атрибутов:

    1. для атрибута DelayOpen следует установить значение FALSE;
    2. таймер DelayOpenTimer следует включить.
• Событие 21: BGPHeaderErr

• • Определение: это событие генерируется при получении сообщения BGP с некорректным заголовком.

  • Статус: обязательное.

• Событие 22: BGPOpenMsgErr

• • Определение: это событие генерируется при получении сообщения OPEN, содержащего ошибки.

  • Статус: обязательное.

• Событие 23: OpenCollisionDump

• • Определение: это событие генерируется административным путем при детектировании конфликта соединений в процесс обработки входящего сообщения OPEN, если данное соединение планируется разорвать; описание детектирования конфликтов приведено в параграфе 6.8.

    Событие 23 является административным действием, генерируемым логикой реализации, принимающей решение о сбросе соединения в соответствии с правилами параграфа 6.8. Это событие может происходить, если FSM реализована как две связанных машины состояний.

  • Статус: дополнительное.

  • Статус дополнительных атрибутов: если машина состояний обрабатывает это событие из состояния Established, для дополнительного атрибута CollisionDetectEstablishedState следует установить значение TRUE.

  • Примечание: событие OpenCollisionDump может происходить в состояниях Idle, Connect, Active, OpenSent и OpenConfirm без установки каких-либо дополнительных атрибутов.

• Событие 24: NotifMsgVerErr

• • Определение: это событие генерируется при получении сообщения NOTIFICATION с кодом ошибки несоответствия версий.

  • Статус: обязательное.

• Событие 25: NotifMsg

• • Определение: это событие генерируется при получении сообщения NOTIFICATION с кодом ошибки, отличным от несовпадения версий.

  • Статус: обязательное.

• Событие 26: KeepAliveMsg

• • Определение: это событие генерируется при получении сообщения KEEPALIVE.

  • Статус: обязательное.

• Событие 27: UpdateMsg

• • Определение: это событие генерируется при получении корректного сообщения UPDATE.

  • Статус: обязательное.

• Событие 28: UpdateMsgErr

• • Определение: это событие генерируется при получении некорректного сообщения UPDATE

  • Статус: обязательное.

8.2. Описание FSM

8.2.1. Определение FSM

Реализация BGP должна поддерживать отдельную FSM для каждого включенного в конфигурацию партнера. Каждый узел BGP, включенный в потенциальное соединение, будет пытаться связаться с партнером, если для данного узла не задано сохранение состояния Idle или пассивный режим. В последующем обсуждении активная или подключающаяся сторона соединения TCP (та сторона, с которой был передан первый пакет TCP SYN) называется исходящей (outgoing). Пассивная или ожидающая сторона (отправитель первого пакета SYN/ACK) будет называться входящей. Дополнительные разъяснения терминов «активный» и «пассивный» приведены ниже в параграфе 8.2.1.1.

Реализация BGP должна подключиться к порту TCP с номером 179 и прослушивать его с целью приема входящих вызовов в дополнение к своим попыткам организовать соединение с партнером. Для каждого входящего соединения должен создаваться экземпляр машины состояний. Существует период, в течение которого соединение с партнером на другой стороне уже организовано, но его идентификатор BGP еще не известен. В течение этого периода могут одновременно существовать входящее и исходящее соединение для одной пары партнеров. Такая ситуация называется конфликтом при соединении (см. параграф 6.8).

Реализация BGP будет иметь не более одной машины FSM для каждого указанного в конфигурации партнера и одну FSM для каждого входящего соединения TCP, в котором партнер еще не идентифицирован. Каждый экземпляр FSM соответствует одному соединению TCP.

Между парой партнеров может существовать несколько соединений, если в них используются различные пары адресов IP. Такая ситуация называется «множественным партнерством» (multiple «configured peerings»).

8.2.1.1. Термины «активный» и «пассивный»

Термины «активный» и «пассивный» присутствуют в сленге операторов Internet уже почти десятилетие и оказались весьма полезными. Эти термины в контексте соединений TCP или соединений с партнерами имеют специфическое толкование. В любом соединении TCP может быть только одна активная и одна пассивная сторона (в соответствии с приведенным выше определением и описанными ниже состояниями FSM). Когда узел BGP настроен как активный, он может располагаться как на активной, так и на пассивной стороне соединения, которое будет организовано в результате. После завершения процесса организации соединения TCP уже не имеет значения, какая из сторон была активной, а какая пассивной на этапе организации соединения. Единственное различие заключается в том, какая из сторон будет использовать порт TCP с номером 179.

8.2.1.2. FSM и детектирование конфликтов

Существует одна машина FSM на каждое соединение BGP. При возникновении конфликта соединений до того, как партнер будет полностью идентифицирован, может существовать два соединения с одним партнером. После разрешения конфликта (см. параграф 6.8) FSM разорванного соединения следует освободить (отключить).

8.2.1.3. FSM и дополнительные атрибуты сессий

Дополнительные атрибуты сессий действуют как флаги (TRUE или FALSE) или дополнительные таймеры. Для атрибутов, являющихся флагами, должно поддерживаться соответствующее действие BGP FSM, если для флага может быть установлено значение TRUE. Например, если в реализации BGP могут быть установлены опции AutoStart и PassiveTcpEstablishment, должны поддерживаться События 3, 4 и 5. Если дополнительный атрибут сессии не может иметь значения TRUE, соответствующие события не поддерживаются.

Каждый из дополнительный таймеров (DelayOpenTimer и IdleHoldTimer) имеет группу атрибутов, включающую:

• флаг индикации поддержки;
• значение времени (Time) для таймера;
• таймер.

Формат дополнительный таймеров показан ниже:

• DelayOpenTimer: DelayOpen, DelayOpenTime, DelayOpenTimer
• IdleHoldTimer: DampPeerOscillations, IdleHoldTime, IdleHoldTimer

Если флаг индикации поддержки для дополнительного таймера (DelayOpen или DampPeerOscillations) не может иметь значение TRUE, таймеры и события, поддерживающие данную опцию, не поддерживаются.

8.2.1.4. Номера событий FSM

Номера событий (1-28) используются при описании машины состояний. Реализации могут использовать эти номера для систем сетевого управления. Точная форма FSM или событий FSM зависит от реализации.

8.2.1.5. Действия FSM, зависящие от реализации

В некоторых случаях BGP FSM указывает, что будет выполняться инициализация BGP или удаление ресурсов BGP. Инициализация BGP FSM и связанных с машиной ресурсов зависит от связанной с политикой части реализации BGP. Детальное рассмотрение этих действий выходит за пределы описания FSM.

8.2.2. Машина конечных состояний

• Состояние Idle

• Изначально FSM узла BGP находится в состоянии Idle (далее машина конечных состояний узла BGP будет обозначаться для краткости BGP FSM).

  В этом состоянии BGP FSM отвергает все входящие соединения BGP для данного узла. Никаких ресурсов не выделено. В ответ на событие ManualStart (1) или AutomaticStart (3) локальная система будет:

  • инициализировать все ресурсы BGP для соединения с партнером;
  • устанавливать ConnectRetryCounter = 0;
  • запускать таймер ConnectRetryTimer с начальным значением;
  • инициировать соединение TCP с другим узлом BGP;
  • прослушивать соединения, инициированные удаленными узлами BGP;
  • переходить в состояние Connect.

  События ManualStop (Событие 2) и AutomaticStop (Событие игнорируются в состоянии Idle.

  В ответ на событие ManualStart_with_PassiveTcpEstablishment (4) или AutomaticStart_with_PassiveTcpEstablishment (5) локальная система будет:

  • инициализировать все ресурсы BGP;
  • устанавливать ConnectRetryCounter = 0;
  • запускать таймер ConnectRetryTimer с начальным значением;
  • прослушивать соединения, инициированные удаленными узлами BGP;
  • переходить в состояние Active.

  Точное значение ConnectRetryTimer определяется локально, но его следует делать достаточно большим для того, чтобы прошла инициализация TCP.

  Если атрибут DampPeerOscillations имеет значение TRUE, в состоянии Idle возможны три события:

  • AutomaticStart_with_DampPeerOscillations (Событие 6),
  • AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment (Событие 7),
  • IdleHoldTimer_Expires (Событие 13).

  Эти события будут использоваться локальной системой для предотвращения осцилляций. Метод предотвращения постоянных осцилляций выходит за пределы данного документа.

  Любое другое событие (9-12, 15-28) в состоянии Idle не приводит к смене состояния локальной системы.

• Состояние Connect

• В этом состоянии BGP FSM ожидает завершения процесса организации соединения TCP. Стартовые события (1, 3-7) игнорируются в состоянии Connect. В ответ на событие ManualStop (Событие 2) локальная система будет:

  • сбрасывать соединение TCP;
  • освобождать все ресурсы BGP;
  • устанавливать ConnectRetryCounter = 0;
  • останавливать таймер ConnectRetryTimer и устанавливать для него нулевое значение;
  • переходить в состояние Idle.

  В ответ на событие ConnectRetryTimer_Expires (9) локальная система будет:

  • сбрасывать соединение TCP;
  • заново запускать таймер ConnectRetryTimer;
  • останавливать таймер DelayOpenTimer и сбрасывать его значение в 0;
  • инициировать соединение TCP с другим узлом BGP;
  • продолжать прослушивание порта для определения входящих вызовов от других узлов BGP;
  • сохранять состояние Connect.

  Если происходит событие DelayOpenTimer_Expires (12) в состоянии Connect, локальная система будет:

  • передавать партнеру сообщение OPEN;
  • устанавливать большое значение для таймера удержания HoldTimer;
  • переходить в состояние OpenSent.

  Если BGP FSM получает информацию о событии TcpConnection_Valid (14), обрабатывается соединение TCP и сохраняется состояние Connect.

  При получении BGP FSM информации о событии Tcp_CR_Invalid (15) локальная система отвергнет соединение TCP и сохранит состояние Connect.

  При успешной организации соединения TCP (Событие 16 или 17) локальная система будет сначала проверять атрибут DelayOpen. Если этот атрибут имеет значение TRUE, локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его в 0;
  • устанавливать начальное значение для таймера DelayOpenTimer;
  • сохранять состояние Connect.

  Если атрибут DelayOpen имеет значение FALSE, локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его в 0;
  • завершать инициализацию BGP;
  • передавать партнеру сообщение OPEN;
  • устанавливать большое значение для таймера удержания HoldTimer;
  • переходить в состояние OpenSent.

  Предлагается использовать для HoldTimer значение 4 минуты.

  При отказе в организации соединения TCP (Событие 18) локальная система проверяет DelayOpenTimer. Если этот таймер запущен, локальная система будет:

  • заново запускать таймер ConnectRetryTimer;
  • останавливать таймер DelayOpenTimer и сбрасывать его значение в 0;
  • продолжать прослушивание порта для приема входящих вызовов от других узлов BGP;
  • переходить в состояние Active.

  Если таймер DelayOpenTimer не запущен, локальная система будет:

  • заново запускать таймер ConnectRetryTimer;
  • сбрасывать соединение TCP;
  • освобождать все ресурсы BGP;
  • переходить в состояние Idle.

  Если получено сообщение OPEN при запущенном таймере DelayOpenTimer (Событие 20), локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;
  • завершать инициализацию BGP;
  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;
  • передавать сообщение OPEN;
  • передавать сообщение KEEPALIVE;

  • если начальное значение таймера HoldTimer отлично от 0:

    • запускается таймер KeepaliveTimer с начальным значением;
    • таймер HoldTimer сбрасывается в согласованное значение,

    в противном случае (начальное значение HoldTimer равно 0)

    • сбрасывается таймер KeepaliveTimer;
    • таймер HoldTimer сбрасывается в 0,
  • система переходит в состояние OpenConfirm.

  Если значение поля AS совпадает с номером локальной автономной системы, для соединения устанавливается статус внутреннего, в противном случае соединение считается внешним.

  Если обнаружены ошибки при проверке заголовка BGP (Событие 21) или сообщения OPEN (Событие 22) (см. параграф 6.2), локальная система будет:

  • (необязательно) если атрибут SendNOTIFICATIONwithoutOPEN имеет значение TRUE, локальная система сначала будет передавать сообщение NOTIFICATION с соответствующим кодом ошибки;
  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  При получении сообщения NOTIFICATION об ошибке верификации (Событие 24), локальная система проверяет таймер DelayOpenTimer. Если этот таймер запущен, локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;
  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • переходить в состояние Idle.

  Если таймер DelayOpenTimer не запущен, локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  В ответ на все остальные события (8, 10-11, 13, 19, 23, 25-28) локальная система будет:

  • если таймер ConnectRetryTimer запущен, — останавливать и сбрасывать его в 0;
  • если таймер DelayOpenTimer, — останавливать и сбрасывать его в 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

• Состояние Active

• В этом состоянии BGP FSM пытается приобрести партнеров путем прослушивания и восприятия соединений TCP.

  Стартовые события (1, 3-7) игнорируются в состоянии Active. В ответ на событие ManualStop (2) локальная система будет:

  • при запущенном таймере DelayOpenTimer и установленном атрибуте SendNOTIFICATIONwithoutOPEN передавать сообщение NOTIFICATION с кодом ошибки Cease;
  • освобождать все ресурсы BGP и останавливать таймер DelayOpenTimer;
  • сбрасывать соединение TCP;
  • устанавливать ConnectRetryCounter = 0;
  • останавливать таймер ConnectRetryTimer и сбрасывать его значение в 0;
  • переходить в состояние Idle.

  В ответ на событие ConnectRetryTimer_Expires (9) локальная система будет:

  • заново запускать таймер ConnectRetryTimer (с начальным значением);
  • инициировать соединение TCP с другим узлом BGP;
  • продолжать прослушивание входящих вызовов TCP, которые могут приходить от удаленных узлов BGP;
  • переходить в состояние Connect.

  В ответ на событие DelayOpenTimer_Expires (12) локальная система будет:

  • устанавливать ConnectRetryCounter = 0;
  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;
  • завершать инициализацию BGP;
  • передавать удаленному узлу сообщение OPEN;
  • устанавливать большое значение для таймера удержания;
  • переходить в состояние OpenSent.

  Для этого перехода предлагается устанавливать значение HoldTimer равным 4 минутам.

  При получении сведений о событии TcpConnection_Valid (14) локальная система обрабатывает флаги соединения TCP и остается в состоянии Active.

  При получении информации о событии Tcp_CR_Invalid (15) локальная система отвергнет соединение TCP и сохранит состояние Active.

  При успешной организации соединения TCP (Событие 16 или 17) локальная система будет проверять сначала дополнительный атрибут DelayOpen.

  Если DelayOpen = TRUE, локальная система будет:

  • останавливать таймер ConnectRetryTimer и сбрасывать его значение в 0;
  • устанавливать для таймера DelayOpenTimer начальное значение (DelayOpenTime);
  • сохранять состояние Active.

  Если DelayOpen = FALSE, локальная система будет:

  • устанавливать ConnectRetryTimer = 0;
  • завершать инициализацию BGP;
  • передавать удаленному узлу сообщение OPEN;
  • устанавливать большое значение для таймера удержания;
  • переходить в состояние OpenSent.

  Для этого перехода предлагается устанавливать значение HoldTimer равным 4 минутам.

  В ответ на событие TcpConnectionFails (18) локальная система будет:

  • заново запускать таймер ConnectRetryTimer (с начальным значением);
  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;
  • освобождать все ресурсы BGP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  Если получено сообщение OPEN и запущен таймер DelayOpenTimer (Событие 20), локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот запущен) и сбрасывать его значение в 0;
  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;
  • завершать инициализацию BGP;
  • передавать сообщение OPEN;
  • передавать сообщение KEEPALIVE;

  • если значение HoldTimer отлично от 0:

    • запускать таймер KeepaliveTimer с начальным значением;
    • сбрасывать таймер HoldTimer в согласованное значение,

    если HoldTimer = 0

    • сбрасывать таймер KeepaliveTimer (0);
    • сбрасывать в 0 таймер HoldTimer;
  • переходить в состояние OpenConfirm.

  Если в поле AS содержится номер локальной автономной системы, соединение относится к числу внутренних, в противном случае считается внешним.

  Если обнаружены ошибки при проверке заголовка BGP (Событие 21) или сообщения OPEN (Событие 22) (см. параграф 6.2), локальная система будет:

  • (необязательно) если атрибут SendNOTIFICATIONwithoutOPEN имеет значение TRUE, локальная система сначала будет передавать сообщение NOTIFICATION с соответствующим кодом ошибки;
  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  При получении сообщения NOTIFICATION об ошибке верификации (Событие 24), локальная система проверяет таймер DelayOpenTimer. Если этот таймер запущен, локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;
  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • переходить в состояние Idle.

  Если таймер DelayOpenTimer не запущен, локальная система будет:

  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  В ответ на любое другое событие (8, 10-11, 13, 19, 23, 25-28) локальная система будет:

  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

• Состояние OpenSent

• В этом состоянии BGP FSM ожидает сообщения OPEN от партнера.

  Стартовые события (1, 3-7) игнорируются в состоянии OpenSent.

  Если в состоянии OpenSent происходит событие ManualStop (2), локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • устанавливать ConnectRetryCounter = 0;
  • переходить в состояние Idle.

  Если в состоянии OpenSent происходит событие AutomaticStop (8), локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  В ответ на событие HoldTimer_Expires (10) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом ошибки Hold Timer Expired;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  События TcpConnection_Valid (14), Tcp_CR_Acked (16) или TcpConnectionConfirmed (17) говорят о том, что может иметь место попытка организации второго соединения TCP. Это второе соединение находится под контролем системы обработки конфликтов при соединениях (параграф 6.8), пока не будет принято сообщение OPEN.

  Запросы соединений TCP через некорректный порт (Tcp_CR_Invalid — Событие 15)) игнорируются.

  При получении информации о событии TcpConnectionFails (18) локальная система будет:

  • закрывать соединение BGP;
  • заново запускать таймер ConnectRetryTimer;
  • продолжать прослушивание порта на предмет вызовов от удаленных узлов BGP;
  • переходить в состояние Active.

  При получении сообщения OPEN проверяется корректность всех полей этого сообщения. Если сообщение OPEN не содержит ошибок (Событие 19), локальная система будет:

  • сбрасывать в 0 таймер DelayOpenTimer;
  • устанавливать для таймера ConnectRetryTimer значение 0;
  • передавать сообщение KEEPALIVE;
  • устанавливать значение таймера KeepaliveTimer (см. ниже);
  • устанавливать для таймера HoldTimer согласованное значение (см. параграф 4.2);
  • переходить в состояние OpenConfirm.

  Если согласованное время удержания равно 0, таймеры HoldTimer и KeepaliveTimer не запускаются. Если значение поля My Autonomous System совпадает с номером локальной AS, соединение трактуется как внутреннее, в противном случае относится к числу внешних (это будет оказывать влияние на описанную ниже обработку сообщений UPDATE).

  Если обнаружены ошибки при проверке заголовка BGP (Событие 21) или сообщения OPEN (Событие 22) (см. параграф 6.2), локальная система будет:

  • передавать сообщение NOTIFICATION с соответствующим кодом ошибки;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  При получении корректного сообщения BGP OPEN (Событие 19 или 20) требуется применять механизм детектирования конфликтов (параграф 6.8).

  Событие CollisionDetectDump происходит, когда реализация BGP определяет наличие конфликта при соединении (рассмотрение этих механизмов выходит за пределы данного документа).

  Если в состоянии OpenSent возникает необходимость закрыть соединение, машине состояний передается сигнал OpenCollisionDump (Событие 23). При получении такого события в состоянии OpenSent локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  Если получено сообщение NOTIFICATION с кодом ошибки несоответствия версий (Событие 24), локальная система будет:

  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • переходить в состояние Idle.

  В ответ на любое другой событие (9, 11-13, 20, 25-28) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Finite State Machine Error;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

• Состояние OpenConfirm

• В этом состоянии BGP FSM ожидает приема сообщения KEEPALIVE или NOTIFICATION.

  Любый стартовые события (1, 3-7) игнорируются в состоянии OpenConfirm.

  В ответ на событие ManualStop (2), инициированное оператором, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • устанавливать ConnectRetryCounter = 0;
  • устанавливать ConnectRetryTimer = 0;
  • переходить в состояние Idle.

  В ответ на событие AutomaticStop (8), инициированное системой, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  Если событие HoldTimer_Expires (Событие 10) происходит до получения сообщения KEEPALIVE, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом ошибки Hold Timer Expired,
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  Если локальная система получает сигнал KeepaliveTimer_Expires (Событие 11), она будет:

  • передавать сообщение KEEPALIVE;
  • заново запускать таймер KeepaliveTimer;
  • сохранять состояние OpenConfirmed.

  Событие TcpConnection_Valid (14) или успешная организация соединения TCP (Событие 16 или 17) в состоянии OpenConfirm требуют от локальной системы проверки отсутствия второго соединения (с тем же партнером).

  При попытке организации соединения TCP через некорректный порт (Событие 15) локальная система будет игнорировать вторую попытку организации соединения.

  Если локальная система получает сигнал TcpConnectionFails (Событие 18) от нижележащего уровня TCP или сообщение NOTIFICATION (Событие 25), она будет:

  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  Если локальная система получает сообщение NOTIFICATION с кодом ошибки несоответствия версий (NotifMsgVerErr — Событие 24)), она будет:

  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • переходить в состояние Idle.

  Если локальная система получает корректное сообщение OPEN (BGPOpen — Событие 19), выполняется процесс детектирования конфликтов, описанный в параграфе 6.8. Если в результате данное соединение будет разрываться, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP (пакет TCP FIN);
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  Если получено сообщение OPEN, проверяется корректность всех полей этого сообщения. Если обнаружены ошибки при проверке заголовка BGP (Событие 21) или сообщения OPEN (Событие 22) (см. параграф 6.2), локальная система будет:

  • передавать сообщение NOTIFICATION с соответствующим кодом ошибки;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  Если (в процессе обработки другого сообщения OPEN) реализация BGP определяет (способы детектирования выходят за пределы данного документа), что произошел конфликт при соединении и данное соединение будет закрыто, локальная система будет подавать сигнал OpenCollisionDump (Событие 23). При получении сигнала OpenCollisionDump (Событие 23) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  При получении сообщения KEEPALIVE (KeepAliveMsg — Событие 26) локальная система будет:

  • заново запускать таймер HoldTimer;
  • переходить в состояние Established.

  В ответ на все остальные события (9, 12-13, 20, 27-28) локальная система будет:

  • передавать сообщение NOTIFICATION с соответствующим кодом Finite State Machine Error;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

• Состояние Established

• В состоянии Established машина BGP FSM может обмениваться сообщениями UPDATE, NOTIFICATION и KEEPALIVE со своим партнером. Любые стартовые события (1, 3-7) игнорируются в состоянии Established.

  В ответ на событие ManualStop (Событие 2), инициированное оператором, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • устанавливать ConnectRetryCounter = 0;
  • переходить в состояние Idle.

  В ответ на событие AutomaticStop (8) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;
  • устанавливать ConnectRetryTimer = 0;
  • удалять все маршруты, связанные с этим соединением;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  Одной из причин сигнала AutomaticStop может быть получение сообщений UPDATE с числом префиксов, превышающим заданный предел общего числа префиксов. Локальная система будет автоматически разрывать соединение с данным партнером.

  В ответ на событие HoldTimer_Expires (10) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом ошибки Hold Timer Expired;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations attribute = TRUE;
  • переходить в состояние Idle.

  По сигналу KeepaliveTimer_Expires (Событие 11) локальная система будет:

  • передавать сообщение KEEPALIVE;
  • заново запускать таймер KeepaliveTimer, если согласованное значение HoldTime не равно 0.

  Каждый раз при получении локальной системой сообщения KEEPALIVE или UPDATE она заново запускает таймер KeepaliveTimer, если согласованное значение HoldTime не равно 0.

  Сигнал TcpConnection_Valid (Событие 14), принятый для корректного порта, будет инициировать систему отслеживания второго соединения.

  Некорректные соединения (Tcp_CR_Invalid — Событие 15) будут игнорироваться.

  В ответ на индикацию завершения организации соединения TCP (Событие 16 или 17) следует отслеживать второе соединение, пока не будет передано сообщение OPEN.

  Если получено корректное сообщение OPEN (BGPOpen — Событие 19) и CollisionDetectEstablishedState = TRUE, сообщение OPEN будет проверяться на предмет конфликта (параграф 6.8) с другими соединениями. Если реализация BGP принимает решение о разрыве данного соединения, она будет генерировать сигнал OpenCollisionDump (Событие 23). Если соединение нужно разорвать, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;
  • устанавливать ConnectRetryTimer = 0;
  • удалять все маршруты, связанные с соединением;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  Если локальная система получает сообщение NOTIFICATION (Событие 24 или 25) или сигнал TcpConnectionFails (Событие 18) от нижележащего уровня TCP, она будет:

  • устанавливать ConnectRetryTimer = 0;
  • удалять все маршруты, связанные с соединением;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • переходить в состояние Idle.

  При получении сообщения KEEPALIVE (Событие 26) локальная система будет:

  • заново запускать таймер HoldTimer, если согласованное значение HoldTime не равно 0;
  • сохранять состояние Established.

  В ответ на сообщение UPDATE (Событие 27) локальная система будет:

  • обрабатывать принятое сообщение;
  • заново запускать таймер HoldTimer, если согласованное значение HoldTime не равно 0;
  • сохранять состояние Established.

  Если локальная система получает сообщение UPDATE и процедура контроля ошибок в сообщениях UPDATE (см. параграф 6.3) обнаруживает ошибку (Событие 28), локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Update Error;
  • устанавливать ConnectRetryTimer = 0;
  • удалять все маршруты, связанные с соединением;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

  В ответ на все прочие события (9, 12-13, 20-22) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Finite State Machine Error,
  • удалять все маршруты, связанные с соединением;
  • устанавливать ConnectRetryTimer = 0;
  • освобождать все ресурсы BGP;
  • сбрасывать соединение TCP;
  • увеличивать значение ConnectRetryCounter на 1;
  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;
  • переходить в состояние Idle.

9. Обработка сообщений UPDATE

Сообщение UPDATE может быть получено только в состоянии Established. Получение такого сообщения в любом другом состоянии является ошибкой. При получении сообщения UPDATE проверяется корректность каждого поля в соответствии с параграфом 6.3.

Если не удается распознать дополнительные непереходные атрибуты, они просто игнорируются. Если не удается распознать дополнительные переходные атрибуты, устанавливается значение бита Partial=1 в поле флагов атрибута (третий по старшинству бит) и атрибут сохраняется для передачи другим узлам BGP.

Если дополнительный атрибут распознан и имеет корректное значение, тогда (в зависимости от типа дополнительного атрибута) этот атрибут обрабатывается локально, сохраняется и обновляется (при необходимости) для возможной передачи другим узлам BGP.

Если сообщение UPDATE содержит непустое поле WITHDRAWN ROUTES (отзываемые маршруты), ранее анонсированные маршруты, чьи адресаты указаны префиксами IP в данном поле, удаляются из таблицы Adj-RIB-In. Узлу BGP следует запустить процесс выбора маршрутов (Decision Process), поскольку анонсированные ранее маршруты больше не являются доступными.

Если сообщение UPDATE содержит доступный маршрут, таблицу Adj-RIB-In следует обновить, добавив этот маршрут, как указано здесь — если поле NLRI нового маршрута идентично одному из маршрутов, хранящихся в Adj-RIB-In, новый маршрут нужно поместить взамен имеющегося в Adj-RIB-In (таким образом, неявно отзывая более старый маршрут). В противном случае, если Adj-RIB-In не содержит маршрута с идентичным значением NLRI, новый маршрут следует включить в таблицу Adj-RIB-In.

После того, как узел BGP обновит базу Adj-RIB-In, ему следует инициировать процесс выбора маршрутов (Decision Process).

9.1. Процесс выбора маршрутов (Decision Process)

Процесс выбора маршрутов (Decision Process) обеспечивает выбор маршрутов для последующего анонсирования путем применения правил, заданных в локальной базе PIB (Policy Information Base), к маршрутам из базы Adj-RIB-In. Результатом процесса является набор маршрутов, которые будут анонсироваться всем партнерам, — эти маршруты хранятся в локальной базе Adj-RIB-Out в соответствии с политикой.

BGP Decision Process описывается здесь концептуально и не обязательно должен быть реализован в точном соответствии с этим описанием. Если реализация поддерживает описанную функциональность, она будет демонстрировать внешнее поведение, соответствующее данному описанию.

Процесс выбора формализуется путем определения функций, принимающих атрибуты данного маршрута в качестве аргументов и возвращающих (a) неотрицательное целое число, которое задает уровень предпочтения для данного маршрута, или (b) значение, показывающее, что данный маршрут нежелательно включать в Loc-RIB и он будет исключен рассмотрения на последующих этапах процесса выбора.

В функции, вычисляющей уровень предпочтения для данного маршрута, не следует использовать в качестве входных данных перечисленной здесь информации — существование других маршрутов, отсутствие других маршрутов, атрибуты пути для других маршрутов. Процесс выбора маршрутов состоит из независимого определения уровня предпочтения каждого доступного маршрута и последующего выбора одного из маршрутов с максимальным уровнем предпочтения.

Процесс выбора применяется ко всем маршрутам из базы Adj-RIB-In и отвечает за:

• выбор маршрутов, которые будут использоваться локальным узлом;
• выбор маршрутов, которые будут анонсироваться партнерам BGP;
• агрегирование (объединение) маршрутов и снижение объема маршрутной информации.

Decision Process делится на три фазы, каждая из которых включается определенными событиями:

• Фаза 1 отвечает за расчет уровня предпочтения для каждого маршрута, полученного от партнеров.

• Фаза 2 начинается по завершении фазы 1 и отвечает за выбор лучшего маршрута из числа доступных для каждого адресата, а также включение выбранных маршрутов в Loc-RIB.

• Фаза 3 начинается после обновления Loc-RIB и отвечает за распространение маршрутов из Loc-RIB всем партнерам в соответствии с политикой, содержащейся в PIB. На этой фазе также может выполняться объединение маршрутов и снижение объема маршрутной информации.

9.1.1. Фаза 1: Расчет предпочтений (Calculation of Degree of Preference)

Фаза 1 активизируется всякий раз, когда локальный узел BGP получает от партнера сообщение UPDATE, анонсирующее новый маршрут, замену или отзыв маршрута.

Фаза 1 представляет собой отдельный процесс, который завершается после выполнения всех требуемых операций.

Функция, используемая в фазе 1, блокирует базу Adj-RIB-In прежде, чем начать работу с содержащимися в ней маршрутами и снимет блокировку по завершении работы со всеми новыми или недоступными маршрутами в этой базе.

При получении нового маршрута или замене доступного маршрута локальный узел BGP определяет уровень предпочтения, как описано ниже:

• Если маршрут получен от внутреннего партнера в качестве уровня предпочтения принимается значение атрибута LOCAL_PREF или локальная система рассчитывает этот уровень на основе заданных конфигурацией параметров политики. Отметим, что последний вариант может приводить к возникновению постоянных маршрутных петель.

• Если маршрут получен от внешнего партнера, локальный узел BGP рассчитывает уровень предпочтения на основе заданных конфигурацией параметров политики. Если полученное значение показывает, что маршрут является неподходящим, этот маршрут может не передаваться на следующий этап процесса выбора, в противном случае возвращенное значение должно использоваться как значение LOCAL_PREF в любом повторном анонсе IBGP.

• Конкретные правила политики и методы расчета уровня предпочтения задаются локально.

9.1.2. Фаза 2: Выбор маршрута (Route Selection)

Фаза 2 выполняется после завершения фазы 1 и представляет собой отдельный процесс, который завершается после выполнения всех необходимых операций. В фазе 2 используются все маршруты из базы Adj-RIBs-In.

Активизация фазы 2 блокируется, пока не будет завершена работа фазы 3. Функция фазы 2 блокирует целиком базу Adj-RIBs-In перед началом работы и снимает блокировку по завершении расчета.

Если атрибут NEXT_HOP маршрута BGP указывает непреобразуемый адрес или этот адрес не будет преобразовываться после установки маршрута, такой маршрут BGP должен исключаться из обработки в фазе 2.

Если атрибут AS_PATH маршрута BGP содержит петлю (AS loop), маршрут BGP следует исключить из рассмотрения в фазе 2. Детектирование петель осуществляется путем полного сканирования пути, указанного в атрибуте AS_PATH, и проверки отсутствия в нем номера локальной AS. Обсуждение работы узлов BGP, настроенных на восприятие маршрутов с номером AS этого узла в атрибутах пути, выходит за пределы данного документа.

Важно, чтобы узлы BGP внутри AS при выборе маршрутов не принимали конфликтующих решений, которые будут приводить к возникновению петель при пересылке пакетов.

Для каждого набора адресатов, к которому существует доступный маршрут в таблице Adj-RIBs-In, локальный узел BGP идентифицирует маршрут, соответствующий одному из перечисленных условий:

• маршрут имеет высший уровень предпочтения из всего набора путей к этому множеству адресатов;
• маршрут является единственным для данного множества адресатов;
• маршрут выбран в результате применения в фазе 2 правил «отбрасывания лишнего» (tie breaking) описанных в параграфе 9.1.2.2.

После этого локальному узлу следует установить маршрут в таблицу Loc-RIB, заменяя любой маршрут к тому же адресату, который в настоящее время хранится в Loc-RIB. После включения нового маршрута BGP в таблицу маршрутизации следует принять меры по удалению из таблицы других маршрутов к тому же адресату. Принятие решения о замене имеющегося в таблице маршрута, полученного не от BGP, на маршрут BGP определяется локальной политикой узла BGP.

Локальный узел должен определить адрес ближайшего маршрутизатора (immediate next-hop) из атрибута NEXT_HOP выбранного маршрута (см. параграф 5.1.3). При смене ближайшего маршрутизатора или стоимости IGP до NEXT_HOP (NEXT_HOP преобразуется через маршрут IGP) выбор маршрута в фазе 2 должен быть проведен заново.

Отметим, что даже в тех случаях, когда маршруты BGP не включаются в таблицу маршрутизации с immediate next-hop, реализация должна принять меры для того, чтобы адрес NEXT_HOP был преобразован в адрес подключенного напрямую следующего маршрутизатора до того, как по маршруту BGP будет начата пересылка пакетов, и этот адрес (адреса) использовался при реальной пересылке пакетов.

Маршруты, которые невозможно преобразовать, следует удалить из базы Loc-RIB и таблицы маршрутизации. Однако соответствующие непреобразуемые маршруты следует сохранить в базе Adj-RIBs-In (впоследствии их преобразование может стать возможным).

9.1.2.1. Возможность преобразования маршрута

Как сказано в параграфе 9.1.2, узлам BGP следует исключать непреобразуемые маршруты из рассмотрения в фазе 2. Это позволяет включать в базу Loc-RIB и таблицу маршрутизации только действующие маршруты.

Возможность преобразования маршрута определяется перечисленными ниже условиями:

• Маршрут Rte1, указанный только промежуточным адресом, рассматривается как преобразуемый, если таблица маршрутизации содержит по крайней мере один маршрут Rte2, который соответствует промежуточному адресу маршрута Rte1 и преобразуется без рекурсии (непосредственно или опосредованно) через Rte1. Пр наличии более одного такого маршрута следует рассматривать только маршрут с максимальным соответствием.

• Маршруты, указанные интерфейсами (с промежуточным адресом или без него) считаются преобразуемыми, если указанный для маршрута интерфейс активен и для него включена обработка IP.

Маршруты BGP не включают интерфейсов, но могут быть преобразованы в маршруты из таблицы маршрутизации, которые могут относиться к обоим перечисленным выше типам (т. е., задавать или не задавать интерфейс). Предполагается, что маршруты IGP и маршруты в непосредственно подключенные сети задают выходной интерфейс. Статические маршруты могут задавать выходной интерфейс, промежуточный адрес или оба параметра.

Отметим, что маршрут BGP рассматривается как непреобразуемый в ситуации, когда таблица маршрутизации узла BGP не включает маршрута, соответствующего значению NEXT_HOP из маршрута BGP. Взаимно-рекурсивные маршруты (маршруты, преобразующие друг друга или самого себя) также не проходят проверку на возможность преобразования.

Важно также обеспечить исключение доступных маршрутов, которые станут непреобразуемыми после их включения в таблицу маршрутизации даже если значение NEXT_HOP для такого маршрута может быть преобразовано в текущем контексте таблицы маршрутизации (примером могут служить взаимно-рекурсивные маршруты). Эта проверка гарантирует, что узел BGP не включит в свою таблицу маршруты, которые будут удалены и не будут использоваться узлом. Следовательно, в дополнение к стабильности локальной таблицы маршрутизации эта проверка также делает более эффективной работу протокола в сети.

В тех случаях, когда узел BGP идентифицирует маршрут как непреобразуемый по причине взаиморекурсии, следует записывать сообщение об ошибке в журнальный файл системы.

9.1.2.2. «Отбрасывание лишнего» (фаза 2)

В таблице Adj-RIBs-In узла BGP может храниться несколько маршрутов к одному адресату, имеющих одинаковый уровень предпочтения. Локальный узел может выбрать только один из таких маршрутов для включения в таблицу Loc-RIB. К рассмотрению принимаются все маршруты с одинаковым уровнем предпочтения, полученные как от внутренних, так и от внешних партнеров.

В описанной ниже процедуре предполагается, что для каждого маршрута-кандидата все узлы BGP в автономной системе могут определить стоимость пути (внутренняя дистанция) до адреса, указанного атрибутом NEXT_HOP в данном маршруте, и применяется один алгоритм выбора маршрутов.

Работа алгоритма tie-breaking начинается с рассмотрения всех маршрутов к одному множеству адресатов, имеющих одинаковый уровень предпочтения, и выбором маршрутов, которые будут исключаться из рассмотрения. Работа алгоритма завершается после того, как останется единственный маршрут. Критерии отбора должны применяться в указанном ниже порядке.

Некоторые критерии описаны с использованием псевдокода. Отметим, что выбор псевдокода был продиктован соображениями ясности, а не эффективности. Он не предназначен для конкретной реализации. Реализации протокола BGP могут использовать любой алгоритм, который будет давать такой же результат, как описано здесь.

• Исключаются из рассмотрения все маршруты, с числом номеров AS в атрибуте AS_PATH, большим минимального значения. Отметим, что при расчете этого значения AS_SET учитывается как 1, независимо от количества AS в данном наборе.

• Исключаются из рассмотрения все маршруты, для которых значение атрибута Origin превышает минимальное.

• Исключаются из рассмотрения маршруты с менее предпочтительными атрибутами MULTI_EXIT_DISC. Значения MULTI_EXIT_DISC можно сравнивать только для маршрутов, полученных из одной соседней AS (эта AS определяется из атрибута AS_PATH). Маршруты без атрибута MULTI_EXIT_DISC рассматриваются как маршруты с наименьшим возможным значением MULTI_EXIT_DISC.

  Описанный выше алгоритм можно представить в виде следующей процедуры:

  for m = число остающихся в рассмотрении маршрутов
      for n = число остающихся в рассмотрении маршрутов
          if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
              исключить маршрут m из рассмотрения

  В приведенном выше псевдокоде функция MED(n) возвращает значение атрибута MULTI_EXIT_DISC для маршрута n. Если маршрут n не имеет атрибута MULTI_EXIT_DISC, функция возвращает минимальное из возможных значений MULTI_EXIT_DISC (т. е., 0).

  Функция neighborAS(n) возвращает номер соседней AS, из которой был получен маршрут n. Если маршрут получен через IBGP и другой узел IBGP не является исходной точкой этого маршрута, это будет номер соседней AS, из которой другой узел IBGP получил маршрут. Если маршрут получен через IBGP и другой узел IBGP (a) является исходной точкой маршрута или (b) создал маршрут путем агрегирования и атрибут AS_PATH агрегированного маршрута пуст или начинается с AS_SET, это локальная AS.

  Если атрибут MULTI_EXIT_DISC удаляется до повторного анонсирования маршрута в IBGP, можно провести сравнение с использованием полученного через EBGP атрибута MULTI_EXIT_DISC. Если реализация решает удалить MULTI_EXIT_DISC, тогда дополнительное сравнение MULTI_EXIT_DISC, если оно выполняется, должно учитывать только маршруты, полученные через EBGP. Наилучший маршрут от EBGP можно тогда сравнивать с маршрутами от IBGP после удаления атрибута MULTI_EXIT_DISC. Если атрибут MULTI_EXIT_DISC удаляется из подмножества маршрутов от EBGP и из выбранного «лучшего» маршрута от EBGP не будет удален атрибут MULTI_EXIT_DISC, тогда этот атрибут должен использоваться для сравнения с маршрутами от IBGP. Для полученных через IBGP маршрутов атрибут MULTI_EXIT_DISC должен использоваться при сравнении маршрутов, которые не исключены на предыдущих этапах выбора (Decision Process). Включение атрибута MULTI_EXIT_DISC маршрутов от EBGP в сравнение с маршрутами от IBGP с последующим удалением атрибута MULTI_EXIT_DISC и анонсированием маршрута будет предотвращать возникновение маршрутных петель.

• Если хотя бы один из маршрутов-кандидатов получен через EBGP, исключаются из рассмотрения все маршруты, полученные от IBGP.

• Исключаются из рассмотрения все маршруты с наименее предпочтительной внутренней стоимостью (interior cost). Внутренняя стоимость маршрута определяется путем расчета метрики до NEXT_HOP для маршрута с использованием таблицы маршрутизации. Если маршрутизатор NEXT_HOP для этого маршрута доступен, но стоимость пути невозможно определить, этот этап следует пропустить (возможно, рассматривая все маршруты, как равноценные).

  Описанный выше алгоритм можно представить псевдокодом:

  for m = число остающихся в рассмотрении маршрутов
      for n = число остающихся в рассмотрении маршрутов
          if (cost(n) < cost(m))
              исключить маршрут m из рассмотрения

  В приведенном псевдокоде функция cost(n) возвращает стоимость пути (внутренняя дистанция) до адреса, указанного в атрибуте NEXT_HOP рассматриваемого маршрута.

• Исключаются из рассмотрения все маршруты, кроме того, который был анонсирован узлом BGP с наименьшим значением BGP Identifier.

• Выбирается маршрут, полученный от партнера с наименьшим адресом.

9.1.3. Фаза 3: Распространение маршрутов (Route Dissemination)

Фаза 3 выполняется после завершения операций фазы 2 или по любому из перечисленных ниже событий:

• изменение в Loc-RIB маршрутов к локальным адресатам;
• изменение локально сгенерированных маршрутов, которые не были получены от BGP;
• организация соединения с новым узлом BGP.

Функция фазы 3 представляет собой отдельный процесс, работа которого завершается после выполнения всех требуемых действий. Функция фазы 3 блокируется на время работы функции фазы 2.

Все маршруты базы Loc-RIB обрабатываются для включения в Adj-RIBs-Out, согласно заданной конфигурацией политике. Эта политика может исключать маршруты, содержащиеся в Loc-RIB, из числа добавляемых в базу Adj-RIB-Out. Маршрут не следует устанавливать в Adj-Rib-Out, если для адресатов и NEXT_HOP этого маршрута а таблице маршрутизации нет соответствующей записи. Если маршрут из базы Loc-RIB не включается в ту или иную базу Adj-RIB-Out, ранее анонсированный маршрут этой базы Adj-RIB-Out должен быть отозван с помощью сообщения UPDATE (см. параграф 9.2).

В этой фазе могут дополнительно применяться методы агрегирования маршрутов и снижения объема маршрутных данных (см. параграф 9.2.2.1).

Вопросы локальной политики, которая может приводить к включению маршрутов в базу Adj-RIB-Out без их добавления в таблицу пересылки локального узла BGP выходят за пределы данного документа.

После завершения процессов обновления Adj-RIBs-Out и таблицы маршрутизации локальный узел BGP запускает процесс передачи обновлений (Update-Send — параграф 9.2).

9.1.4. Перекрывающиеся маршруты

Узел BGP может передавать маршруты с перекрывающимися NLRI другому узлу BGP. Перекрытие NLRI происходит в тех случаях, когда множество адресатов отображается в несоответствующее множество маршрутов. Поскольку BGP представляет NLRI с использованием префиксов IP, перекрытия всегда могут быть выражены как подмножества. Маршрут, описывающий более узкое множество адресатов (более длинный префикс), будем называть более специфичным по сравнению с маршрутом, описывающим более широкое множество адресатов (префикс короче), — такие маршруты будем называть менее специфичными.

Отношения предпочтительности позволяют разделить менее специфичный маршрут на 2 части:

• множество адресатов, описываемое менее специфичным маршрутом, и
• множество адресатов, описываемое перекрытием менее специфичного и более специфичного маршрутов.

Набор адресатов, описываемый перекрытием, представляет часть менее специфичного маршрута, которая доступна, но в настоящее время не используется. Если более специфичный маршрут впоследствии отзывается, описываемые перекрытием адресаты остаются доступными через менее специфичный маршрут.

Если узел BGP получает перекрывающиеся маршруты, процесс выбора маршрутов (Decision Process) должен рассматривать оба маршрута на основе заданной конфигурацией политики восприятия маршрутов. Если приемлемы оба маршрута (менее специфичный и более специфичный), процесс выбора должен установить в Loc-RIB оба маршрута или объединить их и установить в Loc-RIB агрегированный маршрут, что обеспечивается наличием в обоих маршрутах одинакового значения атрибута NEXT_HOP.

Если узел BGP выбирает агрегирование маршрутов, ему следует включить все AS, используемые при формировании агрегированного маршрута, в AS_SET или добавить в маршрут атрибут ATOMIC_AGGREGATE. Данный атрибут в настоящее время используется в основном как информационный. По мере избавления от протоколов маршрутизации IP, хостов и маршрутизаторов, не поддерживающих бесклассовую маршрутизацию, необходимость в деагрегировании маршрутов отпадет. Маршруты не следует деагрегировать. В частности, маршруты с атрибутом ATOMIC_AGGREGATE деагрегировать недопустимо. Таким образом, значение NLRI такого маршрута не может быть более специфичным. Пересылка по такому маршруту не обеспечивает гарантии, что пакеты IP будут в реальности проходить только через AS, указанные в атрибуте AS_PATH этого маршрута.

9.2. Процесс передачи обновлений (Update-Send)

Процесс передачи обновлений (Update-Send) отвечает за анонсирование сообщений UPDATE всем партнерам. Например, он распространяет маршруты, выбранные Decision Process, другим узлам BGP, которые могут располагаться в той же или соседних AS.

Когда узел BGP получает сообщение UPDATE от внутреннего партнера, принимающему узлу BGP не следует заново распространять содержащуюся в сообщении UPDATE информацию другим внутренним узлам (если данный узел не используется как BGP Route Reflector [RFC2796]).

В фазе 3 процесса выбора маршрутов узел BGP обновляет свою базу Adj-RIBs-Out. Все вновь включенные маршруты и все маршруты, ставшие недоступными (если для них нет замены), следует анонсировать партнерам в сообщениях UPDATE.

Узлу BGP не следует анонсировать доступный маршрут BGP из своей базы Adj-RIB-Out, если это будет порождать сообщение UPDATE, содержащее маршрут BGP, который уже был анонсирован.

Все маршруты из базы Loc-RIB, помеченные как недоступные, следует удалять. Изменения в состоянии доступности адресатов внутри своей автономной системы также следует анонсировать в сообщениях UPDATE.

Если единичный маршрут в силу ограничений на размер сообщений UPDATE (см. главу 4) не помещается в сообщение, для узла BGP недопустимо анонсирование этого маршрута; реализация может записывать информацию о таких фактах в системный журнал.

9.2.1. Контроль служебного трафика

Протокол BGP вынужден ограничивать объем служебного трафика (сообщения UPDATE) в целях снижения расхода полосы каналов на анонсирование и ресурсов системы, требуемых на этапе выбора маршрутов (Decision Process) для обработки информации, содержащейся в сообщениях UPDATE.

9.2.1.1. Частота анонсирования маршрутов

Параметр MinRouteAdvertisementInterval определяет минимальное время, которое должно пройти между анонсированием и/или отзывом маршрутов для конкретного адресата от одного узла BGP. Процедура ограничения частоты рассылки обновлений применяется независимо для каждого адресата, хотя значение MinRouteAdvertisementInterval устанавливается для узла BGP в целом.

Два сообщения UPDATE, передаваемые партнеру узлом BGP, с анонсами доступных и/или недоступных маршрутов к некоторому общему набору адресатов, должны быть разделены промежутком времени не менее MinRouteAdvertisementInterval. Очевидно, что для достижения этого требуется использовать отдельный таймер для каждого общего набора адресатов. Такой подход будет порождать недопустимую нагрузку (overhead). Для практического применения подходит любой метод, обеспечивающий между двумя последовательными сообщениями UPDATE с анонсом доступных и/или недоступных маршрутов к некому множеству адресатов, адресованными одному партнеру, интервал не менее MinRouteAdvertisementInterval и способный гарантировать приемлемое постоянное значение верхней границы для такого интервала.

Поскольку внутри AS требуется быстрое схождение маршрутов, (a) значение MinRouteAdvertisementIntervalTimer, используемое для внутренних партнеров, следует делать меньше значения этого параметра для внешних партнеров или (b) описанную здесь процедуру не следует применять для маршрутов, передаваемых внутренним партнерам.

Эта процедура не ограничивает скорость выбора маршрута, внося лишь ограничение на частоту анонсирования. Если новые маршруты были выбраны несколько раз в течение ожидания MinRouteAdvertisementInterval, по завершении этого периода следует анонсировать последний выбранный маршрут.

9.2.1.2. Частота обновления из исходной AS

Параметр MinASOriginationInterval определяет минимальный интервал времени между последовательными сообщениями UPDATE, которые содержат информацию об изменениях внутри AS анонсирующего узла BGP.

9.2.2. Эффективная организация маршрутных данных

Имея маршрутную информацию для анонсирования, узел BGP может воспользоваться несколькими методами эффективной организации маршрутных данных.

9.2.2.1. Снижение объема информации

Снижение объема информации означает снижение уровня гранулярности контроля над политикой маршрутизации — после сжатия информации одни и те же правила будут применяться ко всем адресатам и путям одного класса.

Процесс выбора маршрутов (Decision Process) может дополнительно снижать объем информации, включаемой в базу Adj-RIBs-Out, любым из перечисленных ниже методов.

• Информация о доступности на сетевом уровне (NLRI):

  IP-адреса получателей могут быть представлены как префиксы IP. В тех случаях, когда имеется соответствие между структурой адреса и системами, находящимися под управлением администратора AS, можно уменьшить размер NLRI, передаваемых в сообщениях UPDATE.

• AS_PATH:

  Информация об AS в пути может быть упорядоченной (AS_SEQUENCE) или неупорядоченной (AS_SET). Вариант AS_SET используется в алгоритме агрегирования маршрутов, описанном в параграфе 9.2.2.2. Агрегирование снижает объем данных AS_PATH за счет однократного указания номера каждой AS (независимо от числа ее упоминаний во множестве агрегируемых атрибутов AS_PATH).

  AS_SET означает, что адресаты, указанные в NLRI, могут быть достигнуты по пути, проходящему по крайней мере через некоторые из включенных в сегмент AS. Сегменты AS_SET обеспечивают достаточную информацию для предотвращения маршрутных петель, однако при их использовании могут теряться потенциально возможные пути, поскольку они больше не указываются индивидуально в форме AS_SEQUENCE. На практике это обычно не вызывает проблем, поскольку по прибытии одного пакета IP на границу группы AS узел BGP в этой точке явно будет иметь более детальную информацию о пути и сможет различать отдельные маршруты к адресатам.

9.2.2.2. Агрегирование маршрутной информации

Агрегирование представляет собой процесс объединения характеристик нескольких маршрутов таким образом, чтобы их можно было анонсировать как единый маршрут. Агрегирование может выполняться как часть процесса выбора маршрутов для снижения объема маршрутных данных, помещаемых в Adj-RIBs-Out.

Агрегирование снижает объем информации, которую узел BGP должен сохранять и рассылать другим узлам BGP. Маршруты можно агрегировать путем применения описанной ниже процедуры раздельно к однотипным атрибутам пути и NLRI.

Маршруты с разными атрибутами MULTI_EXIT_DISC не следует агрегировать.

Если агрегированный маршрут имеет сегмент AS_SET в качестве первого элемента атрибута AS_PATH, маршрутизатору, от которого исходит маршрут, не следует анонсировать с этим маршрутом атрибут MULTI_EXIT_DISC.

Атрибуты пути с различными кодами типа не могут быть агрегированы. Однотипные атрибуты пути могут агрегироваться в соответствии с приведенными ниже правилами:

• NEXT_HOP
• При агрегировании маршрутов с разными атрибутами NEXT_HOP в атрибуте NEXT_HOP агрегированного маршрута следует указывать интерфейс узла BGP, выполняющего агрегирование.
• Атрибут ORIGIN
• Если хотя бы один из агрегируемых маршрутов имеет ORIGIN = INCOMPLETE, для объединенного маршрута также должно устанавливаться ORIGIN = INCOMPLETE. Если хотя бы один из объединяемых маршрутов имеет значение ORIGIN = EGP, агрегированный маршрут также должен иметь значение EGP для этого атрибута. В остальных случаях для агрегированного маршрута устанавливается ORIGIN = IGP.
• Атрибут AS_PATH

• Если агрегируемые маршруты имеют идентичные атрибуты AS_PATH, объединенный маршрут имеет такое же значение AS_PATH.

  В целях объединения атрибутов AS_PATH будем моделировать каждую AS в атрибуте AS_PATH как пару <type, value>, где type определяет тип сегмента пути, к которому относится AS (например, AS_SEQUENCE, AS_SET), а value указывает номер AS. Если агрегируемые маршруты имеют разные атрибуты AS_PATH, для агрегированного атрибута AS_PATH следует обеспечить выполнение всех перечисленных ниже требований:

  • всем парам типа AS_SEQUENCE агрегированного AS_PATH следует присутствовать в каждом атрибуте AS_PATH исходного набора агрегируемых маршрутов;
  • всем парам типа AS_SET агрегированного AS_PATH следует присутствовать хотя бы в одном атрибуте AS_PATH исходного набора (возможно, как AS_SET или AS_SEQUENCE);
  • для любой пары X типа AS_SEQUENCE в агрегированном AS_PATH, которая предшествует паре Y агрегированного AS_PATH, X предшествует Y в каждом атрибуте AS_PATH исходного набора, который содержит Y, независимо от типа Y;
  • ни одной паре типа AS_SET не следует появляться в агрегированном AS_PATH более одного раза;
  • множество пар типа AS_SEQUENCE с одинаковыми значениями может присутствовать в агрегированном AS_PATH только по соседству с другой однотипной парой с совпадающим значением.

  Разработчики могут выбирать любой алгоритм, который обеспечивает соответствие приведенным правилам. Соответствующей требованиям этого документа реализации следует поддерживать по крайней мере описанный ниже алгоритм для выполнения всех приведенных выше требований:

  • определить наиболее длинную последовательность лидирующих пар (как описано выше), присутствующую в атрибутах AS_PATH всех объединяемых маршрутов и сделать ее лидирующей в AS_PATH объединенного атрибута;
  • установить для оставшихся пар из атрибутов AS_PATH объединяемых маршрутов тип AS_SET и присоединить их в конце агрегированного атрибута AS_PATH;
  • если объединенный атрибут AS_PATH содержит несколько одинаковых пар (независимо от типа), лишние (все, кроме одной) пары типа AS_SET следует удалить из объединенного атрибута AS_PATH;
  • для каждых двух смежных пар в агрегированном AS_PATH следует произвести операцию их слияния, если пары имеют одинаковый тип и размер сегмента не будет превышать 255.

  В приложении F (параграф F.6) представлен другой алгоритм, соответствующий условиям и допускающий более сложную конфигурационную политику.

• Атрибут ATOMIC_AGGREGATE
• Если хотя бы один из объединяемых маршрутов имеет атрибут ATOMIC_AGGREGATE, в объединенный маршрут также следует включать этот атрибут.
• Атрибут AGGREGATOR
• Любые атрибуты AGGREGATOR из агрегируемых маршрутов недопустимо включать в агрегированный маршрут. Выполняющий агрегирование узел BGP может включить в маршрут новый атрибут AGGREGATOR (см. параграф 5.1.7).

9.3. Критерии выбора маршрута

В общем случае рассмотрение дополнительных правил сравнения маршрутов выходит за пределы данного документа. Однако имеются два исключения:

• если локальная AS присутствует в пути нового маршрута, этот маршрут не может считаться лучше какого-либо из имеющихся путей (предполагается, что узел принимает такие маршруты); нарушение этого правила ведет к возникновению маршрутных петель;
• для обеспечения эффективной распределенной обработки следует выбирать только маршруты, представляющиеся стабильными. Таким образом, AS следует избегать применения нестабильных маршрутов и не следует вносить скороспелых спонтанных изменений при выборе путей. Трактовка слов «нестабильный» и «скороспелый» в предыдущем предложении требует некоторого опыта, но, в принципе, достаточно понятна. Нестабильные маршруты могут быть «оштрафованы» (например, с использованием процедур, описанных в документе [RFC2439]).

9.4. Порождение маршрутов BGP BGP

Узел BGP может порождать (originate) маршруты BGP, помещая информацию, полученную из других источников (например, IGP), в BGP. Порождающий маршруты узел BGP указывает для таких маршрутов уровень предпочтения (например, в соответствии с локальной политикой), используя для этого Decision Process (см. параграф 9.1). Эти маршруты могут также рассылаться другим узлам BGP в локальной AS, как часть процесса обновления (см. параграф 9.2). Решение о целесообразности рассылки полученной из других источников информации внутри AS с использованием BGP зависит от используемой в AS среды (например, типа IGP) и его следует задавать на уровне конфигурации.

10. Таймеры BGP

BGP поддерживает пять таймеров — ConnectRetryTimer (см. главу 8), HoldTimer (см. параграф 4.2), KeepaliveTimer (см. главу 8), MinASOriginationIntervalTimer (см. параграф 9.2.1.2) и MinRouteAdvertisementIntervalTimer (см. параграф 9.2.1.1).

Могут также поддерживаться два дополнительных таймера — DelayOpenTimer и IdleHoldTimer (см. главу 8). Использование этих таймеров описано в главе 8. Полное описание работы этих дополнительных таймеров выходит за пределы данного документа.

Параметр ConnectRetryTime является обязательным атрибутом FSM и хранит начальное значение для таймера ConnectRetryTimer. Предлагается по умолчанию устанавливать значение ConnectRetryTime равным 120 секундам.

Параметр HoldTime является обязательным атрибутом FSM и сохраняет начальное значение таймера HoldTimer. Предлагается по умолчанию использовать для HoldTime значение 90 секунд.

На некоторых этапах (см. главу для HoldTimer устанавливается большое значение. Предлагается в качестве такого значения устанавливать 4 минуты.

Параметр KeepaliveTime является обязательным атрибутом FSM и сохраняет начальное значение таймера KeepaliveTimer. По умолчанию предлагается устанавливать для KeepaliveTime значение 1/3 HoldTime.

Для таймера MinASOriginationIntervalTimer предлагается по умолчанию использовать значение 15 секунд.

Для таймера MinRouteAdvertisementIntervalTimer предлагается устанавливать значение 30 секунд на соединениях EBGP.

Для таймера MinRouteAdvertisementIntervalTimer предлагается устанавливать значение 5 секунд на соединениях IBGP.

Реализация BGP должна обеспечивать возможность установки значения HoldTimer с помощью конфигурационного параметра независимо для каждого партнера и может обеспечивать возможность выбора значений для других таймеров.

Для снижения вероятности возникновения пиков при распространении сообщений BGP данным узлом следует использовать флуктуации (jitter) для таймеров, связанных с MinASOriginationIntervalTimer, KeepaliveTimer, MinRouteAdvertisementIntervalTimer и ConnectRetryTimer. Данный узел BGP может использовать одинаковые флуктуации для каждого из этих таймеров независимо от адресатов передаваемых обновлений (т. е., флуктуации не требуется делать независимыми для каждого партнера).

Предлагаемую по умолчанию величину флуктуаций следует определять путем умножения базового значения соответствующего таймера на случайное значение из диапазона 0,75 — 1,0. При каждой установке таймера следует выбирать новое случайное значение. Диапазон флуктуаций может быть настраиваемым.

Приложение A. Сравнение с RFC 1771

В настоящем документе имеется множество редакторских правок спецификации [RFC1771] (слишком много для перечисления).

Ниже приводится список технических изменений:

• Внесены изменения, связанные с использованием TCP MD5 [RFC2385], BGP Route Reflectors [RFC2796], BGP Confederations [RFC3065] и BGP Route Refresh [RFC2918].
• Разъяснено использование поля BGP Identifier в атрибуте AGGREGATOR.
• Процедуры задания верхней границы для числа префиксов, которые узел BGP будет принимать от партнера.
• Возможность включать более одного экземпляра своей AS в атрибут AS_PATH для управления картиной трафика между AS.
• Разъяснены различные типы NEXT_HOP.
• Разъяснено использование атрибута ATOMIC_AGGREGATE.
• Соотношения между ближайшим маршрутизатором (immediate next hop) и следующим маршрутизатором, указанным атрибутом пути NEXT_HOP.
• Разъяснены процедуры «отбрасывания лишнего» (tie-breaking).
• Разъяснены требования по частоте анонсирования маршрутов.
• Отменено использование дополнительного параметра типа 1 (Authentication Information).
• Отменен субкод 7 (AS Routing Loop) для ошибок в сообщениях UPDATE.
• Отменен субкод 5 (Authentication Failure) для ошибок в сообщениях OPEN.
• Отменено использование поля Marker для аутентификации.
• Реализация должна поддерживать механизм TCP MD5 [RFC2385] для аутентификации.
• Разъяснена работа BGP FSM.

Приложение B. Сравнение с RFC 1267

Все изменения, перечисленные в Приложении A, а также указанные ниже изменения:

• BGP-4 может работать в среде, где множество доступных адресатов может указываться с помощью одного префикса IP. Концепция классов сетей или подсетей чужеродна для BGP-4. Для поддержки работы с префиксами в BGP-4 изменена семантика и кодирование, связанное с атрибутом AS_PATH. В спецификацию добавлено определение семантики, связанной с префиксами IP. Такое расширение позволяет BGP-4 поддерживать предложенную схему supernet [RFC1518, RFC1519].
• Для упрощения настройки вводится новый атрибут LOCAL_PREF, упрощающий процедуру выбора маршрута.
• Атрибут INTER_AS_METRIC переименован в MULTI_EXIT_DISC.
• Добавлен новый атрибут ATOMIC_AGGREGATE для управления возможностью деагрегирования маршрутов. Другой новый атрибут — AGGREGATOR — может добавляться в агрегированные маршруты, чтобы указать, какая AS и какой узел BGP в этой AS выполнили агрегирование.

Приложение C. Сравнение с RFC 1163

Все изменения, перечисленные в Приложениях A и B, а также указанные ниже изменения:

• Для обнаружения конфликтов при соединениях BGP и восстановления работы протокола добавлено новое поле BGP Identifier в сообщения OPEN. Для описания процедур детектирования и разрешения конфликтов при соединениях в документ добавлен новый параграф (6.8).
• Снято ограничение, требовавшее чтобы граничный маршрутизатор, указанный атрибутом пути NEXT_HOP, относился к той же AS, в которой находится узел BGP.
• В новом документе оптимизировано и упрощено описание процедур обмена информацией о ранее доступных маршрутах.

Приложение D. Сравнение с RFC 1105

Все изменения, перечисленные в Приложениях A, B и C, а также указанные ниже изменения:

• Потребовалось внесение незначительных изменений в машину конечных состояний RFC1105 для согласования с пользовательским интерфейсом TCP в системах BSD версии 4.3.
• Понятия и отношения Up/Down/Horizontal, присутствующие в RFC1105, были исключены из протокола.

• Внесен ряд изменений в формат сообщений RFC1105:

  1. Поле Hold Time было удалено из заголовка BGP и включено в сообщение OPEN.
  2. Поле номера версии было удалено из заголовка BGP и включено в сообщение OPEN.
  3. Из сообщений OPEN было удалено поле Link Type.
  4. Вместо подтверждений OPEN CONFIRM используются сообщения KEEPALIVE.
  5. Существенно изменен формат сообщений UPDATE, добавлены новые поля для поддержки множества атрибутов пути.
  6. Поле Marker было расширено и стало использоваться также для аутентификации.

Отметим, что достаточно часто протокол BGP, соответствующий RFC 1105, называют BGP-1, соответствующий RFC 1163 — BGP-2, а соответствующий RFC 1267 — BGP-3. Вариант BGP, описанный в этом документе, называют BGP-4.

Приложение E. Опции TCP, которые могут использоваться с BGP

Если пользовательский интерфейс TCP в локальной системе поддерживает функцию TCP PUSH, каждое сообщение BGP следует передавать с установленным флагом PUSH. Установка флага приводит к ускорению передачи сообщений BGP.

Если пользовательский интерфейс TCP в локальной системе поддерживает установку поля DSCP [RFC2474] для соединений TCP, транспортные соединения для BGP следует открывать с битами 0-2 поля DSCP, имеющими двоичное значение 110.

Реализация должна поддерживать опцию TCP MD5 [RFC2385].

Приложение F. Рекомендации для разработчиков

В этом приложении даются некоторые рекомендации разработчикам.

Приложение F.1. Множество префиксов сетей в одном сообщении

Протокол BGP позволяет указывать в одном сообщении множество адресных префиксов с одинаковыми атрибутами пути. Настоятельно рекомендуется использовать эту возможность. Передача сообщений с единственным префиксом существенно повышает нагрузку на получателя. В результате передачи множества сообщений растет не только нагрузка на системы, но и издержки при сканировании таблиц маршрутизации для передачи обновлений партнерам BGP и другим протоколам маршрутизации (увеличивается и объем передаваемых обновлений).

Одним из способов создания сообщений с множеством префиксов для каждого набора атрибутов пути из таблицы маршрутизации, не организованной по наборам атрибутов, является создание множества сообщений при сканировании таблицы. При обработке каждого префикса создается сообщение для связанного набора атрибутов пути, если оно не существует и в это сообщение добавляется новый префикс. Если сообщение уже создано, новый префикс просто добавляется в конец этого сообщения. Если в сообщение уже нельзя добавить новый префикс по соображениям размера, имеющееся сообщение передается, а для префикса создается новое сообщение. После завершения сканирования всей таблицы маршрутов созданные сообщения передаются и выделенные для них ресурсы освобождаются. Максимальное сжатие при таком методе обеспечивается в тех случаях, когда все адресаты перекрываются адресными префиксами с одним набором атрибутов пути. В этом случае сообщение может содержать столько префиксов, сколько позволяет ограничение на размер сообщений BGP (4096 октетов).

При работе с реализациями BGP, которые не поддерживают множества префиксов в одном сообщении, может потребоваться выполнение ряда операций для снижения нагрузки в результате лавинной рассылки данных, полученных при обретении нового партнера или существенном изменении сетевой топологии. Одним из способов такого снижения является ограничение частоты передачи обновлений. Это позволяет избавиться от избыточного сканирования таблиц для «мгновенного» обновления узлов BGP и других протоколов маршрутизации. Недостатком этого способа является увеличение задержек при распространении маршрутной информации. Выбор минимального интервала обновлений, который незначительно превышает время обработки множества сообщений, позволяет минимизировать эту задержку. Наилучшим решением будет просмотр всех полученных сообщений до передачи обновлений.

Приложение F.2. Снижение числа переключений маршрутов

Во избежание ненужных переключений маршрутов (route flapping) узлу BGP, которому нужно отозвать маршрут к адресатам и передать обновление с более (или менее) специфичным маршрутом, следует объединять такие анонсы в одно сообщение UPDATE.

Приложение F.3. Упорядочение атрибутов пути

Реализации, комбинирующие обновления (как описано в параграфе 6.1), могут предпочесть просмотр всех атрибутов пути, представленных в определенном порядке. Такой подход позволяет быстро идентифицировать наборы атрибутов из разных обновлений, которые идентичны семантически. Для реализации такого подхода полезно упорядочивать атрибуты в соответствии с кодом типа. Такая оптимизация не является обязательной.

Приложение F.4. Сортировка AS_SET

Другим полезным способом оптимизации является упорядочение по номерам AS, найденным в атрибуте AS_SET. Такая оптимизация не является обязательной.

Приложение F.5. Контроль за согласованием версий

Поскольку протокол BGP-4 может передавать агрегированные маршруты, которые не могут быть корректно представлены в BGP-3, реализациям, поддерживающим BGP-4 и иные версии BGP, следует обеспечивать возможность работы только с BGP-4 независимо для каждого партнера.

Приложение F.6. Комплексное агрегирование ASAS_PATH

Реализация, обеспечивающая механизм агрегирования маршрутов с сохранением значительного количества данных о пути, может использовать описанную ниже процедуру.

Для объединения атрибутов AS_PATH двух маршрутов будем представлять каждую AS как пару <type, value>, где type указывает тип сегмента пути, к которому принадлежит AS (например, AS_SEQUENCE, AS_SET), а value задает номер AS. Если две пары <type, value> совпадают, они относятся к одной AS.

Алгоритм объединения двух атрибутов AS_PATH работает следующим образом:

• Идентифицируется совпадение AS (как описано выше) в каждом атрибуте AS_PATH, которые находятся в том же относительном порядке для каждого атрибута AS_PATH. Две AS (X и Y) следуют в одинаковом порядке, если выполняется любое из приведенных ниже условий:

  • X предшествует Y в обоих атрибутах AS_PATH;
  • Y предшествует X в обоих атрибутах AS_PATH.

• Агрегированный атрибут AS_PATH состоит из AS, найденных на этапе (a) и представленных в том же порядке, который был обнаружен в объединяемых атрибутах AS_PATH. Если две последовательные AS, найденные на этапе (a), не следуют одна за другой непосредственно в каждом из объединяемых атрибутов AS_PATH, мешающие AS (AS, расположенные между двумя последовательно совпадающими AS) из обоих атрибутов объединяются в сегмент пути AS_SET. Этот сегмент пути помещается в агрегированном атрибуте между двумя последовательными AS, идентифицированными в пункте (a).

• Для каждых из двух смежных пар в агрегированном AS_PATH (если они имеют одинаковый тип) выполняется слияние, если оно не будет приводить к генерации сегмента пути размером более 255.

Если в результате применения описанной выше процедуры данный номер AS появляется в агрегированном атрибуте AS_PATH более одного раза, все вхождения этого номера, кроме последнего (самый правый) следует удалить из агрегированного атрибута PATH.

Вопросы безопасности

Реализация BGP должна поддерживать механизм аутентификации, определенный в RFC 2385 [RFC2385]. Аутентификация на основе этого механизма может осуществляться независимо для каждого партнера.

BGP использует протокол TCP для организации надежного обмена трафиком между маршрутизаторами-партнерами. Для обеспечения целостности соединений и аутентификации источников данных в соединениях между парами узлов спецификация BGP задает использование механизма, определенного в RFC 2385. Этот механизм предназначен для детектирования и предотвращения активного перехвата (wiretapping attacks) данных из соединений TCP между маршрутизаторами. В отсутствие такого рода механизмов обеспечения безопасности атакующие могут разрывать соединения TCP и/или маскироваться под легитимные партнерские маршрутизаторы. Поскольку определенный в RFC механизм не обеспечивает аутентификацию партнеров, протокольные соединения могут служить объектом некоторых атак с повторным использованием перехваченных ранее данных (replay attack), которые не будут детектироваться уровнем TCP. Такие атаки могут приводить к доставке (от уровня TCP) «испорченных» или «подмененных» сообщений BGP.

Механизм, определенный в RFC 2385, добавляет к обычным контрольным суммам TCP 16-байтовый код аутентификации сообщения (MAC) который рассчитывается на основе тех же данных, что и контрольная сумма TCP. Расчет MAC основан на использовании необратимой хэш-функции (MD5) и закрытых ключей. Ключ известен паре маршрутизаторов-партнеров и используется для генерации значений MAC, которые не могут быть вычислены атакующим без знания ключа. Соответствующие спецификации реализации протокола должны поддерживать этот механизм и позволять администратору активизировать его использование независимо для каждого партнера.

RFC 2385 не задает механизмов поддержки ключей (например, их генерации, распространения и замены), используемых для расчета MAC. Документ RFC 3562 [RFC3562] (он имеет статус информационного) содержит некоторые рекомендации в этом направлении с обоснованием приведенных рекомендаций. В документе отмечается, что следует использовать разные ключи для связи с каждым защищенным партнером. Если один ключ используется для множества партнеров, это может привести к снижению уровня безопасности (например, за счет того, что при компрометации одного маршрутизатора становятся известными ключи, используемые для других маршрутизаторов).

Используемые для расчета MAC ключи следует периодически заменять для минимизации возможности компрометации ключа или успешной криптоаналитической атаки. В RFC 3562 предлагается устанавливать крипто-период (срок действия ключа) не более 90 дней. Более частая смена ключей снижает вероятность успеха атак с повторным использованием перехваченных данных. Однако отсутствие стандартного механизма эффективной координированной замены ключа, используемого парой маршрутизаторов, не позволяет надеяться, что реализации BGP-4, соответствующие данной спецификации, будут поддерживать такую частоту смены ключей.

Очевидно, что ключи следует выбирать так, чтобы атакующему было сложно угадать или подобрать ключ. Описанные в RFC 1750 методы генерации случайных чисел обеспечивают руководство по созданию значений, которые могут использоваться в качестве ключей. RFC 2385 предлагает разработчикам использовать ключи, представляющие собой строки печатных символов ASCII размером 80 байтов или меньше. В RFC 3562 предлагается в таком контексте использовать ключи размером от 12 до 24 байтов, состоящие из случайных (псевдослучайных) битов. Это полностью совместимо с предложениями для аналогичных алгоритмов MAC, которые обычно используют ключи размером от 16 до 20 байтов. В части обеспечения достаточного уровня случайности при использовании ключей минимальной длины в RFC 3562 также отмечается,что типичная срока текста ACSII будет близка к верхней границе диапазона длины ключей, заданного в RFC 2385.

Анализ уязвимостей протокола BGP приводится в документе [RFC4272].

Согласование с IANA

Все сообщения BGP содержат 8-битовые идентификаторы типа сообщения, для которых агентство IANA создало и поддерживает реестр «BGP Message Types». В данном документе определены следующие типы сообщений:

Выделение новых значений для типов сообщений происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем «Заблаговременного выделения агентством IANA», как описано в [RFC4020]. Типы сообщений задаются именем и числовым идентификатором.

Сообщения BGP UPDATE могут содержать один или множество атрибутов пути (Path Attribute), каждый из которых включает 8-битовый код типа (Attribute Type Code). Агентство IANA поддерживает реестр таких кодов, названный «BGP Path Attributes». В этом документе определяются следующие типы атрибутов пути (Path Attributes Type Code):

Выделение новых значений для кодов атрибутов пути происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем «Заблаговременного выделения агентством IANA», как описано в [RFC4020]. Типы атрибутов задаются именем и числовым идентификатором.

Сообщения BGP NOTIFICATION содержат 8-битовые значения кода ошибки (Error Code), для которых агентство IANA создало и поддерживает реестр «BGP Error Codes». В этом документе определены следующие коды ошибок:

Выделение новых значений для кодов ошибок происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем «Заблаговременного выделения агентством IANA», как описано в [RFC4020]. Коды ошибок задаются именем и числовым идентификатором.

Сообщения BGP NOTIFICATION содержат 8-битовые значения субкода ошибки (Error Subcode) и каждое значение субкода определяется в контексте соответствующего кода ошибки (Error Code) и, таким образом, является уникальным только в этом контексте.

Агентство IANA создало и поддерживает набор реестров «Error Subcodes», в котором для каждого кода ошибки BGP имеется отдельный реестр. Выделение новых значений для субкодов ошибок происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем «Заблаговременного выделения агентством IANA», как описано в [RFC4020]. Субкоды ошибок задаются именем и числовым идентификатором.

В этом документе определяются следующие субкоды для ошибок в заголовках сообщений (Message Header Error):

В этом документе определяются следующие субкоды для ошибок в сообщениях OPEN (OPEN Message Error):

В этом документе определяются следующие субкоды для ошибок в сообщениях UPDATE (UPDATE Message Error):

Нормативные документы

Дополнительная литература

Адреса редакторов

Yakov Rekhter
Juniper Networks
EMail: ten.repinuj@vokay

Tony Li
EMail: il.ynot@il.ynot

Susan Hares
NextHop Technologies, Inc.
825 Victors Way
Ann Arbor, MI 48108
Phone: (734)222-1610
EMail: moc.pohtxen@hks

Важно ли знать форматы заголовков передаваемых данных? Во многих учебных курсах по сетям разбору заголовков протоколов уделяется больше или меньше времени, но обычно без этого не обходится. Нося по своей природе описательный характер часто их изучение вызывает скуку, а наличие средств автоматического разбора не улучшает картину. Иногда заголовок действительно содержит интересный подход, но в большинстве случаев всё это вписывается в какой-то один принцип и следующий новый формат обычно уже не вызывает удивления. Самое интересное это, конечно, всевозможные сочетания тех опций, которые влияют на функционал, но стоит ли помнить какие опции в каком порядке вписываются в заголовке?

Не могу сказать, что я это помню, ещё не могу сказать что это мне мешает в работе. Я даже не могу сказать, что мне приходится часто видеть заголовки в каком-то необработанном виде, потому что, как правило, сообщения в syslog или на консоли уже переформатированы в связные английские предложения. Но, иногда, приходиться смотреть глубже, например, этот год был урожайный на подобные сообщения:

Ericsson SmartEdge

notification msg sent (nbr 192.0.2.1, context 0x40030044 32 bytes, repeated 89 times, code 3/4 (update: attribute flags error) - 
0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

Cisco, то же с другой стороны

NOTIFICATION received from 192.0.2.2 (External AS 64496):
code 3 (Update Message Error) subcode 4 (attribute flags error),
Data: e0 07 08 00 03 02 ed 5b dc 3f 01

Попробуем разобрать это руками как написано в RFC4271. Не будем искать причину — просто разбор заголовков. Будет много цитат и, скорее всего, ничего нового для тех кто уже это умеет делать. Для остальных читаем дальше.

Чтобы внести разнообразие не ограничимся одним сообщением и разберём ещё вот это issue с GitHub FRRouting:

%NOTIFICATION: received from neighbor 192.168.0.1
3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes
50 02 0c de 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... очень много раз 00 04 00 35

Что мы можем прочитать? Видим тип сообщения, его значение и подзначение, IP адрес соседства (который нам и так известен) и шестнадцатеричная строка, которую мы не понимаем.

Начнём с главного с сайта IANA где есть все нужные коды с отсылкой к RFC4271. Если набраться сил и прочитать RFC от корки до корки, то всё должно стать понятно, но мы попытаемся разобраться только в формате наших двух сообщений не затрагивая поведенческие аспекты.

Разбираем NOTIFICATION

Из содержания, по названию, нам подходит пункт 4.5 NOTIFICATION Message Format. Открыв который действительно находим формат нужного нам заголовка и список всех кодов с ссылкой на соответствующие разделы (дальше всё цитирование спрячем под спойлеры):

      0                   1                   2                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Error code    | Error subcode |   Data (variable)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Error Code:

         This 1-octet unsigned integer indicates the type of
         NOTIFICATION.  The following Error Codes have been defined:

            Error Code       Symbolic Name               Reference
              1         Message Header Error             Section 6.1
              2         OPEN Message Error               Section 6.2
              3         UPDATE Message Error             Section 6.3
              4         Hold Timer Expired               Section 6.5
              5         Finite State Machine Error       Section 6.6
              6         Cease                            Section 6.7

Наш раздел 6.3 UPDATE Message Error с кодом ошибки 3. Видим его во всех сообщениях, вместе с уточняющим кодом:

code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

code 3 (Update Message Error) subcode 4 (attribute flags error), Data: e0 07 08 00 03 02 ed 5b dc 3f 01

3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... очень много раз 00 04 00 35

Табличек тут нет, поэтому читаем несколько страниц текста. Каждый абзац описывает поведение в различных ситуациях, которая характеризуется своим кодом ошибки.

В нашем случае — используемые флаги не могут быть использованы c данным атрибутом:

If any recognized attribute has Attribute Flags that conflict with
the Attribute Type Code, then the Error Subcode MUST be set to
Attribute Flags Error.  The Data field MUST contain the erroneous
attribute (type, length, and value).

и — фактическая длина атрибута не совпадает с ожидаемой:

If any recognized attribute has an Attribute Length that conflicts
with the expected length (based on the attribute type code), then the
Error Subcode MUST be set to Attribute Length Error.  The Data field
MUST contain the erroneous attribute (type, length, and value).

Самое важное, что тут написано и что нам поможет в дальнейшем это то, что помимо кодов ошибок в сообщении ДОЛЖЕН присутствовать ошибочный атрибут из UPDATE сообщения в поле data в формате TLV (тип, длина, значение). Та самая шестнадцатеричная строка которую мы пока не можем интерпретировать. Однако, у нас по прежнему есть проблема в идентификации этого поля, связанная теперь с различными соглашениями принятыми производителями устройств для отображения журнала логов.

В примере с Cisco, явно указывается начало словом «Data»:
code 3 (Update Message Error) subcode 4 (attribute flags error), Data: e0 07 08 00 03 02 ed 5b dc 3f 01

В остальных случаях, такой привязки нет. При этом строка с Ericsson, содержит гораздо больше данных чем у Cisco, хотя мы знаем что эти сообщения идентичны. Поэтому возвращаемся на шаг назад к описанию NOTIFICATION и видим что мы разобрали его полностью, поле data переменной длины является последним в сообщении.

Поднимемся выше по иерархии и начнём читать с начала раздела 4.1:

      0                   1                   2                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                                                               +
      |                           Marker                              |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Length               |      Type     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Каждое сообщение начинается с поля:

This 16-octet field is included for compatibility; it MUST be
set to all ones.

длиной в 16 байт и состоящее из всех единиц ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff. Такой же паттерн мы видим в логе Ericsson:
code 3/4 (update: attribute flags error) - 0000 0000 (ffff ffff ffff ffff ffff ffff ffff ffff) 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

Далее поле длины в два байта:
code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff (0020) 0303 04e0 0708 0003 02ed 5bdc 3f01, со значением 32 десятичные, что совпадает с расшифровкой из журнала notification msg sent (nbr 192.0.2.1, context 0x40030044 32 bytes, а ещё дальше :

This 1-octet unsigned integer indicates the type code of the
message.  This document defines the following type codes:

                     1 - OPEN
                     2 - UPDATE
                     3 - NOTIFICATION
                     4 - KEEPALIVE

и мы знаем что оно номер 3 — NOTIFICATION: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 (03)03 04e0 0708 0003 02ed 5bdc 3f01

А следом уже само сообщение и то что мы распознали (раздел 4.5) 03 04 — тип и подтип ошибки: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 03(03 04)e0 0708 0003 02ed 5bdc 3f01

Ericsson повторил нам не только поле data которое начинается с e0, а всё сформированное сообщение. В логе Cisco именно с него начинается байтовая последовательность. Лог FRRouting, также содержит полностью расшифрованный заголовок BGP сообщения NOTIFICATION за которым следует уже поле data, к декодированию которого мы возвращаемся.

Направляемся к описанию формата UPDATE, так как рассчитываем там найти описание форматов атрибутов, чтобы понять что именно мы всё же получаем. UPDATE содержит много полей, атрибуты задаются в поле переменной длины Path Attributes:

A variable-length sequence of path attributes is present in
every UPDATE message, except for an UPDATE message that carries
only the withdrawn routes.  Each path attribute is a triple
<attribute type, attribute length, attribute value> of variable
length.

Начнём со значения поля Тип, которое состоит из двух однобайтных частей:

         Attribute Type is a two-octet field that consists of the
         Attribute Flags octet, followed by the Attribute Type Code
         octet.

               0                   1
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Attr. Flags  |Attr. Type Code|
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Здесь опять надо читать всё подряд, так как всё оформлено сплошным текстом. Из него следует, что поле флагов использует 4 первых бита с 0 по 3, а второй байт определяет сам атрибут. Сведём всё это в таблицу:

Биты 4-7 должны быть 0 при передаче и игнорироваться при приёме, на них внимание не обращаем. Бит 3 определяет размер поля length в TLV:

The fourth high-order bit (bit 3) of the Attribute Flags octet
is the Extended Length bit.  It defines whether the Attribute
Length is one octet (if set to 0) or two octets (if set to 1).

Отдельный интерес представляет флаг partial, который может быть установлен для транзитивных опциональных атрибутов. Описание флага разбросано в нескольких местах по всему тексту RFC. Встречаются следующие ситуации его использования:

1. В случае, если атрибут не распознаётся этот флаг устанавливается, а сам атрибут передаётся дальше — 9 раздел:

   Update Message handling

   If an optional transitive attribute is unrecognized, the Partial 
   bit (the third high-order bit) in the attribute flags octet is 
   set to 1, and the attribute is retained for propagation to other 
   BGP speakers.

2. Если атрибут распознаётся следующим спикером, то флаг всё равно не сбрасывается — 5 раздел:

   Path Attributes

   Paths with unrecognized transitive optional attributes SHOULD be 
   accepted.  If a path with an unrecognized transitive optional 
   attribute is accepted and passed to other BGP peers, then the 
   unrecognized transitive optional attribute of that path MUST be 
   passed, along with the path, to other BGP peers with the Partial bit 
   in the Attribute Flags octet set to 1.  If a path with a recognized,
   transitive optional attribute is accepted and passed along to other 
   BGP peers and the Partial bit in the Attribute Flags octet is set 
   to 1 by some previous AS, it MUST NOT be set back to 0 by the 
   current AS.

3. И если не исходный спикер хочет добавить транзитивный атрибут, то флаг так же устанавливается:

   (там же)

   New, transitive optional attributes MAY be attached to the path by
   the originator or by any other BGP speaker in the path.  If they are
   not attached by the originator, the Partial bit in the Attribute
   Flags octet is set to 1.

Приступим к разбору UPDATE

Поле флагов в первом случае e0: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04(e0) 0708 0003 02ed 5bdc 3f01 — в двоичном 1110 0000 — опциональный, транзитивный с установленным флагом partial, поле длины задаётся одним байтом.

code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 (07)08 0003 02ed 5bdc 3f01 — код атрибута 7 — AGGREGATOR

Размер данных 8 байт: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 07(08) 0003 02ed 5bdc 3f01

Во втором случае — общеизвестный атрибут (50 — 0101 0000), размер поля длины в два байта, AS_PATH (02), длина 3294 байта (0c de): 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes (50 02 0c de) 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... очень много раз 00 04 00 35

Оставшаяся часть строки это поле данных самого атрибута. Для этого продвигаемся дальше по разделу 4.3:

AGGREGATOR is an optional transitive attribute of length 6.
The attribute contains the last AS number that formed the
aggregate route (encoded as 2 octets), followed by the IP
address of the BGP speaker that formed the aggregate route
(encoded as 4 octets).  This SHOULD be the same address as
the one used for the BGP Identifier of the speaker.

Следует учесть работу с 32-битными ASn RFC6793, чтобы получить следующий результат:

4 байта это AS197357: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 (0003 02ed) 5bdc 3f01,

и 4 байта IP адрес 91.220.63.1: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed (5bdc 3f01) — в сумме 8 байт, как и указано в поле длины.

Во втором случае AS_PATH, сам по себе TLV:

The path segment type is a 1-octet length field with the
following values defined:

   Value      Segment Type

    1         AS_SET: unordered set of ASes a route in the
                 UPDATE message has traversed

    2         AS_SEQUENCE: ordered set of ASes a route in
                 the UPDATE message has traversed

The path segment length is a 1-octet length field,
containing the number of ASes (not the number of octets) in
the path segment value field.

Поля типа и длины размером по 1 байту.

Тип 2, размер данных (ff — 255 ASn): 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de (02 ff) 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... очень много раз 00 04 00 35

Сами данные — номера AS по 4 байта каждая: 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de 02 ff (00 00 0c b9) (00 00 00 ae ) (00 04 00 3e ) (00 04 00 3e ) (00 04 00 35 ) (00 04 00 35 )... очень много раз 00 04 00 35 — AS3257, AS174, AS262206 AS262206, AS262197, AS262197, AS262197, AS262197 …

Добрались до конца. Показалось не сложным?.. но скучным. Конечно, это нам мало дало именно в понимании проблемы, так как большая часть документа, которой мы даже не касались описывает не форматы, а требуемое поведение. Но хотя бы мы знаем направление на источник.

К сожалению, а может и нет — RFC не является лёгкой прогулкой для чтения, в некоторых местах данные сведены в таблицы, в других ровно в тех же случаях они расписаны непосредственно в тексте и приходится много вычитывать для понимания структуры. Но радует, что они есть и производители смогли их прочитать и довести до реализации.

P.S. В случае FRRouting есть патч, намекающий, что проблема не в формате.

В первом случае, видимо, тоже нужен патч, так как формально я не увидел какой либо проблемы в совместном использовании флагов для атрибута AGGREGATOR, может кто увидел.

The operational functions of BGP are defined in RFC 1771. These definitions should be complied with for any implementation to be successful. Failure to do so could give rise to serious concerns about the integrity of the information provided by the protocol and potentially create a chaotic state of routing.

It is necessary to understand that BGP operates as a finite state machine (FSM). This means, that at all times of operation, there is a defined state of the process. This process cannot move on to the next state or perform other functions without first meeting a predetermined set of criteria. Once these criteria are met, based on the conclusion, the process will proceed to another predefined state, and go through the process of meeting certain criteria, before proceeding. And on and on it goes. This also implies the ability to handle error conditions.

9.2.1 Transport

BGP uses TCP (port 179) as the underlying transport protocol. This provides the reliable transport function, error correction, and retransmission of the higher-level data, if necessary. TCP relies on IP as the network layer protocol. So, if there is IP connectivity to a destination, the TCP session should remain active. This will become relevant during our discussion on peering and how logical peering works.

9.2.2 Events

In BGP there are 13 different events that cause the FSM to change states. Since an FSM is based on a calculated response to a predetermined number of possible events, the state change is predictable. However, the state-event correlation relies not only on the event, but on the current state of the FSM. The following events allow the FSM state to change:

• BGP start

• BGP stop

• BGP transport connection Open

• BGP transport connection Closed

• BGP transport connection open Failed

• BGP transport fatal error

• Connect- retry timer expired

• Hold timer expired

• Keepalive timer expired

• Receive OPEN message

• Receive KEEPALIVE message

• Receive UPDATE message

• Receive NOTIFICATION message

The next section will discuss the various connection states and how the above listed events determine state change.

9.2.3 Connection States

There are six different states to the FSM as documented in RFC 1771. Each state represents where the BGP process is in terms of operation, but also predicates what type of events can occur to cause the state to change.

9.2.3.1 Idle

The initial state of the BGP process is Idle . In this state, the local system is essentially waiting for some start event to get the process moving. The most common start event is nothing more than the network administrator configuring the local system to peer with a remote system.

Depending on which configuration parameters are used, the local system will either wait for incoming TCP connection on port 179 and subsequent OPEN messages, or it will attempt to establish a TCP connection and begin sending OPEN messages. In JUNOS, if the passive parameter is used, the local system will listen for an incoming TCP connection on TCP port 179, then listen for incoming OPEN messages. If the passive parameter is not used, the local system will start a connect-retry timer and attempt to establish a TCP connection on port 179 to the remote system. BGP is typically configured on one router and then on the other, so the first one is usually trying to establish a connection prior to the remote system being configured. Regardless, if both systems attempt to create a peering session at the same time, the potential for two peering sessions between the same neighbors exists. RFC 1771 outlines a mechanism called connection-collision detection, which will prevent multiple sessions between the same neighbors from being established. Once the TCP connection attempt is started, the FSM will transition to the Connect state.

9.2.3.2 Connect

This state occurs when the local system sees a TCP connection initiated on port 179. This state is key to the overall operation of BGP. If the local system cannot transition out of the Connect state, there is a potential problem with establishing the TCP connection. This can be a useful tip in troubleshooting BGP peering problems.

When the TCP connection is established, the local system will reset the connect-retry timer it started earlier and will send an OPEN message to the remote system. When the local system sends the first OPEN message, the FSM transitions to the OpenSent state.

9.2.3.3 Active

If the router is unable to create the TCP connection, the FSM will transition to the Active state. In this state, the local system will still try to create the TCP connection. If it is able to complete the connection, the local system will send out the OPEN message to the potential peer, and the FSM will transition to the OpenSent state. In the Active state, the local system is capable of receiving a connection attempt from a potential neighbor.

9.2.3.4 OpenSent

When the local system sends out its OPEN message, the FSM will transition to the OpenSent state. When this occurs, the local system will listen for an OPEN message from the remote system. When the local system receives an OPEN message from the remote system, it sends out a KEEPALIVE message to the remote, and the FSM transitions to the OpenConfirm state.

When the OPEN message is received from the remote system, the local system is able to determine certain characteristics about the session. If the ASN is different than the local system, the session will be external; if it is the same, then it will be internal.

9.2.3.5 OpenConfirm

When the FSM in the local system reaches this state, it waits for the KEEPALIVE message to be sent from the remote system. When the local system receives the KEEPALIVE message from the remote system, the FSM will then change to the Established state. If the hold timers expire here, the local system will send a NOTIFICATION message to the remote system, and the FSM will change to the Idle state.

9.2.3.6 Established

When the FSM for the peering session transitions to the Established state, the peers are now ready to begin sending UPDATE messages to exchange reachability information.

When a BGP session is truly UP and the FSM is in the Established state, the following can be assumed:

• The BGP process has been started.

• A reliable transport session has been created.

• OPEN messages have been exchanged successfully, and session parameters have been negotiated.

• KEEPALIVE messages have been received successfully, and no error condition exists.

9.2.4 Message Types and Formats

The importance of messages was shown in the previous section on FSM events and states. If you refer to the list of events, you will see the last four events involve the OPEN , UPDATE , NOTIFICATION , and KEEPALIVE messages. Each message has a distinct purpose and provides details necessary for establishing, maintaining, and discontinuing BGP peer sessions between local and remote systems.

The maximum message size supported in BGP is 4,096 bytes, and the minimum message size is 19 bytes. The minimum size message contains only the BGP header without any trailing data and is used as the KEEPALIVE message. Each message header has a fixed length and does not have to contain data in each bit. There are three parts to a message header (see Figure 9-14):

1. Marker (16 bytes) ” contains all 1s for the OPEN message (also used when authentication is configured for BGP peering session)

2. Length (2 bytes) ” indicates the total length of the BGP message to a receiving system

3. Type (1 byte) ” indicates the message type

   OPEN ” 0001 (1)

   UPDATE ” 0010 (2)

   NOTIFICATION ” 0011 (3)

   KEEPALIVE ” 0100 (4)

Figure 9-14. BGP Message Header

9.2.4.1 OPEN Message

The OPEN message is sent by the local system once the TCP connection between the two potential peers has been created. Figure 9-15 illustrates the following OPEN message fields:

• Version (1 byte) ” This indicates the version of BGP used by the local system (in the case of Juniper Networks, it is BGP4).

• My AS (2 bytes) ” This indicates the local system’s ASN.

• Hold time (2 bytes) ” This indicates the configured hold time of the local system. The hold time will be negotiated between local and remote systems if they are not equal. A value of 0 indicates no use of the hold timer or keepalive timer.

• BGP identifier (4 bytes) ” This is the RID field. In JUNOS, the use of the router-id statement will set this value. Otherwise, the value will be taken from the lowest configured IP address on the router.

• Optional parameters length (1 byte) ” This indicates the length of the optional parameters field. When this field is set to 0, there will not be any optional parameters in the packet.

• Optional parameters (variable) ” This is a variable-length field comprising the following parameters (see Figure 9-16):

  Parameter type (1 byte) ” This indicates the type of parameter that will be used. RFC 1771 only defines one optional parameter, authentication information (parameter type 1). RFC 2842 makes a provision to negotiate a list of capabilities. Without this, when a BGP implementation would see a parameter type that it did not recognize, it would cause an error and close the peering session.

  Parameter length (1 byte) ” This indicates the length of the variable-length parameter value field, listed next.

  Parameter value (variable) ” This is assigned based upon the parameter type field.

  Figure 9-16. OPEN Message Parameters

  

Figure 9-15. OPEN Message Format

9.2.4.2 UPDATE Message

BGP uses UPDATE messages to exchange all routing information related to BGP. A single message can contain both NLRI with attributes and a list of withdrawn routes. If the attributes are equal, multiple prefixes can be sent in a single message. This functionality provides an efficient method of information exchange by combining multiple functions into a single message.

The UPDATE message can be thought of as having three distinct categories:

1. Unfeasible routes (withdrawn routes that no longer exist)

2. NLRI (prefix and mask, such as 192.168.0.0/16 )

3. Path attributes (such as MED or AS_PATH )

Unlike some IGPs, where route information is used to construct a topology (usually with the local system as root of that tree), BGP uses a list of ASs that the NLRI has passed through. This list is built on the concept of creating a loop-free path to the destination prefix.

Figure 9-17 illustrates the format of the UPDATE message. The BGP UPDATE message fields are as follows :

• Unfeasible routes length (2 bytes) ” This indicates the length of the withdrawn routes field. A value of 0 tells the receiving system that no withdrawn routes are listed in this UPDATE message.

• Withdrawn routes (variable) ” This consists of IP prefixes to be removed or withdrawn from the routing table. Each prefix is actually broken down to two parts, prefix length and prefix (see Figure 9-18). The length in this case is not related to the actual physical space of the prefix field, but rather to the subnet mask in terms of bits:

  Prefix length (16) ” refers to a mask of 255.255.0.0

  Prefix (10.5.0.0)

  Figure 9-18. UPDATE ”IP Prefix and Prefix Length Fields

  

Figure 9-17. UPDATE Message

The above example refers to 10.5.0.0/16 .

There are two important bits of information regarding the withdrawn routes field. First, the prefix length and value can be set to 0, which would withdraw all routes learned from the advertising neighbor. Second, regardless of the length of the actual prefix field, RFC 1771 calls for it to add trailing bits to keep the length of the field equal to the next highest byte count. These trailing bits are insignificant as they are only used for padding.

Figure 9-19 illustrates the attribute encoding of the UPDATE message.

• Total path attribute length (2 bytes) ” This gives the length of the variable path attribute field. It is necessary, and given a value of 0 would indicate that NLRI would not be present in the UPDATE message.

• Path attribute ” This comprises two parts: attribute type (2 bytes) and attribute flags (1 byte).

• The first four high-order bits determine the category of the attribute.

Figure 9-19. UPDATE ”Attribute Encoding

Attributes are used to provide specific information regarding the characteristic of a particular prefix being advertised. Each of these attributes and their meanings are described in Section 9.2.5. However, for now it is important to understand that BGP interprets and advertises attributes based upon four distinct categories as defined in RFC 1771 and shown in Figure 9-20. The first high-order bit is representative of either a well-known or optional attribute (0 = well known, 1 = optional). The second high-order bit is representative of either transitive or nontransitive (0 = nontransitive, 1 = transitive). For well-known attributes, the bit must be set to 1 for transitive. The third high-order bit is representative of the partial bit. This bit must be set to 0 for well-known and optional nontransitive attributes. The fourth high-order bit is representative of the extended length bit. If this bit is set to 1, then the extended length may be used, but only if the length of the attribute is greater then 255 bytes. The four low-order bits are not currently used in BGP:

• Attribute type code (1 byte)

• Attribute length ” length of the attribute field

• Attribute value ” actual value of the attribute

Figure 9-20. UPDATE ”Attribute Type Field

9.2.4.3 NOTIFICATION Message

Any BGP-speaking router will send a NOTIFICATION message whenever an error condition exists. When this message is sent, the sending router closes the BGP session and transitions to the Idle state. The notification message consist of three fields (see Figure 9-21):

1. Data (variable) ” provides additional information on the error (e.g., incorrect RID information received for a session would cause an error condition. This piece of data could be placed here).

2. Error code (1 byte) ” see Table 9-3 for values.

3. Error subcode (1 byte) ” see Table 9-3 for values.

Figure 9-21. NOTIFICATION Message Format

The error codes and subcodes indicate the major and minor reasons for which the error was detected . The various error codes and subcodes are essential to the control of the BGP process over the session. If this particular information was not evaluated and the error codes were not available, there would be devastating effects on the integrity of the route information passed through ASs and the Internet. Table 9-3 lists these error codes. The numbers following each code indicate the decimal equivalent.

Table 9-3. NOTIFICATION Message Error Codes

9.2.4.4 KEEPALIVE Message

KEEPALIVE messages are exchanged to let each peering neighbor know that the other is there (see Figure 9-22). Two other elements are used: the hold timer and the KEEPALIVE messages. These messages cannot be any more frequent than one per second. When the BGP session is first negotiated, the HoldTime is agreed upon. If the agreed upon HoldTime is set to 0, then no KEEPALIVE messages will be sent. As noted previously, the KEEPALIVE messages consist only of the BGP header.

Figure 9-22. KEEPALIVE Message Format

9.2.5 Attributes

This section will discuss the attributes associated with BGP and what each means. Attributes are passed in UPDATE messages. There are four categories of BGP path attributes:

1. Well-known mandatory ” must accompany each advertisement of the prefix

2. Well-known discretionary ” must be recognized by the BGP implementation, but it is at the discretion of the local system as to whether or not the attribute will be sent in any UPDATE messages

3. Optional transitive ” does not need to be known by the BGP implementation, but it is recommended, due to the attribute’s transitive nature, for the local system to pass the attribute when announcing the prefix to other systems

4. Optional nontransitive ” does not need to be known by the BGP implementation, but, due to the nature of the attribute, it is recommended that it not be passed to other peering neighbors via the UPDATE message

Table 9-4 lists the ten most common attributes used in BGP by category name and type code. The type code is the decimal value that is used in the UPDATE message to specify the type of attribute being passed.

Table 9-4. BGP Path Attributes

9.2.5.1 ORIGIN

This attribute gives an indication of how this particular prefix was learned. The following possible values can be used:

• 0 (IGP) ”learned from the IGP in the originating AS

• 1 (EGP) ”learned from the EGP in the originating AS

• 2 (Incomplete) ”origin of this prefix cannot be determined

By default, JUNOS uses the ORIGIN code value 0, whether or not the route was learned from the IGP, statically defined, or part of an aggregate route.

9.2.5.2 AS_PATH

The AS_PATH attribute lists ASs for which a prefix has been announced. This attribute serves two functions: routing loop avoidance and path selection. If the receiving AS sees its own ASN in the AS_PATH list, it will ignore that announcement.

When a prefix is announced, the AS_PATH only lists the AS that announced the prefix. A single AS may have 10 routers or 100. So, the AS_PATH provides no additional granularity into how the packet would travel to a destination within a given AS.

The AS_PATH is set using the type field. If the type field has a value of 1 ( AS_SET ), then the resulting list is an unordered set of ASs. When an AS_SET is included, if the type value is 2 ( AS_SEQUENCE ), then the list that results is an ordered set of ASs. This means that when the local system readvertises the prefix, it will prepend the AS_SEQUENCE with the local system’s ASN. Prepending always occurs in the left-most bits of the field.

If the prefix originates in the local AS, then the border router will add the local AS to the prefix and send it to the external neighbor. If the prefix is advertised internally, then no prepending is necessary. Remember, the AS_PATH is the listing of ASs that have ANNOUNCED the prefix, ANNOUNCED meaning advertising to other external neighboring ASs.

9.2.5.3 NEXT_HOP

This attribute is vital in the route-selection process. In short, the NEXT_HOP attribute indicates the IP address of the border router that can be used to reach a given destination, not the next-hop as in interface or gateway to the next Layer 3 device. The show route <prefix> detail or show route <prefix> extensive commands can be used to see both physical next-hops and protocol or border router next-hops. Understanding NEXT_HOP and how it is used is essential to understanding BGP route selection. A case study in Sections 10.2.2 and 10.2.3 covers NEXT_HOP .

9.2.5.4 MED

MED is a metric specified by an announcing external neighbor to identify the ingress point to use in the announcing AS for a given prefix. This attribute is used by the announcing system to influence the local system’s decision process. When it is received, it can be propagated via IBGP, but does not get propagated when the local AS advertises the route to another external AS. A case study in Section 10.2.4 can be referenced for more information.

9.2.5.5 LOCAL_PREF

LOCAL_PREF is used by IBGP to influence internal routers to use a particular border router to reach a given prefix. The higher the value, the better the degree of preference. This means that if border router A advertises prefix 10.10.0.0/16 with a LOCAL_PREF of 100 , and border router B advertises 10.10.0.0/16 with a LOCAL_PREF of 150 , the internal routers will choose to send packets via border router B.

9.2.5.6 ATOMIC_AGGREGATE

Aggregation is a method by which the local system advertises a route representative of several more specific routes that it knows about. When this occurs, there is a potential loss of information relating to the more specific prefixes, such as AS_PATH . When this occurs, the local system will attach the ATOMIC_AGGREGATE attribute to the prefix when advertising it. This is important for the receiving system of the route. If a local system receives a prefix with the ATOMIC_AGGREGATE attribute set and does have a more specific route, it will not advertise the more specific route. With this being said, it can be assumed in some cases that routes with the ATOMIC_AGGREGATE attribute included will traverse ASs that may not be in the AS_PATH list. Aggregation can naturally cause loss of path information, hence the need to signal other systems that this has occurred.

9.2.5.7 AGGREGATOR

If a local system performs aggregation on a series of routes, it will include in the aggregated prefix advertisement the local system ASN and local system IP address that performed the aggregation.

9.2.5.8 COMMUNITY

Communities and policy go hand in hand with BGP. You can assign several prefixes the same values by including them in a particular community. Associated with this attribute are three well-known communities, as defined in RFC 1997:

1. NO_EXPORT ( 0xFFFFFF01 ) ” Routes with this attribute value must not be advertised outside the AS boundary.

2. NO_ADVERTISE ( 0xFFFFFF02 ) ” When this attribute is set, the local system does not advertise this route to other BGP neighbors.

3. NO_EXPORT_SUBCONFED ( 0xFFFFFF03 ) ” Routes with this attribute set must not be advertised outside the local AS to external peers. In confederation scenarios, a confederation boundary router will not advertise the route to other external routers, even in the same parent AS.

Communities are essential in service provider networks. They can play a vital role in route coloring and further enhancing the routing domain’s ability to maintain routing-policy control. Section 11.7 provides coverage on the use of communities.

9.2.5.9 ORIGINATOR_ID

This attribute is defined in RFC 1966. Simply put, the ORIGINATOR_ID is the RID of the router that originated the route into the AS. Route reflectors will not send a route learned from an originator back to that originator. The route-reflector server will set this attribute when advertising the prefix to internal neighbors. This attribute will not be sent to external neighbors.

9.2.5.10 CLUSTER_LIST

This is an optional nontransitive attribute and is used by BGP in route-reflector scenarios as well. The route-reflector server sets the CLUSTER_LIST value. Any routes received with this attribute set to the local CLUSTER_ID will be ignored. This, too, is part of the loop avoidance scheme in BGP route reflection and is especially useful when implementing multiple route-reflector clusters within a single AS.