[srg555]

martin74

Скорее всего, я ошибся в сообщении #3749. Ситуация ACK, NAK возникает при L3-connected, когда есть релей, который всегда шлёт на оба сервера. Вообщем нужно перепроверять. В случае двух L2-connected accel-ppp там вроде что-то другое происходит

[xeb]

Вот это у меня пока и одно из препятствий на пути внедрения IPoE. Я не могу придумать, как его корректно сбалансировать на несколько брасов ;)

могу предложить Offer-delay в зависимости от кол-ва абонов, на подобии PADO-delay для pppoe

[martin74]

srg555, мои dhcp сервера сейчас работают в L3-connected, через relay на узлах доступа

[NiTr0]

внимание вопрос - а почему второй nak отправит то?

Если сервер авторитативный - он отправляет NAK неведомому клиенту.

[martin74]

Ээээ. А что в вашем понимании неведомый клиент?

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

Незарегистрированный клиент - у меня получает адрес из специального диапазона в каждой подсети. Вот тут теоретически возможна ситуация, когда два сервера выдадут разные адреса. Но так почему то не происходит ;) Почему - не смотрел, но у меня впечатление, что isc-dhcp смотрит и на ответные пакеты, которые посылаются другими серверами. Могу ошибаться.

 

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

[xeb]

второй сервер NAK'ом отвечать не будет, клиент делает Request к конкретному серверу, хоть и бродкастом, чтобы остальные знали

[srg555]

второй сервер NAK'ом отвечать не будет, клиент делает Request к конкретному серверу, хоть и бродкастом, чтобы остальные знали

 

А через relay?

[NiTr0]

Ээээ. А что в вашем понимании неведомый клиент?

...

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

Если этого диапазона нет (т.е. 100% статика) - тогда на DHCPDISCOVER (если память не изменяет) ISC DHCPD ответит NAK.

 

 

второй сервер NAK'ом отвечать не будет, клиент делает Request к конкретному серверу, хоть и бродкастом, чтобы остальные знали

У меня подобное случилось пару лет назад, когда дома у себя поднял тестовый тазик-роутер, на котором не погасил рилей. Тазик смотрел вланом в служебную подсеть, а голым интерфейсом (с левой подсетью) - в локалку. В сегменте соответственно было 2 рилея. Сервер - ISC DHCPD. К серверу приходило 2 запроса от одного и того же клиента, через 2 рилея - один с корректным giaddr, второй - с неведомым. На первый запрос сервер отвечал, второй - отвергал NAK'ом. Итог - никто в подсети не мог получить DHCP адрес. И, если память не подводит, лиза выдавалась, потом дропалась, потом опять выдавалась и так по кругу.

Тогда как-то такое поведение было не сильно интересно, посмотрел, поудивлялся и пофиксил, погасив рилей. А вот для IPoE инициировать окончание лизы было бы интересно.

Попробую смоделировать ситуацию на стенде, может и получится, посмотрю дамп пакетов...

[xeb]

второй сервер NAK'ом отвечать не будет, клиент делает Request к конкретному серверу, хоть и бродкастом, чтобы остальные знали

 

А через relay?

через релей зависит от реализации, второй запрос надо либо проигнорировать, либо ответить DHCPACK, видимо у isc-dhcp с этим проблемы

в случае accel-ppp, если он является релеем, то никаких проблем не будет, т.к. он в ответе клиенту подставит свой Server-ID, и клиент сделает запрос к нему

поэтому, как я уже писал выше, если ввести задержку ответа на DHCPDISCOVER, можно относительно равномерно распределять клиентов на два и более серверов

 

Если этого диапазона нет (т.е. 100% статика) - тогда на DHCPDISCOVER (если память не изменяет) ISC DHCPD ответит NAK.

на DHCPDISCOVER ответ может быть только DHCPOFFER

Изменено 24 июля, 2013 пользователем xeb

[nik247]

В последних коммитах xeb пофиксил утечку памяти по ipoe.

Может кто-то присоединится к проверке по утечке памяти?

Предварительно течь перестало.

[NiTr0]

на DHCPDISCOVER ответ может быть только DHCPOFFER

По стандарту - да, но тогда бы не было ситуевины описанной выше.

В общем, соберу стенд, посмотрю.

[kayot]

В свежей версии что-то сломалось. Маршруты аццель разучился удалять.

[2013-07-25 21:46:38]:  info: bond1.999.2007: 999.2007: authentication succeeded
[2013-07-25 21:46:38]:  info: bond1.999.2007: ipoe: session started
[2013-07-25 21:47:44]:  info: bond1.999.2007: ipoe: session finished
[2013-07-25 21:47:44]: error: libnetlink: RTNETLINK answers: No such process
[2013-07-25 21:47:44]:  warn: bond1.999.2007: ipoe: failed to delete route from interface 'bond1.999.2007'
2013-07-25 21:49:09]:  info: bond1.999.2007: 999.2007: authentication succeeded
[2013-07-25 21:49:09]: error: libnetlink: RTNETLINK answers: File exists
[2013-07-25 21:49:09]:  warn: bond1.999.2007: ipoe: failed to add route to interface 'bond1.999.2007'
[2013-07-25 21:49:09]:  info: bond1.999.2007: ipoe: session started

