DHCP обрабатывает запросы с тэгированного интерфейса

[Stealch]

Всем привет! Ситуация такова: есть сервер на ubuntu server 14.04. Интерфейс eth0 смотрит в сеть провайдера. eth1 смотрит в локалку. сеть провайдера брошена в локалку посредством VLAN тэгом на уровне ядра, минуя iptables. DHCP натравлен только на физический интерфейс eth1. Но к моему удивлению в логах я вижу запросы DHCP из сети провайдера, при том мой DHCP на них отвечает, но соответственно ответ уходит куда должен - в eth1. Как минус - сралово в логах и забивание пула. В остальном это не проблема, т.к. я не создаю конфликтов для сети провайдера. Как мне сделать чтобы мой dhcp не слушал запросы из тэгированного VLAN? Мне требуется что-то типа опции "Forbidden" как на свичах d-link. Чтобы было понятней - реализовано это так.

[kobaltd]

Vlan на eth1 = это часть eth1 - если dhcp слушает eth1 он также слушает vlan на нем - у Вас полное каша в настройках
если вы на каком то интерфейсе работаете с тэгированным vlan - то вы должны на нем работать ТОЛЬКО с vlan - т.е. подымайте на eth1 второй VLAN и цепляйте DHCP на него.

З.Ы. вообще не понятен весь смысл этой конструкции ? типа сервак заменяет управляемый свич? если да то не проще поставить именно управляемый свич? на нем можно так же будет запретить dhcp relay и все проблемы? темболее меньше шансов словить блокировку порта у прова по loopback после очередного "бага" в модуле vlan

[Stealch]

Vlan на eth1 = это часть eth1 - если dhcp слушает eth1 он также слушает vlan на нем - у Вас полное каша в настройках
если вы на каком то интерфейсе работаете с тэгированным vlan - то вы должны на нем работать ТОЛЬКО с vlan - т.е. подымайте на eth1 второй VLAN и цепляйте DHCP на него.

Я бы согласился с вами, если бы своими глазами не видел работающую конфигурацию, где DHCP не просто не слушает тэгированный интерфейс, а более того - раздает РАЗДЕЛЬНЫЕ адреса на физический и VLAN интерфейсы на одной сетевой плате. Пример - ideco ACP. Самое интересное что демон один и тот же.

З.Ы. вообще не понятен весь смысл этой конструкции ? типа сервак заменяет управляемый свич? если да то не проще поставить именно управляемый свич? на нем можно так же будет запретить dhcp relay и все проблемы? темболее меньше шансов словить блокировку порта у прова по loopback после очередного "бага" в модуле vlan

Смысл конструкции описан в примере этой конфигурации (тема). Управляемый свич стоит, но - как сказано в шапке темы - это DES3526 и у него катастрофическая нехватка гигабитных портов. Другие свичи у меня тоже имеют не более 2-ух портов. Покупать себе свич с адекватным количеством портов и не уступающий по функционалу и надежности существующему пока не имею возможности, собственно по этому и сабж. А так вы совершенно правы, на свиче это было бы сделано за 5 минут без плясок с бубном.

[kobaltd]

То есть Вы хотите сказать что вы с прова получаете ГИГАБИТ или религия воткнуть шнурок от прова в сотку не позволяет?

[Stealch]

То есть Вы хотите сказать что вы с прова получаете ГИГАБИТ или религия воткнуть шнурок от прова в сотку не позволяет?

Я действительно получаю с прова ГИГАБИТ. И не религия, а здравый смысл мне не позволяет занизить себе скорость в 10 раз.

[kobaltd]

т.е. Вы можете позволить себе платить 1к+ деревянных за ГИГАБИТНЫЙ интернет (дешевле он просто не стоит сегодня), а купить DGS-1005A/C1 к примеру за тот же 1к не можете? Установить его между провом и сервом, чтобы еще один линк завести на отдельный vlan для телевиденья на свой управляемый свич в сотку? Или легче решать вопрос через ...., приэтом создавая нагрузку на ядро еще и мультикастом?  Я этого понять не могу

[Stealch]

т.е. Вы можете позволить себе платить 1к+ деревянных за ГИГАБИТНЫЙ интернет (дешевле он просто не стоит сегодня), а купить DGS-1005A/C1 к примеру за тот же 1к не можете? Установить его между провом и сервом, чтобы еще один линк завести на отдельный vlan для телевиденья на свой управляемый свич в сотку? Или легче решать вопрос через ...., приэтом создавая нагрузку на ядро еще и мультикастом?  Я этого понять не могу

