есть 915-й вилан, который уходит на оборудование ... более другого провайдера, который в свою очередь включает (если я правильно ошибаюсь) на своем коммутаторе (назовём его например lbdhub) loopback detection для этого вилана. дамп пакета:
Код:
17:52:37.289281 cc:b2:55:86:d1:d5 > cf:00:00:00:00:00, ethertype 802.1Q (0x8100), length 64: vlan 915, p 3, ethertype Loopback,
0x0000: cf00 0000 0000 ccb2 5586 d1d5 8100 6393 ........U.....c.
0x0010: 9000 0000 0001 0015 0e1a ccb2 5586 d1c0 ............U...
0x0020: d1c0 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
в вилане 915 loopdetect срабатывает на коммутаторе lbdhub. т.е. коммутатор увидел петлю на моей сети (получил свой пакет обратно) и перестал форвардить пакеты в 915-м вилане. нормальное и обоснованное действие.
но у меня "как бы" нет петли
"как бы" - потому что физическая петля есть - но это rstp колцо и логическая топология - дерево.
физическая топология (схематически):
Код:
+-(1)[dgs](2)-...-(25)des3(26)--+
... |
+---{51}des1(52)--(26)des2(25)--+
dgs - корень stp топологии
des1(51) - альтернативный stp порт
... - "многоточие" это цепочка des-ок, которая нам сейчас не интересна.
изначально 915-й вилан был прописан на транковых портах всего кольца (что правильно). чтобы коммутатор lbdhub не видел петлю (а клиент на одном из портов des-ок между dgs(1) ... (51)des1 не страдал) vlan 915 убран (временно) с порта dgs(2).
сейчас в вилане 915 на des1, des2 и des3 не должно быть никаких маков - не правда ли? на самом же деле - на des1 нет маков в вилане 915, но на des2 и des3 их есть и это cc:b2:55:86:d1:d5.
это первая странность.
вторая странность. если я убираю вилан с порта des2(26) то на des2 мака cc:b2:55:86:d1:d5 нет (вообще нет маков в вилане 915), но на des3 он все равно появляется.
я что-то не так понимаю?
des1 - DES-3200-52 C1 4.39B013 RZBI1E6001635
des2 - DES-3200-26 A1 1.88.B005 PVHQ1A8022685
ingress cheking везде enable.
/foo
Вход
Регистрация
FAQ
Поиск