Тут я работающему клиенту сделал accel-cmd terminate ip xx.xx.xx.xx, сессия умерла но маршрут остался. Так же происходит и при shutdown, на каждого клиента лезут варнинги и маршруты остаются в системе.

 

Раньше маршруты в системе выглядели так

194.12.94.2 dev bond1.999.2002 scope link src 10.200.0.100

Сейчас так

194.12.94.2 dev bond1.999.2002 proto none scope link src 10.200.0.100

 

Пока откатился на старую версию, proxy-arp нормально потестить не удалось.

Изменено 25 июля, 2013 пользователем kayot

[nik247]

to kayot

Подобных ошибок нету. Но я использую только shared vlan.

По мотивам http://forum.nag.ru/forum/index.php?showtopic=45266&view=findpost&p=848704.

Прописано?

[ipoe]

proto=100

У меня маршруты выглядят по старому:

10.102.133.4 dev vlan133.ipoe2 proto kernel scope link src 10.102.133.1

10.102.133.5 dev vlan133.ipoe3 proto kernel scope link src 10.102.133.1

10.102.133.6 dev vlan133.ipoe4 proto kernel scope link src 10.102.133.1

10.102.133.7 dev vlan133.ipoe5 proto kernel scope link src 10.102.133.1

10.102.134.3 dev vlan134.ipoe2 proto kernel scope link src 10.102.134.1

Изменено 25 июля, 2013 пользователем nik247

[kayot]

Так, с маршрутами разобрался. Ошибка возникает из-за новой опции proto в конфиге. Возможность указания типа для маршрутов в принципе удобна, но с багом.

В функции route_add переменная из конфига используется, а в route_delete - жестко стоит старая константа RTPROT_BOOT. По умолчанию при отсутствии переменной в конфиге используется proto=0(RTPROT_UNSPEC), и он не совпадает с RTPROT_BOOT=3.

 

nik247

Не, не. Оно не может работать правильно. У тебя с shared vlan оно просто не используется.

Изменено 25 июля, 2013 пользователем kayot

[nik247]

Так, с маршрутами разобрался. Ошибка возникает из-за новой опции proto в конфиге. Возможность указания типа для маршрутов в принципе удобна, но с багом.

В функции route_add переменная из конфига используется, а в route_delete - жестко стоит старая константа RTPROT_BOOT. По умолчанию при отсутствии переменной в конфиге используется proto=0(RTPROT_UNSPEC), и он не совпадает с RTPROT_BOOT=3.

 

nik247

Не, не. Оно не может работать правильно. У тебя с shared vlan оно просто не используется.

Тогда xeb надо маяковать - пусть исправит.

[xeb]

исправил

[kayot]

Маршруты работают, отличное изменение.

[root@ipoe1 etc]# cat /etc/iproute2/rt_protos
# accel ipoe
100     accel/ipoe

[root@ipoe1 etc]# ip r show
194.12.94.6 dev bond1.999.2006  proto accel/ipoe  scope link  src 10.200.0.100
194.12.94.7 dev bond1.999.2007  proto accel/ipoe  scope link  src 10.200.0.100
194.12.94.8 dev bond1.999.2008  proto accel/ipoe  scope link  src 10.200.0.100

[kayot]

В аццеле запилена собственная реализация proxy-arp, независимая от ядерной, я правильно понял?

После отключения системной и добавления в конфиг proxy-arp=2 похоже все работает правильно, меж-клиентский трафик есть, проблем с gratuitous-arp нету.

[xeb]

В аццеле запилена собственная реализация proxy-arp, независимая от ядерной, я правильно понял?

да

[kayot]

Надо это где-то описать и жирным шрифтом указать на необходимость выключать системный proxy_arp, зуб даю 99% пользователей этого не поймут и будут говорить что опция не работает :)

[srg555]

kayot

во всех линукс-дистрах что я видел, он выключен по умолчанию

[xeb]

я думаю это можно в прогу закатать

 

хотя если /proc/sys/net/ipv4/conf/all/proxy_arp = 1 не поможет...

 

пока словами написал https://sourceforge.net/apps/trac/accel-ppp/wiki/IPoE_ru

[kayot]

srg555

По умолчанию да, но для vlan-per-user его первым делом включают, я думал эта опция просто как-то на системную влияет.

 

Я не совсем понял смысл proxy-arp=2 и не вижу каких-либо отличий в работе от proxy-arp=1. И в том и другом случае аццель отвечает маком шлюза.

Если будет ответ маком шлюза из сессии - прокси ж вообще работать не будет. А режим opt=1 когда accel не отвечает(хоть он сейчас и отвечает всегда) не имеет смысла, то же самое что и просто opt=0 или без опции.

 

 

all/proxy_arp на уже поднятые интерфейсы не влияет, как и default. Но это в принципе к accel не относится, выключить или включить всегда можно.

Изменено 26 июля, 2013 пользователем kayot

[xeb]

при vlan-per-user разницы между proxy-arp=1 и 2 не будет

смысл proxy-arp=2 в том, что сервер отвечает маком клиента, при условии что этот клиент находится на том-же интерфейсе (shared-vlan), что, собственно, и сам клиент может сделать, так что этот режим видимо в реальной жизни не пригодится

[kayot]

Неанонсированное изменение, при старте убирающее proxy_arp с интерфейсов работает, проверено :)