[wtyd]

Тема наверное для многих избита, но тем не менее ищу просветления в данном вопросе.

 

В свете схемы vlan per user и аналогов хотелось бы *нормальным* образом раздать адреса именно по /32 без применения всяких обманок типа proxy-arp и ip unnumbered. Без последнего скорее всего не получится, но вот в остальном есть непонятки.

 

Допустим, в linux всё будет работать. Примерно так:

 

ip link set up eth0 -- поднимаем интерфейс

ip addr add 10.0.0.4/32 dev eth0 -- добавляем адрес на интерфейс

ip route add 192.168.20.1 dev eth0 -- говорим, что 192.168.20.1 доступен напрямую в сетевом адаптере

ip route add default via 192.168.20.1 dev eth0 -- добавляем маршрут по-умолчанию.

 

В реальности не тестировал, пока смысла нет, но после этого припопытке что-то попингать линукс начинает слать arp запросы в 192.168.20.1 со своего адреса 10.0.0.4. Т.е. скорее всего работать будет, если шлюз соответственно сконфигурить. Значит торетически схема работать будет.

 

На сколько это правильно с точки зрения rfc ?

 

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

 

Как такие настройки выдавать по dhcp ? Пробовал, но линукс сказал мне, что Network unrichable, когда пытался гейтвей сконвигурить. В man dhcpd.conf нашёл опцию use-lease-addr-for-default-route on; , но либо она не работает для линукса, либо я что-то не так делаю. Написано, что с такой опцией винда должна начать слать арп запросы напрямую в сеть, типа как раз фича для proxy-arp -- совсем не то, что я хотел бы, но может быть есть другие способы ?

 

С SOHO роутерами непонятно. Хотя если dhcp такое умеет, значит надежда ещё есть.

 

Может кто уже давно так делает, поделитесь опытом.

[s.lobanov]

Выдавать маску /32 абоненту(IPoE) - реально не работает. Когда тестил была винда(вроде бы win7), linux, macos и какой-то роутер. На чём-то работало, на чём-то нет. На macos точно не работало и ещё на чём-то не работало

Вообщем не занимайтесь ерундой и отдайте более короткую маску и сделайте proxy-arp(если раздаёте реальники). Всё равно наличие proxy-arp не сильно повышает нагрузку на CPU за счёт "лишних" arp-запросов

 

Даже если вы придумаете способ как заставить работать с маской /32, то по дефолту оно будет не везде работать, что неприемлемо для оператора.

 

А первопричина проблемы в том, что ethernet это изначально не WAN-технология, а LAN, поэтому и приходится костылять ip_unnumbered+proxy_arp

[NiTr0]

Реально - оно работает на винде, работает на линуксе если добавлять мершрут на шлюз через 0.0.0.0 (т.е. через ифейс опцией дхцп), насчет мака - не скажу. Работает на некоторых роутерах. На некоторых - не работает. Некоторые провы юзают as is, без маршрута на шлюз, под них некоторые вендоры роутеров пилят свои нескучные костыли.

 

Но лучше так не делать.

[wtyd]

Реально - оно работает на винде, работает на линуксе если добавлять мершрут на шлюз через 0.0.0.0 (т.е. через ифейс опцией дхцп), насчет мака - не скажу. Работает на некоторых роутерах. На некоторых - не работает. Некоторые провы юзают as is, без маршрута на шлюз, под них некоторые вендоры роутеров пилят свои нескучные костыли.

 

Но лучше так не делать.

 

Дело в том, что ... даже в классической схеме организации сети работает не 100% подключаемых устройств :-). По разным причинам, приходится техподдержке вмешиваться. Т.е. проблемы были, есть и будут всегда. Что так лучше не делать это тоже понятно. Я несколько для другого спрашиваю. А именно: пробовать делать так чтобы прокси-арп не использовался, ну а если не получается, то прописывать маску /24 и тогда с прокси-арп.

 

Пример dhcpd.conf можно с 0.0.0.0 и прочими плюшками ? Что за опции dhcp такие ?

[DVM-Avgoor]

Да можно и /22 выдавать без proxy-arp. Все зависит от профиля трафика. Вообще наличие proxy-arp не сильно-то и важное условие, как показала практика - 99.9% абонентов это не нужно.

[wtyd]

Да можно и /22 выдавать без proxy-arp. Все зависит от профиля трафика. Вообще наличие proxy-arp не сильно-то и важное условие, как показала практика - 99.9% абонентов это не нужно.

 

