DyadyaGenya Опубликовано 30 июня, 2011 (изменено) · Жалоба Последних пару недель сложилась ситуация что периодически в сети на одной ветке пропадает у людей инет. Подключение как по впн так и по пппое. У всех ошибка 800, тоесть нет доступа к серверу. В такие моменты по сети начинают массово ходить пакеты такого типа: 510238 1119.565704 D-Link_06:57:27 D-Link_8f:cd:71 PPPoED 60 Active Discovery Terminate (PADT) 309943 705.360800 D-Link_06:57:27 D-Link_8f:cd:71 PPPoED 60 Active Discovery Terminate (PADT) 309944 705.361369 D-Link_06:57:27 D-Link_8f:cd:71 PPPoED 60 Active Discovery Terminate (PADT) 309945 705.364713 D-Link_06:57:27 D-Link_8f:cd:71 PPPoED 60 Active Discovery Terminate (PADT) и так далее исходящий мак виден у всех свичей на аплинковском порту, но только на центральном свиче виден скажем на порту номер 6, куда приходит одна из веток, но не та где есть проблемы с инетом. Хотя если оставить ситуацию так, то через сутки и в той ветке начинаются проблемы с подключением но не так массово. Схема такая: (проблемная линия) 21 порт головного свича > 26 порт DGS3120 > 26 порт HP2610(вместо сгоревшего 3120 но проблемы начались ещё на нем) > дальше звездой 15 свичей DES-1210-28. Вторая линия, которая воткнута в 6 порт головного свича (откуда якобы берется проблемный мак): 6 порт головного свича > 24 порт второго 3120 > дальше звездой 12 свичей 1210-28, 2 свича DES-3028, 2 свича НР 2610 и пару тупариков. Если отключить на головном свиче порты 6 и 21 то флуд везде пропадает, если только один из них, то продолжается, и инет у людей не появляется. Повторюсь, на всех направлениях, в том числе и на проблемных мак виден только на 28 порту. Исключение головной, где он виден на 6 порту и НР2610, в который воткнуты проблемные 15 штук 1210-28. Если смотреть на этом НР2610 мак на портах, то он гуляет, может появиться где угодно. Если выдернуть все всключенные в него 1210-28 то появиться на аплинковском порту и не пропадет пока не выключить именно 6 порт головного свича. ОТключал 3120 тот что воткнут в 6 порт, и все равно мак в той, отключенной ветке продолжает гулять, но на аплинковских портах. Да и в самой сети тоже флуд остается. ПРобовал на 3120 отключать, который воткнут в 21 порт головного, не помагает, пропадет если отключить 6 порт головного или бутнуть включенный в него 3120. Пока не сходил с ноутом чтоб проверить, что происходит если отключить аплинк на НР, сами понимаете управление на нем потеряю, если сделать удаленно. Причем, пока воткнуты в него по крайней мере 2 свича, управление затреднено, пинги большие, тормозит, когда больше 2 свичей может вообще отпасть и пинги не будут идти ни с головного, ни с компов людей находяшихся в той ветке. хотя головной свич будут видеть в этот момент. Да и свичи которые воткнуты в НР тоже пингуются периодически, то одна группа работает, то другая, без закономерности, единственное, что их как то шевелит это постоянное их долбение, тоесть увидел что свич отпал и ста его как то пинать, напр пингами или постоянными обращениями, как только он завелся, сразу отпадает какой то другой. Защита от кольца включена везде. Добавлю, почти везде настроен ip-mac-binding, естественно кроме головного и 3120, которые агрегируют данные ветки Кроме того, мак может меняться. Замечены пока что 2 вида маков (один асус и два длинка), ни одного в базе нет. Маки к адресам не привязываются, в смысле ни с одним айпи не асоциируются если проверять снифером или скажем арп таблицы на роутре или свичах. На НР2610 могут определяться как принадлежащие сразу к нескольким влнам, хотя там только один влн, дефолтный. Стоит ли идти с ноутом к НР или надо искать где то в другом месте? И вообще, на что грешить? Могу добавить что пакетики все заканчиваются одинаково, типа сесия пппое закрыта Generic-Error: session closed маки определяются как длинковские и как асус, длинковские могут меняться местами, тот что был соурс, может стать дестинейшн на других направлениях если их отключить от головного сразу пропадает проблемный мак, и появляется вскоре после включения в сеть. Изменено 30 июня, 2011 пользователем DyadyaGenya Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 4 июля, 2011 · Жалоба как бороться понятно - включаешь запрет всех пппое кроме твоего и все пропадает, вопрос как вычислить откуда это идет, и злонамеренно или нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 июля, 2011 · Жалоба >Пока не сходил с ноутом чтоб проверить, что происходит если отключить аплинк на НР, сами понимаете управление на нем потеряю, если сделать удаленно. А у вас управление и абонентский трафик в одном влане? Если нет, то можно просто убирать сервсисный влан(ы) с порта на время диагностики, а не выключать порт. В целом, описание проблемы очень сумбурное и малопонятное, вряд ли кто-то сможет вам помочь, разве что дать общие рекомендации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 6 июля, 2011 · Жалоба А у вас управление и абонентский трафик в одном влане? Если нет, то можно просто убирать сервсисный влан(ы) с порта на время диагностики, а не выключать порт. да вот все никак не разведу по разным, исторически сразу не сделали, а как известно нет ничего более постоянного чем временное, но к концу июля сделаю В целом, описание проблемы очень сумбурное и малопонятное, вряд ли кто-то сможет вам помочь, разве что дать общие рекомендации. а я то думал что подробно описал, хотя может слишком подробно, ведь все равно начнутся советы, типа пойти там отключить посмотреть и тп, вот и постарался описать что и где отключали, теперь даже боюсь как то сократить, чтоб вообще инфы мало не показалось. а вообще что именно в описании не понятно? может отвечая на вопросы смогу понятней обьяснить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 6 июля, 2011 · Жалоба Очень похоже на кольцо.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 июля, 2011 · Жалоба 1. Нарисуйте схему 2. Если всё оборудование управляемое, то в 99,9% можно найти откуда приходит это флуд(по мак адресу) 3. Можно заблэкхолить мак, который флудит(или прописать его на аплинке) и подождать пока позвонит этот абонент :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 6 июля, 2011 · Жалоба Очень похоже на кольцо.... похоже, только откуда берется? везде ж вроде защита стоит, даже снифером это видно: 87540 1544.076331 Procurve_bc:20:80 HP_00:00:67 HP 107 HP Switch Protocol 195626 5602.391254 Procurve_ed:1c:80 HP_00:00:67 HP 107 HP Switch Protocol 195634 5602.877621 D-LinkIn_e0:ed:bd Ethernet-Configuration-Test-protocol-(Loopback) LOOP 60 Unknown function (256) и все в таком духе кроме того, будь это кольцо, то один и тот же мак светился бы скажем на одном комутаторе сразу на нескольких портах, ну или на двух комутаторах на разных портах, а светяться только на аплинковских, кроме двух свичей "агрегации", да и на всех свичах натсроен айпи-мак-биндинг, тоесть на порт строго прописана пара мак-айпи, а значит посторонний мак по идее не должен был проскочить, хотя с этими длинками кто его знает я тоже думаю что это кольцо, но вопрос как Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 июля, 2011 · Жалоба DyadyaGenya Кольцо может быть у абонента дома, а трафик приходит уже в один ваш порт, т.е. грубо говоря у абонента стоит свитч и 2 порта соединяется патчкорд Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 6 июля, 2011 (изменено) · Жалоба DyadyaGenya Кольцо может быть у абонента дома, а трафик приходит уже в один ваш порт, т.е. грубо говоря у абонента стоит свитч и 2 порта соединяется патчкорд ну и как его вычислить? бегать отключать? и где бегать? на той ветке где агрегация на НР сделана или на дгс3120? и что самое обидное, мака то в базе такого нет и если просто тупо порты соеденены пачкордом то получается что кто то специально это делает? Изменено 6 июля, 2011 пользователем DyadyaGenya Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 июля, 2011 · Жалоба Так у вас же оборудование управляемое, что мешает просматривать таблицу маков на свитчах спускаясь вниз по даунлинкам? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 6 июля, 2011 · Жалоба ну правильно, я и смотрю, только вредоносные маки светяться только на палинковских портах, если б где то на порту доступа светились то все было бы понятно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 июля, 2011 · Жалоба сколько маков в таблицах коммутации на свитчах доступа, с которых предположительно приходит pppoe-флуд? ну или последуйте п.3 из моего позапредыдущего поста Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 6 июля, 2011 (изменено) · Жалоба имеется ввиду только на юзерских портах? строго по одной паре, есть правда пару где по две пары мак-айпи, и они арп таблице соответсвуют, никаких других, кроме статических нет, нет и в списке заблокированых. статических до 24 на комутатор. мак блокирую легко, никто не звонит, опять же, когда блокирую, то флуд пропадает, но через время может появиться новый мак Изменено 6 июля, 2011 пользователем DyadyaGenya Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 7 июля, 2011 · Жалоба Нет, имеется ввиду сколько всего мак-адресов у вас на коммутаторах доступа? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zefir Опубликовано 8 июля, 2011 (изменено) · Жалоба да проблема есть. но вот можно реально попробовать все пппое отключить кроме своего Изменено 8 июля, 2011 пользователем zefir Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 8 июля, 2011 · Жалоба явно кольцо -ищите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 9 июля, 2011 · Жалоба К сожалению не было времени сюда заходить, появились другие проблемы, о кторых тоже написал на форуме, вот и не отвечал. с этой проблемой я именно так и борюсь, сперваа стал запрещать мак который флудит, потом они стали меняться и я запретил все пппое, но так и не нашел откуда береться кольцо, и насколько это было вредительство. Странно то что даже при полном отключении двух веток в каждой продолжают бегать флудящие маки. Я уже сходил с ноутом на вторую ветку, где в агрегации стоит НР. Стоит отключить запрет ПППОЕ и через время флуд появляется везде на аплинковских портах. Но это не дело постоянно так дергать сеть. Может и не плохо писать правила против чужих пппое, но кольцо то от этого не денеться никуда, и причина его появления тже не выясниться, а в будущем может вылезти ещё каким нибудь боком Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 9 июля, 2011 · Жалоба Нет, имеется ввиду сколько всего мак-адресов у вас на коммутаторах доступа? ниже 200 не опускается, но так всегда было, а проблемы только недавно появились Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 июля, 2011 · Жалоба DyadyaGenya Просто наличие мака на порту X коммутатора Z, к которому подключен коммутатор Y, но его отсутсвие на самом коммутаторе Y может объясняться тем, что на Y он не может изучиться(или затёрся другим) из-за конфликта мак-адресов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 10 июля, 2011 · Жалоба DyadyaGenya Просто наличие мака на порту X коммутатора Z, к которому подключен коммутатор Y, но его отсутсвие на самом коммутаторе Y может объясняться тем, что на Y он не может изучиться(или затёрся другим) из-за конфликта мак-адресов были у меня подозрения на этот счет, особенно с учетом того что на одной из веток есть дес-3028, но, потворюсь, такое колличество маков было всегда. Кроме того, если б это была проблема с хешем, то запрет чужих пппое не помог бы, а он помагает. Да и маки то неизвестно откуда беруться, их в базе нет, к адресам не привязываются, на портах почти везде настроен ip-mac-binding что по идее должно защитить от появления левых маков (естественно не защищены в первую очередь аплинковские порты и кое где юзерские, с тупариками за ним, ну и свичи на агрегации тоже без биндинга) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 10 июля, 2011 · Жалоба Функционал "ip-mac-binding" на вашем оборудовании проверяет IP-трафик или весь? Как известно, arp и ppp-трафик это не IP-трафик с точки зрения коммутатора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 10 июля, 2011 · Жалоба Ещё ни разу не встречал чтоба биндинг работал только скажем с пппое трафик, да и в описании этой функции везде пишут что дропает она все пакеты с не правильной парой, проверяли, пробовали настроить пппое с не правильной парой, так не пускает ни какой трафик в этом порту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 10 июля, 2011 · Жалоба Ещё ни разу не встречал чтоба биндинг работал только скажем с пппое трафик, да и в описании этой функции везде пишут что дропает она все пакеты с не правильной парой, проверяли, пробовали настроить пппое с не правильной парой, так не пускает ни какой трафик в этом порту. IP-MAC это связка L3-L2 адресов, где IP это всего лишь один из многих типов данных в L2 (эзернет) пакете. Будучи в вашей сети в одном л2 сегменте я могу с обоих сторон менять тип эзернет кадра на произвольный и он будет долетать до другого моего роутера в обход всех фильтров с привязкой к IP. Иными словами, в pppoe, arp и сотнях других протоколов L3 - IP нет (те он там может быть в инкапсулированном виде) и они не отфильтруются "ip-mac-binding". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 10 июля, 2011 · Жалоба DyadyaGenya Вы напишите какие конкретно команды вы используете для "ip-mac-binding", а люди, разбирающиеся в длинках уже скажут, что они фильтруют - фреймы с L3==IP или любые L2-фреймы с заданным mac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DyadyaGenya Опубликовано 10 июля, 2011 (изменено) · Жалоба DyadyaGenya Вы напишите какие конкретно команды вы используете для "ip-mac-binding", а люди, разбирающиеся в длинках уже скажут, что они фильтруют - фреймы с L3==IP или любые L2-фреймы с заданным mac не вопрос, для знающих людей пример команды: enable address_binding arp_mode enable address_binding trap_log #show address_binding create address_binding ip_mac ipaddress xxx.xxx.xxx.xxx macaddress yy-yy-yy-yy-yy-yy ports Z config address_binding ip_mac ports Z state enable config address_binding ip_mac ports Z Allow_zeroip enable и никаких других команд никогда не используется. в свое время испытывал эту систему, может и не совсем правильно, но скажем пробовал собирать арп с разных свичей и с сервака, те маки что заблокированы биндингом нигде не всплывают, даже если смотреть динамик фдб. даже если компу не просвоили адрес, на него ни пппое, ни впн не подается, в арп таблицах нигде не светиться, только в списке заблокированых маков для НР команды нужны? IP-MAC это связка L3-L2 адресов, где IP это всего лишь один из многих типов данных в L2 (эзернет) пакете. Будучи в вашей сети в одном л2 сегменте я могу с обоих сторон менять тип эзернет кадра на произвольный и он будет долетать до другого моего роутера в обход всех фильтров с привязкой к IP. Иными словами, в pppoe, arp и сотнях других протоколов L3 - IP нет (те он там может быть в инкапсулированном виде) и они не отфильтруются "ip-mac-binding". вы такое пробовали? или это теория? Изменено 10 июля, 2011 пользователем DyadyaGenya Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
