Вопрос по работе версии 1.11.1 с nat = 1
Posted: 22 Jan 2017, 12:11
Проблема - пытаюсь обновить систему до новой версии, не выходит добиться работы.
Ядро 3.14.79 x86_64. Accel-ppp и модуль собирал из текущего гита. Конфиг (ipoe):
Таблица маршрутизации до инициирования сессии клиентом:
Инициирую сессию. Сессия поднялась. При этом радиус дал адрес для внешки(172.11.27.131).
В системе маршрут присутствует:
На созданном интерфейсе адреса расположились так:
А теперь смотрим в qugga и получаем странности:
Квагга видит только 10.3.0.128 (адрес клиента в локалке), видимо, последний добавленный на интерфейс.
И вот здесь и возникает проблема. Если НАСов только 1 и все идет на него, или пулы привязаны жестко по НАСам,
то проблема не возникнет. А при общем пуле, BGP-бордер по ospf (как и по прочим динамическим) не увидит
маршрут до конкретного абона по его внешнему адресу. Вместо этого в ospf улетает локальный адрес абона (10.3.0.128), а лучше или оба или внешку.....
Помучил quagga, поставил последнюю quagga-1.1.0. Без результатов. Видимо тип интерфейса POINTOPOINT влияет на работу с ним.
Поковырявшись, получилось сделать так (костыль, конечно):
Маршрут появился в квагге:
Теперь главный вопрос - куда копать при NAT=1? Это баг или фича?
Возможно ли изменить порядок добавления адресов на интерфейс ipoe при NAT=1,чтобы полученный от радиуса добавлялся последним?
В логе есть ошибки-предупреждения при старте, но не понимаю, критичны ли они и из-за чего возникают.Вот лог:
Ядро 3.14.79 x86_64. Accel-ppp и модуль собирал из текущего гита. Конфиг (ipoe):
Спойлер
Спойлер
В системе маршрут присутствует:
Спойлер
Спойлер
Code: Select all
# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel,
> - selected route, * - FIB route
S>* 10.0.0.0/8 [254/0] is directly connected, Null0, bh
K>* 10.3.0.0/16 via 10.3.1.1, eth0
C>* 10.3.0.0/23 is directly connected, eth0
C>* 10.3.0.128/32 is directly connected, ipoe0
C>* 172.11.24.0/26 is directly connected, eth1
C>* 127.0.0.0/8 is directly connected, lo
И вот здесь и возникает проблема. Если НАСов только 1 и все идет на него, или пулы привязаны жестко по НАСам,
то проблема не возникнет. А при общем пуле, BGP-бордер по ospf (как и по прочим динамическим) не увидит
маршрут до конкретного абона по его внешнему адресу. Вместо этого в ospf улетает локальный адрес абона (10.3.0.128), а лучше или оба или внешку.....
Помучил quagga, поставил последнюю quagga-1.1.0. Без результатов. Видимо тип интерфейса POINTOPOINT влияет на работу с ним.
Поковырявшись, получилось сделать так (костыль, конечно):
Code: Select all
ip a re 172.2.2.1/32 peer 172.11.27.131 dev ipoe0
Code: Select all
sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel,
> - selected route, * - FIB route
S>* 10.0.0.0/8 [254/0] is directly connected, Null0, bh
K>* 10.3.0.0/16 via 10.3.1.1, eth0
C>* 10.3.0.0/23 is directly connected, eth0
C>* 172.11.24.0/26 is directly connected, eth1
C>* 172.11.27.131/32 is directly connected, ipoe0
C>* 127.0.0.0/8 is directly connected, lo
Возможно ли изменить порядок добавления адресов на интерфейс ipoe при NAT=1,чтобы полученный от радиуса добавлялся последним?
В логе есть ошибки-предупреждения при старте, но не понимаю, критичны ли они и из-за чего возникают.Вот лог:
Спойлер