[220B]

Общее представление:

- сеть хомяков сидящих на мыльницах, которым по DHCP выдаются IPы : заплатившим - по МАСам статические реальники, а должникам - динамические серые;

- мыльница обслуживает один подъезд дома = один VLAN

- все VLANы приходят на Dell PowerConnect 6024f, который не умеет dhcp option 82

- Linux сервер, где запущен ISC-DHCP, смотрит в этот свич одним интерфейсом, на который навешены VLANы

 

Пример конфигурации для реализации IP Unnumbered:

 

NET=88.0.0.0/24
GW=88.0.0.1/32
IF=eth0

ip ro replace unreachable $NET

# создаю VLAN 201
VID=201
ip link add link $IF name vlan$VID type vlan id $VID
ip addr add $GW dev vlan$VID
ip addr add 192.168.$VID.1 dev vlan$VID
ip link set vlan$VID up
ip ro add 192.168.$VID.0/24 dev vlan$VID
sysctl -w net.ipv4.conf.vlan$VID.proxy_arp=1
# добавляю пользователя
ip ro replace 88.0.0.2 dev vlan$VID

# создаю VLAN 202
VID=202
ip link add link $IF name vlan$VID type vlan id $VID
ip addr add $GW dev vlan$VID
ip addr add 192.168.$VID.1 dev vlan$VID
ip link set vlan$VID up
ip ro add 192.168.$VID.0/24 dev vlan$VID
sysctl -w net.ipv4.conf.vlan$VID.proxy_arp=1
# добавляю пользователя
ip ro replace 88.0.0.3 dev vlan$VID

 

ip ro

88.0.0.2 dev vlan201  scope link
88.0.0.3 dev vlan202  scope link
192.168.201.0/24 dev vlan201  scope link
192.168.202.0/24 dev vlan202  scope link
unreachable 88.0.0.0/24

 

ip addr|egrep -i 'up|inet'

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 10000
vlan201@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
   inet 88.0.0.1/32 scope global vlan201
   inet 192.168.201.1/32 scope global vlan201
vlan202@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
   inet 88.0.0.1/32 scope global vlan202
   inet 192.168.202.1/32 scope global vlan202

 

Пример конфигурации ISC DHCP:

 

/etc/default/isc-dhcp-server

INTERFACES="vlan201 vlan202"

 

/etc/dhcp/dchpd.conf

authoritative;
log-facility local7;

shared-network NET {

subnet 88.0.0.0 netmask 255.255.255.0 {
 option routers 88.0.0.1;
 host host1 {hardware ethernet 00:aa:bb:cc:dd:02; fixed-address 88.0.0.2;}
 host host2 {hardware ethernet 00:aa:bb:cc:dd:03; fixed-address 88.0.0.3;}
}

subnet 192.168.201.0 netmask 255.255.255.0 {
 option routers 192.168.201.1;
#  class "vlan201" { ???? }
 pool {
  range 192.168.201.2 192.168.201.254;
#  allow members of "vlan201";
}
}

subnet 192.168.202.0 netmask 255.255.255.0 {
 option routers 192.168.202.1;
#  class "vlan202" { ???? }
 pool {
  range 192.168.202.2 192.168.202.254;
#  allow members of "vlan202";
}
}

}

 

Ситуация:

DHCP сервер нормально выдаёт статические IPы по МАСу, но т.к. фактически это разделяемая сеть, то разумеется выдавать динамические IPы в каждом VLANе не получается. Т.е. не взирая на то откуда пришел запрос, динамика будет выдаваться только из первой встречающейся в конфиге подсети. Свич не умеет вставлять в запросы опцию 82, по этому нарисовать класс и отфильтрать по номеру VLANа не получается.

 

При запросе адреса хостом из VLAN202 в логах ISC пишет, что запрос приходит с интерфейса vlan202.

