Не совсем понял о чём вы говорите.

iptables -m mac -h

>фильтр по маске мак адреса

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

Что зачем ?
Защита по маку зачем ?
Раз ёё ввели в айпитейблс то значит она нужна. Вот такой мой ответ.
Защита по маски мака нужна в моём случае потомучто есть около сотни устройств где первые цыфры макадреса одинаковые. А посколько устройств около сотни нагружать айпитейблс таким количеством правил врядли получится без возникновения тормозов.

Зачем???!

У меня тоже такой же вопрос.
Ты на первом пне крутишь? Или на ембедед чём-то?

Нет. Сервер вполне себе мощный(не помню что но кажеться дуал коре дуо), но и трафик он должен обрабатывать без тормозов. Вводить сотню правил думую нерационально. Лучше вместо сотни сделать 8-10.

первые цыфры макадреса
>>цыфры макадреса
>>цыфры(!!!)
На лицо профессиональный уровень знаний Ethernet.

>>трафик он должен обрабатывать без тормозов

А ты настроил как говоришь «с сотней правил» и «трафик тормозит?»

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

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

Вдумайся напоследок как будет происходить так желаемая тобой «сверка по маске мака на основе фильтра по содержимому пакета»
Реально ли будет быстрее fragment-matching, парсящий весь пакет, отлаженной годами командой netfilter процедуры извлечения стандартных полей из заголовка пакета и проверки по правилам в конфиге?

Всё, больше никого не буду переубеждать - если ты сам себе царь и отлично представляешь принцип работы iptables, основы pattern matching, понимаешь какие алгоритмы более накладны для процессора, а какие более щадящие... дерзай сам.

.. И русского языка.
Но в общем-то действительно цифры.. шестнадцатиричные..

Я думаю парень представляет MAC-адрес 01:23:45:ab:cd:ef как строку у не как 10010001101000101101010111100110111101111.
Если я ошибаюсь - мои извинения, но пусть тогда впредь выражается правильно.

Возможно, что вам нужен ebtables, правда Еthernet интерфейс нужно будет превратить в Bridge и не знаю, как это скажется на производительности.

У меня нет информации о том что сам iptables эту сотню правил соптимизирует так что лучше это поручить ему чем пытатся делать правило вида «pattern matching».

А правильно как?

Несколько первых символов...
Несколько первых щестнадцатиричных цИфр...

ИМХО, в том, что он сказал «несколько цИфр» нет ничего ужасного.

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

Возможно, что вам нужен ebtables, правда Еthernet интерфейс нужно будет >превратить в Bridge и не знаю, как это скажется на производительности.

Если мост это всё что нужно и этот самый ebtables это может то я думую это стоящие решение. Во всяком случае стоит попробовать.

У меня нет информации о том что сам iptables эту сотню правил соптимизирует

Сходи на оффсайт netfilter или возьми книгу по iptables где описан принцип его работы или разбери сорцы, раз ты так любишь делать либо хорошо, либо никак.

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

А у тебя есть информация, что ты сможешь написать десяток своих правил и соптимизировать их так, чтоб «трафик обрабатывать без тормозов.»?

Прочти сперва как он работает хотя бы тут

Если у тебя большой траффик, то ИМХО ты как раз повесишь свой сервер.

brctl - Чем этот код хуже чем аппаратный коммутатор?

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

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

Не всегда. При некоторой длинне бинарного массива поиск будет проигрывать. Хотя у поиска безусловно преимущество при малом размере массива.

или использовать аппаратный коммутатор.

Он собственно итак используется. Кудаже без него.

А если используется несколько коммутаторов, для того чтобы избежать петель коммутации, нужно включить поддержку протокола Spanning Tree Protocol. Теперь тебе страшно?

А если используется несколько коммутаторов, для того чтобы избежать петель коммутации, нужно включить поддержку протокола Spanning Tree Protocol. Теперь тебе страшно?

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

Вот тока я в упор не вижу с чегобы это ?

Петля ЕМНИП возможна с первым же коммутатором, к которому подключен комп-бридж

Мне надоело, можешь считать, что я сливаю.

Ты такой упёртый - только рассуждать горазд - взял бы да протестил конфиг «с сотней правил» (первый ответ в треде) против «маски по маку» (u32 patch). Сравнил отзывчивость. Выложил результаты. Тогда бы и поговорили.

Чтобы сравнить нужно чтобы было с чем сравнивать.
Пока мне дали лишь направление поиска.
Нарыл вот здесь http://ebtables.sourceforge.net/misc/ebtables-man.html вот это:
-s, --source [!] address[/mask]
The source MAC address. Both mask and address are written as 6 hexadecimal numbers separated by colons. Alternatively one can specify Unicast, Multicast, Broadcast or BGA (Bridge Group Address):
Unicast=00:00:00:00:00:00/01:00:00:00:00:00, Multicast=01:00:00:00:00:00/01:00:00:00:00:00, Broadcast=ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff or BGA=01:80:c2:00:00:00/ff:ff:ff:ff:ff:ff. Note that a broadcast address will also match the multicast specification. The flag --src is an alias for this option.
Вроде то что нужно...

