LTP 8x rev. C (model 2) IPOE/DHCP-RA

[semop]

Добрый день.

С самого начала запуска в работу станции LTP-8x были вопросы к работе DHCP-RA.
Схема влан-на пользователя. Доступ IPOE.

Настройки релея:

profile dhcp-ra "DHCP-RA_ONT"
enable
overwrite-option82 circuit-id "%PONSERIAL%"
overwrite-option82 remote-id "%MNGIP%"
exit
profile dhcp-ra "DHCP-RA_261"
exit
profile dhcp-ra "DHCP-RA_262"
exit
gpon olt profile dhcpra "DHCP-RA_ONT"
gpon olt profile dhcpra DHCP-RA_261 vid 261
gpon olt profile dhcpra DHCP-RA_262 vid 262

В предполагаемом варианте хотелось с самого начала указать конкретно для каких вланов релеить запросы. Но у LTP ограничение на определенное количество вланов.
Т.е.
gpon olt profile dhcpra DHCP-RA_101 vid 101
gpon olt profile dhcpra DHCP-RA_102 vid 102
.......
gpon olt profile dhcpra DHCP-RA_500 vid 500

я сделать не могу. Ограничение там что-то порядка 20 или 50 вланов. Не помню уже.
============================
В нашем случае:

profile dhcp-ra "DHCP-RA_ONT" - работает для всех ONT
profile dhcp-ra "DHCP-RA_261" и profile dhcp-ra "DHCP-RA_262" - работают для коммутаторов которые живут за NTU-SFP.

На сети работает так же мультикаст и ПД, в своих кокнретных вланах.

Радует что LTP умеет показывать "ARP" таблицу (тут и ACS и реальный АРП и срелеиные IPшники, которые не знаю каким образом появляются у станции в арпе, видимо для информации)
LTP-8X(switch)# sh ip arp ta
VID | IP | MAC | Interface | Lifetime
76 10.44.33.3 A8:F9:4B:74:B8:91 pon-port 5 00:01:03
76 10.44.33.4 A8:F9:4B:74:B1:C5 pon-port 7 00:01:22
76 10.44.33.5 A8:F9:4B:74:B8:49 pon-port 6 00:01:13
76 10.44.33.6 A8:F9:4B:74:B8:5D pon-port 2 00:01:30
76 10.44.33.7 A8:F9:4B:74:B9:DD pon-port 6 00:03:27
76 10.44.33.8 A8:F9:4B:74:B2:3B pon-port 4 00:01:17
76 10.44.33.9 A8:F9:4B:74:B5:01 pon-port 3 00:01:43
76 10.44.33.10 A8:F9:4B:74:B4:89 pon-port 2 00:01:43
76 10.44.33.11 A8:F9:4B:74:B1:8B pon-port 1 00:01:49
76 10.44.33.13 A8:F9:4B:74:B9:FD pon-port 3 00:03:07
76 10.44.33.14 A8:F9:4B:74:B4:81 pon-port 1 00:01:49
76 10.44.33.15 A8:F9:4B:74:BA:31 pon-port 1 00:01:54
76 10.44.33.16 A8:F9:4B:74:BA:19 pon-port 2 00:01:54
76 10.44.33.17 A8:F9:4B:74:B9:F5 pon-port 2 00:01:54
76 10.44.33.18 A8:F9:4B:74:BA:35 pon-port 1 00:04:08
76 10.44.33.19 A8:F9:4B:74:BA:15 pon-port 3 00:01:41
76 10.44.33.20 A8:F9:4B:74:B2:41 pon-port 3 00:01:54
76 10.44.33.21 A8:F9:4B:74:B9:F1 pon-port 6 00:02:16
76 10.44.33.22 A8:F9:4B:74:B8:59 pon-port 0 00:02:16
76 10.44.33.23 A8:F9:4B:74:B4:D5 pon-port 4 00:03:43
76 10.44.33.24 A8:F9:4B:74:B2:15 pon-port 7 00:04:08
76 10.44.33.25 A8:F9:4B:74:B3:F1 pon-port 0 00:02:49
79 10.44.144.29 00:0F:E2:B2:2D:65 front-port 4 00:01:55
100 10.253.0.161 00:24:68:03:86:08 front-port 4 00:04:02
101 х.х.86.245 00:30:88:1D:FE:F8 front-port 4 00:04:11
102 х.х.43.1 00:30:88:1D:FE:F8 front-port 4 00:03:57
102 х.х.43.38 6C:62:6D:80:51:68 pon-port 1 00:03:57
103 х.х.86.1 00:30:88:1D:FE:F8 front-port 4 00:04:10
103 х.х.86.121 E4:18:6B:1A:61:E9 pon-port 1 00:04:10
103 х.х.86.245 00:30:88:1D:FE:F8 front-port 4 00:03:15
104 х.х.40.1 00:30:88:1D:FE:F8 front-port 4 00:04:11

И случилось то, чего я всегда боялся:

от абонентов прилетели запросы DHCP в совершенно не релеющих вланах, которые LTP пропустил.
И получилась такая штука:

76 влан - управление ACS
100 влан - мультикаст