DHCPDISCOVER from 00:11:78:89:37:ff via vlan202
DHCPOFFER on 192.168.201.2 to 00:11:78:89:37:ff (host3) via vlan202
DHCPREQUEST for 192.168.201.2 (88.0.0.1) from 00:11:78:89:37:ff (host3) via vlan202
DHCPACK on 192.168.201.2 to 00:11:78:89:37:ff (host3) via vlan202

 

 

Вопрос:

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

Изменено 17 марта, 2012 пользователем 220B

[Ilya Evseev]

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

Переходите на dnsmasq, он умеет учитывать интерфейс.

[alexaaa]

Вот так это делается, только свитч должен быть L3

 

if exists agent.circuit-id

{

log(info, concat("Lease"

," IP ", binary-to-ascii(10, 8, ".", leased-address)

," MAC ", binary-to-ascii(16, 8, ":", substring(hardware, 1, 6))

," port ", binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 4, 2))

," VLAN ", binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 2, 2))

," switch ", binary-to-ascii(16, 8, ":", substring(option agent.remote-id, 2, 20))

)

);

}

 

subnet 10.230.16.0 netmask 255.255.248.0 {

class "gorod2"

{

match if ( binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 2, 2)) = "202");

}

pool {

range 10.230.16.100 10.230.23.254;

option routers 10.230.16.1;

option broadcast-address 10.230.23.255;

option ms-classless-static-routes 16, 10,200, 10,230,16,1, 16, 10,230, 10,230,16,1;

option rfc3442-classless-static-routes 16, 10,200, 10,230,16,1, 16, 10,230, 10,230,16,1;

allow members of "gorod2";

}

[220B]

Переходите на dnsmasq, он умеет учитывать интерфейс.

Разве dnsmasq можно сконфигурировать с привязкой к интерфейсу по подсетям? Я понял что только на конкретный хост, т.е. на статику.

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

 

Вот так это делается, только свитч должен быть L3

Вначале сообщения я подчеркнул, что используемый свич Dell 6024f не поддерживает DHCP Option 82. ИМХО L3 тут никаким боком

[s.lobanov]

