Возможность многолучевого распространения BGP с различными номерами ASN для производственных сетей?

на Cisco (эта команда почему-то скрыта)

#bgp bestpath as-path multipath-relax

Поведение BGP по умолчанию устанавливает только маршруты с точно таким же AS_PATH в RIB. При многолучевом расслаблении AS_PATH должен быть только одинаковой длины.

Какие проблемы это может вызвать? Почему не используется чаще?

Является ли поставщик услуг транзита, усложняет ли эта функция устранение неполадок (я думаю о жалобах конечных пользователей на производительность сети)? Делает ли это более трудным узнать путь, по которому проходил конкретный трафик в данный момент времени? Есть ли что-то еще, что может помочь в устранении неполадок. Я не уверен в масштабируемости и стоимости NetFlow в сети SP.

bgp bestpath as-path multipath-relaxбыл представлен CSCea19918. Обычно для балансировки нагрузки eBGP требуются пути-кандидаты с равными затратами; т.е. идентичные атрибуты BGP:

• тот же вес
• тот же местный преф
• один и тот же AS-Path (как номера AS, так и длина пути AS)
• того же происхождения
• то же самое MED
• другой следующий прыжок

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

Какие проблемы это может вызвать?

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

Почему он будет редко использоваться?

Хороший вопрос, это было примерно с 2005 года.

The   basic  issue   is   that  the   BGP   speaker  configured   with
"multipath-relax"   gets  into   a  control   plane  <->   data  plane
inconsistency; i.e.  it advertises  only the  best path,  but installs
multiple paths in the forwarding  that have different ASPATHs than the
best. This breaks the basic tool BGP has to detect loops - ASPATH loop
check.

A (distorted) scenario below. I am sure you can come up with
a better example with a bit more time at hand.

            ...............
            : R4  AS1 (10/8)
           /:..............
     ..../......
     :  R5 AS2
     :....\.....
       /   \  ...............
     /      --:--R1
  R6 AS4      :    \    AS3
     \--------:--- R2
              :    /
              : R3 (10/8)
              :..............

In this example,
- R3 in AS3 and R4 in AS1 announce a prefix 10/8. R5 in AS2 receives
  the prefix from R1(AS3) and R4(AS1).
- AS2 is configured with 'multipath-relax' and chooses both paths
  for multipath forwarding, though it selects AS1's path as best.
- R5 advertises the prefix with AS_PATH "2 1" to R6, and R6 in turn
   to R2.
- Because of some specific policy, it is possible that R2(AS3)
  chooses R6's path as best. If it happens, there is a loop.
  Note that R1-R2-R3 represents the physical connectivity of
  the routers in AS3.