Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Understanding Error Handling for BGP Update Messages

    A BGP message is considered to be malformed when any one of the message attributes is malformed. When a router participating in a BGP session receives a malformed update message, the entire session is reset by default. This is undesirable because update messages with valid routes are also affected. To avoid this undesirable behavior, the error handling for BGP update messages needs to be modified.

    To configure error handling for BGP update messages, configure the bgp-error-tolerance statement at the [edit protocols bgp], [edit protocols bgp group group-name], or [edit protocols bgp group group-name neighbor address] hierarchy level.

    If an attribute contains attribute flags that conflict with the value of the Attribute Type field, the attribute flags are reset to the correct value and the update message is processed. The value of the Extended Length bit in the attribute flags is unchanged because this value defines whether the attribute length is one or two octets. Hence, the value of the attribute flag affects how the BGP update packet is parsed.

    Note: There is no explicit specification for the attribute flag value for the path attributes.

    Malformed update messages are treated on a case by case basis, depending on the values of the attributes contained in the messages. There are three ways of handling malformed BGP update messages, listed in the decreasing order of severity.

    1. Notification message approach—The malformed message error is logged locally, an error code update message is sent to the administration of the peer, and the entire BGP session is reset.

      This approach is chosen when:

      • The BGP update message contains the MP reach attribute or the MP unreach attribute.
      • The NLRI field or the BGP update message cannot be parsed correctly because of a mismatch between the attribute length and the value of the attribute length field.
    2. Treat-as-withdraw approach—All routes within the malformed update message are treated as hidden routes, unless the keep none statement is configured, in which case the routes are discarded. In the absence of the keep none statement, the number of hidden malformed routes are configured with a limit, which when exceeded discards the routes and prevents any further malformed routes from being hidden. Junos OS removes the newly received malformed routes when the malformed route limit is reached.
    3. Attribute discard approach—The malformed attributes in the update message are discarded; however, the message is processed. It is not recommended to use this approach if the attributes to be discarded can affect route selection or installation.

      Note: If an attribute appears more than once in an update message, all occurrences of the attribute, other than the first, will be discarded and the message will be processed.

    The BGP update messages are scanned for the following attributes and are treated as malformed based on the values of these attributes:

    • The origin attribute—Handled by the treat-as-withdraw approach.
    • The AS path attribute—Handled by the treat-as-withdraw approach.

    • The AS 4 path attribute—Handled by the attribute discard approach. If any attribute has attribute flags that conflict with the attribute type code, Junos OS resets the attribute flags to the correct value. The update message continues to be processed.

      Junos OS does not change the value of the extended length bit in the attribute flags. This bit defines whether the attribute length is one octet or two octets. The value of this flag affects how the BGP packet is parsed. There is no explicit specification of this value for the path attributes.

    • The aggregator attribute—Handled by the attribute discard approach.

    • The aggregator 4 attribute—Handled by the attribute discard approach.

    • The next-hop attribute—Handled by the treat-as-withdraw approach.

    • The multiple exit discriminator attribute—Handled by the treat-as-withdraw approach.

    • The local preference attribute—Handled by the treat-as-withdraw approach.

    • The atomic aggregate attribute—Handled by the attribute discard approach.

    • The community attribute—Handled by the treat-as-withdraw approach.

    • The extended community attribute—Handled by the treat-as-withdraw approach.

    • The originator attribute—Handled by the treat-as-withdraw approach.

    • The cluster attribute—Handled by the treat-as-withdraw approach.

    • The PMSI attribute—Handled by the treat-as-withdraw approach.

    • The MP reach attribute—Handled by the notification message approach.

    • The MP unreach attribute—Handled by the notification message approach.

    • The attribute set attribute—Handled by the treat-as-withdraw approach.

    • The AIGP attribute—Handled by the treat-as-withdraw approach.

    • Unknown attribute—If the BGP flag does not indicate that this is an optional attribute, this malformed attribute is handled by the notification message approach.

    Note: When a BGP update message contains multiple malformed attributes, the most severe approach triggered by one of the attributes is followed.

    Published: 2013-07-22