Задачки по сетям. Странное падение

    Новая сетевая задачка из необычных.

    Вот упрощённая топология:



    Имеем опорную сеть, с запущенным MPLS TE. Поверх сети организована услуга VPLS для крупного клиента.
    Между маршрутизаторами натянуты TE-Туннели, в которые трафик VPLS заворачивается с помощью политик.

    Какое оборудование стоит за нашими маршрутизаторами, можно только догадываться, но мы доверяем их QoS меткам и знаем, что основной тип трафика идёт с метками EF.

    Одним чудесным утром всё пропало — два линка, изображённые красным, упали (физически, порвали оптику, например). И как бы логично, что стали недоступны узлы 2 и 3. Но вот странность: вслед за ними клиент стал жаловаться на проблемы с узлом 4 — сервисы тоже перестали работать. После восстановления повреждённых линий всё починилось на всех узлах.

    Внимание, знатоки, вопрос: кто виноват и что делать?

    Похожие публикации

    Средняя зарплата в IT

    110 500 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 7 087 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

      0
      А как сигнализирован туннель R4? Explicit или autoroute? Конфиги бы с обеих сторон. Если пытаться угадывать, то в explicit указывался r8 или r7, а бекап не был задан, или был задан некорректно.

      Ну и, конечно, логи бы со всех устройств на момент падения и восстановления…
        0
        Туннели Explicit — и основной и резервный.

        В логах на R2 фиксируется падение только туннелей до R7 и R8. На R7 и R8 наоборот. Никакого указания на направление в сторону R4 нет.
          0
          Волшебного слово «verbatim» нету? И так что с explicit, там всё нормально?

          Круто бы конфиг VPLS и TE…
            0
            Промахнулся, ответил ниже.
        0
        Конфигурация.

        R2:

        interface Tunnel0/0/27
         ip address unnumbered interface LoopBack0
         tunnel-protocol mpls te
         destination R7
         mpls te tunnel-id 27
         mpls te record-route label
         mpls te path explicit-path ep_main
         mpls te path explicit-path ep_sec
         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
        
         explicit-path ep_main
          next hop R2 include loose
          next hop R5 include loose
          next hop R7 include loose
        
         explicit-path ep_sec
          next hop R2 include loose
          next hop R5 include loose
          next hop R6 include loose
          next hop R8 include loose
          next hop R7 include loose
        
        vsi test static
         pwsignal ldp
          vsi-id 50
          mac-withdraw enable
          peer R2
         mtu 9600
         tnl-policy tnl_policy
        


        Конфигурация R7, R8, R4 зеркальна.
          0
          Конфигурация туннеля на R4 вряд ли зеркальна, посмотреть бы…

          vsi test static
          pwsignal ldp
          vsi-id 50
          mac-withdraw enable
          peer R2

          Это опечатка?
            0
            Да, Дим, опечатка. Менял IP, поставил не ту цифру, извини.

            Обратный туннель зеркальный.
            Конфига
            interface Tunnel0/0/72
             ip address unnumbered interface LoopBack0
             tunnel-protocol mpls te
             destination R2
             mpls te tunnel-id 72
             mpls te record-route label
             mpls te path explicit-path ep_main
             mpls te path explicit-path ep_sec
             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
            
             explicit-path ep_main
              next hop R7 include loose
              next hop R5 include loose
              next hop R2 include loose
            
             explicit-path ep_sec
              next hop R7 include loose
              next hop R8 include loose
              next hop R6 include loose
              next hop R5 include loose
              next hop R2 include loose
            
            vsi test static
             pwsignal ldp
              vsi-id 50
              mac-withdraw enable
              peer R2
             mtu 9600
             tnl-policy tnl_policy
            

              0
              Если реальная проблема только с туннелем между R2 и R4, а остальные закономерно развалились из-за потери линков, то их конфиги как-то не очень интересны. Или я неправильно понял задачу, и надо расследовать причины изоляции на левой стороне схемы?
                0
                Перефразирую постановку: порвали обе оптики, естественно отвалились R7 и R8. Но вместе с ними почему-то начались проблемы и с R4. Как так вышло, ведь, казалось бы R4 никак не связан с упавшими линками.
                  0
                  А чего тогда все конфиги выше не имеют отношения к R4? :)
                    0
                    Да это всё не имеет значения. Сразу скажу — конфигурация TE правильная. Она типовая на всех PE :)
                      0
                      Понятно. VPLS? Бриджи на интерфейсы в сторону клиента?
                        0
                        Извини, что такое бриджи?
                          0
                          Каким образом клиентский трафик уводится в VPLS?
                            0
                            Для vsi настраивается политика по использованию туннеля.
            0
            К слову на сети были и некоторые другие клиенты/сервисы, которые проблем не испытывали.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Да, оставался доступным. Отвалились только некоторые сервисы.

              Конфиг пока не могу показать — в пути. Но там обычная терминация влан и привязка к vsi.
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Нет, альтернативных линий нет.
                  По картинкам трафик был вал время проблемы и можно говорить о незначительном его росте.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Для простоты скажем так: отвалились сервисы данного клиента, но при этом продолжал работать шпд, для обычных.
                      Трафик сохранился в обе стороны. Рост только в направлении от р2 к р4.
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          У клиента не работает его L2-сервисы, но своё оборудование он видит и может на него заходить, настраивать.
                          Туннели R2-R4 в Апе. Клиентский порт в Апе. Трафик между R2-R4 ходит, на клиентский порт передаётся.

                          Конфигурация UNI-интерфейсов:
                          interface GigabitEthernet1/1/0
                           carrier up-hold-time 10000
                           negotiation auto
                           description TO_CLIENT
                           undo shutdown
                           mode user-termination
                           portswitch
                           port link-type trunk
                           port trunk allow-pass vlan 3001
                           trust upstream default vlan 3001 
                           trust 8021p vlan 3001 
                           port-queue be wfq weight 1 port-wred wred_be outbound
                           port-queue af1 wfq weight 3 outbound
                           port-queue af2 wfq weight 7 outbound
                           port-queue af3 wfq weight 14 outbound
                           port-queue af4 wfq weight 100 outbound
                           port-queue ef pq shaping 500 outbound
                          
                          
                          interface GigabitEthernet1/1/0.201
                           mtu 9600
                           description CLIENT_SERVICE1
                           control-vid 201 qinq-termination
                           vlan-group 1
                            statistic enable
                            #
                           qinq termination pe-vid 201 ce-vid 201 vlan-group 1
                           l2 binding vsi test
                           trust upstream qinq
                           trust 8021p
                          


                          Все клиентские интерфейсы настроены похожим образом.
                            0
                            Если трафик ходит, то какие проблемы были тогда?
                            Из описания не понятно совершенно ничего.
                              0
                              Трафик на интерфейсах есть, да. Но сервисы заказчика не работают. При этом не полностью — свои устройства на узлах они видят.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  Нет, не мту и не маршрутизация. Опорная сеть отработала штатно.
                                  Вообще ниже уже дали правильный ответ, но мы можем подложить)
              +1
              А на том ли уровне ищем проблему? Где у клиента DNS-сервер находится? DHCP-сервер? Или какой-нибудь контроллер домена?..
                0
                Ищем на том — на сетевом.
                0
                Я правильно понимаю что некоторые сервисы внутри VPLS работают, а некоторые нет. Т.е. другими словами какая-то часть траффика в туннель R2-R4 пролезает, а какая-то нет?
                Если все так, то хотелось бы получить больше информации о сервисах с которыми всё ок, а с которыми нет? И раз уж нам намекают на QoS, то интересна так же раскраска траффика этих сервисов.
                  0
                  Можно считать так. Через VPLS клиент «гоняет» разный трафик — как минимум какие-то свои внутренние сервисы и канал управления. Так вот канал управления работает безупречно, без лагов и тормозов.

                  С точностью известно, что клиент испытывает проблемы как минимум с трафиком EF. На том же сайте идут сервисы ШПД — с маркировкой BE — всё работает.
                    0
                    Значит если перемаркировать весь клиентский траффик в BE с двух сторон, то у клиента все заработает? А если только с одной стороны?
                      0
                      «если перемаркировать весь клиентский траффик в BE с двух сторон, то у клиента все заработает?»


                      Зависит от обстоятельств. В определённых обстоятельствах может сработать.
                        0
                        Обычно что для BE, что для EF выделяют отдельные QoS очереди.
                        Возможно что-то пошло не так, и в сервисе с метками EF образовалась петля, которая как раз вызвала рост трафика R2->R4 При этом осталась нормальная работоспособность других очередей, так как верхняя очередь была с шейпером

                        Что еще могло забить данную очередь? возможно unknown-unicast который образовался после отвала R7 и R8, либо какое то нештатное поведение сигнализации RSVP/OSPF на сети оператора
                          0
                          Бинго. Unknown unicast — это правильный ответ. На NNI-интерфейсах настроен шейпер для очереди ef, который дропал пакеты, а сервис заказчика очень чувствителен к потерям.
                            0
                            Забавный кейс :)
                            Если не секрет, как решили проблему?
                            Заказчику предложили L3VPN, или просто задрали mac-addr-age таймеры/прописали маки статикой?
                              0
                              L3VPN не применим в ситуации клиента. Проблема была в том, что, упали одновременно два канала потому, что физически шли рядом. Основная рекомендация — не допускать таких ситуаций. :)
                          0
                          Тогда хотелось бы посмотреть
                          1. статистику дропов по очередям на R1-R2-R3-R4.
                          2. На них же посмотреть статискику маркированых пакетов или хотя бы раскладки по очередям.
                          3. Маки изученные R1 на соответствующем vsi.
                          4. TE туннели настроены без каких либо ограничений по полосе?
                            0
                            1-2. Это правильное направление. По статистике очень большие дропы в очереди EF.
                            3. Намёк на unknown unicast? Совершенно верно.
                            4. Туннели без ограничения, но на физических интерфейсах настроены шейперы.

                            Я думаю, вы справились с задачей. И надо признать довольно быстро.
                              0
                              Ну видея про unknown unicast принадлежала DAzgluk, мне до последнего не хотелось в это верить.
                              ИМХО, роль саппорта в данном случае — найти проблему с перегрузкой очередей/шейперов и указать клиенту, а уж что там внутри летает — unknown unicast или что-то еще — проблема клиента.
                                0
                                В принципе, да. Но с другой стороны такие всплески могут вредить и другим клиентам и самому оператору даже. Так что с его стороны тоже какие-то действия нужны.
                    0
                    Можно считать так. Через VPLS клиент «гоняет» разный трафик — как минимум какие-то свои внутренние сервисы и канал управления. Так вот канал управления работает безупречно, без лагов и тормозов.

                    С точностью известно, что клиент испытывает проблемы как минимум с трафиком EF. На том же сайте идут сервисы ШПД — с маркировкой BE — всё работает.

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

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