- Нет, так нельзя! - сказал инопланетянин с машинкой перемещения.

- Да можно! - сказал прораб и нажал на кнопку.

 

(с) Кин-дза-дза

 

На самом деле нет единственно верного способа, есть несколько приемлемых. Я вот в сети одного провайдера запускаю tcpdump и получаю такое:

 

time tcpdump -nc 300 -i eth1 'arp'

...

300 packets captured

302 packets received by filter

0 packets dropped by kernel

real 0m 9.51s

user 0m 0.00s

sys 0m 0.02s

 

30 пакетов в секунду, там арп перманентно летит.

 

В одном сегменте у них несколько сетей класса С с разных блоков, которые им райп выдал. Они вообще не парятся с вланами и изоляцией. Т.е., выходит, что так тоже можно. У нас сделано не так, но в свете тенденций в сторону vlan per user ищу оптимальные для себя решения. Пока картинка не очень складывается. Хочу снизить арп трафик нормальными способами, но что-то таких нет.

[s.lobanov]

И? Если у вас будет vlan-per-user, то чужие арпы к вам лететь не будут при включенном proxy-arp

[Saab95]

Если у вас схема влан на клиента то делается следующее:

 

1. Создается влан.

2. Вешается на него адрес, например 10.0.0.1/8.

3. Прописывается маршрут, что адрес абонента, например 10.10.10.10/32 находится на интерфейсе влан.

4. На интерфейсе влан включается в ARP - Reply only.

5. Настраивается DHCP сервер на влане с одним адресом в пуле - 10.10.10.10. Настраиваете выдачу статических ARP записей при выдаче адреса. Клиент руками адрес не сможет поставить.

 

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

 

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

[wtyd]

И? Если у вас будет vlan-per-user, то чужие арпы к вам лететь не будут при включенном proxy-arp

 

не будут, я это как пример построения сети привёл -- для некоторых и так нормально типа :-).

[wtyd]

Если у вас схема влан на клиента то делается следующее:

 

1. Создается влан.

2. Вешается на него адрес, например 10.0.0.1/8.

3. Прописывается маршрут, что адрес абонента, например 10.10.10.10/32 находится на интерфейсе влан.

4. На интерфейсе влан включается в ARP - Reply only.

5. Настраивается DHCP сервер на влане с одним адресом в пуле - 10.10.10.10. Настраиваете выдачу статических ARP записей при выдаче адреса. Клиент руками адрес не сможет поставить.

 

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

 

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

 

Вообще у нас пока классическая схема применяется (одна подсеть на один влан без всяких методов типа прокси-арп). В качестве перспективы я пока что рассматриваю vlan per switch с изоляцией портов (или без изоляции портов, пока не решил). L3 свич должен будет делать ip unnumbered с этой кучкой вланов-пер-свич, а так же proxy-arp. Интерес у меня пока только теоретический и исследовательский, просто для более глубокого понимания.

 

Кстати, а почему абоненты не будут видеть соседей ? прокси-апр же будет отвечать каждому юникастом, что "запрашиваемый адрес это я", т.е. роутер, чтобы всё пошло через роутер.

 

Про статический арп тоже не понял. Это при выдаче адреса надо делать статическую арп запись на роутере ? Или вы что-то другое имели ввиду ?

[kayot]

wtyd

Не пытайтесь понять, он бред какой-то написал.

 

/32 мы тоже пробовали выдавать, и с ним есть проблемы. Виндам всех видов все равно, что не выдавай - работает. Даже с пустым шлюзом или с "gw=client IP" :)

Хуже с линуксами, роутерами и различными STB, помучались немного и сделали нормально с большими масками, и uunumbered+proxy arp.

[NiTr0]

Дело в том, что ... даже в классической схеме организации сети работает не 100% подключаемых устройств :-). По разным причинам, приходится техподдержке вмешиваться. Т.е. проблемы были, есть и будут всегда

Дело в том, что обычные проблемы решаемые. Проблема с нежеланием работать с маской /32 - нерешаемая в принципе. На производителя вы не повлияете. А какой-то упоротый владелец роутера RT-N10E "Enterprise" (ибо продаван ему так расшифровал букву Е) весь моск выест, потом пойдет к конкуренту (у которго все внезапно работает искаропки), и будет поливать вас оттуда фекалиями...

 

