cisco

ASR9K перезагрузка карты

Оставить комментарий

Симптомы, упали и через непродолжительное время поднялись все интерфейсы одной из плат, если к данной карте подлючены сателиты, их интерфейсы также перейдут в состояние down.
Проверяем текущее состояние, нас интересует 0/2 слот:

В логах выглядит так:

Аптайм карты и причину перезагрузки можно посмотреть:

Причины перезагрузки, взято отсюда:

CPU_RESET_UNKNOWN = 1,               (CBC was reset after CPU was reset. So, CBC doesn’t know)
CPU_RESET_OIR_POR = 2,               (Board was plugged-in and CBC powered-on board by default)
CPU_RESET_SRESET = 3,                (CBC received a CAN message to S-Reset CPU)
CPU_RESET_HRESET = 4,                (CBC received a CAN message to H-Reset CPU)
CPU_RESET_POR = 5,                   (CBC received a CAN message to Power-Off or Power-Cycle CPU)
CPU_RESET_WDOG_SRESET = 6,           (Watchdog expired and CBC S-Reset CPU so CPU can collect core-dump)
CPU_RESET_WDOG_HRESET = 7,           (Watchdog expired and CBC H-Reset CPU)
CPU_RESET_WDOG_POR = 8,              (Watchdog expired and CBC power-cycled board)
CPU_RESET_PSEQFAIL_POR = 9,          (CBC power-cycled board following power-sequencer failure)
CPU_RESET_PWR_OFF = 10,              (Board powered-off)
CPU_RESET_PLDREQ_SRESET = 11,        (Lance / Mace S-Reset CPU)
CPU_RESET_PLDREQ_HRESET = 12,        (Lance / Mace H-Reset CPU)
CPU_RESET_AUTO_RESET = 13,           (CPU reset autonomously without informing CBC)
CPU_RESET_MCLR_PROLONGED_HOLD = 14,  (CPU held in reset for several minutes, typically during PLD upgrade)

Если логи затерлись, посмотреть историю ребутов карты:

По «Cause Code«: «0x2c00001b» видно, что из-за аппаратных проблем карта ресетилась несколько раз, можно оформлять RMA.

Core файлы:

 

BGP, cisco

BGP redistribute static

Оставить комментарий

R1 выступает в качестве CE, R2 — PE, R3 удаленный (iBGP) PE, между R2 и R3 должен быть iBGP, а сам клиент в проде живет в VRF, но сейчас и так сойдет:

CE подключен к PE по eBGP, и анонсирует 0/0 в сторону PE. Анонсируем default от клиента через redistribute static:

Статика анонсируется в BGP:

R2 и R3 видят 0/0:

Далее клиент говорит, что он хочет чтобы наша PE (R2) анонсировала 0/0  в случае если его CE1 перестанет отдавать нам 0/0 , повторяем настройки сделанные на проде:

Настраиваем backup маршрут через R1, на случай если мы потеряем маршрут от BGP пира, AD=250, чтобы выигрывал у [ie]BGP (AD=20,200):

Никаких изменений в BGP таблице, т.к коробке нечего редистрибутить, статики нет в GRT:

Все работает ОК, далее клиент по какой-то причине перестает анонсировать 0/0  через BGP:

Ушел BGP маршрут, в GRT установился static, далее он появился в BGP ( weight 32768) а анонсируется другим пирам:

Со стороны R3 поменялся AS_PATH (« Local «):

Далее клиент снова начинает анонсировать 0/0 :

На данном этапе от него пришла заявка, что на удаленном сайте он не видит 0/0 от CE.

На R3 без изменений:

R2 не анонсирует eBGP маршрут полученный от R1 т.к он не является best, происходит это потому-что Weight у локально генерируемых маршрутов = 32768 и он выигрывает у [ie]BGP маршрутов (« Weight = 0 «).
Если попробовать уровнять Weight (установить отрицательный мы не можем), далее будет проверятся LP (он у нас будет одинаковый) и потом будут выигрывать локально генерируемые маршруты.

Попробуем в добавок сбросить LP:

Маршрут выбрался от R1:

Проверяем еще раз:

Генерируем 0/0 от R2:

Возвращаем:

Также можно на PE в сторону CE выставить максимальный Weight, чтобы всегда был приоритет у eBGP маршрута, но тем самым мы поломаем возможность клиенту самостоятельно управлять трафиком BGP атрибутами.