eucariot May 16 2014 at 12:27

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

1 min

16K

System administration*Network technologies*

+12

Comments 43

JDima May 16 2014 at 12:51

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

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

eucariot May 16 2014 at 12:55

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

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

JDima May 16 2014 at 13:07

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

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

eucariot May 16 2014 at 13:20

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

eucariot May 16 2014 at 13:20

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

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 May 16 2014 at 13:29

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

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

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

eucariot May 16 2014 at 13:36

Да, Дим, опечатка. Менял 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 May 16 2014 at 13:48

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

eucariot May 16 2014 at 13:52

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

JDima May 16 2014 at 13:58

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

eucariot May 16 2014 at 13:59

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

JDima May 16 2014 at 14:01

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

eucariot May 16 2014 at 14:09

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

JDima May 16 2014 at 14:15

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

eucariot May 16 2014 at 14:19

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

eucariot May 16 2014 at 13:29

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

UFO just landed and posted this here

eucariot May 16 2014 at 14:17

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

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

UFO just landed and posted this here

eucariot May 16 2014 at 14:32

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

UFO just landed and posted this here

eucariot May 16 2014 at 14:50

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

UFO just landed and posted this here

eucariot May 17 2014 at 07:11

У клиента не работает его 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 May 17 2014 at 09:34

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

eucariot May 17 2014 at 09:38

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

UFO just landed and posted this here

eucariot May 19 2014 at 03:10

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

mayorovp May 16 2014 at 16:22

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

eucariot May 17 2014 at 06:57

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

AwesomeBanana May 18 2014 at 01:10

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

eucariot May 18 2014 at 12:17

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

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

AwesomeBanana May 18 2014 at 14:01

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

eucariot May 18 2014 at 14:03

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

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

DAzgluk May 18 2014 at 22:54

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

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

eucariot May 19 2014 at 03:00

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

DAzgluk May 19 2014 at 07:53

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

eucariot May 19 2014 at 20:44

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

AwesomeBanana May 19 2014 at 02:50

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

eucariot May 19 2014 at 03:08

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

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

AwesomeBanana May 19 2014 at 12:00

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

eucariot May 19 2014 at 20:23

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

eucariot May 18 2014 at 12:10

Show the best of all time