BDCOM 3608 трафик между онушками непредсказуемо зеркалируется

[Пэтро 18]

Цитата

BDCOM(tm) P3608-2TE Software, Version 10.1.0E Build 37276
Copyright by Shanghai Baud Data Communication CO. LTD.
Compiled: 2016-8-18 17:39:31 by SYS, Image text-base: 0x10000
ROM: System Bootstrap, Version 0.4.5, Serial num:00315001480
System image file is "Switch.bin"
hardware version:V1.0
(RISC) processor with 262144K bytes of memory, 32768K bytes of flash

 

Заметил странную ситуацию. На коммутаторе(24 абонента) за онушкой одинаковый трафик по всем портам.

Стал wiresharkом вижу обычный Unicast с коммутатора соседнего дома.

 

Т.е. трафик с онушки соседнего дома зачем-то льется на другую онушку.

 

Заменил онушку, но ситуация не изменилась(что парадоксально). На  других онушках этой ветки все тихо.

 

Чертовщина какая-то)

 

 

 

 

 

 

[nedoinet 440]

26 минут назад, Пэтро сказал:

На коммутаторе(24 абонента) 

Бедный олт.

26 минут назад, Пэтро сказал:

Т.е. трафик с онушки соседнего дома зачем-то льется на другую онушку.

Вангую без конфига epon inner-onu-switch?

[Пэтро 18]

2 минуты назад, nedoinet сказал:

Вангую без конфига epon inner-onu-switch?

Без и что?

2 минуты назад, nedoinet сказал:

Бедный олт.

у нас почти не осталось ethernet портов в ядре, почти все на PON. и никаких проблем нет.

[nedoinet 440]

34 минуты назад, Пэтро сказал:

Без и что?

Опция epon inner-onu-switch включена? Иначе какого ляда тогда трафик бегает между онушками одного порта?

37 минут назад, Пэтро сказал:

и никаких проблем нет.

Кроме утилизации проца в 95%?

[Пэтро 18]

CPU utilization for one second: 70%; one minute: 82%; five minutes: 82%

1 минуту назад, nedoinet сказал:

Опция epon inner-onu-switch включена? Иначе какого ляда тогда трафик бегает между онушками одного порта?

 

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

[Туйон 1 265]

Проц уже вахуе. 

[nedoinet 440]

16 минут назад, Туйон сказал:

Проц уже вахуе. 

Еще не совсем. Ахуе будет при 95%, когда перестанет правильно отрабатывать тдма. А когда нагрузочка на пон порт эбакнет под гигу это вообще пестня будет. Видели мы уже город аборигенов на одном олте.

2 часа назад, Пэтро сказал:

никаких проблем нет.

Пока что.

[KaYot 3 708]

12 часов назад, Пэтро сказал:

трафик с онушки соседнего дома зачем-то льется на другую онушку.

 

Заменил онушку, но ситуация не изменилась(что парадоксально). На  других онушках этой ветки все тихо.

 

Чертовщина какая-то)

Нет тут никаких чертей. У олта кончилась mac-таблица и он работает в режиме "вероятностного свитчинга" как длинки 3028 в свое время.

Не изучаются маки за этой onu, трафик льется как unknown unicast на весь глаз или даже весь олт.

 

Лечить надо ОНУ не пускающую маки, или ОЛТ. Смотри маки на свиче, ОНУ, голове, в ядре.

Відредаговано 2020-01-18 08:22:52 KaYot

[nedoinet 440]

6 минут назад, KaYot сказал:

олта кончилась mac-таблица

У олта вроде 8к таблица, но на сколько корректно оно работает никто ж не знает и коллизии никто не отменял. А вот у онушек она совсем не резиновая.

[Пэтро 18]

Перебросил ветку с 2 свитчами по 24 порта на другой олт

 

Switch#show cpu
CPU utilization for one second: 17%; one minute: 26%; five minutes: 25%
 

Другой олт

 

Switch#show cpu
CPU utilization for one second: 66%; one minute: 68%; five minutes: 68%
 

Всем спасибо за советы..

 

 

 

[Пэтро 18]

На другом Олту (3310B) ситуация повторилась.

поменяли онушку "источник трафика", никакой реакции.

 

Загрузка процессора:

 

Switch#show cpu
CPU utilization for one second: 81%; one minute: 79%; five minutes: 78%

 

Такое впечатление, что этот трабл кто-то инициализирует изнутри.

[KaYot 3 708]

Маки смотрели?

Или флудер какой генерит поток маков сканером/подгоревшим портом, или мультикаст бегает.

ОЛТ это обычный многопортовый свич(256/512 портовый), любые чудеса с ним объяснимы и легко находимы.

[Пэтро 18]

Там обычный HTTP/HTTPS  src Internet dst ip/mac соседнего дома.

Схема такая

 

ONU->Tplink TL-SL5428E -> D-Link DGS1100-06/ME

 

Так вот, приходит трафик предназназначенный  для D-Link. все IP c него.

[nedoinet 440]

7 минут назад, Пэтро сказал:

ONU->Tplink TL-SL5428E -> D-Link DGS1100-06/ME

Жестко... За глинком кучка аборигенов или юрик? Тобишь один вася ходит к другому через ядро? Или там у вас пидемия локальная и аборигенов трючат из вне?

Кстати в 1100-06 есть хороший функционал в виде trafic segmentation и traffic control. И оно даже работает на свежих паршифках.

