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

[JDima]

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

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

[eucariot]

Туннели Explicit — и основной и резервный.

В логах на R2 фиксируется падение только туннелей до R7 и R8. На R7 и R8 наоборот. Никакого указания на направление в сторону R4 нет.

[JDima]

Волшебного слово «verbatim» нету? И так что с explicit, там всё нормально?

Круто бы конфиг VPLS и TE…

[eucariot]

Промахнулся, ответил ниже.

[eucariot]

Конфигурация.

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 зеркальна.

[JDima]

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

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

Это опечатка?

[eucariot]

Да, Дим, опечатка. Менял 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

[JDima]

Если реальная проблема только с туннелем между R2 и R4, а остальные закономерно развалились из-за потери линков, то их конфиги как-то не очень интересны. Или я неправильно понял задачу, и надо расследовать причины изоляции на левой стороне схемы?

[eucariot]

Перефразирую постановку: порвали обе оптики, естественно отвалились R7 и R8. Но вместе с ними почему-то начались проблемы и с R4. Как так вышло, ведь, казалось бы R4 никак не связан с упавшими линками.

[JDima]

А чего тогда все конфиги выше не имеют отношения к R4? :)

[eucariot]

Да это всё не имеет значения. Сразу скажу — конфигурация TE правильная. Она типовая на всех PE :)

[JDima]

Понятно. VPLS? Бриджи на интерфейсы в сторону клиента?

[eucariot]

Извини, что такое бриджи?

[JDima]

Каким образом клиентский трафик уводится в VPLS?

[eucariot]

Для vsi настраивается политика по использованию туннеля.

[eucariot]

К слову на сети были и некоторые другие клиенты/сервисы, которые проблем не испытывали.

[eucariot]

Да, оставался доступным. Отвалились только некоторые сервисы.

Конфиг пока не могу показать — в пути. Но там обычная терминация влан и привязка к vsi.

[eucariot]

Нет, альтернативных линий нет.
По картинкам трафик был вал время проблемы и можно говорить о незначительном его росте.

[eucariot]

Для простоты скажем так: отвалились сервисы данного клиента, но при этом продолжал работать шпд, для обычных.
Трафик сохранился в обе стороны. Рост только в направлении от р2 к р4.

[eucariot]

У клиента не работает его 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

Все клиентские интерфейсы настроены похожим образом.

[tgz]

Если трафик ходит, то какие проблемы были тогда?
Из описания не понятно совершенно ничего.

[eucariot]

Трафик на интерфейсах есть, да. Но сервисы заказчика не работают. При этом не полностью — свои устройства на узлах они видят.

[eucariot]

Нет, не мту и не маршрутизация. Опорная сеть отработала штатно.
Вообще ниже уже дали правильный ответ, но мы можем подложить)

[mayorovp]

А на том ли уровне ищем проблему? Где у клиента DNS-сервер находится? DHCP-сервер? Или какой-нибудь контроллер домена?..

[eucariot]

Ищем на том — на сетевом.

[AwesomeBanana]

Я правильно понимаю что некоторые сервисы внутри VPLS работают, а некоторые нет. Т.е. другими словами какая-то часть траффика в туннель R2-R4 пролезает, а какая-то нет?
Если все так, то хотелось бы получить больше информации о сервисах с которыми всё ок, а с которыми нет? И раз уж нам намекают на QoS, то интересна так же раскраска траффика этих сервисов.

[eucariot]

Можно считать так. Через VPLS клиент «гоняет» разный трафик — как минимум какие-то свои внутренние сервисы и канал управления. Так вот канал управления работает безупречно, без лагов и тормозов.

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

[AwesomeBanana]

Значит если перемаркировать весь клиентский траффик в BE с двух сторон, то у клиента все заработает? А если только с одной стороны?

[eucariot]

«если перемаркировать весь клиентский траффик в BE с двух сторон, то у клиента все заработает?»

Зависит от обстоятельств. В определённых обстоятельствах может сработать.

[DAzgluk]

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

Что еще могло забить данную очередь? возможно unknown-unicast который образовался после отвала R7 и R8, либо какое то нештатное поведение сигнализации RSVP/OSPF на сети оператора

[eucariot]

Бинго. Unknown unicast — это правильный ответ. На NNI-интерфейсах настроен шейпер для очереди ef, который дропал пакеты, а сервис заказчика очень чувствителен к потерям.

[DAzgluk]

Забавный кейс :)
Если не секрет, как решили проблему?
Заказчику предложили L3VPN, или просто задрали mac-addr-age таймеры/прописали маки статикой?

[eucariot]

L3VPN не применим в ситуации клиента. Проблема была в том, что, упали одновременно два канала потому, что физически шли рядом. Основная рекомендация — не допускать таких ситуаций. :)

[AwesomeBanana]

Тогда хотелось бы посмотреть
1. статистику дропов по очередям на R1-R2-R3-R4.
2. На них же посмотреть статискику маркированых пакетов или хотя бы раскладки по очередям.
3. Маки изученные R1 на соответствующем vsi.
4. TE туннели настроены без каких либо ограничений по полосе?

[eucariot]

1-2. Это правильное направление. По статистике очень большие дропы в очереди EF.
3. Намёк на unknown unicast? Совершенно верно.
4. Туннели без ограничения, но на физических интерфейсах настроены шейперы.

Я думаю, вы справились с задачей. И надо признать довольно быстро.

[AwesomeBanana]

Ну видея про unknown unicast принадлежала DAzgluk, мне до последнего не хотелось в это верить.
ИМХО, роль саппорта в данном случае — найти проблему с перегрузкой очередей/шейперов и указать клиенту, а уж что там внутри летает — unknown unicast или что-то еще — проблема клиента.

[eucariot]

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

[eucariot]

Можно считать так. Через VPLS клиент «гоняет» разный трафик — как минимум какие-то свои внутренние сервисы и канал управления. Так вот канал управления работает безупречно, без лагов и тормозов.

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