DIR-300 и DIR-320 не работают в IPoE (accel-ppp)

[AlKov]

Занялись переводом абонентов с PPPoE на IPoE. В качестве NAS используется accel-ppp, QinQ, ip-unnumbered.

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

Выглядит так - роутер IP и DNS получает, "соединение" поднимается и всё.. С "локалки" никуда не ходит, от слова "вообще".

tcpdump на интерфейсе NAS-а показывает глухой ноль.. Т.е. выглядит так, как будто роутер всё, что предназначено "во внешку", тупо гонит в null.

На TpLink, Zyxel и Asus таких проблем не наблюдается.

Прошу "помощь зала"..

[alibek]

IPoE — в смысле DHCP IPoE?

Я бы начал с проверки опций.

[AlKov]

21 минуту назад, alibek сказал:

IPoE — в смысле DHCP IPoE?

Я бы начал с проверки опций.

Каких опций  и где?

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

Т.е. роутер считает, что раз у него "Dynamic IP", то значит должна быть подсеть, т.е. минимум /30.

Если это так, то "пилюли" походу не существует..

Но непонятно тогда, почему же другие жрут это на ура?

[Totoshka]

16 минут назад, AlKov сказал:

Каких опций  и где?

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

Т.е. роутер считает, что раз у него "Dynamik IP", то значит должна быть подсеть, т.е. минимум /30.

Если это так, то "пилюли" походу не существует..

Речь была об опциях DHCP, насколько понимаю.

Мне отчего то казалось что IP источника (wan) и IP шлюза (default gateway) обязаны быть в одной подсетке иначе ничего дальше этой подсети не уйдёт.

 

[AlKov]

9 минут назад, Totoshka сказал:

Речь была об опциях DHCP, насколько понимаю.

Мне отчего то казалось что IP источника (wan) и IP шлюза (default gateway) обязаны быть в одной подсетке иначе ничего дальше этой подсети не уйдёт.

 

И? Что из этого следует?

P.S. Не забываем про успешно работающие тплинки, зюксели, асусы..

[alibek]

Предположу, что видимо они умеют роутить на интерфейс, а D-Link только на IP.

[AlKov]

7 минут назад, alibek сказал:

Предположу, что видимо они умеют роутить на интерфейс, а D-Link только на IP.

Похоже, что так оно и есть..

И какие могут быть варианты?

Уродовать accel, пытаясь выдавать IP с "мелкой" маской (/16, /22 и т.п.), вопреки "канонам" ip-unnumbered?

Не уверен, что оно вообще получится..

[alibek]

Выкинуть D-Link?

Ну или хотя бы перешить их в dd-wrt.

 

А вообще шлюз за пределами подсети считается некошерно, лучше так не делать.

Ведь по IPoE серые адреса раздаются? Раздавайте /27, всем будет проще.

[ShyLion]

6 minutes ago, AlKov said:

Похоже, что так оно и есть..

И какие могут быть варианты?

Уродовать accel, пытаясь выдавать IP с "мелкой" маской (/16, /22 и т.п.), вопреки "канонам" ip-unnumbered?

Не уверен, что оно вообще получится..

По "канонам" IPoE клиенту таки дается нормальная маска и шлюз в пределах сети, а никак не /32. Это же не PPP.

А для работы между абонентами используется Local-Proxy-ARP.

То что "другие же работают" - это скорее баг а не фича.

Вы хотите починить то что не ломалось.

[AlKov]

4 минуты назад, alibek сказал:

Выкинуть D-Link?

Ну или хотя бы перешить их в dd-wrt.

 

А вообще шлюз за пределами подсети считается некошерно, лучше так не делать.

Ведь по IPoE серые адреса раздаются? Раздавайте /27, всем будет проще.

Вариант №1 сложен в реализации, т.к. объяснить абоненту - у которого всё работало "до того как" - практически невозможно..

Вариант №2 можно попробовать, но учитывая п. №1, придётся делать это собственными силами.

 