Я вот хотел уточнить, а какой именно «лишний» трафик приходит на интерфейс, если сеть построена на свичах, у которых не переполнена таблица MAC-адресов?

А то в Инете только повторение этой цитаты (оригинал http://www.linuxfoundation.org/en/Net:Bridge ), а объяснения нет.

Я почему-то сразу подумал про броадкасты, траффик для поддержки соединений (ну как это называется, когда периодически посылается друг-другу пинг, чтоб не закрылось на нате или по таймауту не закрылось), когда копипастил фразучитал статью, поэтому посчитал вполне себе логичным. Если не прав, исправь, я не могу назвать себя экспертом в этом вопросе.

Загляни, пожалуйста, в этот тред, интересно твоё мнение.

Броадкасты всегда приходят и обрабатываются. Другое дело, если бридж, то дальше рассылаются. Но это часть работы бриджа, ИМХО, это нельзя рассматривать как замедление системы.

Если отбросить в строну случай с переполенной таблицей, (когда switch = hub и производительности сети вобще нет), то, вроде и нет лишнего трафика.

Единственное, если мы бриджим через себе кучу трафика и свитч видит на этом порту кучу MAC-адресов, то оно может решить, что там другой свитч и начать отправлять в этот порт вобще весь трафик.

Вобще я в Инете не нашёл замера, насколько падает производительность при создании бриджа из одного интерфейса.

А как грамотно сделать поднятие моста автоматически ?
Вроде всё просто с одной стороны - создай загрузочный скрипт и наслаждайся жизнью, но есть ведь /etc/network/interfaces. Туда надо чтонить писать или не надо.
сам скрипт который будет поднимать мост стоит вызывать до вызова /etc/init.d/networking или после и вместо? Конечно можно самому поэксперементировать, но одна задача для которой это было нужно уже неактуальна (командировка закончена), а вторая задача ещё не наступила.

А мост это даже хорошо так как у сервера две сетевухи, а используеться тока одна.
Можно по идеи сделать так чтобы от свитча шло два соединения на две сетевухи.
Вот тока как узнать поодерживает ли он одинаковые айпи на нескольких портах.
Вроде должен так как свитч сюрьёзный гигабитный D-Link DGS на 24 порта (какой не помню). Но в сетях я ламер по сравнению с теми кто админит у интернет провайдеров, поэтому таких специфических заморочек не знаю. подскажите кто знает ?

Вот, если делать дистрибутивно-правильно, через правку /etc/network/interfaces: http://acidborg.wordpress.com/2010/01/21/how-to-configure-a-network-bridge-in...

сам скрипт который будет поднимать мост стоит вызывать до вызова /etc/init.d/networking или после и вместо?

«До», ИМХО, смысла не имеет, настройки перепишутся. «Вместо», тогда этот скрипт должен быть полной заменой /etc/init.d/networking, и поднимать все интерфейсы и, вроде, что-то ещё делать. «После» можно, но лучше, всё таки поправить /etc/network/interfaces, чтобы потом не вспоминать, почему в interfaces одно, а по факту другие настройки.

Если сервер нужно связать со свичём несколькими линками, то это бондинг. Тогда сервер не форвардит пакеты между интерфейсами, а старается загрузить оба интерфейса. Причём, лучше, когда свитч понимает агрегацию портов (EtherChannel), но возможны варианты, когда разным клиентам сервер сообщает разные MAC-адреса. DGS'ы, вроде, не управляемые, поэтому там нельзя настроить агрегацию портов, но с DLink я не дружил.

А если сетёвки объединить в мост и воткнуть в одни свитч, то получится закольцовка (петля) и свичу будет плохо.

Можно ли будет засунуть bond-интерфейс (bond0) в bridge (br0) --- не знаю, не пробовал.

mky, спасибо очень интересно читать тебя.
Я думал просто объеденить два сетевых интерфейса в один мост и создать виртуальный интерфейс. Таким образом получится этот самый bonding по идеи. Если нет форвординга (отключим если что) то по идеи не должно быть закольцовок.

Нет. Бондинг и бриджинг это разные вещи.

Если взять «правильный» бондинг в режиме load balancing (round-robin), при котором свич должен знать какие порты объединены в один, то можно дать следующие различия. В режиме бондинга любой, в том числе и широковещательный пакет пойдёт через один из двух физических интерфейсов (через тот, который свободен в данный момент). В режиме бриджа широковещательные пакет будет отправлен через оба физических интерфейса, а не широковещательные (unicast) пойдут через тот интерфейс, на котором ядро «видело» адресуемый MAC-адрес.

Кроме этого, в режиме бриджа ядро получит от свича широковещательный ARP-зарос на оба физических интерфейса, ответит на оба этих пакета, что, ИМХО, не понравится свичу.