RFC: 4271
Оригинал: A Border Gateway Protocol 4
Предыдущие версии: RFC 1654, RFC 1771
Категория: Проект стандарта
Дата публикации:
Авторы: , ,
Перевод: Николай Малых

RFC 4271, Страница 23 из 65

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 следует трактовать как корректные.

Страница 23 из 65

2007 - 2022 © Русские переводы RFC, IETF, ISOC.