[dalt_ud]

Добрый день.

 

Имеется небольшая сеть, примерно на 500 абонентов, на свитчах d-link 3526 и zyxel mes3500, ну и корневой, куда это всё втыкается SNR S2985G-24T. Все клиенты изолированы друг от друга посредством port-based vlan, т.е. от каждого порта траффик допускается только на uplink порт. И соответственно на корневом свитче есть разизолированный порт, куда я и подключаюсь, для управления всем этим хозяйством своим компом.

 

Есть клиент с mikrotik, от которого на своем порту я вижу весь его входящий траффик. Т.е. подключившись в корневой свитч, я wireshark`ом вижу широковещательные запросы от всех других клиентов (что нормально), и весь входящий траффик идущий на реальный адрес клиента с микротиком, исходящего траффика не вижу. Этого траффика я видеть не должен вообще на этом порту, клиентов с реальными адресами много, а я вижу траффик только одного из них, что ненормально. Иногда траффик пропадает на несколько минут, потом появляется снова. 

 

Совпадение mac-адресов мы исключили. Я их даже попросил поменять mac-адрес на своем микротике, чтобы проверить не коллизия ли это хэш-функций, они поменяли, примерно через полчаса-час, всё началось снова.

 

Может ли каким-нибудь образом сам микротик принимать адресованный ему траффик, но при этом еще зеркалить его обратно в локалку?  Или любые другие идеи, как это может происходить?

 

Я уже полностью исчерпал все свои идеи.

Изменено 22 января, 2019 пользователем dalt_ud

[dalt_ud]

з.ы. несколько лет назад, я видел ситуацию с отражением трафика в локалку, тоже от микротика, но там ситуация была другой. Там у микротика сменился мак-адрес (последний символ), а на шлюзе у нас привязка по мак-адресу. Вот там у клиента с микротиком работал инет (хотя не должен был бы по-идее), шлюз нам бодро рапортовал о попытках подмены мак адреса, а трафик зеркалился в локалку. Как только привязали новый мак-адрес на шлюзе - всё прекратилось. Общего в этих ситуациях только появление траффика внутри локалки, и то, что оба раза были микротики.

 

Сейчас на шлюзе все точно привязано правильно, более того, на всякий случай привязку для этого клиента вообще убрали. Но мак-адрес у него не меняется сам по себе. В логах шлюза (FreeBSD) вообще ничего подозрительного.

Изменено 14 января, 2019 пользователем dalt_ud

[Saab95]

Не совсем понятно. То есть у вас на сети на каждом коммутаторе настроен влан на порт, все вланы передаются в некий центр где стоит шлюз? Как тогда вы можете видеть трафик абонентов? Со шлюза смотрите или нужный влан у себя настраиваете?

Или у вас просто изоляция портов а общая локалка единая по типу большой помойки? Только передавать все могут в направление центра?

[dalt_ud]

46 minutes ago, Saab95 said:

Не совсем понятно. То есть у вас на сети на каждом коммутаторе настроен влан на порт, все вланы передаются в некий центр где стоит шлюз? Как тогда вы можете видеть трафик абонентов? Со шлюза смотрите или нужный влан у себя настраиваете?

Или у вас просто изоляция портов а общая локалка единая по типу большой помойки? Только передавать все могут в направление центра?

Единая локалка, в которой порты изолированы друг от друга, т.е. да, все могут передавать в направлении центра, но не друг другу.  Прилагаю скриншот настроек изоляции портов, чтоб понятнее было. А дальше уже корневой свитч, в котором настроено по тому же принципу, все могут передавать на uplink к шлюзу, ну и соответственно на мой порт, куда я подключаюсь для доступа к свитчам в этой локалке. Но то, что они могут передавать, это не значит, что я должен видеть весь их траффик :)

 

А подключаюсь я отдельной машиной на порту на котором изоляция снята, и он может отправлять и видеть траффик с других портов. Проблема в том, что туда прилетает входящий траффик адресованный клиенту с микротиком (в пакетах правильно указан и dst_ip и dst_mac этого клиента, а не мой) в больших количествах (подозреваю, что весь входящий).

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

От других клиентов ни с реальными, ни с внутренними адресами - ничего не прилетает, кроме стандартных широковещательных запросов.

 

Изначально, в сети начались потери примерно 0.3-0.5%, поэтому я включил wireshark, увидел траффик которого видеть не должен и начал разбираться с этим. Может быть потери с этим не связаны, но разобраться всё равно нужно.

Изменено 14 января, 2019 пользователем dalt_ud

[Saab95]

Поздравляю - пора начинать переделывать сеть на схему влан на пользователя, такое возможно на ваших коммутаторах сделать?

 

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

 

Ведь всего же надо пройтись по всем коммутаторам и создать по влану на абонентский порт, стянуть их в центр и на центральном маршрутизаторе создать пачку вланов.

[pingz]

@dalt_ud имхо выложите дамп

Если клиент поставить пк зеркалится трафик будет?

[dalt_ud]

1 hour ago, pingz said:

@dalt_ud имхо выложите дамп

Если клиент поставить пк зеркалится трафик будет?

К сожалению клиент организация, и поставить вместо их микротика другой девайс проблематично, у них работа встанет.

 

Подобная проверка это крайний вариант, когда все другие будут исчерпаны.

[dalt_ud]

1 hour ago, Saab95 said:

Поздравляю - пора начинать переделывать сеть на схему влан на пользователя, такое возможно на ваших коммутаторах сделать?

 

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

 

Ведь всего же надо пройтись по всем коммутаторам и создать по влану на абонентский порт, стянуть их в центр и на центральном маршрутизаторе создать пачку вланов.

А что меняется принципиально? Сейчас трафик добегает до корневого свитча без пересечения с другими пользователями, по vlan`ам будет то же самое. Причем наша проблема никуда не исчезнет, просто я видеть этот траффик перестану, но отражение его никуда не денется. Я так это понимаю, будет всё равно лишняя нагрузка на оборудование, так или иначе.

