BiTel

Добрый день, используем биллинг версии 6, модуль inet.

Рассматриваем возможность перехода с пптп/пппое на dhcp раздачу.

BRAS - mikrotik CCR1036-8G-2S
Как должно работать DHCP?
Есть сегмент проводной, где оборудование в большинстве своём умеет dhcp.82 (cisco linksys), то что не умеет заменим. Напрашивается собственно полноценное .82
Есть беспроводной сегмент премущественно на оборудовании Ubiquiti, необходимо авторизовать и их тоже по DHCP.

Про Микротик пишут довольно много, что он то не умеет, другое, третье.

Хотелось бы услышать опыт реализаций полностью или частично наших хотелок и как правильнее это реализовывать, где должен быть DHCP (mikrotik, billing, etc).
Может ли Mikrotik нормально релеить или релеить лучше на свитчах?
Можно ли нормально подружить dhcp микротика по радиусу с биллингом?

И как вообще в биллинге контролировать раздачу по dhcp, в случае c туннелями понятно - видим сессии.

Вместо RoutesOS для NAS смотрите лучше на accel-ppp.
В нем есть и IPoE (shared vlan with opt82, vlan-per-user, QinQ, ip unnumbered) и PPPoE и PPtP.
И все это через радиус c поддержкой CoA/PoD.
В биллинге у Вас будет выглядеть все одниково - что IPoE, что PPPoE(PPtP).
Accel-ppp для DHCP клиентов является DHCP сервером с авторизацией в BG-Inet по радиусу.
Выдачей IP или своего ip-pool (static или Framed-Pool), или динамика от BG-Inet(радиус) или статика от BG-Inet(радиус).
Можно паралельно настроить 2(n) серверов с accel-ppp и получить балансировку по кол-ву клиентов, резервирование для IPoE, PPPoE, PPtP.
Также есть возможность переименовывать интерфейсы - имя формирую в ответе BG-Inet(radius).
Получается, что клиент имеет всегда постоянное имя интерфейса и по нему можно строить графики, чего нелья в RoS (точнее можно, но только он доступен, пока сессия не закончится.)

Как раз таки от тазиков с accel-ppp и ушли в сторону mikrotik.
Нужно сдавать узлы связи, как мы это будем делать с тазиками?

Посему задача остаётся прежней, рассматриваем возможность перехода на DHCP используя BRAS Mikrotik CCCR1036, в том или ином юзкейсе.

Скорее всего можно.

Биллинг создает у себя в БД сессии, аналогично RADIUS, когда выдает ACK, закрывает же сессию по таймауту DHCP-запроса.

Хочу увеличить время на которое выдаются адреса, но чтобы сессии долго не висели.
Думаю эти параметры изменить...
dhcp.renew.option.leaseTime=1800
dhcp.renew.option.renewalTime=900
dhcp.renew.option.rebindingTime=1575
dhcp.option.leaseTime=1800
dhcp.option.renewalTime=900
dhcp.option.rebindingTime=1575

dhcp.connection.closeOnNew=1
connection.close.timeout=1920
connection.finish.timeout=1920

Если я увеличу dhcp.renew.option.leaseTime раза в 2 к примеру и зависящие от нее параметры тоже, а connection.close.timeout, connection.finish.timeout оставлю прежними или уменьшу, чтобы сессии долго не валялись, освобождались адреса...
не получится ли так что сессии начнут разрываться раньше чем нужно, и если получиться, то какие лучше всего выставить тайминги для времени аренды 3600 (1 час), чтобы сессия длилась как можно меньше в отсутствии запросов, но и не разрывалась раньше времени????

connection.close.timeout закрывает сессию, если за это время не было DHCP или RADIUS-пакетов по сессии.
По умолчанию DHCP-клиент должен слать RENEW-пакеты через leaseTime*0.5.
Если на RENEW ответа нет, то клиент переходит в состояние REBIND через leaseTime*0/75 и начинает слать запрос broadcast'ом.
Если ответ на RENEW есть - следующий запрос тоже будет RENEW.

Если RENEW-запросы доходят до биллинга, то теоретически connection.close.timeout должен быть не меньше чем leaseTime*0.5, чтобы сессия постоянно не закрывалась в биллинге.
Если не доходят - то больше чем leaseTime.

Если leaseTime не вышел - клиент считает, что IP его, даже если на RENEW не получает ответа.
Однако если получит NAK на RENEW - вроде как должен попробовать переполучить.

Очень зависит от схемы и оборудования, в том числе у абонента.


Можно также передавать T1 и T2 опции - время, когда DHCP-клиенту перейти в RENEW и когда в REBIND.
dhcp.option.leaseTime=3000
dhcp.option.renewalTime=900
dhcp.option.rebindingTime=1200

В этому случае будет слать RENEW раз в 900 секунд, но если нет ответа - пока не истечет 3000 должен считать, что IP-адрес его.

