Fortinet black logo

Administration Guide

BGP error handling per RFC 7606

BGP error handling per RFC 7606

The FortiGate uses one of the three approaches to handle malformed attributes in BGP UPDATE messages, in order of decreasing severity:

  1. Notification and Session reset

  2. Treat-as-withdraw

  3. Attribute discard

When a BGP UPDATE message contains multiple malformed attributes, the most severe approach that is triggered by one of the attributes is followed. See RFC 7606 for more information.

The following table lists the BGP attributes, and how FortiGate handles a malformed attribute in the UPDATE message:

BGP attribute

Handling

origin Handled by the treat-as-withdraw approach.
AS path Handled by the treat-as-withdraw approach.
AS 4 path Handled by the attribute discard approach.
aggregator Handled by the attribute discard approach.
aggregator 4 Handled by the attribute discard approach.
next-hop Handled by the treat-as-withdraw approach.
multiple exit discriminator Handled by the treat-as-withdraw approach.
local preference Handled by the treat-as-withdraw approach.
atomic aggregate Handled by the attribute discard approach.
community Handled by the treat-as-withdraw approach.
extended community Handled by the treat-as-withdraw approach.
originator Handled by the treat-as-withdraw approach.
cluster Handled by the treat-as-withdraw approach.
PMSI Handled by the treat-as-withdraw approach.
MP reach Handled by the notification message approach.
MP unreach Handled by the notification message approach.
attribute set Handled by the treat-as-withdraw approach.
AIGP Handled by the treat-as-withdraw approach.
Unknown If the BGP flag does not indicate that this is an optional attribute, this malformed attribute is handled by the notification message approach.

This example shows how the ORIGIN attribute can be malformed, and how it is handled.

Reason for malformed attribute

Handling

ORIGIN attribute length not one

The prefix will be gone and the BGP session will not be reset.

ORIGIN attribute value is invalid

The prefix will be gone and the BGP session will not be reset.

Two ORIGIN attributes with different values

The attributes are ignored, the BGP session will not be reset, and the BGP route will remain.

ORIGIN attribute is absent

The BGP session will be reset

For example, if the FortiGate receives a malformed UPDATE packet from the neighbor at 27.1.1.124 that has no ORIGIN attribute, the BGP session is reset and the state of the neighbor is shown as Idle, the first state of the BGP neighborship connection.

# get router info bgp summary
VRF 0 BGP router identifier 27.1.1.125, local AS number 125
BGP table version is 6
1 BGP AS-PATH entries
0 BGP community entries

Neighbor     V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
3.3.3.3         4         33       0       0        0    0    0    never Active
27.1.1.124   4        124      94     126        0    0    0    never Idle

Total number of neighbors 2

BGP error handling per RFC 7606

The FortiGate uses one of the three approaches to handle malformed attributes in BGP UPDATE messages, in order of decreasing severity:

  1. Notification and Session reset

  2. Treat-as-withdraw

  3. Attribute discard

When a BGP UPDATE message contains multiple malformed attributes, the most severe approach that is triggered by one of the attributes is followed. See RFC 7606 for more information.

The following table lists the BGP attributes, and how FortiGate handles a malformed attribute in the UPDATE message:

BGP attribute

Handling

origin Handled by the treat-as-withdraw approach.
AS path Handled by the treat-as-withdraw approach.
AS 4 path Handled by the attribute discard approach.
aggregator Handled by the attribute discard approach.
aggregator 4 Handled by the attribute discard approach.
next-hop Handled by the treat-as-withdraw approach.
multiple exit discriminator Handled by the treat-as-withdraw approach.
local preference Handled by the treat-as-withdraw approach.
atomic aggregate Handled by the attribute discard approach.
community Handled by the treat-as-withdraw approach.
extended community Handled by the treat-as-withdraw approach.
originator Handled by the treat-as-withdraw approach.
cluster Handled by the treat-as-withdraw approach.
PMSI Handled by the treat-as-withdraw approach.
MP reach Handled by the notification message approach.
MP unreach Handled by the notification message approach.
attribute set Handled by the treat-as-withdraw approach.
AIGP Handled by the treat-as-withdraw approach.
Unknown If the BGP flag does not indicate that this is an optional attribute, this malformed attribute is handled by the notification message approach.

This example shows how the ORIGIN attribute can be malformed, and how it is handled.

Reason for malformed attribute

Handling

ORIGIN attribute length not one

The prefix will be gone and the BGP session will not be reset.

ORIGIN attribute value is invalid

The prefix will be gone and the BGP session will not be reset.

Two ORIGIN attributes with different values

The attributes are ignored, the BGP session will not be reset, and the BGP route will remain.

ORIGIN attribute is absent

The BGP session will be reset

For example, if the FortiGate receives a malformed UPDATE packet from the neighbor at 27.1.1.124 that has no ORIGIN attribute, the BGP session is reset and the state of the neighbor is shown as Idle, the first state of the BGP neighborship connection.

# get router info bgp summary
VRF 0 BGP router identifier 27.1.1.125, local AS number 125
BGP table version is 6
1 BGP AS-PATH entries
0 BGP community entries

Neighbor     V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
3.3.3.3         4         33       0       0        0    0    0    never Active
27.1.1.124   4        124      94     126        0    0    0    never Idle

Total number of neighbors 2