Перейти к содержимому
Калькуляторы

Разлетаются пакеты UDP/TCP

Иногда наблюдаю в сетке с широковещательным доменом Ethernet (один VLAN на всех) с Cisco посередине и DES-3526 по периферии странное явление - начинают разлетаться пакеты TCP/UDP в места, где им вообще не место. То есть пакет приземляется на порт, где нет DST MAC и/или DST IP. Заметил это после установки Mikrotik в виде bridge на периферии и мониторинга трафика на них.

Т.е., предположим, есть где то в сети IP 1.1.1.1 mac 00:11:22:33:44:55 и 1.1.1.2 mac 00:11:22:33:44:56, за Mikrotik стоит 1.1.1.3 mac 00:11:22:33:44:57, mac cisco 00:11:22:33:44:50. В итоге вижу варианты на Mikrotik:

- соединение TCP м/у 1.1.1.1 и 1.1.1.2 SRCMAC 00:11:22:33:44:55 / DSTMAC 00:11:22:33:44:56

- UDP м/у 1.1.1.1 и 1.1.1.2 SRCMAC 00:11:22:33:44:55 / DSTMAC 00:11:22:33:44:56

- соединение TCP м/у 1.1.1.1 SRCMAC 00:11:22:33:44:55 и внешним хостом 2.2.2.2 (за cisco`ой) DSTMAC 00:11:22:33:44:50

- аналогичное UDP соединение

 

Собственно вопрос - какого хрена они залетают туда - где их вообще не ждут? Ни по MAC, ни по IP...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

IP не важен.

Мониторьте арп пакеты.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А в то время, когда пакеты приземляются не куда положено, dst машина вообще в сети видна ? пакеты от нее есть ? show ip mac xxxx.xxxx.xxxx (show mac xx:xx:xx:xx:xx:xx на длинке кажется, где хххххххххх - мак получателя) че кажет ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А в то время, когда пакеты приземляются не куда положено, dst машина вообще в сети видна ? пакеты от нее есть ? show ip mac xxxx.xxxx.xxxx (show mac xx:xx:xx:xx:xx:xx на длинке кажется, где хххххххххх - мак получателя) че кажет ?

Да, есть. Вот такую ситуацию отловил. Периферийный Mikrotik отловил TCP соединение между внутренним хостом сети 1.1.1.1 mac 00:11:22:33:44:55 и внешним хостом, находящимся за маршрутизатором c mac 00:11:22:33:44:50, то есть я вижу в неположенном месте полноценный коннект ext_ip mac 00:11:22:33:44:50 -> 1.1.1.1 mac 00:11:22:33:44:55 . При этом на порту абонента с ip 1.1.1.1 вижу этот же mac 00:11:22:33:44:55 (show fdb) и вижу аналогичный по пакетам трафик (show util port), который наблюдаю на Mikrotik совершенно в другой части сети. За Mikrotik нету хостов, которые бы могли генерить битый фреймы Ethernet с mac 00:11:22:33:44:55, порт на d-link в сторону Mikrotik показывает аналогичный трафик, но правильный mac, который должен находиться за Mikrotik и mac адрес самого Mikrotik. (Правда D-Link с точки зрения построения fdb таблицы _для отображения_ доверяю не до конца, ибо сам поймал глюк на 3526 с 5 прошивки по 6, когда свитч знает mac (learned), но в fdb не отображает - техподдержка D-Link в курсе).

При этом, если я кладу порт абонента по физике (ip 1.1.1.1), то на Mikrotik сразу пропадает трафик.

 

2 Ivan_83: не очень понял - при чем здесь ARP?

Изменено пользователем tartila

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По цепочке от маршрутизатора, show fdb/show mac для мака 00:11:22:33:44:55 есть везде? ассимметрии нигде нету ? (как вариант на машине 1.1.1.1 шлюз стоит на 1.1.1.2, а не IP реального шлюза 1.1.1.3, тогда трафик от 1.1.1.1 к шлюзу приходит не с маком отправителя 00:11:22:33:44:55 а с маком 1.1.1.2) и если время жизни arp больше времени жизни таблицы коммутации в коммутаторах (ну или арп на шлюзе прибит гвоздям), то коммутаторы ближайшие к шлюзу могут "забывать" мас 00:11:22:33:44:55 и слать его во все стороны. Можно придумать другие схемы, когда трафика от мака 00:11:22:33:44:55 к маку шлюза нет(достаточно долго для скисания кеша таблицы коммутации), а обратно есть. в момент наличия проблемы пинг со шлюза до 1.1.1.1 проблему снимает (а еще лучше удалить мак, чтобы случился арп запрос-ответ)?

 

Сколько размер таблицы коммутации в кошке (это кстати свитч или рутер у Вас?), и сколько там реально максимальное количество (про вариант коллизий у кошек вроде небыло сведений)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По цепочке от маршрутизатора, show fdb/show mac для мака 00:11:22:33:44:55 есть везде? ассимметрии нигде нету ? (как вариант на машине 1.1.1.1 шлюз стоит на 1.1.1.2, а не IP реального шлюза 1.1.1.3, тогда трафик от 1.1.1.1 к шлюзу приходит не с маком отправителя 00:11:22:33:44:55 а с маком 1.1.1.2) и если время жизни arp больше времени жизни таблицы коммутации в коммутаторах (ну или арп на шлюзе прибит гвоздям), то коммутаторы ближайшие к шлюзу могут "забывать" мас 00:11:22:33:44:55 и слать его во все стороны. Можно придумать другие схемы, когда трафика от мака 00:11:22:33:44:55 к маку шлюза нет(достаточно долго для скисания кеша таблицы коммутации), а обратно есть. в момент наличия проблемы пинг со шлюза до 1.1.1.1 проблему снимает (а еще лучше удалить мак, чтобы случился арп запрос-ответ)?

 

Сколько размер таблицы коммутации в кошке (это кстати свитч или рутер у Вас?), и сколько там реально максимальное количество (про вариант коллизий у кошек вроде небыло сведений)?

Ассиметрии нет, собираю таблицы mac по snmp. У меня есть подозрение на одну штуку, у нас сеть /21, но такие пакеты разлетаются только в одном префиксе /24. То есть у нас сеть 1.1.1.0/21, а разлетаются они скажем в 1.1.3.0/24 (подмечено). Таким образом полагаю, что ктото у себя влепил маску /24 и думает, что 1.1.3.255 - броадкаст. Единственное, что мне не понятно - как он работает, ведь гейт для него 1.1.1.1. И собственно главный вопрос, как это исправить - кроме как настучать по рукам?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сначала надо поймать. Снимите трафик на порту 1.1.1.1 ОТ него во вне, и посмотрите DST маки там. (и на шлюзе DST и SRC для того же трафика ОТ 1.1.1.1) могут быть интересные варианты.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Опять же тяжело понять, как трафик попадает в несколько частей сети... На коммутерах стоит IP-Port-Mac-Binding... На всех.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может быть банально на коммутаторах слетает таблица коммутации маков и они превращаются в хаб шлющий пакеты во все стороны?

!!!На коммутерах стоит IP-Port-Mac-Binding... На всех. !!! - это не спасет - это вообще из другой оперы.

И чем больше будет разрастаться сеть в таком виде тем больше у вас будет таких проблем.

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

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

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

Если у вас в центре циска типа 3500 или 3750 то это все несложно сделать с помощью ip unnumbered не трогая настройки у клентов.

После этого можно пойти спокойно спать.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может быть банально на коммутаторах слетает таблица коммутации маков и они превращаются в хаб шлющий пакеты во все стороны?

!!!На коммутерах стоит IP-Port-Mac-Binding... На всех. !!! - это не спасет - это вообще из другой оперы.

И чем больше будет разрастаться сеть в таком виде тем больше у вас будет таких проблем.

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

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

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

Если у вас в центре циска типа 3500 или 3750 то это все несложно сделать с помощью ip unnumbered не трогая настройки у клентов.

После этого можно пойти спокойно спать.

Есть одно маленькое НО ;) Для unnumbered центральная Cisco должна точно знать, где находиться IP - за каким VLAN с помощью статик маршрутизации. Это довольно тяжело будет организовать в случае нескольких /21 и динамическим распределением IP по всей сети.

Про IP-Port-MAC-Binding я упомянул из соображений отсутствия возможности генерации ложных Ethernet фреймов. Опять же не очень понятно, что имелось в виду, когда Вы говорили о том, что сбойная карта положит сеть. Петля? А зачем тогда Loopback detection?

Нее... Проблема тут явно не в Ethernet. Тут именно IP уровень.

 

p.s. VLAN управления, конечно есть.

Изменено пользователем tartila

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

tartila вы очень наивны и верите в dlink - это неправильно.

Устранили аварию. В квартале, широковещательный домен общий только под управление, тварилось неведомое - дикий дроп пакетов по всем портам аплинков.

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

 

А вы верите в защиту от петель и мак-порт-биндинг :)

По субъективным ощущениям Loopback detection спасает в 99% случает, IMPB чуть реже - 90-95%. И даже разделение на вланы не всегда помогает, ухитряются таки пакетики проскакивать :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

tartila вы очень наивны и верите в dlink - это неправильно.

Устранили аварию. В квартале, широковещательный домен общий только под управление, тварилось неведомое - дикий дроп пакетов по всем портам аплинков.

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

 

А вы верите в защиту от петель и мак-порт-биндинг :)

По субъективным ощущениям Loopback detection спасает в 99% случает, IMPB чуть реже - 90-95%. И даже разделение на вланы не всегда помогает, ухитряются таки пакетики проскакивать :)

Совершенно не удивлен. Почему то большая часть аудитории считает, что разбивка на VLAN решит все проблемы. Наверняка верхним апом пакеты собирались, из них изучался битый MAC, наверняка улетали за счет сбойного пакета в соседние VLAN и там продолжали срать. Я думаю, изучение таблиц fdb быстро бы выявило проблему без замены свитчей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так то в эзернет фреймах есть преамбола, црц и тип пакета.

Из белого шума трудно получить валидный фрейм.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так то в эзернет фреймах есть преамбола, црц и тип пакета.

Из белого шума трудно получить валидный фрейм.

Кто будет заставлять свитч изучать crc перед learning? Это ж какие, по Вашему должны быть свитчи? На базе 8 ксеонов? ;))))))

 

Короче, никто не угадал ;) А дело было то простое.

 

Решил зацепиться к киске напрямую и обнаружил, что этот шум летает уже в ней. Глянул на MAC, которые улетают в неизвестность, оказывается DST MAC, который так улетает - не существует в таблице коммутации, но существует в ARP таблице. Совпадений нет, проверено 100 раз. Сделал просто, arp timeout на интерфейсе в 300 сек, mac aging в 300 сек. Результат - несколько часов - полет нормальный.

 

p.s. Предполагаю, что глюк прошивки.

 

# sh ver

Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(50)SE3

 

Изменено пользователем tartila

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы же нем рассказывали, что мак абонента и он верный. И что при выключении порта трафик пропадает.... неувязачка..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

tartila разбивка на вланы помогает очень сильно. Из опыта могу сказать, что критическое число абонентов в домене 2000. При превышении порога сеть в вечернее время просто перестаёт работать, а у ПК подключенного к сети загрузка CPU возрастает до 50-70%. И это происходит каждый будний вечер и каждые выходные с обеда.

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

Сегментированная сеть тоже бывает дохнет, но это экзотика....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы же нем рассказывали, что мак абонента и он верный. И что при выключении порта трафик пропадает.... неувязачка..

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

 

 

tartila разбивка на вланы помогает очень сильно. Из опыта могу сказать, что критическое число абонентов в домене 2000. При превышении порога сеть в вечернее время просто перестаёт работать, а у ПК подключенного к сети загрузка CPU возрастает до 50-70%. И это происходит каждый будний вечер и каждые выходные с обеда.

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

Сегментированная сеть тоже бывает дохнет, но это экзотика....

Ну это самый распространенный ответ на тему "почему требуется разбивка на VLAN" ;) Зачем нам ACL? Мы сейчас все побьем на VLAN ;)

 

p.s. Кол-во активных абонов - 3500. Пока живем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

tartila У нас и ацл и вланы и лупдетекты и куча прочей защиты начиная от активной и заканчивая пассивной в виде анализа сислогов на лету или дежурного инженера контролирующего ввереный участок сети.

Вот только всёравно и пользователи и оборудование ухитряется преподносить неприятные сюрпризы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Короче, Вы меня убедили VLANизировать сеть. Особенно, при учете фичи polling ;))))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Короче, никто не угадал ;) А дело было то простое.
p.s. Предполагаю, что глюк прошивки.
Сказать что у вас сеть глючит мог любой школьник/старушка/гадалка.

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

В след раз перезагрузите сеть а потом приходите спрашивать, если не поможет :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Короче, никто не угадал ;) А дело было то простое.
p.s. Предполагаю, что глюк прошивки.
Сказать что у вас сеть глючит мог любой школьник/старушка/гадалка.

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

В след раз перезагрузите сеть а потом приходите спрашивать, если не поможет :)

Не понял тонкого виндового юмора ;)

 

p.s. На VLAN таки склонила аудитория nag, буду делать VLAN на свитч

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

В след раз перезагрузите сеть а потом приходите спрашивать, если не поможет :)

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

"А у нас профилактика!"(С)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Чтобы не создавать тему - спрошу тут, проблема такая-же :

Используем ip unnumbered, при выключении клиента устройства во весь vlan идет трафик из вне для него, и коммутаторы честно их рассылают во все порты. В arp таблице он присутствует, а в таблице коммутации - уже нет.

Решили установкой arp timeout в 300 сек, как и автор темы.

 

Но остается вопрос : это штатное поведение, или баг софта, можно решить ли как-то? Потому, что все равно до 300 секунд трафик будет идти.

 

Cisco 6509 SUP-7203B (s72033_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(33)SXH, RELEASE SOFTWARE (fc5)

Спасибо.

Изменено пользователем h1vs2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Штатное: роутер шлёт пакеты на L2 из арп кеша, коммутаторы доставляют как могут. АРП запись устареет, роутеру станет некуда слать.

 

Можете покрутить софтину, которая у вас за пропуск трафика клиента отвечает, чтобы после закрытия сессии блочила/нульроутила трафик к клиенту.

 

Если у вас ISG то настраивайте его.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.