Получается надо все таки повышать connection.close.timeout, так как когда делали лиз на получасовку, замечали, что у некоторых (немногих) клиентов сессии отваливались раньше, в случае если connection.close.timeout меньше lease. А правильно всех dhcp-клиентов работать не заставишь(

А какая цель? Чтобы реже DHCP шли или чтобы дольше IP оставался у абонента, если DHCP-сервер недоступен?

Цель - чтобы реже dhcp шли. Да, при проблеме с сервером было бы полезно. И чтобы меньше ip-адресов бесполезно висело в сессиях по факту уже не использующихся

Наверно можно попробовать большой leaseTime и небольшие renew и rebind (но тоже от сети и оборудования зависит, будет ли нормально работать у всех):

dhcp.option.leaseTime=7000
dhcp.option.renewalTime=300
dhcp.option.rebindingTime=500

connection.close.timeout=1080

Реже запросы идти не будут, но побыстрее закрываться должно, но при этом, если нет ответа на renew|rebind - IP должен оставаться у абонента на время leaseTime.

Попробую так!

Еще хочу раздать клиентам dhcp option 35, чтобы уменьшить количество arp в сетях от абонентов.
Если сделаю, например, таймаут 5 минут (300), в конфиге устройства:

dhcp.option.35=12C

Так будет правильно? Есть ли какие-нибудь подводные камни?

dhcp.option.35=012C

После чтения документации стало понятно, что можно без проблем на одном устройстве раздавать IP-адреса из двух пулов:

- ip.resource.categoryId - статические адреса,
- dhcp.ipCategories - динамические адреса.

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

- статические белые адреса,
- динамические серые адреса,
- динамические белые адреса.

Как это реализовать? В идеале было бы здорово получить привязку пулов к договору или к сервису.

PS. Сейчас в моей схеме RADIUS не используется.

Сейчас вроде бы нет такого для DHCP.

Пул к договору или сервису - вряд ли. Cтараемся избегать излишней "персональности".

Можем попробовать сделать по аналогии с RADIUS:
https://docs.bitel.ru/pages/viewpage.action?pageId=119505956#id-ПроцессорInetRadiusProcessor-ВыдачаIP-адреса
А в тарифе опцию можно указать в зависимости от группы договора или тарифной опции.

Указал опцию в тарифе. Не работает.



В опции 5 у меня

Сделал похожий тариф для статических адресов с опцией



Тоже не работает. При создании сервиса - сообщение об ошибке "Категория IP-ресурса не найдена!".

Я и написал, что для DHCP в данный момент такого нет, только для RADIUS. Можем сделать по аналогии с RADIUS.

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

Там были слова "вроде бы", вот я и решил попробовать.



Прописал



Всё равно получаю сообщение "Категория IP-ресурса не найдена!".



Ух ты! Нужно! А сколько времени займёт?

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

Нет, никакой возможности выбора нет:



IP-ресурсы:



inet 7.1_587

Ошибся, указывается всегда в конфигурации устройства:
ip.resource.categoryId=3

Но для определенных типов сервиса можно прописать так:
ip.resource.categoryId.1,2,3=3


Может быть дело в том, что сейчас прописали в конфигурации типа сервиса, а не устройства (т.к. я до этого написал, что можно указать там).

Недели две

Да, указывал в типе сервиса. Сейчас прописал для устройства



Так работает. Спасибо.



Буду ждать.

Это в 7.1 будет? Или только в 7.2?

7.1

Отлично. Спасибо.

Выложили обновление.
Не забудьте сделать бэкап старых библиотек.

Спасибо. Проверяю.

Создал опции:

select
  id, title, config
from
  inet_option_1
where
  parentId = 4


id |title                       |config                    |
---|----------------------------|--------------------------|
5  |Статический белый IP-адрес  |ip.resource.categoryId=6¶ |
6  |Динамический белый IP-адрес |dhcp.ipCategories=5¶      |
7  |Статический серый IP-адрес  |ip.resource.categoryId=3¶ |
8  |Динамический серый IP-адрес |dhcp.ipCategories=2¶      |

Создал тариф с одной из опций.

В access-логах вижу:

dhcp 2018-06-19 04:12:50 INFO  [dhcpLstnr-p-10-t-5] InetDhcpProcessor2 - InetServ found: ContractId: 1; status: 0; servId: 2
    Серый динамический адрес, VLAN 104
    Options [] TariffModuleTreeSet [1:19.06.2018-…; ]
    Device state: 1; optionSet:
dhcp 2018-06-19 04:12:50 INFO  [dhcpLstnr-p-10-t-5] InetApplication - contract tariffOptions: {}
dhcp 2018-06-19 04:12:50 INFO  [dhcpLstnr-p-10-t-5] InetApplication - inetServ[id=2] balance ok: 0.00 [0]
dhcp 2018-06-19 04:12:50 INFO  [dhcpLstnr-p-10-t-5] InetApplication - OptionSet: [8]
dhcp 2018-06-19 04:12:50 INFO  [dhcpLstnr-p-10-t-5] InetDhcpProcessor2 - IP not found in service. Searching in device...
dhcp 2018-06-19 04:12:50 INFO  [dhcpLstnr-p-10-t-5] InetDhcpProcessor2 - Free IP-address not found

Видно, что опция пришла. Но IP для отдачи клиенту всё равно не найден. Что я делаю не так?

kernel 7.1.985 / 18.06.2018 19:11:03
inet 7.1.599 / 18.06.2018 19:11:12

Добавил опцию 7 в другой тариф. При создании сервиса получаю сообщение "Категория IP-ресурса не найдена!" (как здесь).

Похоже, в конфигурации NAS нужно написать:

resource.ip.pool.dynamicPrivate.ipCategories=2

А в опции:

dhcp.ipPool=dynamicPrivate

Да, забыл сразу написать.
https://docs.bitel.ru/pages/viewpage.action?pageId=119505964#id-ПроцессорInetDhcpProcessor-ВыдачаIP-адресавзависимостиотопцийInet