BGP Part 14. Практика.

2023.03.25. Kurapov Alexey.

BGP Part 14. 

                   Схема сети такая же, как и раньше:

 

Фича BGP – LOCAL-AS 

                    Рассмотрим ситуацию – внутри организации используется iBGP с номером private-ASN 65 000, для eBGP пиринга с ISP, для организации Интернет каналов связи в организации, требуется, чтобы на BR (Border Router) организации была public AS, например, ASN = 100.                   

                    Также применяется при миграции, если необходимо мигрануть номер AS. Например, хотим съэммулировать другой номер AS. Рассмотрим R8 – сейчас ASN на R8 равен 810, хотим изменить на 81. R8 является Border Router-ом в сторону AS 457.

Попробуем запустить второй BGP процесс с ASN = 81, для установления соседства с R7 в рамках AS с номером 81:

Как указывали раньше, не можем запустить два BGP процесса на роутерах Cisco. 

Тогда изменим номер AS на R8 и далее скажем на R8 в сторону R7, как было раньше для AS 810:

Было: 

Сделали:

Как видим соседство с R7 не поднимается, причина:

 

0х51 в 16-ной системе счисления равно 81 в десятичной СЧ.

NOTIFICATION – еще один тип сообщений BGP, наравне с OPEN, UPDATE, KEEPALIVE. В них BGP соседи указывают, что им мешает установить BGP соседство. В нашем случае:

R7 сообщает R8, что ему не нравится номер AS указанный на R8 и который R8 ему прислал в OPEN сообщении ранее: 

Общая картина установки TCP сессии, обмена OPEN и NOTIFICATION сообщениями и закрытием TCP Сессии:

Можем перенастроить R7 в нашем случае, но если R7 это ISP – не имеем доступа к R7 и мы должны указывать в сторону него public ASN, а R10 – наша AS и в сторону него хотим использовать другой номер AS, в общем случае private ASN, в нашем случае ASN  =810. Не сможет запустить два BGP процесса на R8. Решение проблемы – фича BGP – local-as, применим в сторону R7: 

                    И перенастроим R10:

                    Было: 

Стало:

                     Т.о. мы сменили внутри нашей AS номер с 810 на 81, но для внешних eBGP соседей ничего не изменилось, для них по прежнему представляемся c ASN 810, как они и ожидают исходя из своих настроек: 

Внутри нашей AS:

 

                    Т.о. внутри AS смигрировали с ASN 810 на ASN 81 – на R8 и R10, но для внешних eBGP соседей – R7 и R6 по прежнему представляемся как AS с номером 810. Для проверки перезапустим на R8 BGP в сторону всех соседей: 

Проверим в Wireshark:

В сторону iBGP соседа R8 анонсирует в качестве номера своей AS число 81. 

В сторону eBGP соседа R8 анонсирует в качестве номера своей AS число 810.

 Сколько и какие префиксы из своей AS анонсирует R8 в сторону R7, проверим на R7: 

Это префиксы 88.88.88.88/32 и 100.100.100.100/32. 

Как R8 предлагает R7 ходить внутрь своей AS:

                    У префиксов из AS с внешним номером 810 и внутренним номером 81, в  as-path в сторону eBGP соседа R7, который может представлять собой ISP два ASN – 81 – настроен в локальной сети и 810 – чем хотим казаться для ISP и всего интернета.

                    Для удобства настроим в AS R8-R10 в качестве внутреннего номера AS, значение 65 810:

 

                     Смотрим еще раз на R7: 

                    У префиксов из AS с внешним номером 810 и внутренним номером 65810, в  as-path в сторону eBGP соседа R7, который может представлять собой ISP по прежнему два ASN – 65810 – настроен в локальной сети и 810 – чем хотим казаться для ISP и всего интернета.

Такое поведение может привести к проблемам, погасим линк между R8 и R10, в этом случае update от R8 до R10 будут распространяться по пути R8 - R7 - R4 - R6 -R10 на R10 эти update будут дропаться, т.к. в as-path есть номер собственной AS R10 – 65810, проверим это: 

Как видно R10 DENIED update про 88.88.88.88/32 от R6, т.к. as-path содержит номер собственной AS на R10. 

Аналогично поступает R8 с update про R10, полученными от R7, в результате R8 и R10 ничего не знают о префиксах друг друга. Как решить данную проблему?

Два варианта для разного оборудования на стороне ISP - R6 и R7.

Вариант 1.

Команда ALLOWAS-IN 

    Если на стороне ISP в качестве R6 и R7 используется обычный IOS Можем на R10 модифицировать работу BGP – по сути отключить механизм Loop Prevention в сторону R6:

    В команде allowas-in можем указать сколько раз может в as-path повторяться номер нашей AS.

    В итоге R10 принимает от R6 update про R8, несмотря на то, что в as-path содержится номер его собственной AS: 

Замечание! Возможно ли таким образом получить петлю? Технически можем, всегда когда вмешиваемся в атрибут as-path, можем создать петлю. По факту команда allowas-in требуется тогда, когда имеется разорванная AS. Например, между R8 и R10  в принципе нет линка, это два территориально-распределенных Border роутера нашей организации, которые подключаются к ISP по eBGP. И без команды allowas-in не получится принимать в разных офисах префиксы другого офиса. И в данном случае гарантируется отсутствие петли, т.к. префиксы не имеют другой связности, кроме как через ISP.

 Вариант 2.

Команда AS-OVERRIDE 

Если на стороне ISP в качестве R6 и R7 используется не обычный IOS, а IOS XR, то команда allowas-in не поможет. IOS XR ведет себя иначе, например, R7 прежде чем выслать update в сторону R8 проверяет as-path. Видит, что в update в as-path есть AS 810 и сосед R8 настроен как находящийся в AS 810:

  В результате R7 решает, что R8 дропнет такой update и  в целях оптимизации не высылает его в сторону соседа R8. Команда allowas-as на R8 в данном случае не поможет.

Как бороться с этим? Требуется настройка на стороне ISP – на R7. На IOS XR свои команды, можно использовать команду as-override.