Установите на этом же сервере dhcrelay, который будет добавлять имя интерфейса("vlanXXX") в circuit_id и отправляйте эти запросы на 127.0.0.1, где уже будет слушать dhpcd и парсить circuit_id обычным match if substring(option ... Конечно костыль, но при таком кривом софт-брасе как у вас уже ничего не страшно.

[220B]

Установите на этом же сервере dhcrelay, который будет добавлять имя интерфейса("vlanXXX") в circuit_id и отправляйте эти запросы на 127.0.0.1, где уже будет слушать dhpcd и парсить circuit_id обычным match if substring(option ... Конечно костыль, но при таком кривом софт-брасе как у вас уже ничего не страшно.

Спасибо за идею, обязательно попробую, но пока dnsmasq справился с поставленной задачей парой строк конфига.

Всем спасибо за внимание.

[sillybilly]

Добрейшего дня.

Вообще идея здравая, - но указанный конфиг действительно выглядит старательно прикрученным изолентой к текущей задаче. А вот не придумал ли кто общего решения для терминации unnumbered vlan на линухе? Пока что гугель на эту тему скромно отмалчивается.

[s.lobanov]

sillybilly

linux bras = жуткие костыли(особенно ipoe, для тунелей хоть что-то есть), при том ядро-то почти всё умеет, нет нормальной обвязки.

[sirmax]

Хм, решение "в лоб" - сбриджевать все вланы и запретить траффик между вланами ebtables. Интнерфейс один - проблемы нет? (я так делал, это не фантазия - работает)

[s.lobanov]

sirmax

А с arp spoofing как бороться при этом? Опять какой-то костыль к dhcp-серверу надо приворачивать

[white_crow]

linux bras = жуткие костыли(особенно ipoe, для тунелей хоть что-то есть), при том ядро-то почти всё умеет, нет нормальной обвязки.

обвязка есть - Mikrotik RouterOS (а внутрях - линагз) - но платно - но не дорого.

[s.lobanov]

white_crow

Не суть, я о том что непроприетарного полноценного(а не 100500 самописных скриптов) решения для реализации ipoe-браса на linux, фактически нет

[white_crow]

непроприетарного полноценного

взаимоисключающие параграфы, не?

(а есть еще проприетарные неполноценные : )

(шучу-шучу - конечно есть примеры открытого полноценного ПО)

****

Но Вы усложняете в данном случае.

Есть решения (как вы говорите - проприетарные), есть железяки разные, Вы - их не хотите/ не можете ?

Значит все просто - пишИте стопиццот первый самописный скрипт.... : )

И может именно ваш алгоритм и код - станет стандартом, полноценным и не проприетарным...

Изменено 3 апреля, 2012 пользователем white_crow

[sirmax]

sirmax

А с arp spoofing как бороться при этом? Опять какой-то костыль к dhcp-серверу надо приворачивать

Всмысле с подменой маков клиентом? Т.е. когда клиент ставит мак соседа? Да на уровне привязки к портам - ip-mac-binding в терминах длинка.

Если поставил ип руками - болт, не пущает. А по дхцп даст тебе твойи ИП и только твой ...

Или я не уловил вопроса?

[s.lobanov]

sirmax

Вы уловили вопрос и да, действительно, на современных свитчах можно контролировать source mac, source ip и содержимое arp, но вот только надо помнить, что arp копируется на CPU(и тут свои проблемы), а для построения таблицы ipmb(в терминах длинка) требуется включение dhcp-snooping(или как его там длинк называет), что тоже cpu + баги.

 

Нормальные брасы сами строят все таблицы и заливают данные в линейные карты для того, что можно проверить аппаратно. В случае линукс-браса это некий скрипт, привязанный к событиям dhcp, который добавляет соответствующую запись в arp(при этом arp learning должен быть отключен) и создающий маршрут /32(для rpf)

[Megas]

sirmax, ну да, ну да, давно dlink допили imdb?

открыть их форум, закрыть, и перейти на acl.

[sirmax]

sirmax, ну да, ну да, давно dlink допили imdb?

открыть их форум, закрыть, и перейти на acl.

Да вроде допилили, на 3200 серии вроде бы стабильно работает, правда сетка небольшая. Ну пусть не длинк, так ежкор будет. =)

 

sirmax

Вы уловили вопрос и да, действительно, на современных свитчах можно контролировать source mac, source ip и содержимое arp, но вот только надо помнить, что arp копируется на CPU(и тут свои проблемы), а для построения таблицы ipmb(в терминах длинка) требуется включение dhcp-snooping(или как его там длинк называет), что тоже cpu + баги.

 

Нормальные брасы сами строят все таблицы и заливают данные в линейные карты для того, что можно проверить аппаратно. В случае линукс-браса это некий скрипт, привязанный к событиям dhcp, который добавляет соответствующую запись в arp(при этом arp learning должен быть отключен) и создающий маршрут /32(для rpf)

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

Я так не делал потому что свитчи не выбирал, а строил на том что было - а были более-менее нормальный с ipmb и рабочим снуппингом + опт82.

Но если строить совсем с нуля и выбирать максимально дешевый свитч и не закладываться на мультикаст (который не будет работать скорее всего в дешевых свитчах) - то можно попробовать построить как вы говорите...

Скрипт это конечно криво, но альтернативы не вижу, если честно (для софт-браса)

[sillybilly]

sillybilly

linux bras = жуткие костыли(особенно ipoe, для тунелей хоть что-то есть), при том ядро-то почти всё умеет, нет нормальной обвязки.

Принципиально не согласен.

