uncnown unicast

[aaaaa]

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

[VolanD666]

Ну а как фрейм долетит до получателя, если свич не знает на каком он порту?

[zstas]

может у человека все маки прописаны статикой.

 

а что за оборудование то?)

 

[nemo_lynx]

Какая разница как прописаны МАС-и? Unknown unicast - это когда свич вообще не знает куда слать пакет, МАС назначения у которого неизвестен свичу. Дефолтная политика в подавляющем большинстве свичей на этот случай - слать во все порты в данном влане (режим тупого хаба).

У меня на доступе в длинках везде стоит ограничение на Broadcast + Multicast + Unknown Unicast в 64 пакета в секунду. Всё что превышает заданный битрейт - дропается. С таким фильтром у абонентов всё живёт и работает, жалоб нет. Но если полностью заблочить UU, думаю, проблемы появятся.

Пример. Свич стоит между абоном1 и абоном2. Оба абона в своих FDB знают МАС друг друга. Свич ребутнулся, сбросил свой FDB. От абона1 прилетел в свич пакет для абона2, но пока ещё девственный FDB свича не содержит МАС абона2, пакет дропается. И это происходит до тех порт, пока от абона2 что-то не прилетит, и его МАС не попадёт в FDB свича.

Edited December 20, 2017 by nemo_lynx

[aaaaa]

В заполнение мак таблицы коммутатора участвуют broadcast или uncnown unicast пакеты?

_lynx

[nemo_lynx]

Любые пакеты с полем source-mac, отличным от 0000.0000.0000 и ffff.ffff.ffff.

[aaaaa]

29 минут назад, nemo_lynx сказал:

У меня на доступе в длинках везде стоит ограничение

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

[VolanD666]

Вы что сделать то хотите?

[nemo_lynx]

Откуда возмётся неизвестный юникаст на шлюзе? Либо извне, либо из своей сети. Для исключения первого варианта поставьте перед шлюзом (или на нём) фильтр, разрешающий со стороны аплинков только пакеты, у которых IP получателя относятся только к вашим сетям. Или вообще попросите аплинков это сделать у себя. Это исключит появление неизвестного юникаста на шлюзе извне.

Из моего опыта unknown unicast (как впрочем и паразитные broadcast/multicast) рождается у абонента, который либо цепляет себе некий вирус, либо выходит из строя сетевушка на компе. Тогда комп абонента превращается в генератор флуда. А это как раз решается на свиче доступа.

Edited December 20, 2017 by nemo_lynx

[aaaaa]

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

 

34 минуты назад, VolanD666 сказал:

Вы что сделать то хотите?

Я хотел получить информацию о том, сможет ли таблица маков заполняться без unicast трафика.

Edited December 20, 2017 by aaaaa

[aaaaa]

Но попробую на будущее, выставить ограничение на всех портах для uncnown unicast

[nemo_lynx]

20 минут назад, aaaaa сказал:

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

 

Я хотел получить информацию о том, сможет ли таблица маков заполняться без unicast трафика.

Вообще-то, шлюз работает на уровне L3 (надеюсь, у вас так?), а всякие там broadcast/multicast/unknown unicast - это всё только на L2. Шторм на уровне L2 не может идти "от шлюза" (если конечно шлюз не заглючил), потому как любой шторм возникает из-за потока пакетов, который что-то генерит, а уже свичи этот поток невольно размножают. Вы определитесь точно, что у вас является источником шторма и в каких пределах этот шторм накрывает вашу сеть. Если это происходит только в пределах одного сегмента L2 (одна адресная подсеть), значит это точно что-то из broadcast/multicast/unknown unicast - либо где-то возникает петля, либо кто-то из абонов превращается в генератор флуда. Такой шторм устраняется настройкой фильтрации на свичах доступа. Например, в длинках есть такая штука - IMPB, пропускающая от абонента только пакеты с его MAC и с его IP. Также там есть всякие LBD, Port Security, Storm Control, ARP Spoofing Prevention и ещё много чего, не говоря уже про ACL. Если же у вас шторм накрывает разные подсети (в разных вланах), то, тут надо смотреть причины в настройках и работе оборудования на L3. Возможно, где-то на L3-железе "слетают" какие-то настройки и трафик попадает в несколько вланов. Обычно такие проблемы возникают либо из-за неисправного оборудования, либо у любителей строить кольца, либо от наличия чрезмерного энтузиазма при одновременном отсутствии мозгов или знаний.

[zhenya`]

чаще всего на л3 шлюзе порты используются как л2 и к примеру, когда арп таймаут больше чем mac aging время можно словить флуд.

 

Абонент выключил комп, мак пропал, арпа еще жива. если кто-то будет слать пакеты на адрес абонента, то л3 свитч это будет форвардить во все порты, где этот влан есть.

 

А если сканить блок, то л3 девайс будет генерить поток arp request. Тоже не очень приятная хрень.. 

[nemo_lynx]

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

И потоком арп-реквестов при обычном IP-скане сеть уж точно не уложить - мелковаты пакеты и частота их генерации тоже не ахти :) . Даже если поток сканов составит 10Г, L3-шлюз один раз разошлёт арп-реквесты и будет ждать ответа некоторый интервал, складируя в это время входной поток скана в буфер. Как буфер закончится, так начнутся дропы. Но на поток арп-реквестов это никак не повлияет.

[zhenya`]

Работу с арпами у китайцев гляньте и офигейте. Даже у циски так себе с agingом, если не крутить.

[Ivan_83]

ARP вообще больная тема, протокол проще некуда, но подавляющее большинство умудряется реализовать его с ошибками.

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

[aaaaa]

Причина флуда, в абоненте.

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

 

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

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