100 х.х.69.158 A8:F9:4B:74:B4:D7 pon-port 4 00:00:47
100 х.х.0.161 00:24:68:03:86:08 front-port 4 00:04:09
100 192.168.21.21 A8:F9:4B:74:BA:33 pon-port 1 00:04:14
76 192.168.2.1 A8:F9:4B:74:BA:21 pon-port 0 00:03:35
100 192.168.21.21 A8:F9:4B:74:BA:23 pon-port 0 00:03:56

Этого физически не должно было получиться, а оно получилось как то)
По итогам в этих вланах начался "DHCP шум", который начал сбрасывать активные сессии у абонентов.

Подозреваю gpon olt profile dhcpra "DHCP-RA_ONT" - абсолютно лоялен к любым DHCP запросам вне зависимости от влана, в котором они пришли и откуда.

Потом в логах вылезло такое:
Feb 1 09:04:51 LTP-8X pmchal: error: [DHCPRA] procmsg: ok/rt/bal/put=14974895/226300/0/0: rate for upstream exceeds the limit..
Feb 1 09:04:54 LTP-8X pmchal: error: [DHCPRA] procmsg: ok/rt/bal/put=14974895/226400/0/0: rate for downstream exceeds the limit..


Эта вся штука "починилсь" перезагрузкой LTP (reboot)
Все восстановилось.
Но через какое то время абоненты опять начали шуметь во вланах управления ACS и мультикаста. Был совершен выезд к одному из абонентов, отключили у него роутер от ONT и подключили напрямую в ПК. Проблема исчезла. Но теперь этот человек работает без роутера, таких людей около десятка (причем есть люди с роутерами но такой проблемы у них нет).

Вопрос.
Как так вообще вышло и как это починить?
И можно ли все-таки расширить диапазон вланов, для которых можно включать DHCP-RA?

ПС:
Поможет ли в этом фильтрация DHCP?
LTP-8X(config-dhcp-ra)("dhcp-ra-01")# trusted primary x.x.x.x
LTP-8X(config-dhcp-ra)("dhcp-ra-01")# trusted secondary y.y.y.y
LTP-8X(config-dhcp-ra)("dhcp-ra-01")# trusted timeout 100
LTP-8X(config-dhcp-ra)("dhcp-ra-01")# trusted
LTP-8X(config-dhcp-ra)("dhcp-ra-01")# do commit

А так же:
ip dhcp relay х.х.х.х
ip dhcp relay y.y.y.y
ip dhcp relay z.z.z.z
ip dhcp relay w.w.w.w
........

В этом случае можно ли указывать более двух серверов? Если это невозможно, то этот вариант фильтрации нам не подходит, тк. у нас их более 2х.

100% поможет указание конкретно вланов для релея (как можно делать на любых L2 коммутаторах доступа). С этого я и начинал, все работало как надо, но позже вланов стало гораздо больше и я уперся в ограничение. В связи с чем убрал из конфига их все, оставив так как написано выше. Но как выяснилось работает оно не очень корректно при таком конфиге.

[Dirks G]

Добрый день.
Отправьте бекап вашей конфигурации и полный лог на почту - techsupp@eltex.nsk.ru

[semop]

Проблема повторяется неоднократно.
Отписался вам на почту.

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

[semop]

И вновь проблема дала о себе знать)
Заметил совпадения за последние 2 мес.

LTP сходит сума первого числа месяца. Это день, когда у людей может быть заблокирован интернет из за отсутствия аб.платы.
Биллинговая система настроена таким образом, что сессию абонент все равно поднимет, но с редиректом и временем жизни lease = 180сек.
После ее истечения - сессия рвется и происходит новое полное DHCP-DISCOVER/REQUEST/и тд.

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

В конфиге LTP:
ip dhcp server lease-time 600

Это минимальное значение, но я думал это распространяется только на локальный DHCP-сервер, который рулит ASC.
Но это похоже неправда, так как lease у внешних IP адресов, которые выдает брас со всеми атрибутами совсем не та, а именно LTP'шная, которые "светит/изучает" станция.

LTP-8X(switch)# sh ip arp ta
VID | IP | MAC | Interface | Lifetime
76 10.44.33.3 A8:F9:4B:74:B8:49 pon-port 6 00:04:15
76 10.44.33.4 A8:F9:4B:74:B4:D5 pon-port 4 00:02:01
...
101 х.х.41.1 02:03:39:04:98:CB front-port 4 00:04:15

Сверху mng IP адреса терминалов, которые они получают честно по DHCP от LTP.
Внизу абонентских хост, которому все выдает брас/биллинг.
Откуда он берет 4 минуты? Вернее я подозреваю откуда, но зачем?
Возможно в этом косяк.
Хотя после перезагрузки все равно lease остаются неактуальными, но зато не происходит рандомный сброс всех сессий у pon-абонентов.

Это можно починить не прибегая к реконфигу биллинга по изменению у ВСЕХ абонентов на сети lease = 600, только ради LTP?

[otis]

LTP 8x rev C (model 2) IPOE/DHCP-RA
LTP8x-C is an enterprise class router featuring 8x10 Gbps FastLane with IPv6, IPv4, Dual Band and PoE. With a powerful CPU and dedicated cryptographic hardware, the LTP 8x rev C supports fnaf advanced security features such as IEEE 802.1AE (802.1AX soon), TCP Segmentation pokedle Offload (TSO), TCP operation state awareness