А почему именно /27? Может уж тогда /30? И как это реализовать в accel, скрестив сиё с ip-unnumbered?

Оно вообще возможно??

[alibek]

Не обязательно именно /27, можно и чуть поуже маску, но больше, чем /30.

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

[Ivan_83]

1 час назад, AlKov сказал:

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

Отдайте ему в опциях маршрут до шлюза через выданный IP адрес.

[AlKov]

7 минут назад, Ivan_83 сказал:

Отдайте ему в опциях маршрут до шлюза через выданный IP адрес.

А как это реализовать в accel?

Может отдавать радиусом? Только каким атрибутом?

[kayot]

1 час назад, AlKov сказал:

У меня пока такое предположение, что железку заводит в ступор маска /32 на WAN интерфейсе

Это даже не предположение, это истина.

Странно что только с длинками напоролись - когда мы внедряли лет 5 назад вообще кроме винды ничего не работало в таком режиме. Такая схема нарушает все принципы маршрутизации.

Выдавайте большую маску(реальную), и реальный шлюз из этой подсети. На аццеле включите proxy-arp что б клиенты друг друга видели, все по мануалу из Вики accel-pppd.

[DRiVen]

44 минуты назад, AlKov сказал:

А почему именно /27? Может уж тогда /30?

Нахрена? Если межабонентский L2 изолирован - хоть /8 отдавайте, тут уж исходя из распределения пулов между BRAS.

 

7 минут назад, kayot сказал:

Выдавайте большую маску(реальную), и реальный шлюз из этой подсети.

+1

[AlKov]

22 минуты назад, kayot сказал:

Это даже не предположение, это истина.

Странно что только с длинками напоролись - когда мы внедряли лет 5 назад вообще кроме винды ничего не работало в таком режиме. Такая схема нарушает все принципы маршрутизации.

Выдавайте большую маску(реальную), и реальный шлюз из этой подсети. На аццеле включите proxy-arp что б клиенты друг друга видели, все по мануалу из Вики accel-pppd.

Так.. 

1. С маской понятно - отдам радиус-атрибутом Framed-IP-Netmask

2. Шлюз отдаёт аццел, но сейчас без маски. Добавить?

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

4. Что делать с ip-unnumbered в данном случае? Убрать?

[kayot]

@AlKov 

1,2. Маску и сам аццель выдает без радиуса. Добавите в конфиг запись вида gateway=xx.xx.xx.xx/yy(точно синтаксис не помню), тут и маска для нужного блока задается и шлюз.

3. Если межабонентский трафик не нужен - не добавляйте. Сейчас с /32 он у вас есть через БРАС, включение proxy arp даст тот же функционал. Без него абоненты не увидят друг друга по L3.

[Ivan_83]

1 час назад, AlKov сказал:

А как это реализовать в accel?

Может отдавать радиусом? Только каким атрибутом?

Без понятия как там в акеле, я такое бы легко сделал и на фрирадиусе в его костыльном дхцп, прямо на уровне анленга походу, или в своём перловом дхцп сервере - пара строк кода.

 

1 час назад, kayot сказал:

Странно что только с длинками напоролись - когда мы внедряли лет 5 назад вообще кроме винды ничего не работало в таком режиме. Такая схема нарушает все принципы маршрутизации.

Просто вендоры походу подложили костыли уже в дхцп клиента.

То что выдаётся маска /32 ничего не нарушает, не надо выдумывать.

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

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

 

Когда ты пишешь: route add 8.8.8.8/32 192.168.0.1

при этом у тебя на одном интерфейсе уже 192.168.0.1 адрес стоит то это оно и есть.

 

Касательно венды.

Там одна рамка объединяет и IP адрес с маской и шлюз. Да. Но это не значит что шлюз должен быть из этой сети.

 

52 минуты назад, AlKov сказал:

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

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

На основании какого решения суда им запрещён доступ к этим адресам?

 

52 минуты назад, AlKov сказал:

4. Что делать с ip-unnumbered в данном случае? Убрать?

Донастроить.

[NiTr0]

4 часа назад, AlKov сказал:

