отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

"Следствие ведут ИТ-шники". День 2. Маршрутизация и коммутация. Имена победителей

Прежде всего мы благодарим всех за участие в конкурсе.

 

Имена победителей:

1 место - Максим Климанов (РФ)

2 место - Овездурды Исмаилов (Туркменистан)

3 место - Кирилл Мамаев (РФ)

 

Поощрительный приз (7-10 место):

4 место - Константин Деев (Украина)

5 место - Алексей Пучкин (РФ)

6 место - Михаил Селецкий (РФ)

7 место - Валерий Денисов (РФ)

8 место - Дмитрий Бунас (Белоруссия)

9 место - Николай Попов (Украина)

10 место - Дмитрий Докучаев (Казахстан)

 

 

РЕШЕНИЯ для задачи 2 (BGP)

Проблема достаточно распространенная.

В общем случае потенциальных причин может быть несколько.

Т.е. в задаче нет только одного "правильного" ответа, причины следует исключать последовательно, и при оценке учитывалась так же методология.

 

Базовые проверки:

=====

1) Уточняем платформу R1 :

основные:  IOS SW Router, IOS XE (asr1k, ISR43xx/44xx), c7600 или IOS XR;

В данном случае по формату вывода команды "show ip bgp" речь о XR.

 

Поэтому особенности и ограничения платформ IOS XE asr1k и c7600 отбрасываем.

Кроме того, если бы столкнулись с проблемами TCAM/FIB/CEF, специфичными для этих платформ,

то в логах были бы явные сообщения.

 

2) Смотрим конкретную платформу XR и версию (например - show platform, show install act sum):

Если asr9k до релиза 4.2.1 - то по умолчанию имеем 512K ipv4 unicast AF ограничение;

Если 4.2.1 и выше - то default ограничение увеличенно до 1M:

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/command/reference/b-routing-cr53xasr9k/b-routing-cr53xasr9k_chapter_01.html#wp3192417938

 

Кроме того, если в шасси есть карты первого поколения (Trident),

то до релиза 5.1.2 есть ограничение в 512K со стороны TCAM/CEF на этих картах,

т.е. применяется hw-module profile default.

 

Выше этого релиза "hw-module profile scale l3" яв-ся профилем по умолчанию c ограничением в 1M ipv4.

Увеличение сделанно в рамках DDTS:

CSCul97045 "Make the layer 3 scale profile the default for Trident linecards"

 

В любом случае, если бы столкнулись с этим в логе

были бы явные ошибки от процесса  fib_mgr

на карте - %ROUTING-FIB-4-RSRC_LOW  : CEF running low on DATA_TYPE_TABLE_SET resource memory.

 

Так же в выводе указанное значение в ~137K полученных ipv4 префиксов далеко меньше 512K.

 

3) Пункт 3 в задании описывал тест с временным снятием политик.

Т.к. платформа XR и соседство eGBP - неявно нужно было учесть/отметить момент,

что должны быть политики route-policy c 'pass'.

В данном случае как минимум input на R1 и output на ISP1(если тоже XR).

В противном случае вообще не было бы ни одного полученного префикса.

 

Так же нужно учесть - поддерживает ли ISP1 маршрутизатор route refresh или нет.

 

4) Т.к. в выводе show ip bgp sum - для ISP1 Input/Output BGP очереди нулевые,

то скорее проблема не на принимающей стороне (например - High ЦПУ),

а на транспорте/транзите или на стороне отправителя.

Дополнительно все же имеет смысл посмотреть локальные input queue drops на входящем интерфейсе.

Для XR так же актуальны дропы NP в show controllers с карты к ISP1.

 

5) Подтверждаем с провайдером ISP1 отсылку в сторону R1 ipv4 BGP full view.

А так же факт не выставления каких-либо политик с модификацией bgp attr.

Например, no-export community и др.

Так же с XR есть тонкости - возможная фильтрация AS в as-path не только на input, но и на output в некоторых сценариях, в случае ISP1 транзитной AS (больше характерно для mpls vpn).

В частности для XR есть контроль включения/отключение работы данной фильтрации

на при отсылке  - "as-path-loopcheck out disable":

http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-0/routing/command/reference/b_rr40crs1book/b_rr40crs1book_chapter_01.html#wp4289523382

 

Варианты ответов:

Вариант1) Т.к. R1 XR, то с точки зрения локального конфига

проверка факта наличия на R1: 

- maximum-prefix <maximum> discard-extra-paths

Важно именно применение опции 'maximum-prefix <maximum> discard-extra-paths',

которая добавилась только начиная с 5.3.1 XR релиза.

Ее применения на R1 соответствует указанным симптомам - т.е. отсутствие сообщений в логах и bgp tcp estab с соседом и нет флапов.