Пример dhcpd.conf можно с 0.0.0.0 и прочими плюшками ? Что за опции dhcp такие ?

dhcp ms-static-route и тп., шлюз для маршрута на dgw указываете 0.0.0.0 и все...

[Saab95]

Если у вас схема влан на клиента то делается следующее:

 

1. Создается влан.

2. Вешается на него адрес, например 10.0.0.1/8.

3. Прописывается маршрут, что адрес абонента, например 10.10.10.10/32 находится на интерфейсе влан.

4. На интерфейсе влан включается в ARP - Reply only.

5. Настраивается DHCP сервер на влане с одним адресом в пуле - 10.10.10.10. Настраиваете выдачу статических ARP записей при выдаче адреса. Клиент руками адрес не сможет поставить.

 

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

 

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

 

Вообще у нас пока классическая схема применяется (одна подсеть на один влан без всяких методов типа прокси-арп). В качестве перспективы я пока что рассматриваю vlan per switch с изоляцией портов (или без изоляции портов, пока не решил). L3 свич должен будет делать ip unnumbered с этой кучкой вланов-пер-свич, а так же proxy-arp. Интерес у меня пока только теоретический и исследовательский, просто для более глубокого понимания.

 

Кстати, а почему абоненты не будут видеть соседей ? прокси-апр же будет отвечать каждому юникастом, что "запрашиваемый адрес это я", т.е. роутер, чтобы всё пошло через роутер.

 

Про статический арп тоже не понял. Это при выдаче адреса надо делать статическую арп запись на роутере ? Или вы что-то другое имели ввиду ?

 

Прочитайте внимательнее что я написал. У всех клиентов получается одна подсеть, и когда он отправляет запрос соседу, он идет прямо ему, а не на адрес роутера, поэтому данные не будут доставлены. Статическая ARP запись позволяет защититься от установки адреса абонентом вручную, то есть если ему адрес автоматом сервер не выдаст, то он работать не сможет.

 

В моей схеме прокси-АРП не используется, все абоненты изолированы друг от друга.

 

wtyd

Не пытайтесь понять, он бред какой-то написал.

 

/32 мы тоже пробовали выдавать, и с ним есть проблемы. Виндам всех видов все равно, что не выдавай - работает. Даже с пустым шлюзом или с "gw=client IP" :)

Хуже с линуксами, роутерами и различными STB, помучались немного и сделали нормально с большими масками, и uunumbered+proxy arp.

 

Это не бред а вполне рабочая схема. Т.к. ничего лучше и проще придумать нельзя.

[s.lobanov]

В моей схеме прокси-АРП не используется, все абоненты изолированы друг от друга.

 

 

Если выдаёте реальники, то так делать нельзя, обязательно найдётся какой-нибудь клиент, который vpn поверх интернета поднимает. Если же выдаёте серые адреса, то можно вообще без unnumbered обходится, а тупо выдать /30(ну или /29 или типа того)

[Saab95]

В моей схеме прокси-АРП не используется, все абоненты изолированы друг от друга.

 

 

Если выдаёте реальники, то так делать нельзя, обязательно найдётся какой-нибудь клиент, который vpn поверх интернета поднимает. Если же выдаёте серые адреса, то можно вообще без unnumbered обходится, а тупо выдать /30(ну или /29 или типа того)

 

В моей схеме нет проблем с реальниками, есть только проблема с тем, что абоненты не могут общаться между собой, т.к. получают маску, допустим 24, и запрос с адреса 10.10.10.10 на адрес 10.10.10.11 не проходит, потому что клиент считает что этот адрес находится напрямую в сети, а не за шлюзом. На все другие адреса доступ без проблем, т.к. данные идут через шлюз.

[s.lobanov]

В моей схеме нет проблем с реальниками, есть только проблема с тем, что абоненты не могут общаться между собой, т.к. получают маску, допустим 24, и запрос с адреса 10.10.10.10 на адрес 10.10.10.11 не проходит, потому что клиент считает что этот адрес находится напрямую в сети, а не за шлюзом. На все другие адреса доступ без проблем, т.к. данные идут через шлюз.

 

Да, я это прекрасно понимаю и это жирный минус в вашей схеме. L2-изоляция это нормально. Отсутсвие L3-связности с соседним абонентом это недоинтернет какой-то

[DVM-Avgoor]

Снизить АРП - бейте меньше чем /24.

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

 

