Комментарии 34
Ты бы дорисовал, как сигнализированы TE туннели.
По графикам поведения: в какой момент времени передернули порт? Около 11:00 и 12:40 что ли?
И я правильно понимаю, что вообще говоря проблемному трафику нечего делать на участке между R3 и R6, и ходить он должен только между R1 и R4?
И классика. Что интересного в логах всех железок? Есть ли какие события RSVP в момент аварии? Есть ли ошибки на портах?
По графикам поведения: в какой момент времени передернули порт? Около 11:00 и 12:40 что ли?
И я правильно понимаю, что вообще говоря проблемному трафику нечего делать на участке между R3 и R6, и ходить он должен только между R1 и R4?
И классика. Что интересного в логах всех железок? Есть ли какие события RSVP в момент аварии? Есть ли ошибки на портах?
Я попытался идти от того, как описывают ситуацию заказчики)
Передёрнули порт R3<->R6 в 12 часов примерно. После этого всё восстановилось. На схеме не дописал, что это график с линка R2<->R4.
Данный трафик ходить по R<->R6 не должен, верно.
Логи с какого устройства и за какой момент времени показать?
P.S. Ещё раз повторюсь, что я сейчас в роли заказчика и совершенно не знаю, с какой стороны подойти к проблеме)
Чтобы было понятнее, настроены туннели R1<->R4 туда и обратно.
Передёрнули порт R3<->R6 в 12 часов примерно. После этого всё восстановилось. На схеме не дописал, что это график с линка R2<->R4.
Данный трафик ходить по R<->R6 не должен, верно.
Логи с какого устройства и за какой момент времени показать?
P.S. Ещё раз повторюсь, что я сейчас в роли заказчика и совершенно не знаю, с какой стороны подойти к проблеме)
Чтобы было понятнее, настроены туннели R1<->R4 туда и обратно.
Тогда неплохо бы заодно график R3<->R6 за тот же интервал времени.
Со всех нарисованных по схеме. Начиная с 10:00.
Как настроены? Autoroute? Explicit?
Ну а вообще, в данном сценарии инженер поддержки в первую очередь запросит еще и полные конфиги всех затронутых устройств, но понятно, что в данном случае это будет головной болью, так что продолжим на словах :)
Логи с какого устройства и за какой момент времени показать?
Со всех нарисованных по схеме. Начиная с 10:00.
настроены туннели R1<->R4 туда и обратно.
Как настроены? Autoroute? Explicit?
Ну а вообще, в данном сценарии инженер поддержки в первую очередь запросит еще и полные конфиги всех затронутых устройств, но понятно, что в данном случае это будет головной болью, так что продолжим на словах :)
НЛО прилетело и опубликовало эту надпись здесь
Нет никакой проверки полосы пропускания, задержек и других параметров канала.
Самое интересное, почему LSP построился именно так.
Мне кажется как-то так, проблема в настройках backup LSP на R1 (и, возможно, R4)
Какая именно?
Конфигурация простая: типичные дестинейшн, таннел-айди, explicit-path. Плюс настроен FRR и make-before-break (команда mpls te backup frr-in-use).
Как собственно, исправить проблему? :)
Самое интересное, почему LSP построился именно так.
Мне кажется как-то так, проблема в настройках backup LSP на R1 (и, возможно, R4)
Какая именно?
Конфигурация простая: типичные дестинейшн, таннел-айди, explicit-path. Плюс настроен FRR и make-before-break (команда mpls te backup frr-in-use).
Как собственно, исправить проблему? :)
НЛО прилетело и опубликовало эту надпись здесь
Не, я имел в виду причину, по которой через длинный LSP задержки, плохая скорость и всё такое.
Прошу прощения, не сразу понял. Да — конечный ответ — там был линк низкого качества. Но это не так интересно.
Вот об этой фиче make-before-break я первый раз слышу, так что решение этого вопроса оставлю для более умных людей
Такой функционал позволяет создать резервный туннель до того, как основной будет разрушен. Предусмотрительный FRR, так сказать, но это временная мера, а не полноценный резервный туннель.
Я бы настроил основной LSP через explicit path R1-R2-R4 и резервный R1-R3-R4.
Опять же правильно, но почему в данной ситуации путь построился именно так? Почему не отработал FRR? Или почему он отработал именно так?
НЛО прилетело и опубликовало эту надпись здесь
Ошибки нет. LSP дальше простраивается с помощью RSVP CSPF.
Но RSVP ищет end-to-end путь. Он не может просто отдать бразды R2, чтобы тот сам маялся. И искал путь.
Дам ещё один симптом: после падения интерфейса сервис не прерывается, первую минуту всё работает без потерь и ошибок. И только потом всё ломается.
Но RSVP ищет end-to-end путь. Он не может просто отдать бразды R2, чтобы тот сам маялся. И искал путь.
Дам ещё один симптом: после падения интерфейса сервис не прерывается, первую минуту всё работает без потерь и ошибок. И только потом всё ломается.
Jul 31 2013 10:33:08 R2 LSPM/2/MPLSTUNNELUP:OID 1.3.6.1.2.1.10.166.3.0.1 Tunnel Changes to Up.(SessionTunnelId=82, LocalLspId=32823, IngressLsrId=179857416, EgressLsrId=179857410, OutIfIndex=51, mplsTunnelAdminStatus=1, mplsTunnelOperStatus=1, mplsTunnelName=Tunnel0/0/82, OutIfName=GigabitEthernet2/0/1)
По картинке это 0/0/2 что ли?
И вынужден спросить, так как опасно некомпетентен в Huawei. Как понимать это?
Jul 31 2013 10:59:39 R2 %%01SRM/2/NODEFAULT(l)[167090]:Slot=1;PIC0 of LPU1 is failed, perhaps RXPowLowAlarm of XFP1 ALARM is abnormal. (Reason=«L2XXN0 XFP RX power low alarm, Current Rxpower is -18.76dBm. „)
Какая-то аппаратная проблема с портом?
НЛО прилетело и опубликовало эту надпись здесь
1) Нет.
2) Настроек таких нет. Babdwidth не учитывается.
3)
R1:
С обратной стороны всё симметрично.
2) Настроек таких нет. Babdwidth не учитывается.
3)
R1:
interface Tunnel0/0/14
ip address unnumbered interface LoopBack0
tunnel-protocol mpls te
destination 4.4.4.4
mpls te tunnel-id 14
mpls te record-route label
mpls te path explicit-path EP_R1R4
mpls te fast-reroute
mpls te backup hot-standby wtr 60
mpls te backup frr-in-use
mpls te reserved-for-binding
mpls te commit
statistic enable
С обратной стороны всё симметрично.
Господа, не хочу спойлерить, но решение этой задачки, а также разбор полётов по ней, можно найти по ссылке, которую автор привёл в конце статьи.
наверняка нужно увидеть path profile для туннеля R1-R4 с устройств R1,R2,R3,R4
используется ли OSPF (включен ли ip ecmp?), используется ли LDP?
используется ли OSPF (включен ли ip ecmp?), используется ли LDP?
Что конкретно вам предоставить?
Конфигурация дана выше. Explicit-path:
Никаких дополнительных ограничений.
Протокол внутренней маршрутизации не имеет значения (но в примере IS-IS). IP ECMP нет, LDPZ не используется.
Конфигурация дана выше. Explicit-path:
explicit-path EP_R1R4
next hop 10.0.12.2
Никаких дополнительных ограничений.
Протокол внутренней маршрутизации не имеет значения (но в примере IS-IS). IP ECMP нет, LDPZ не используется.
не буду оригинален, что тоже в huawei не разбираюсь, но разве для RSVP-TE не нужно указывать резервный path сальтернативным next hop? или так и задумано, что туннель строить в сторону R4 только через R2?
Некоторое понимание этого принципа дает статья по TE
habrahabr.ru/post/169987/
Некоторое понимание этого принципа дает статья по TE
habrahabr.ru/post/169987/
Это не является обязательным условием, но направление верное.
По мысли заказчика. Основной путь через R2, резервный обработает FRR.
По мысли заказчика. Основной путь через R2, резервный обработает FRR.
А как mpls te tunnel-id 14 описан на R2? Какой там path до destination 4.4.4.4?
interface Tunnel0/0/41
ip address unnumbered interface LoopBack0
tunnel-protocol mpls te
destination 1.1.1.1
mpls te tunnel-id 41
mpls te record-route label
mpls te path explicit-path EP_R4R1
mpls te fast-reroute
mpls te backup hot-standby wtr 60
mpls te backup frr-in-use
mpls te reserved-for-binding
mpls te commit
statistic enable
explicit-path EP_R4R1
next hop 10.0.13.3
Это конфигурация с R3 ообратного туннеля. Я прав? Вообще странно, что уже второе место, где не указан backup path. Если так везде, то странно почему туннель сходится после обрыва линка (увидел выше про RSVP CSPF — уже понял). Для правильного применения RSVP нужен backup path иначе используется path через R2, т.к. интерфейс в апе. Вот если бы падал R1-R2 линк, то деградации через верхнее кольцо не случилось бы (отработал бы RSVP CSPF) — верно?
Вы совершенно правы. Осталось добавить, что сначала отрабатывает FRR — после обрыва и в течение примерно минуты трафик идёт R1-R3-R4, пока RSVP не построит основной LSP, через верхнее кольцо)
Не совсем, тогда бы обратный туннель от R4 к R1 строился бы через верх и всё равно были бы потери)
Вот если бы падал R1-R2 линк
Не совсем, тогда бы обратный туннель от R4 к R1 строился бы через верх и всё равно были бы потери)
Спасибо. Интересная задачка :)
Мне кажется, что траблшутинг был бы быстрее и проще, если бы можно было посмотреть на show/display команды в момент наличия проблем.
Реквестирую еще таких кейсов по тематике mpls и всего с ним связанного.
Мне кажется, что траблшутинг был бы быстрее и проще, если бы можно было посмотреть на show/display команды в момент наличия проблем.
Реквестирую еще таких кейсов по тематике mpls и всего с ним связанного.
Не вопрос, я мог бы как минимум описать их вывод, либо даже воспроизвести их в лабе и показать точный.
На самом деле, если бы я решал проблему так, как в этом топике, я бы, пожалуй был не на лучшем счету) Как-то всё на уровне догадок. Больше.
Если интересно, то постараюсь подбирать интересные кейсы. Просто действительно интересных задачек попадается не так уж и много.
На самом деле, если бы я решал проблему так, как в этом топике, я бы, пожалуй был не на лучшем счету) Как-то всё на уровне догадок. Больше.
Если интересно, то постараюсь подбирать интересные кейсы. Просто действительно интересных задачек попадается не так уж и много.
В следующий раз так и сделаем. Если никто раньше не разгадаем. Вообще решать задачу методом пристального взгляда на конфиг — неверно. Show команды как раз и придуманы для траблшутинга.
Я, пожалуй, соберу такую лабу и дам коллегам погадать :)) Ты лабу в хуавеевском эмуляторе собираешь или в gns?
Я, пожалуй, соберу такую лабу и дам коллегам погадать :)) Ты лабу в хуавеевском эмуляторе собираешь или в gns?
Вообще решать задачу методом пристального взгляда на конфиг — неверно.
Не согласен. С точки зрения сотрудника техподдержки именно такой метод решения проблем предпочтителен. Причина проста: каждый лишний вопрос, заданный клиенту, откладывает решение проблемы на N (десятков) минут. Не скажу за Huawei, но Cisco TAC всегда первым делом требует «show tech-support» со всего железа, имеющего отношение к проблеме. Там и конфиги, и масса других «show», с предусмотрительно вырезанными паролями.
А вот если по конфигам проблема непонятна и ясно, что потребуется много вопросов и уточнений — тогда можно организовать и webex сессию и самому полазить по железкам, что тоже отнимает лишнее время. И я уверен, что далеко не каждый клиент на такое согласится.
Но если мы говорим про какой-нибудь CCIE (лаба), то само собой разумеется, что основным методом траблшутинга будут show команды. Хотя и тут ни в коем случае нельзя забывать окинуть взглядом полный конфиг на предмет всяких неожиданных VACLов, switchport backup'ов и так далее (они точно будут). Вычислять такое без show run довольно утомительно — есть немало способов частично (самое мерзкое) или полностью сломать передачу трафика через интерфейс, не трогая конфиг этого интерфейса.
Я начинаю с логов, если известно точное время возникновения проблемы. Далее уже конфиг.
Хотя, конечно, зависит от вопроса. Если просто что-то не работает, конечно, конфигурация.
Первое, что я прошу: display diagnostic-information, топологию и логи. Зачастую этого уже достаточно.
Но, учитывая мой небогатый опыт — лаба это для меня всё — виртуальная или настоящая. Собственно в офисе нас двое таких, которые пропадают в автозале постоянно :)
Хотя, конечно, зависит от вопроса. Если просто что-то не работает, конечно, конфигурация.
Первое, что я прошу: display diagnostic-information, топологию и логи. Зачастую этого уже достаточно.
Но, учитывая мой небогатый опыт — лаба это для меня всё — виртуальная или настоящая. Собственно в офисе нас двое таких, которые пропадают в автозале постоянно :)
Я собирал в симуляторе Huawei. Я так понял в GNS не заработает такой эксплисит-пас.
У Хуавэя есть два симулятора: WVRP — пожалуй на уровне GNS. Лабу собирал в нём. Работает только в корпоративной сети.
Второй ENSP — похож на Cisco PT, но не в пример круче: MPLS, VPN, Multicast, возможность снимать дампы итд. На нём не проверял, но, скорее всего, сработает. Скачать можно на huawei.com любому желающему.
У Хуавэя есть два симулятора: WVRP — пожалуй на уровне GNS. Лабу собирал в нём. Работает только в корпоративной сети.
Второй ENSP — похож на Cisco PT, но не в пример круче: MPLS, VPN, Multicast, возможность снимать дампы итд. На нём не проверял, но, скорее всего, сработает. Скачать можно на huawei.com любому желающему.
если бы я решал проблему так, как в этом топике
Дык тут наберется мало спецов по части специфики Huawei. У меня например чуть мозг не лопнул, когда я читал ту гору логов. Обычно проглядываешь по диагонали, и взгляд сразу цепляется за важное, а тут надо в каждую букву вчитываться, всё незнакомо. Надо бы зарыться в документацию, но так как пост опубликован посреди рабочего дня — банально нет времени, а к вечеру уже и ответ есть. В общем, само собой разумеется, что большинство присутствующих, даже будучи грамотными сетевиками, категорически не годятся на твое место хотя бы по причине полного отсутствия опыта работы с данным железом :)
Реквестую интересные задачки, связанные с общеупотребимыми технологиями, но желательно на всем знакомом языке IOS. Игра-то ведь интересная. И первым делом — полные конфиги в самом посте. Любая адекватная техподдержка в первую очередь запросит их вместе с топологией и логами на момент аварии, и только после этого начнет изучать вопрос — если ответ сразу не ясен. Можно попросить тех, кто сразу понял причину и полностью уверен в этом, не спойлерить.
В целом, интересных задачек можно написать много, но всё что приходит мне в голову либо касается специфики железки и принципиально невоспроизводимо в лабе, либо после устранения проблемы выглядит очевидным и неинтересным. Например, много лет назад я получил по лбу следующей проблемой: трафик, прилетевший на cat6500 с одного конкретного типа интерфейса, не уходит в MPLS. Метки раздаются верно, LFIB в порядке, софт синхронизирован с железом, стек меток состоит из одной штуки (никаких наворотов вроде VPN или TE, т.е. форвардинг полностью соответствует IGP и идет по глобальной таблице). Локально генерируемый либо приходящий не из того интерфейса трафик прекрасно летит куда надо. Сначала я, молодой и глупый, мучился. Потом один CCIEшник из интегратора долго мучился, что только ни делал, ничего родить не смог. Инженер TAC мимоходом дал верный ответ. И нет, не баг, штатное поведение, особенность реализации определенного функционала на PFC. Если сразу не знать ответ — задача нерешаема в принципе.
Про Huawei согласен. Тут и правда есть спцифика. Я не знал, например, что на циске на заработает такой explicit-path.
В принципе взгляд цепляется за падение интерфейса, BFD-сессий и перестроение LSP. Плюс графики поведения трафика на всех линках.
Потом я проверил конфигурацию, где настроен FRR и только один Explicit-path. Идеят тут уже появилась о решение. Потом в течение часа я проверил её в симуляторе (надо сказать, что в MPLS TE даже не huawei у меня опыт почти нулевой). Ну а ночью в ходе ремонта оптики я проверил догадку на реальной сети.
Про конфигурацию устройств соглашусь, пожалуй. Но заказчики очень редко такие данные предоставляют сразу))
Интересных задач, связанных не с железом, спецификой реализации протоколов или багом софта не так уж и много. Касающихся хорошоизвестных технологий, ещё меньше, потому что в основном — это просто тупняк со стороны инженера, явная неправильная настройка.
Ну и задачки, как и твоего примера явно не для коллективного решения)
В принципе взгляд цепляется за падение интерфейса, BFD-сессий и перестроение LSP. Плюс графики поведения трафика на всех линках.
Потом я проверил конфигурацию, где настроен FRR и только один Explicit-path. Идеят тут уже появилась о решение. Потом в течение часа я проверил её в симуляторе (надо сказать, что в MPLS TE даже не huawei у меня опыт почти нулевой). Ну а ночью в ходе ремонта оптики я проверил догадку на реальной сети.
Про конфигурацию устройств соглашусь, пожалуй. Но заказчики очень редко такие данные предоставляют сразу))
Интересных задач, связанных не с железом, спецификой реализации протоколов или багом софта не так уж и много. Касающихся хорошоизвестных технологий, ещё меньше, потому что в основном — это просто тупняк со стороны инженера, явная неправильная настройка.
Ну и задачки, как и твоего примера явно не для коллективного решения)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Задачки по сетям. Проблемы в сети MPLS TE