Аццкий гей-парад в Москве 16.05.09

[dil]

https://www.youtube.com/watch?v=WqVv2S8e6AU&has_verified=1

via dinozavr

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

Comments

[kritik-at-work.livejournal.com]

баг в прошивке, забытая команда зеркалирования трафика на коммутаторе
статическая привязка мака к порту коммутатора
а мак в сети вообще существует?

[dil.livejournal.com]

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

вот три SMB-пакета на 445 порт пролетели от одного источника одному получателю: NTLMSSP_NEGOTIATE, затем NTLMSSP_AUTH, и TREE_CONNECT к C$.
Ответов я не вижу, но раз сессия развивалась, то они, очевидно были. Значит, реальный получатель тоже эти пакеты получил, и гипотеза о статической привязке мака к порту отпадает.

Мак существует, на arping отзывается.

[schors.livejournal.com]

Ну да, экспирится или переполняется действительно.

[schors.livejournal.com]

Сеть топят. Затопление сети происходит если у коммутатора нет информации куда послать пакет.

Пример клиники.
Есть такая штука как Microsoft Load Balanser. Он IP вешает на две разных машины. Причём, отвечает от имени виртуального MAC. Соответственно, в коммутатор НИКОГДА не приходит пакета, у которого обратный MAC будет тем, что ответил ARP. Соответственно, в таблице коммутатора никогда не появляется соответствия и он просто "топит" по всем портам согласно собственно спецификации.

[schors.livejournal.com]

Соответсвенно, кривые ответы, перезагрузка таблицы. А, кстати, ещё бывает очень мало памяти для MAC-таблицы в коммутаторе и он постоянно её сбрасывает. Соответственно, порты опять "затапливает".

[dil.livejournal.com]

у меня явно другой случай. мак существует. вот с переполнением таблицы - это вариант..

[schors.livejournal.com]

MAC может и существует. А он реально в реальных ответах себя подставляет? И не срёт ли он в несколько портом своим MAC? Тогда тоже таблица от него избавляется. Ты понял идею, да? MAC записывается в таблицу ТОЛЬКО когда сквозь коммутатор проходит пакет Ethernet с таким вот MAC в обратном адресе заголовка. Что там ARP отвечает коммутатор не волнует.

[schors.livejournal.com]

http://strict.spb.ru/cisco/bp-c6500.html#pre4
пруфлинк. выдрано, но зато по делу и кратенько

[kiltum.livejournal.com]

Про коммутатор скажи.

У некоторых есть такая опция - если им плохо и они не успевают разроутить пакеты, они в режим хаба переходят. У тебя не такое?

[dil.livejournal.com]

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

[tejblum.livejournal.com]

Если циска, и там не выключен CDP, можно много чего из этого самого CDP узнать.

Переполнение таблиц достаточно маловероятно, и выглядело бы это скорее всего несколько по другому, мне кажется. Могут быть, например, эффекты STP: если порт не сконфигурирован специальным образом (у циски это называется portfast), и этот порт включился или выключился, это считается "topology change" и вызывает сброс мак-таблицы во всем stp-домене. А может и какие другие глюки.

[pe3yc.livejournal.com]

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

[dil.livejournal.com]

угу, и желательно из самогО коммутатора

[nikulina.livejournal.com]

>сеть коммутируемая

а ты твердо уверен? вдруг таки кое-где нет?

[dil.livejournal.com]

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

[ef-end-y.livejournal.com]

если кто-нить посредине кабелька от тебя до свича врежется ... хабом?

[dmarck.livejournal.com]

Их мало? Unknown unicasts?

[dil.livejournal.com]

их мало, но они вполне known. от реально существующих в сети машин, по вполне обычным протоколам - smb, http, ssh и прочая

[dmarck.livejournal.com]

Это тебе и прочим хостам они known, а у свитча могли из таблицы протухнуть -- часто я встречал, что default arp lifetime - 10 минут, а L2 mac lifetime - 5.

UPD: если ты видишь только сетап пакеты от TCP, то, скорее всего, так оно и есть

[ef-end-y.livejournal.com]

свичи работают на уровне мак-адресов (есть и ip, но я думаю это не тот случай). Послать пакет на заданный мак можно с любым dst-ip. Чтобы было понятно: представь, что твой комп - это шлюз, тогда на него будет слаться трафик с любыми dst-ip. Администратор правильно сказал - ты можешь видеть трафик в своем вилане, при условии, что пакеты шлются на твой мак-адрес. Причина поможет выяснить анализ трафика. Может у какой-нить секретарши (не знаю что у вас за организация) нет инета по причине, что шлюз указан как твой комп. А может работает icmp-перенаправление маршрутов, хотя эту фичу везде блокирует, но я с таким встречался

[ef-end-y.livejournal.com]

сори, невнимательный я. \если мак не твой, то вся стройная теория не к месту)

[dil.livejournal.com]

э-э.. спасибо, я в общих чертах представляю, как работают свитчи. и как работает arp, и его спуфинг, и icmp-redirect тоже представляю. это не тот случай.

[ef-end-y.livejournal.com]

да, я невнимательно прочитал первый пост, уже отметил выше)

[ivlad.livejournal.com]

unknown unicast или истощение CAM-таблицы. ну, либо бага, либо какая-нибудь настройка.

[bond-jimme.livejournal.com]

Как вариант: странная логика работы портовых ASIC ( http://nag.ru/2006/0730/0730.shtml )