Задачки по сетям. Проблемы в сети MPLS TE

    Как инженера тех.поддержки вендора и автора цикла «Сети для самых маленьких» и подкаста для связистов, меня часто спрашивают, чем мне приходится заниматься на работе и как накапливается опыт.
    Итак, я занимаюсь решением проблем.
    Хотел бы предложить хабрасообществу сетевиков новый формат статей — задачки. Я описываю симптомы, предоставляю данные, которые вы попросите, вы ищите решение.

    Итак, начнём с простого: имеем вот такую MEN-сеть:



    На ней запущен MPLS TE. R1 является центральным устройством, обеспечивающий подключение к Интернету и контроллерам базовых станций. Всё организовано через L2VPN. До 2G БС, конечно, проведён TDM.
    Время от времени на сети происходит странное: базовые станции теряют синхронизацию с контроллерами. На фиксированной сети начинаются потери, и скорость падает значительно.
    Всё это относится к сегменту доступа, подключенному к R4.


    Эмпирически было установлено, что решается проблема путём выключения и включения интерфейса R3<->R6.
    Периодичность — несколько раз в день.

    Первая, очень говорящая подсказка
    Графики поведения трафика в день, когда возникала проблема, на линке R2<->R4:




    Вторая подсказка - дополнительный симптом
    После падения интерфейса между R2 и R4 сервисы не падают и работают некоторое время вполне успешно, без потерь. Но примерно через минуту сервисы начинают страдать, пока не дёрнут R3<->R6.


    Основная работа и наше свежеобретённое хобби по решению чужих проблем иногда подкидывают такие и не только такие интересные задачки(Осторожно, спойлер) на траблшутинг.

    P.S. Некоторых логов и картинок у меня не осталось, поэтому буду объяснять на словах.

    Задача — решить проблему, а не выдвинуть предположение. ;)
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 34

      0
      Ты бы дорисовал, как сигнализированы TE туннели.
      По графикам поведения: в какой момент времени передернули порт? Около 11:00 и 12:40 что ли?

      И я правильно понимаю, что вообще говоря проблемному трафику нечего делать на участке между R3 и R6, и ходить он должен только между R1 и R4?

      И классика. Что интересного в логах всех железок? Есть ли какие события RSVP в момент аварии? Есть ли ошибки на портах?
        0
        Я попытался идти от того, как описывают ситуацию заказчики)

        Передёрнули порт R3<->R6 в 12 часов примерно. После этого всё восстановилось. На схеме не дописал, что это график с линка R2<->R4.

        Данный трафик ходить по R<->R6 не должен, верно.

        Логи с какого устройства и за какой момент времени показать?

        P.S. Ещё раз повторюсь, что я сейчас в роли заказчика и совершенно не знаю, с какой стороны подойти к проблеме)
        Чтобы было понятнее, настроены туннели R1<->R4 туда и обратно.
          0
          Тогда неплохо бы заодно график R3<->R6 за тот же интервал времени.
          Логи с какого устройства и за какой момент времени показать?

          Со всех нарисованных по схеме. Начиная с 10:00.
          настроены туннели R1<->R4 туда и обратно.

          Как настроены? Autoroute? Explicit?

          Ну а вообще, в данном сценарии инженер поддержки в первую очередь запросит еще и полные конфиги всех затронутых устройств, но понятно, что в данном случае это будет головной болью, так что продолжим на словах :)
            0
            График R3<->R6
            image


            Настроены с explcicit-path и FRR.

            Логи с R2, которые должны многое объяснить
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Нет никакой проверки полосы пропускания, задержек и других параметров канала.
                Самое интересное, почему LSP построился именно так.

                Мне кажется как-то так, проблема в настройках backup LSP на R1 (и, возможно, R4)

                Какая именно?

                Конфигурация простая: типичные дестинейшн, таннел-айди, explicit-path. Плюс настроен FRR и make-before-break (команда mpls te backup frr-in-use).

                Как собственно, исправить проблему? :)
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Не, я имел в виду причину, по которой через длинный LSP задержки, плохая скорость и всё такое.


                    Прошу прощения, не сразу понял. Да — конечный ответ — там был линк низкого качества. Но это не так интересно.

                    Вот об этой фиче make-before-break я первый раз слышу, так что решение этого вопроса оставлю для более умных людей


                    Такой функционал позволяет создать резервный туннель до того, как основной будет разрушен. Предусмотрительный FRR, так сказать, но это временная мера, а не полноценный резервный туннель.

                    Я бы настроил основной LSP через explicit path R1-R2-R4 и резервный R1-R3-R4.


                    Опять же правильно, но почему в данной ситуации путь построился именно так? Почему не отработал FRR? Или почему он отработал именно так?
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Ошибки нет. LSP дальше простраивается с помощью RSVP CSPF.
                        Но RSVP ищет end-to-end путь. Он не может просто отдать бразды R2, чтобы тот сам маялся. И искал путь.

                        Дам ещё один симптом: после падения интерфейса сервис не прерывается, первую минуту всё работает без потерь и ошибок. И только потом всё ломается.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Возможно, это так, на циске пока ещё не пробовал.
                0
                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. „)

                Какая-то аппаратная проблема с портом?
                  0
                  По картинке это 0/0/2 что ли?


                  Не все детали поменялись. Это E0/0/1.

                  Какая-то аппаратная проблема с портом?


                  Это информация о том, что SFP видит очень слабый сигнал или он вовсе отсутствует.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            1) Нет.
            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


            С обратной стороны всё симметрично.
            0
            Господа, не хочу спойлерить, но решение этой задачки, а также разбор полётов по ней, можно найти по ссылке, которую автор привёл в конце статьи.
              0
              наверняка нужно увидеть path profile для туннеля R1-R4 с устройств R1,R2,R3,R4
              используется ли OSPF (включен ли ip ecmp?), используется ли LDP?
                0
                Что конкретно вам предоставить?

                Конфигурация дана выше. Explicit-path:

                explicit-path EP_R1R4
                next hop 10.0.12.2


                Никаких дополнительных ограничений.

                Протокол внутренней маршрутизации не имеет значения (но в примере IS-IS). IP ECMP нет, LDPZ не используется.
                  0
                  не буду оригинален, что тоже в huawei не разбираюсь, но разве для RSVP-TE не нужно указывать резервный path сальтернативным next hop? или так и задумано, что туннель строить в сторону R4 только через R2?

                  Некоторое понимание этого принципа дает статья по TE
                  habrahabr.ru/post/169987/
                    0
                    Это не является обязательным условием, но направление верное.

                    По мысли заказчика. Основной путь через R2, резервный обработает FRR.
                      0
                      А как mpls te tunnel-id 14 описан на R2? Какой там path до destination 4.4.4.4?
                        0
                        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
                          0
                          Это конфигурация с R3 ообратного туннеля. Я прав? Вообще странно, что уже второе место, где не указан backup path. Если так везде, то странно почему туннель сходится после обрыва линка (увидел выше про RSVP CSPF — уже понял). Для правильного применения RSVP нужен backup path иначе используется path через R2, т.к. интерфейс в апе. Вот если бы падал R1-R2 линк, то деградации через верхнее кольцо не случилось бы (отработал бы RSVP CSPF) — верно?
                            0
                            Вы совершенно правы. Осталось добавить, что сначала отрабатывает FRR — после обрыва и в течение примерно минуты трафик идёт R1-R3-R4, пока RSVP не построит основной LSP, через верхнее кольцо)

                            Вот если бы падал R1-R2 линк


                            Не совсем, тогда бы обратный туннель от R4 к R1 строился бы через верх и всё равно были бы потери)
                0
                Спасибо. Интересная задачка :)
                Мне кажется, что траблшутинг был бы быстрее и проще, если бы можно было посмотреть на show/display команды в момент наличия проблем.
                Реквестирую еще таких кейсов по тематике mpls и всего с ним связанного.
                  0
                  Не вопрос, я мог бы как минимум описать их вывод, либо даже воспроизвести их в лабе и показать точный.

                  На самом деле, если бы я решал проблему так, как в этом топике, я бы, пожалуй был не на лучшем счету) Как-то всё на уровне догадок. Больше.

                  Если интересно, то постараюсь подбирать интересные кейсы. Просто действительно интересных задачек попадается не так уж и много.
                    0
                    В следующий раз так и сделаем. Если никто раньше не разгадаем. Вообще решать задачу методом пристального взгляда на конфиг — неверно. Show команды как раз и придуманы для траблшутинга.

                    Я, пожалуй, соберу такую лабу и дам коллегам погадать :)) Ты лабу в хуавеевском эмуляторе собираешь или в gns?
                      0
                      Вообще решать задачу методом пристального взгляда на конфиг — неверно.

                      Не согласен. С точки зрения сотрудника техподдержки именно такой метод решения проблем предпочтителен. Причина проста: каждый лишний вопрос, заданный клиенту, откладывает решение проблемы на N (десятков) минут. Не скажу за Huawei, но Cisco TAC всегда первым делом требует «show tech-support» со всего железа, имеющего отношение к проблеме. Там и конфиги, и масса других «show», с предусмотрительно вырезанными паролями.

                      А вот если по конфигам проблема непонятна и ясно, что потребуется много вопросов и уточнений — тогда можно организовать и webex сессию и самому полазить по железкам, что тоже отнимает лишнее время. И я уверен, что далеко не каждый клиент на такое согласится.

                      Но если мы говорим про какой-нибудь CCIE (лаба), то само собой разумеется, что основным методом траблшутинга будут show команды. Хотя и тут ни в коем случае нельзя забывать окинуть взглядом полный конфиг на предмет всяких неожиданных VACLов, switchport backup'ов и так далее (они точно будут). Вычислять такое без show run довольно утомительно — есть немало способов частично (самое мерзкое) или полностью сломать передачу трафика через интерфейс, не трогая конфиг этого интерфейса.
                        0
                        Я начинаю с логов, если известно точное время возникновения проблемы. Далее уже конфиг.
                        Хотя, конечно, зависит от вопроса. Если просто что-то не работает, конечно, конфигурация.

                        Первое, что я прошу: display diagnostic-information, топологию и логи. Зачастую этого уже достаточно.

                        Но, учитывая мой небогатый опыт — лаба это для меня всё — виртуальная или настоящая. Собственно в офисе нас двое таких, которые пропадают в автозале постоянно :)
                          0
                          Логи — само собой первым делом. Они ответят на вопрос «что произошло?». А дальше уже возникает вопрос «почему произошло?», и тут без конфигов никуда.
                        0
                        Я собирал в симуляторе Huawei. Я так понял в GNS не заработает такой эксплисит-пас.

                        У Хуавэя есть два симулятора: WVRP — пожалуй на уровне GNS. Лабу собирал в нём. Работает только в корпоративной сети.
                        Второй ENSP — похож на Cisco PT, но не в пример круче: MPLS, VPN, Multicast, возможность снимать дампы итд. На нём не проверял, но, скорее всего, сработает. Скачать можно на huawei.com любому желающему.
                        0
                        если бы я решал проблему так, как в этом топике

                        Дык тут наберется мало спецов по части специфики Huawei. У меня например чуть мозг не лопнул, когда я читал ту гору логов. Обычно проглядываешь по диагонали, и взгляд сразу цепляется за важное, а тут надо в каждую букву вчитываться, всё незнакомо. Надо бы зарыться в документацию, но так как пост опубликован посреди рабочего дня — банально нет времени, а к вечеру уже и ответ есть. В общем, само собой разумеется, что большинство присутствующих, даже будучи грамотными сетевиками, категорически не годятся на твое место хотя бы по причине полного отсутствия опыта работы с данным железом :)

                        Реквестую интересные задачки, связанные с общеупотребимыми технологиями, но желательно на всем знакомом языке IOS. Игра-то ведь интересная. И первым делом — полные конфиги в самом посте. Любая адекватная техподдержка в первую очередь запросит их вместе с топологией и логами на момент аварии, и только после этого начнет изучать вопрос — если ответ сразу не ясен. Можно попросить тех, кто сразу понял причину и полностью уверен в этом, не спойлерить.

                        В целом, интересных задачек можно написать много, но всё что приходит мне в голову либо касается специфики железки и принципиально невоспроизводимо в лабе, либо после устранения проблемы выглядит очевидным и неинтересным. Например, много лет назад я получил по лбу следующей проблемой: трафик, прилетевший на cat6500 с одного конкретного типа интерфейса, не уходит в MPLS. Метки раздаются верно, LFIB в порядке, софт синхронизирован с железом, стек меток состоит из одной штуки (никаких наворотов вроде VPN или TE, т.е. форвардинг полностью соответствует IGP и идет по глобальной таблице). Локально генерируемый либо приходящий не из того интерфейса трафик прекрасно летит куда надо. Сначала я, молодой и глупый, мучился. Потом один CCIEшник из интегратора долго мучился, что только ни делал, ничего родить не смог. Инженер TAC мимоходом дал верный ответ. И нет, не баг, штатное поведение, особенность реализации определенного функционала на PFC. Если сразу не знать ответ — задача нерешаема в принципе.
                          0
                          Про Huawei согласен. Тут и правда есть спцифика. Я не знал, например, что на циске на заработает такой explicit-path.

                          В принципе взгляд цепляется за падение интерфейса, BFD-сессий и перестроение LSP. Плюс графики поведения трафика на всех линках.

                          Потом я проверил конфигурацию, где настроен FRR и только один Explicit-path. Идеят тут уже появилась о решение. Потом в течение часа я проверил её в симуляторе (надо сказать, что в MPLS TE даже не huawei у меня опыт почти нулевой). Ну а ночью в ходе ремонта оптики я проверил догадку на реальной сети.

                          Про конфигурацию устройств соглашусь, пожалуй. Но заказчики очень редко такие данные предоставляют сразу))

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

                          Ну и задачки, как и твоего примера явно не для коллективного решения)

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

                    Самое читаемое