- 5.3.1 BGP Maximum Prefix - Discard Extra Paths

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/configuration/guide/b_routing_cg53xasr9k/implementing_bgp.html#concept_5AF38064B1D044B7B5F439C10BCF9808

- maximum-prefix <maximum> discard-extra-paths

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/command/reference/b-routing-cr53xasr9k/b-routing-cr53xasr9k_chapter_01.html#wp3192417938

Если Вариант1 проверен + базовые проверки сделаны, то на загрузку full view обычно требуется

не более 1-5 минут (зависит от платформы).

Поэтому далее исследуем:

 

Вариант2) Медленный обмен BGP Updates из-за того, что на стороне ISP1 R1 попал в группу апдейтов BGP Slow Peer.

  • Убедиться, что ISP1 провайдер не отметил R1 как slow-peer.

Или же

  • R1 не попал в одну update-group с какими-то другими медленными пирами, которые, например, имеют плохой L1/L2 транспорт или загруженные ресурсы (ЦПУ, память).

Для IOS - существует механизм динамического определения BGP Slow Peer и выделения для них отдельных update групп:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/detecting_and_mitigating_a_bgp_slow_peer.html

 Для XR - динамическое выделение в отдельную группу  не поддерживается и потенциально будет торможение всех соседей в этой же update-group.

 

Вариант3) Медленный обмен BGP Updates или его полное прекращение на каком-то этапе загрузки из-за:

- Несогласованнсоти MTU на транзите и BGP TCP MSS;

- Дропы на транзите из-за плохих каналов, отработке QoS на транзитных L1/L2 сегментах, проблемы с ресурсами на транзитных L2 устройствах.

Включение debug bgp updates на R1 даже с учетом возможности фильтрации по пиру и address family возможно, но в общем случае нерекомендованно по причине большого кол-ва префиксов.

Для локализации B3:

3a) Т.к. есть условие, что в логах нет сообщений, то проверяем факт наличия логирования  изменения статуса BGP соседств на R1:

router bgp 65355

    bgp log neighbor changes

-----

Для XR факт наличия 'disable' в команде.

 

3b) В случае периодических дропов/проблем на L2 транзите BGP сессия не будет сбрасываться, т.к. помимо keepalive  будут периодические tcp retransmit-ы, которые вызовут сбросы hold timer (по rfc - получение keepalive, update или notif).

3с) В случае полного непрохождения какого-то большого BGP Update пакета из-за проблем MTU на L1/L2 транзите - будут попытки его retransmit до момента достижения hold timer.

Но тут так же момент, что следует проверить согласованные между ISP1 и R1 hold timer на предмет:

- Значения 0, т.е. отключен вообще;

- Увеличенное значение до величины большей чем указанные в выводе 17:44 в estab.

Тем самым даже если в течении HOLDTIME из-за проблем с bgp tcp сессией R1 не получит UPDATE/KEEPALIVE/NOTIF, сессия будет в состоянии established.

Если же (3a) верно, то флап BGP сессии не будет виден в логах.

Детальные шаги по локализации и методика решения для данного варианта на CCO описаны например здесь:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/116377-troubleshoot-bgp-mtu.html

4) В случае XR имеет смысл так же посмотреть возможные дропы LPTS:

- show lpts pifib hardware police loc <карта к ISP1>

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/addr_serv/command/reference/b-ipaddr-cr-asr9k/b-ipaddr-cr-asr9k_chapter_0111.html#wp1262276624

 5) Факт наличия в приведенном выводе несогласованных RcvTblVer, bRIB/RIB и SendTblVer так же интересен.

Как отмечалось выше - InQ==0 в принципе указывает на то, что на локальный ЦПУ постоянной нагрузки нет. Но кроме этого большие расхождения Rcv и Send версий может говорить о проявлении дефекта.

Имеет смысл посмотреть выводы в динамике, а так же сравнить версии для каких-то конкретных префиксов на стороне R1 и ISP1. По возможности проверить поведение после hard clear cессии с пиром.

 

  • Найти больше статей с меткой:
Комментарии
New Member

А сколько всего участников было? Статистики нет.

Cisco Employee

Добрый день,

По всем дням не скажу (возможно официальная статистика будет позже).

Во второй день были получены ответы от 82 участников.

Спасибо,

Сергей

New Member

Здравствуйте, Сергей.

А как можно получить ваучер? :-)

Cisco Employee

Добрый день.

350 пользователей из 10 стран приняли участие в конкурсе "Следствие ведут IT-шники".

Cisco Employee

Максим, добрый день.

На этой неделе появится официальная процедура.

Мы обязательно сообщим всю информацию победителям.

Спасибо!

Мария

743
Просмотры
0
Полезный материал
5
Комментарии