Відредаговано 2020-01-18 15:07:25 nedoinet

[Пэтро 18]

Физики 5 чел.

Короче я ошибся. Все клиенты за онушкой зеркалятся.

 

трафик например такой

 

18:11:09.743776 IP report.appmetrica.yandex.net.https > 10.0.3.152.33872: Flags [.], ack 3193499830, win 936, options [nop,nop,TS val 32668233 ecr 20110186], length 0
18:11:09.744310 IP report.appmetrica.yandex.net.https > 10.0.3.152.33872: Flags [P.], seq 0:245, ack 1, win 936, options [nop,nop,TS val 32668233 ecr 20110186], length 245

 

 

Відредаговано 2020-01-18 15:25:56 Пэтро

[Sоrk 47]

столкнулся с аналогичной проблемой - в некоторых ветках абоненты получают копию трафика других абонентов.

 

После эксперементов выяснилось следующее:
проблема связана с "locally administered MAC address" (пул "приватных МАК-адресов") (те самые x2:xx:xx:xx:xx:xx, x6:xx:xx:xx:xx:xx, xA:xx:xx:xx:xx:xx, xE:xx:xx:xx:xx:xx) и их обработкой на BDCOM после введения команды epon local-mac forward

 

По факту получается такое:

• - весь трафик к МАК-адресам из этого пула отправляется всем абонентом EPON-порта
• - такие МАК-адреса не видны на EPON-порту и на самой OLT в таблице МАК-адресов
• - основным источником видится роутер TP-link TL-WR850N, он, по какой-то неведомой причине начинает использовать locally administered МАК-адреса на WAN-порту при автоматической настройке. При этом, если потом удалить WAN-порт и создать по новой, то МАК-адрес WAN-порта становиться "нормальным".

Подтверждается экспериментом на пустом EPON-порту:

• ONU1 - 10.8.93.254 (TP-link TL-WR850N), мак адрес из приватного пула 72:FF:7B:D7:57:F5 (назначен при автоматической настройке), Здесь запускаем speedtest.
• ONU2 - 10.8.93.4 (Mikrotik) - "обычный" абонент, на нём ничего не запускам, просто включаем сниффер (Touch на Uplink-порту), в результате получаем копию трафика 10.8.93.254.
  • Если мак-адрес у роутера TP-link TL-WR850N будет из "нормального пула" 68:ff:7b:d7:57:f5 (удалил и снова добавил WAN-порт), то никакого лишнего трафика на Mikrotik нет, и он будет виден в таблице мак-адресов OLT.

 

 

отправил вопрос в представительство TP-Link, пусть пояснят суть манипуляций с МАК-адресами на WAN-порту, но большой вопрос к BDCOM - почему? и куда сдать проблему чтобы не пустили по кругу?

Відредаговано 2020-03-02 17:08:40 Sоrk

[Sоrk 47]

С помощью DEPS показали Китайцам проблему с зеркалированием (по сути происходило "unknown unicast flood")

Выпущена тестовая прошивка 10.1.0F Build 71984

Получен новый tiger.blob (размер файла 2114772, строка из файла - iROS Tiger3 4.2.7.67 Apr 16 2019 17:48:38).

 

Из изменений:
- OLT больше не отдаёт полную FDB по SNMP (только опрос отдельных ONU)

- все "locally administered MAC address" по "show mac address-table" теперь видны в таблице (раньше их не было) и они помечены как STATIC а не DYNAMIC (хотя работают как  DYNAMIC)

BDCOM(tm) P3616-2TE Software, Version 10.1.0F Build 71984
Copyright by Shanghai Baud Data Communication CO. LTD.
Compiled: 2020-3-26 14:44:28 by SYS, Image text-base: 0x10000
ROM: System Bootstrap, Version 0.4.1, Serial num:S15070268
System image file is "Switch.bin"
hardware version:V1.0
(RISC) processor with 262144K bytes of memory, 16384K bytes of flash

 

Файлы не выкладываю, поскольку у них ещё статус тестовых.

[Zlobar 30]

В 02.03.2020 в 18:43, Sоrk сказал:

отправил вопрос в представительство TP-Link, пусть пояснят суть манипуляций с МАК-адресами на WAN-порту, но большой вопрос к BDCOM - почему? и куда сдать проблему чтобы не пустили по кругу?

 

Є прошивки для 850N (і V2, і V3), щоб були коректні MAC адреси.

[Sоrk 47]

2 минуты назад, Zlobar сказал:

 

Є прошивки для 850N (і V2, і V3), щоб були коректні MAC адреси.

 

Есть, но те что дали в TP-link на всю первую страницу пишут что они BETA.

так же, они не дали механизма как обновить уже установленные роутеры.

 

и проблема не только в TP-Link, а такие МАК-адреса попадаются на оборудовании UBNT, прошивках OpenWRT, мобильных устройствах с функцией "случайный МАК при каждом подключении", на виртуальных машинах, Dual-WAN роутерах.

И достаточно было одного такого "качальщика" на vlan, чтобы были проблемы по вечерам у всего EPON-порта.

Конечно plan-per-user спасает, но не у всех он и не везде.

[Zlobar 30]

5 часов назад, Sоrk сказал:

Есть, но те что дали в TP-link на всю первую страницу пишут что они BETA.

 

Вже є не бета.