Предлагаемый вами 5-ти портовик - ТУПОЙ СВИЧ первого уровня. Управляемая L2 модель такого же класса НЕНАДЕЖНА и крива в настройке. Я написал

Покупать себе свич с адекватным количеством портов и не уступающий по функционалу и надежности существующему пока не имею возможности, собственно по этому и сабж.

И вообще, к чему этот разговор? Есть готовая конфигурация, есть проблема ТОЛЬКО с DHCP. Остальная конфигурация и оборудование здесь не имеют значения, по крайней мере мне не интересны. Спасибо за проявленный интерес, но если вы не знаете решения задачи, то незачем продолжать дискуссию на тему "поставь свич".

[kobaltd]

А зачем Вам "Умный" управляемы свитч между провом и сервом ? Вам и нужен дешевый и неуправляемый - его задача подать от прова вам ГИГАБИТНЫЙ порт на сервер (раз у Вас дефицит с ними) и еще дать возможность воткнуть один кабелек в другой vlan (для телевиденья)  т.е. "тупой разветвитель" - "мозги" для этого не нужны - я лично не могу придумать для чего может понадобиться "управление" на стыке прова и серва, а Вы можете?

[Stealch]

Мне нужно именно так. И тупой свич мне в конфигурации не требуется. Вы знаете как решить задачу с данными условиями?

[kobaltd]

Я Вам уже ответил - подымайте и работайте ТОЛЬКО с тэгированными vlan на интерфейсе. Да бывает и по другому, но сравнивать препроетарные продукты и опен по возможностям не совсем корректно - если способ не устраивает - то решаете или аппаратно как предлогаю или исходники в руки и допиливайте для своих задач.

Для того чтобы понимать ситуацию - возьмите tcpdump в руки и посмотрите что вы ловите на eth<х> и что на Vlan<х> на этом интерфейсе - вопросы отпали бы сразу.

[Stealch]

Я Вам уже ответил - подымайте и работайте ТОЛЬКО с тэгированными vlan на интерфейсе. Да бывает и по другому, но сравнивать препроетарные продукты и опен по возможностям не совсем корректно - если способ не устраивает - то решаете или аппаратно как предлогаю или исходники в руки и допиливайте для своих задач.

Для того чтобы понимать ситуацию - возьмите tcpdump в руки и посмотрите что вы ловите на eth<х> и что на Vlan<х> на этом интерфейсе - вопросы отпали бы сразу.

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

[kobaltd]

Я сейчас глянул Вашу тему по ссылке
Если это Ваш конфиг

# Внутренняя сеть
auto eth1
iface eth1 inet static
   address 172.16.0.1
   netmask 255.255.255.0

#Vlans
auto eth1.777
iface eth1.777 inet manual

#Bridge_local
auto br0
iface br0 inet dhcp
bridge_ports eth0 eth1.777   
up ip route add 10.0.0.0/8 via 10.37.134.1


auto dsl-provider
iface dsl-provider inet ppp
   pre-up /sbin/ifconfig br0 up # line maintained by pppoeconf
   provider dsl-provider
   pre-up iptables-restore < /etc/iptables.up.rules

То Вы хоть убейте - я У Вас не вижу VLAN вообще, если Вы написали комментарий к настройке "VLAN", от этого интерфейс vlan`ном не стал. Я У Вас вижу только мост и алиас - это текущий конфиг?

[Stealch]

Да, это текущий конфиг. И он работает.

[kobaltd]

Ну так для начала разберитесь в терминологии и чем отличаються bridge, alias и vlan - при вашем конфиге Вас спасет только "физика" с тупым свичем или действительно уходите на vlan.
Пользователь решил продолжить мысль 05 Марта 2015, 19:10:17:Если Вам нужен igmp за сервом то есть только 3 пути
1) разделение на уровне свича/vlan - на дорогой свич у Вас денег нет, дешевый не позволяет религия
2) использование igmpproxy - глючно и не стабильно + 50-60% хардварных приставок не работают через него
3) создание моста в локалку - работает, но много минусов 1) нагрузка на сервак (бесполезная) 2) паразитный трафик и "шумы" в локалке 3) все сервисы висящие на "мосте" - ловят и транслируют все в сеть прова, т.е. о защите локалки забудте

Все больше вариантов НЕ СУЩЕСТВУЕТ. Вам выбирать что реализовывать.

[AnrDaemon]

kobaltd,
Альяс это ":". Точка - vlan.