Большинству пользователей L2/3 изоляция только на пользу, меньше рученки чешутся. Наш профиль трафика таков, что локального обмена практически нет, все заменяет инет и город.

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

[andryas]

Наименее геморойная схема в плане совместимости с оборудованием - vlan на свитч. Правда подсетей немеряно много.

[kayot]

andryas

С какой такой радости? Vlan per user дает все то же, только на доступ можно ставить любую порнографию. Ну и изоляция клиентов железная.

[Ivan_83]

Снизить АРП - бейте меньше чем /24.

Чушь.

Арп летает броадкастом, и ему по барабану какие вы там IP/mask нарисовали, всё равно его все будут получать, даже из других подсетей.

Только L2 сегментирование меняет ситуацию.

[andryas]

С какой такой радости? Vlan per user дает все то же, только на доступ можно ставить любую порнографию. Ну и изоляция клиентов железная.

 

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

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

[Diamont]

С какой такой радости? Vlan per user дает все то же, только на доступ можно ставить любую порнографию. Ну и изоляция клиентов железная.

 

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

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

ТС хочет влан на юзера без проксиарп:

 

В свете схемы vlan per user

[DVM-Avgoor]

Чушь.

 

Хер.

Я могу ровно так же ответить.

Основной источник арп - запросы пользователей. По поводу и без. При одном и том же л2 домене использование одной /21 вместо кучки /24 дает хорошую арп-нагрузку. Широкая маска тут во вред.

 

Только L2 сегментирование меняет ситуацию.

 

Вы курсы для дошкольников решили открыть? :)

Если вы повешаете /22 на ХХХХ вланов, весь арп будет лезть через ваш л3 прокси-арп. А меньше его не станет - причина в широкой маске у клиента.

[wtyd]

Я вообще-то думал, что мне дадут 3-4 ответа, а тут уже вторая страница пошла :-).

 

"В свете схемы vlan-per-user" -- это я имел ввиду современную тенденцию, т.е. сейчас стало модно и появилась возможность делать L2 изоляцию юзеров друг от друга. Но это же не только именно vlan-per-user, есть ещё private-vlans, где можно делать vlan-per-switch и на L3 включать local-proxy-arp. Пока что мне именно vlan-per-switch нравится больше как более компромиссное решение. Ну ещё РРРоЕ никто не отменял, но тут речь не об этом.

 

На счёт арп активности: действительно, чем длинее префикс, тем меньше арп-запросов будет слать клиент, т.к. при этом будет всё больше трафика, который он будет слать через шлюз. именно поэтому и возник вопрос "как правильно заставить работать клиентское оборудование с маской /32", чтобы клиентское оборудование без вопросов всегда слало весь травик через L3, всёравно ж в схеме vlan-per-user равно как и в vlan-per-switch+private-vlan только так и можно слать трафик. Выходит, что /32 в широкие массы внедрить нельзя, можно только прецизионными настройками, но кто это будет делать ? Т.е. идеал снова недостижим. Выходит, что какой-то прокси-арп всё же придётся включать, при этом желательно маску клиенту выдавать меньше (длинее префикс), чтобы было меньше арп запросов. Тут уж каждый сам решает какую именно.

 

Тут ещё одна идея появилась по поводу снижения арп-трафика: у цыски умолчальный арп-таймаут 4 часа что ли, у линукса несколько параметров от 30 до 60 секунд и ещё алгоритм посылания запросов, у винды что-то тоже десятками секунд измеряется и зависит от версии винды. Нашёл опцию для dhcpd.conf option arp-cache-timeout, но для линукса никакого эффекта эта опция не возымела, на винде проверить пока не могу ввиду отсутствия последней :-). Я понимаю, что умолчальные параметры таймаутов взяты не с потолка и что менять их лучше не нужно, но в ситуации, когда оборудование меняется крайне редко можно попробовать увеличить таймаут на стороне клиента до 5-10 минут.

 

Вопрос: как это сделать с помощью dhcpd, если вообще возможно ? В основном клиенты используют творение редмонда, вдруг есть какая-то ms-option, которая именно это и делает ?

 

P.S. А ещё хочу IPv6 отключать в винде опциями dhcp типа как можно отключать NetBIOS, возможно ли ? Как ?

[DVM-Avgoor]

Тут ещё одна идея появилась по поводу снижения арп-трафика

 

Вы сами то хоть пробовали то что рассказываете?

 

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