Да и со слов начальника, который изучал этот вопрос, в случае в vlan на каждого пользователя - очень сильно возрастает нагрузка на корневой свитч. Не знаю так это или нет, но  экспериментировать на живой сети - желания крайне мало.

 

 

Порт другой попробуем, это относительно не сложно. Зеркалирования у нас точно нигде не включено. Правда если битый порт на клиентском микротике, то тут упираемся в проблему. 

Изменено 14 января, 2019 пользователем dalt_ud

[Saab95]

С виду кажется, что у вас и вашего начальника слабые познания в сетестроении.

 

Сейчас у вас получается так, что каждый абонентский порт может передавать данные только в сторону магистрального порта.

Магистральные порты идут до центрального свича? Или есть промежуточные устройства?

 

Получается, если ваш маршрутизатор отправляет данные абоненту, то они идут по цепочке коммутаторов до нужного порта (это коммутаторы сами определяют по наличии нужного мака на порту), однако со стороны маршрутизатора видится весь абонентский трафик, даже тот, который там совершенно не нужен, и маршрутизатор имеет один порт для всех абонентов, если он отправит широковещательный запрос, то он попадет на все абонентские порты.

 

Никакой нагрузки на оборудование (коммутаторы) вланы не создают, они для того и созданы, что бы эти вланы передавать через себя. В вашем случае настройки корневого коммутатора вообще трогать не следует, он будет пропускать все транзитом между маршрутизатором и абонентскими коммутаторами. На абонентских коммутаторах создаете уникальный влан на каждом порту, и пакуете данные абонента во влан. На маршрутизаторе создаете пачку вланов, с номерами допустим 1001, 1002 и т.п. На каждом порту коммутатора свой номер влана. Тогда на маршрутизаторе будет столько интерфейсов, сколько портов на коммутаторах, и можно будет легко и контролировать загрузку каждого интерфейса, смотреть какой трафик и что там идет, отключить его быстро при необходимости и т.п.

[pingz]

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

[dalt_ud]

В общем разобрались, как и предполагали, виновник был микротик.

 

Клиенту было выделено 4 IP, внутреннюю их структуру сети не представляем, но к нам они были подключены 1 кабелем, который втыкался, как я понял как раз в микротик.

Он часть времени на ip1 держал mac1, а большую часть  времени, брал mac2 от ip2. И получалось когда шлюз возвращал пакеты на адрес ip1 и mac1, коммутатор не знал, кому принадлежит mac1, потому что в этот момент времени у ip1 и ip2 был mac2, и слал входящий на ip1 траффик широковещательно, из-за чего у нас и случились потери и просадки сети.

 

Их админ что-то прикрутил, и проблема ушла, а нас выручила функция IP-MAC binding на порту коммутатора, которая и позволила увидеть всё это безобразие в логах коммутатора.

 

upd, после общения с их админом, выяснилось, что сдвоить один мак-адрес на два IP адреса было их осознанное решение, из серии "самый легкий путь" к тому, чтобы что-то работало у них.

Изменено 22 января, 2019 пользователем dalt_ud

[Saab95]

Скорее всего клиент включил прокси-ARP для получения выделенных им IP в свою локалку, либо тупо объединил локалку с вашей сетью. От чего все это и происходило. Если бы у вас изначально была схема влан на порт абонента, то никаких проблем бы вообще не возникало в подобных случаях.

[dalt_ud]

2 hours ago, Saab95 said:

Скорее всего клиент включил прокси-ARP для получения выделенных им IP в свою локалку, либо тупо объединил локалку с вашей сетью. От чего все это и происходило. Если бы у вас изначально была схема влан на порт абонента, то никаких проблем бы вообще не возникало в подобных случаях.

Я могу сказать только одно, за 13 лет, что я здесь работаю, проблемы с серьезной перегрузкой сети были 4 раза. Один раз лет 10 назад был вирус, а последние 3 раза (с интервалами в год-два) были связаны с криво настроенными микротиками. Сейчас нейтрализуем и микротики, благо IP-MAC биндинг на порту не позволит им шалить с мак-адресами.