У меня еще 9 лет назад вскочил вопрос - кысо 7200 или линух на приличной платформе. До сегодня, 3тьфу, ни разу не пожалел о выборе второго варианта, ибо творить на линусях можно просто всё. Иногда, правда, и костылями (см. выше), но, в случае заинтересованности конкретным вопросом хорошего числа энтузиастов, костыль становится протезом, а затем, окончательно доработанный напильником, превращается в имплант. :D Вспомните, когда-то не было ни ebtables, ни виланов - приходилось ковырять ядро и драйвера сетевух.

Сейчас у меня на одном компе терминится 30 вланов (по одной на клаентскую контору, каждая из них шейпится с приоритизацией, натится и фильтруется), крутятся BGP с 2х full view, dhcpd, dns, статистика по юзерам и ее вебморда. Попробуйте сделать это на одной кысе, сравнимой по затратам с линуховым серваком.

Это не холивар. Это просто возражение на абсурдное заявление.

[s.lobanov]

sillybilly

С чем конкрентно Вы не согласны? Что ядро почти всё умеет или то, что для требуется много костылей?

[sillybilly]

sillybilly

С чем конкрентно Вы не согласны? Что ядро почти всё умеет или то, что для требуется много костылей?

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

Ну разве вот кроме unnumbered vlans, о которых лениво подумываю сейчас; задача, собственно, в том, чтоб пошейпить разных клиентов с реальными айпи. Сеть сямкать на /28 или /30 неэффективно, а шейпер у меня работает по интерфейсам, так проще и логичнее.

[Ilya Evseev]

не придумал ли кто общего решения для терминации unnumbered vlan на линухе?

http://habrahabr.ru/post/71689/

http://habrahabr.ru/post/108453/

[s.lobanov]

Ilya Evseev

Зачем Вы даёте ссылки на эту помойку? Там кроме мусора, написанного для офисных админов ничего нет.

 

По первой ссылке вообще тривиальщина, аспект dhcp не освещён никак, во второй есть про dhcp, но там подход со статическими ipv4, не интересно для большинства isp

[Ilya Evseev]

Зачем Вы даёте ссылки на эту помойку? Там кроме мусора, написанного для офисных админов ничего нет.

Примите вальерьянки наконец :) Нормально всё работает.

 

По первой ссылке вообще тривиальщина, аспект dhcp не освещён никак, во второй есть про dhcp, но там подход со статическими ipv4, не интересно для большинства isp

В схеме "vlan per customer" игры с option82 не нужны, dnsmasq раздаёт настройки по dhcp в зависимости от интерфейса.

[kayot]

В схеме "vlan per customer" игры с option82 не нужны, dnsmasq раздаёт настройки по dhcp в зависимости от интерфейса.

1) А как собственно говоря заставить dnsmasq выдавать ip по интерфейсу? Просто указать для хоста eth0.100,ip?

2) Правильно ли я понимаю, что свежие ядра умеют все что нужно для создания мега-БРАСа, но не хватает "сущих мелочей". Например автоматического построения маршрута на клиента после выдачи адреса по dhcp и убивание этого маршрута после устаревания лизы?

Можно конечно эти самые маршруты строить жестко скриптами, но возникают проблемы с несколькими БРАСами и анонсированием актуальных маршрутов бордеру..

 

Пробовал создавать/удалять интерфейсы q-in-q(200svlan, в них по 100cvlan), на 3.7.2 20к создалось секунд за 30, с этой стороны ограничений никаких.

[s.lobanov]

2) Правильно ли я понимаю, что свежие ядра умеют все что нужно для создания мега-БРАСа, но не хватает "сущих мелочей". Например автоматического построения маршрута на клиента после выдачи адреса по dhcp и убивание этого маршрута после устаревания лизы?

 

Всё правильно понимаете. В последних версиях accel-ppp есть наработки именно в этом направлении(реализация тех самых "мелочей"). Описание тут

 

Можно конечно эти самые маршруты строить жестко скриптами, но возникают проблемы с несколькими БРАСами и анонсированием актуальных маршрутов бордеру..

 

А в чём тут проблема? quagga умеет отслеживать маршруты загруженные извне по отношению к ней. redistribute kernel