Если это так, то "пилюли" походу не существует..

существует. роут на шлюз через 0.0.0.0. но не на всех роутерах прокатывает (асусы на реалтеках к примеру не переваривают).

 

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

[kayot]

1 час назад, Ivan_83 сказал:

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

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

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

Пытаться достучаться к левому шлюзу просто отсылая пакеты на WAN мягко говоря странно, повторюсь, 5 лет назад кроме винды вообще ничего не работало в таком режиме. Мандрива настольная и первый взятый роутер тп-линк не завелись, на этом мы подобные эксперементы прекратили.

Кроме жажды приключений и научной ценности попытка эмулировать PPP с его /32 смысла не имеет..

[AlKov]

@kayot , да, добавил маску в конфиге accel  - gw-ip-address=172.16.0.1/12 - всё взлетело. Но.. Такое ощущение, что сделал костыль..

Я более согласен с @Ivan_83 -

1 час назад, Ivan_83 сказал:

Просто вендоры походу подложили костыли уже в дхцп клиента.

То что выдаётся маска /32 ничего не нарушает, не надо выдумывать.

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

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

 

Когда ты пишешь: route add 8.8.8.8/32 192.168.0.1

при этом у тебя на одном интерфейсе уже 192.168.0.1 адрес стоит то это оно и есть.

 

Касательно венды.

Там одна рамка объединяет и IP адрес с маской и шлюз. Да. Но это не значит что шлюз должен быть из этой сети.

 

Опять же, возвращаясь к "классике циско жанра" - как бы повели себя эти дилинки в этом случае?

 

@Ivan_83 

1 час назад, Ivan_83 сказал:

2 часа назад, AlKov сказал:

4. Что делать с ip-unnumbered в данном случае? Убрать?

Донастроить.

А что конкретно входит в "донастроить"?

 

P.S.

1 час назад, Ivan_83 сказал:

2 часа назад, AlKov сказал:

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

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

На основании какого решения суда им запрещён доступ к этим адресам?

Ну, например, это не запрещают, но и не разрешают условия договора, где сказано, что абоненту предоставляется "доступ в сеть Интернет".

И к тому же хотелки "междусобойчика" уже давно не имеют спроса. Так-что.. Ну вообщем, понятно - что.. :)

[kayot]

1 минуту назад, AlKov сказал:

да, добавил маску в конфиге accel  - gw-ip-address=172.16.0.1/12 - всё взлетело. Но.. Такое ощущение, что сделал костыль..

Наоборот, вы сделали правильный ip unnumbered. Костыли были до этого.

[AlKov]

А на основании конкретно ЧЕГО Вы считаете, что это -

1 минуту назад, kayot сказал:

...попытка эмулировать PPP с его /32 ..

Я извиняюсь за назойливые повторы, но это же явный Cisco ip unnumbered.

Или я ошибаюсь и путаю тёплое с мягким? Поправьте, пожалуйста, если это так.

[Ivan_83]

2 часа назад, AlKov сказал:

Опять же, возвращаясь к "классике циско жанра" - как бы повели себя эти дилинки в этом случае?

Для продолжения гадания на кофейной гуще приложите dhcpdump запроса от них.

 

2 часа назад, AlKov сказал:

А что конкретно входит в "донастроить"?

Я ж выше написал - отдавать им маршрут до шлюза через тот адрес что вы им выдаёте.

 

2 часа назад, AlKov сказал:

Ну, например, это не запрещают, но и не разрешают условия договора, где сказано, что абоненту предоставляется "доступ в сеть Интернет".

Это если абоненты за NAT, а если они с белыми адресами то конективити должно быть.

[NiTr0]

2 часа назад, AlKov сказал:

Я извиняюсь за назойливые повторы, но это же явный Cisco ip unnumbered.

с какой радости? циска что, клиентам /32 выдает?

циска /32 в интерфейс роутит у себя. а не заставляет клиента это делать.

 

а попытка прописать шлюз который физически недоступен - у нормальных *nix осей вызывает непонимание.