не работает lan порт на onu olt bdcom GP3600-16B

[forella 20]

имеется bdcom gp3600-16B c с прошивкой 10.3.0D build 81888, и 2 onu на тест: zte f601 и huawei hg8310m

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

нашел только команду: Switch_config_gpon0/1:1#gpon onu uni 1  noshutdown - не помогаетпрограмно он включен, физические его нет.

Проблема когда назначаешь свой темплейт на gpon порт. на 1 порту проблема есть, на 2 порту с дефолтными настройками все работает как нужно.

 

Switch#show gpon interface gpoN 0/1:1 onu port 1 state
        GPON0/1:1       uni-port 1      up
                        100BASE-T(Unknown)
Switch#show gpon interface gpoN 0/1:2 onu port 1 state
        GPON0/1:2       uni-port 1      up
                        10/100/1000 BASE-T(Unknown)

 

 Switch#show gpon interface gpoN 0/2:1 onu port 1 state
        GPON0/2:1       uni-port 1      up
                        10/100/1000 BASE-T(1Gbps Full-Duplex)
Switch#show gpon interface gpoN 0/2:2 onu port 1 state
        GPON0/2:2       uni-port 1      up
                        100BASE-T(100Mbps Full-Duplex)

 

ниже собствественно конфиг olt:

Current configuration:
!
!version 10.3.0D build 99242
service timestamps log date
service timestamps debug date
logging buffered 100000
!
port-protected 1
!
spanning-tree mode rstp
!
gpon profile onu-rate-limit ratelimit-default id 1
 gpon-profile pir 1244160 cir 1244160
!
gpon profile onu-uni MTU id 2
 gpon-profile max-frame-size 1550
!         
gpon profile onu-uni test id 3
!
gpon profile onu-tcont tcont-default id 1
 gpon-profile tcont-type 3 pir 1024000 cir 512
!
gpon profile onu-virtual-port virtual-port-default id 1
 gpon-profile encryption disable
 gpon-profile upstream queue 8
 gpon-profile downstream queue 8
!
gpon profile onu-tcont-virtual-port-bind tvbind-default id 1
 gpon-profile virtual-port 1 profile virtual-port-default tcont 1 profile tcont-default
!
gpon profile onu-flow-mapping flow-mapping-default id 1
 gpon-profile entry 1 uni type eth-uni all
 gpon-profile entry 1 virtual-port 1
!
gpon profile onu-flow-mapping flow-mapping-default-hgu id 2
 gpon-profile entry 1 uni type veip all
 gpon-profile entry 1 virtual-port 1
!
gpon profile onu-flow-mapping vlan1701 id 3
 gpon-profile entry 1 uni type eth-uni all
 gpon-profile entry 1 vlan 1701
 gpon-profile entry 1 virtual-port 1
!
gpon profile onu-vlan vlan1701 id 3
 gpon-profile vlan mode trunk
 gpon-profile vlan pvid 1701 0
 gpon-profile vlan trunk vlan-allowed 1701
!
!
gpon onutype-template onutype-default-hgu
 gpon-onutype match ctc-onu-type HGU
 gpon-onutype config tcont-virtual-port-bind-profile tvbind-default
 gpon-onutype config flow-mapping-profile flow-mapping-default-hgu
!
gpon onutype-template onutype-default
 gpon-onutype config tcont-virtual-port-bind-profile tvbind-default
 gpon-onutype config flow-mapping-profile flow-mapping-default
!
gpon onu-config-template port1
 cmd-sequence 001 tcont-virtual-port-bind-profile tvbind-default
 cmd-sequence 002 gpon onu flow-mapping-profile vlan1701
 cmd-sequence 003 gpon onu uni 1 vlan-profile vlan1701
 cmd-sequence 004 gpon onu uni 1 uni-profile MTU
 cmd-sequence 005 gpon onu loopback-detect protocol private
 cmd-sequence 006 gpon onu uni 1 loopback-detect enable
!
!
interface Null0
!
interface GigaEthernet0/0
!
!!slot 0 1 GP3600-16B mother card
!
interface TGigaEthernet0/1
 switchport trunk vlan-allowed 1601,1700-1701,2201
 switchport trunk vlan-untagged none
 switchport mode dot1q-tunnel-uplink
 dhcp snooping trust
 storm-control broadcast threshold 5
 storm-control multicast threshold 5
 storm-control unicast threshold 5
!
!
interface GPON0/1
 gpon pre-config-template port1 bind-onuid 1-128
 gpon bind-onutype onutype-default-hgu precedence 127
 gpon bind-onutype onutype-default precedence 128
 filter dhcp
 switchport trunk vlan-allowed 1701
 switchport trunk vlan-untagged none
 switchport mode trunk
 switchport protected 1
 storm-control broadcast threshold 1000
 storm-control multicast threshold 1000
 storm-control unicast threshold 5
!
interface GPON0/2
 gpon bind-onutype onutype-default-hgu precedence 127
 gpon bind-onutype onutype-default precedence 128
 gpon bind-onu sn HWTC:F8AB4A35 1
 gpon bind-onu sn ZTEG:C69C26CC 2
 switchport protected 1
 storm-control broadcast threshold 5
 storm-control multicast threshold 5
 storm-control unicast threshold 5
!
interface GPON0/2:1
 gpon onu model-id HG8310M
 gpon onu tcont-virtual-port-bind-profile tvbind-default
 gpon onu flow-mapping-profile flow-mapping-default
 gpon onu virtual-port 1 gem-port 257
 gpon onu tcont 1 alloc-id 257
!
interface GPON0/2:2
 gpon onu model-id F601V6.0
 gpon onu tcont-virtual-port-bind-profile tvbind-default
 gpon onu flow-mapping-profile flow-mapping-default
 gpon onu virtual-port 1 gem-port 256
 gpon onu tcont 1 alloc-id 256
!

!!slot end
!
interface VLAN1
 ip address dhcp
 no ip directed-broadcast
!
interface VLAN1601
 ip address 172.16.1.10 255.255.255.0
 ip directed-broadcast
!
interface VLAN1700
 ip address 172.17.0.11 255.255.255.0
 no ip directed-broadcast
!
interface VLAN2201
 ip address 172.16.22.11 255.255.255.0
 no ip directed-broadcast
 ip helper-address 172.16.22.1
!
!
!
vlan 1700
 name vlan_olt
!
vlan 1701
 name abon_port1
!
vlan 2201
 name dhcp_server
!
vlan 1,1601,1700-1701,2201
!
!
!
!
ip dhcpd enable
!
ip dhcp-relay snooping
ip dhcp-relay snooping vlan  1701,2201
ip dhcp-relay snooping rapid-refresh-bind
ip dhcp-relay snooping information format ascii
!         
!
!
!
!
!
!
ip route default 172.16.1.1 
ip exf
!
ipv6 exf
!
ip telnet attack-defense
!
ip http server
!
!
!
!
!
!
!Pending configurations for absent linecards:
!
!No configurations pending global

 

Изменено 2022-07-20 08:51:15 пользователем forella

[khatgit 22]

Какое-то описание у вас дурацкое - читаешь и ничего не понятно. По какому критерию вы определяете, что lan порт ону не работает? 

Я бы предположил, что в этом порту не поднимается  линк  - но в вашем же комментарии есть вывод команды "show gpon interface gpoN 0/1:1 onu port 1 state", которая говорит что линк есть.

 

P.S. - прошивка 10.3.0D build 81888 кривая. Там есть проблемы с применением onu-vlan profile - вроде как этот баг исправлен на 89045.

Изменено 2022-07-20 08:38:28 пользователем khatgit

[forella 20]

33 минуты назад, khatgit сказал:

Какое-то описание у вас дурацкое - читаешь и ничего не понятно. По какому критерию вы определяете, что lan порт ону не работает? 

Я бы предположил, что в этом порту не поднимается  линк  - но в вашем же комментарии есть вывод команды "show gpon interface gpoN 0/1:1 onu port 1 state", которая говорит что линк есть.

 

P.S. - прошивка 10.3.0D build 81888 кривая. Там есть проблемы с применением onu-vlan profile - вроде как этот баг исправлен на 89045.

 

 

извиняюсь, конфиг не тот скинул с олт, исправил. сейчас выяснилось что проблема когда темплейт на гпон порт ставишь проявляется проблема такая, с дефолтными настройками (2 порт) такой проблемы нет, пока в поисках где в темплейте может проявляться такая проблема. прошивку обновил на BD_GP3616B_10.3.0D_99242.bin

на счет show gpon interface gpoN 0/1:1 onu port 1 state - линка нет, когда он есть пишет к примеру: 

                        GPON0/2:2       uni-port 1      up
                        100BASE-T(100Mbps Full-Duplex)

а когда нет: 

                        GPON0/1:2       uni-port 1      up
                        10/100/1000 BASE-T(Unknown)

то что он up это он включен, а то что он Unknown - это его физически нет.

Изменено 2022-07-20 08:55:47 пользователем forella

[forella 20]

вобщем ошибка заключается в %GPON-ONUCONFIG: Flow-mapping config failure on port GPON0/1:1. поэтому и нет ethernet линка.
кому не сложно поделитесь куском конфига с рабочим куском gpon profile и gpon onu-config-template?

вот тут такая проблема обсуждалась https://forum.nag.ru/index.php?/topic/147277-problema-s-konfigom-bdcom-gp3600-16/ , но что-то не с одним из решений не удалось заставить заработать лан порт.

[khatgit 22]

Подозреваю в вашем конфиге ему не нравится вот этот профайл:
 

! gpon profile onu-flow-mapping vlan1701 id 3

   gpon-profile entry 1 uni type eth-uni all

   gpon-profile entry 1 vlan 1701

   gpon-profile entry 1 virtual-port 1

!

Уберите из него одну из строчек что бы было или:

!
gpon profile onu-flow-mapping vlan1701 id 3
 gpon-profile entry 1 uni type eth-uni all
 gpon-profile entry 1 virtual-port 1
!

или:

!
gpon profile onu-flow-mapping vlan1701 id 3
 gpon-profile entry 1 vlan 1701
 gpon-profile entry 1 virtual-port 1
!

 

Изменено 2022-07-20 09:41:40 пользователем khatgit

[forella 20]

с таким конфигом заработало когда cmd-sequence 006 gpon onu flow-mapping-profile vlan1701 стоит в конце всех правил:
 

gpon profile onu-flow-mapping vlan1701 id 3
gpon-profile entry 1 uni type eth-uni 1
gpon-profile entry 1 virtual-port 1


gpon profile onu-vlan vlan1701_test id 4
gpon-profile vlan mode tag
gpon-profile vlan pvid 1701 0


gpon onu-config-template port1_1
cmd-sequence 001 gpon onu tcont-virtual-port-bind-profile tvbind-default
cmd-sequence 002 gpon onu uni 1 vlan-profile vlan1701_test
cmd-sequence 003 gpon onu uni 1 uni-profile MTU
cmd-sequence 004 gpon onu loopback-detect protocol private
cmd-sequence 005 gpon onu uni 1 loopback-detect enable
cmd-sequence 006 gpon onu flow-mapping-profile vlan1701

 

Теперь вопрос про option82, удалось у кого-то заставить передавать в option82 mac onu? 

из всех возможностей:

 snmp-ifindex         -- Use SNMP ifindex option 82 format
 hn-type              -- Use cisco option 82 format
 cm-type              -- Use cm-type option 82 format
 hw-type              -- Use hw-type option 82 format
 option82-customized  -- Use option82-customized
 manual               -- Config option 82 format manual
 fixed-type           -- Hostname/SN.VLAN

ни в одном случае мака ону нет.

хотя имеем в работе p3310 с настройкой 

ip dhcp-relay snooping information option format hn-type host - получаем мак ону в Remote-ID
а в gp3600 с этой настройкой прилетает 35:41:35:34:34:35:34:37:43:36:39:43:32:36:43:43:2d:31 (5A544547C69C26CC-1) и что это такое понятно только китайцам

[khatgit 22]

Теперь вопрос про option82, удалось у кого-то заставить передавать в option82 mac onu? 

Мак ону даже через cli нельзя посмотреть(во всяком случае я не нашел как), не говоря уже о добавлении его в opt82.  В Remote-ID при information option format hn-type host olt  добавляет s/n onu + номер виртуал порта.

 

Возможно вам поможет информация, каким образом формируется pon-овский s/n. Он состоит из 8 байт. Первые 4 байта это vendor id переведенный из ascii в hex. Последние 4 байта - это младшие 4 байта мак адреса ону.

То есть в вашем примере 5A544547C69C26CC-1 - это ону с серийным номером ZTEG:C69C26CC (show gpon interface gpon 0/*:* onu basic-info) и первый виртуал порт.

Изменено 2022-07-26 07:55:23 пользователем khatgit

[ISK 259]

В 26.07.2022 в 09:42, forella сказал:

ни в одном случае мака ону нет.

хотя имеем в работе p3310 с настройкой 

ip dhcp-relay snooping information option format hn-type host - получаем мак ону в Remote-ID
а в gp3600 с этой настройкой прилетает 35:41:35:34:34:35:34:37:43:36:39:43:32:36:43:43:2d:31 (5A544547C69C26CC-1) и что это такое понятно только китайцам

При всём внешнем сходстве БДКОМовские прошивки для EPON и GPON различаются кардинально! От слова совсем. Да, понятно, что технологии немножечко сильно разные, но по видимому, китайцы заморачиваться с унификацией прошивки особо не захотели...

В 26.07.2022 в 10:52, khatgit сказал:

Мак ону даже через cli нельзя посмотреть(во всяком случае я не нашел как), не говоря уже о добавлении его в opt82.

Да, в этом вся китайская особенность. На GPON OLT команда show interface GPON X/Y:Z показывает mac самой олты, а никак не онушки. Про opt82 смотрите ниже:

В 26.07.2022 в 10:52, khatgit сказал:

Возможно вам поможет информация, каким образом формируется pon-овский s/n. Он состоит из 8 байт. Первые 4 байта это vendor id переведенный из ascii в hex. Последние 4 байта - это младшие 4 байта мак адреса ону.

То есть в вашем примере 5A544547C69C26CC-1 - это ону с серийным номером ZTEG:C69C26CC (show gpon interface gpon 0/*:* onu basic-info) и первый виртуал порт.

Не совсем так. Точнее совсем не так! Ну, по крайней мере, в моих случаях: последние 4 байта серийника онушки абсолютно не зависят от её mac. Опять же, от слова совсем. Пример: GP3600-16B, серийник фоксгейтовской онушки FGXP:00664429, а последние цифры mac, на минуточку, 3f:8c.

Ну а опция 82 для бдкомовских GPON, таки да, по серийнику формируется. Да 16 цифр, но они, опять же, никакого отношения к маку не имеют. Опять же, от слова совсем...

Изменено 2022-07-29 07:47:37 пользователем ISK

[khatgit 22]

Не совсем так. Точнее совсем не так! Ну, по крайней мере, в моих случаях: последние 4 байта серийника онушки абсолютно не зависят от её mac. Опять же, от слова совсем. Пример: GP3600-16B, серийник фоксгейтовской онушки FGXP:00664429, а последние цифры mac, на минуточку, 3f:8c.

Хм... странно. Я тестировал на нескольких разных ону и там оно совпадало. Единственное это все xpon ону, которые работают на epon и gpon

 

Но в любом случае спасибо за информацию - буду иметь ввиду.

[ISK 259]

2 минуты назад, khatgit сказал:

Хм... странно. Я тестировал на нескольких разных ону и там оно совпадало. Единственное это все xpon ону, которые работают на epon и gpon

Ну у меня такая же ситуация - универсалки GPON/EPON. Но только в основном они Foxgate и BDCOM. А, ну и немножечко TP-Link. И у всех маки тупо несовпадают с серийниками. Если увижу такой случай, обязательно приведу в пример.

[Sufi 3]

On 7/29/2022 at 8:24 AM, ISK said:

Ну у меня такая же ситуация - универсалки GPON/EPON. Но только в основном они Foxgate и BDCOM. А, ну и немножечко TP-Link. И у всех маки тупо несовпадают с серийниками. Если увижу такой случай, обязательно приведу в пример.

Foxgate универсальные (FGXP) - совпадают только последние 2 байта PON MAC и PON sn.

BDCom, Picotel, Optolink норм, по маку на этикетке можно примерно вычислить серийный номер.

[forella 20]

Впринципе mac или серийник не суть важно, главное как-то уникализировать, по серийнику тоже все получилось, прост оне знал чт оу gpon логика немного изменилась с мака на серийник.
теперь еще один вопрос на счет dhcp. никто не сталкивался с проблемой, не доходит dhcpoffer до клиента? т.е. запрос от клиента прилетает на dhcp сервер, он оттдает ip, но до абонента он не доходит, и так покругу. может чего в конфиге упустил или ону такая попалась? хотя имеем на тесте 2 ону zte и huawei и у обеих поведение идентичное. на статике работает все норм.

 

[ISK 259]

22 часа назад, forella сказал:

теперь еще один вопрос на счет dhcp. никто не сталкивался с проблемой, не доходит dhcpoffer до клиента? т.е. запрос от клиента прилетает на dhcp сервер, он оттдает ip, но до абонента он не доходит, и так покругу. может чего в конфиге упустил или ону такая попалась? хотя имеем на тесте 2 ону zte и huawei и у обеих поведение идентичное. на статике работает все норм.

Да, это таки проблема с ону, причём известная давно: https://ixnfo.com/nastrojka-bdcom-gp3600.html

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

[forella 20]

В 03.08.2022 в 10:42, ISK сказал:

Да, это таки проблема с ону, причём известная давно: https://ixnfo.com/nastrojka-bdcom-gp3600.html

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

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

может ктото поделится куском конфига где работает ip helper, т.к. думаю что гдето промлема там.

вот с таким куском конфига (vlan1701 - ону(абонент), vlan2201 - dhcp сервер)

interface VLAN1701
 ip address 172.17.1.254 255.255.255.0
 no ip directed-broadcast
 ip helper-address 172.16.22.1
!
interface VLAN2201
 ip address 172.16.22.11 255.255.255.0
 no ip directed-broadcast
 ip helper-address 172.16.22.1
 

запросы приходят в оба vlan, и на ip helper и в тот с которого был запрос(vlan1701).

похоже что ip helper както странно отрабатывает в одну сторону перебрасывает пакеты из абонентского vlan в dhcp сервер, а вот в обратном порядке нет т.к. ответ не доходит.

кажется что либо где-то что-то прое*, либо какойто косяк в прошивке.

[forella 20]

короче получилось заставить работать. но очень по кривому, схему прикрепил как работает.

вобщем первый пакет прилетает броадкастом и на 172.17.1.1 и на 172.16.22.1. пришлось поднимать на dhcp server 172.17.1.2 чтоб ответить на первый пакет, следующие пакеты(перезапросы) уже идут туда куда ip helper назначен т.е. на 172.16.22.1. может есть у кого-то мысли как убрать с этой схемы все ip подсети 172.17.1.1\24 кроме собственно 172.17.1.1. посоветовали поднимать dhcp сервер на шлюзе в каждом влане да и все, но так не получится, шлюз это оттдельный физический сервер а dhcp это другой, в оттдельном влане который не только olt будет обслуживать. т.е. нужно релеить запросы абонские всеравно на оттдельный влан.

вот так это выглядит на dhcp server:
Aug  8 15:50:33 dds2 dhcpd[47478]: DHCPDISCOVER from d4:ca:6d:f4:5c:9c via 172.17.1.254
Aug  8 15:50:33 dds2 dhcpd[47478]: DHCPOFFER on 172.17.1.232 to d4:ca:6d:f4:5c:9c via 172.17.1.254
Aug  8 15:50:33 dds2 dhcpd[47478]: DHCPREQUEST for 172.17.1.232 (172.16.22.1) from d4:ca:6d:f4:5c:9c via 172.17.1.254
Aug  8 15:50:33 dds2 dhcpd[47478]: DHCPACK on 172.17.1.232 to d4:ca:6d:f4:5c:9c via 172.17.1.254
Aug  8 15:58:03 dds2 dhcpd[47478]: DHCPREQUEST for 172.17.1.232 from d4:ca:6d:f4:5c:9c via vlan2201
Aug  8 15:58:03 dds2 dhcpd[47478]: DHCPACK on 172.17.1.232 to d4:ca:6d:f4:5c:9c via vlan2201
 

а вот так на router

17:50:12.989476 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from d4:ca:6d:f4:5c:9c (oui Unknown), length 300
17:50:15.612475 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from d4:ca:6d:f4:5c:9c (oui Unknown), length 300

[ISK 259]

В 08.08.2022 в 16:55, forella сказал:

короче получилось заставить работать. но очень по кривому, схему прикрепил как работает.

вобщем первый пакет прилетает броадкастом и на 172.17.1.1 и на 172.16.22.1. пришлось поднимать на dhcp server 172.17.1.2 чтоб ответить на первый пакет, следующие пакеты(перезапросы) уже идут туда куда ip helper назначен т.е. на 172.16.22.1. может есть у кого-то мысли как убрать с этой схемы все ip подсети 172.17.1.1\24 кроме собственно 172.17.1.1. посоветовали поднимать dhcp сервер на шлюзе в каждом влане да и все, но так не получится, шлюз это оттдельный физический сервер а dhcp это другой, в оттдельном влане который не только olt будет обслуживать. т.е. нужно релеить запросы абонские всеравно на оттдельный влан.

Конечно будет очень по кривому! То что Вы сделали - откровенно ущербный костыль, выкиньте его немедленно!
Логика™, как бы, подсказывает нам, что первый пакет в DHCP запросе всегда будет идти в пределах своего влана и ответ, соответственно тоже.

В чём, собственно, проблема приземлить все клиентские вланы на DHCP сервер и не изобретать велосипеды с квадратными колёсами?

И не трогать при этом другие вланы, особенно если это, бляха-муха, менеджмент влан! И не гонять туда-сюда бесполезный траффик.

 

Навесьте абонские вланы на DHCP сервер, выкиньте отовсюду эту XYZню, под названием ip helper и живите счастливо! В чём проблема?

[forella 20]

16 часов назад, ISK сказал:

Конечно будет очень по кривому! То что Вы сделали - откровенно ущербный костыль, выкиньте его немедленно!
Логика™, как бы, подсказывает нам, что первый пакет в DHCP запросе всегда будет идти в пределах своего влана и ответ, соответственно тоже.

В чём, собственно, проблема приземлить все клиентские вланы на DHCP сервер и не изобретать велосипеды с квадратными колёсами?

И не трогать при этом другие вланы, особенно если это, бляха-муха, менеджмент влан! И не гонять туда-сюда бесполезный траффик.

 

Навесьте абонские вланы на DHCP сервер, выкиньте отовсюду эту XYZню, под названием ip helper и живите счастливо! В чём проблема?

это справедливо когда и dhcp сервер и шлюз на ордном серевере. но в схеме физически 2 сервера, один dhcp второй шлюз с nat и т.п.

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

клиент дал запрос - завернули юникастом на dhcp сервер - оттдали ip - все, дальше пускай работает со шлюзом.

по конфигам c ip helper мне будет достаточно поднять dhcp сервер на одном влан. а если у меня будет 1000 подсетей маленьких, в каждой чтоли прослушивать запросы dhcp сервером. я думаю это не очень правильно. У кого есть схема vlan peer user вы в каждом vlan прослушиваете запросы?

на epon у меня есть схема с ip unnambered, где dhcp сервер раздает всего в одном влан ip, но там запросы релеит cisco, и нормально с этим справляется.

сдесь жешь чтото не то, тот же supervlan на бдкоме функция такая что тянет на оттдельное обсуждение, так и не удалось заставить работать по принципу циски повесить все на loopback, там такого просто нет. supervlan поднимается как интерфейс хотя при этом ни в каком vlan не состоит, и назначить ему vlan никак нельзя.

вот както так оно умеет:

Switch_config#interface superVLAN ?
 <1-32>      -- SuperVLAN interface number
------

interface SuperVLAN17
no ip address
no ip directed-broadcast
ip helper-address 172.16.22.1
subvlan add 1701
----

оно б меня спасло, можно было бы поднять Ip в супервлан и поднять этот влан на dhcp севрер один и потом раскидывать по абонентским (subvlan) на олт, так этому supervlan никак нельзя назначить влан, он как бы есть, а как им пользоваться хз.
 

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

т.е. если сделать вот так, не работает:

interface VLAN1701
 ip helper-address 172.16.22.1

а вот так рабоатет:

interface VLAN1701
 ip address 172.17.1.254 255.255.255.0
 ip helper-address 172.16.22.1

но, опять же, приходит заспрос на 172.16.22.1 от  172.17.1.254

хотя что мешает отправить запрос напрямую с вот таким конфигом?

interface VLAN1701
 ip helper-address 172.16.22.1
!
interface VLAN2201
 ip address 172.16.22.11 255.255.255.0

как его заставить отправить напрямую запрос на 172.16.22.1 с 172.16.22.11 и передать ip абоненту?

Изменено 2022-08-11 07:11:51 пользователем forella

[khatgit 22]

Цитата

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

Ну так поднимите на шлюзе не dhcp сервер, а dhcp relay(dhcp-helper).

[forella 20]

3 минуты назад, khatgit сказал:

Ну так поднимите на шлюзе не dhcp сервер, а dhcp relay(dhcp-helper).

Не совсем понятно зачем? Релеит бдком, на дхсп сервер, зачем ещё и на шлюзе это делать?

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

От адреса в vlan1701 на dhcp сервере удалось избавиться добавив маршрут типа ip a add 172.17.1.0/24 dev vlan2201

Осталась одна проблема с броадкастовыми запросами во vlan1701

[ISK 259]

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

т.е. если сделать вот так, не работает:

interface VLAN1701
 ip helper-address 172.16.22.1

а вот так рабоатет:

interface VLAN1701
 ip address 172.17.1.254 255.255.255.0
 ip helper-address 172.16.22.1

Да, IP ему нужен, потому что это L3 интерфейс. А если просто вот так:

vlan 1,1701,2201

 

это уже L2.

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

хотя что мешает отправить запрос напрямую с вот таким конфигом?

interface VLAN1701
 ip helper-address 172.16.22.1
!

Логика модели OSI.

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

оно б меня спасло, можно было бы поднять Ip в супервлан и поднять этот влан на dhcp севрер один и потом раскидывать по абонентским (subvlan) на олт, так этому supervlan никак нельзя назначить влан, он как бы есть, а как им пользоваться хз.

Посмотрите в сторону Q-in-Q.

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

Не совсем понятно зачем? Релеит бдком, на дхсп сервер, зачем ещё и на шлюзе это делать?

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

От адреса в vlan1701 на dhcp сервере удалось избавиться добавив маршрут типа ip a add 172.17.1.0/24 dev vlan2201

Осталась одна проблема с броадкастовыми запросами во vlan1701

Если это L3 интерфейс, то так:

interface VLAN1701
 ip address 172.17.1.254 255.255.255.0
 no ip directed-broadcast
!

ip route default 172.17.1.1

!
 

А если L2:

filter dhcp
filter enable
!
ip dhcp-relay snooping
ip dhcp-relay snooping vlan 1701
ip dhcp-relay snooping rapid-refresh-bind
ip dhcp-relay snooping information option format hn-type
!

 

Ну и, как я уже сказал, все вланы приземлить на DHCP сервер. Ну вот как-то так...

Изменено 2022-08-11 11:11:24 пользователем ISK

[forella 20]

2 минуты назад, ISK сказал:

Да, IP ему нужен, потому что это L3 интерфейс. А если просто вот так:

vlan 1,1701,2201

 

это уже L2.

Логика модели OSI.

Посмотрите в сторону Q-in-Q.

Если это L3 интерфейс, то так:

interface VLAN1701
 ip address 172.17.1.254 255.255.255.0
 no ip directed-broadcast
!

ip route default 172.17.1.1

!
 

А если L2:

filter dhcp
filter enable
!
ip dhcp-relay snooping
ip dhcp-relay snooping vlan 1701
ip dhcp-relay snooping rapid-refresh-bind
ip dhcp-relay snooping information option format hn-type
!

 

Ну и, как я уже сказал, все вланы приземлить на DHCP сервер. Ну вот как-то так...

l2 не вариант, на dhcp клиентские вланы не нужны, они и так будут на шлюзе, еще и кашу городить на dhcp. остановился пока на варианте l3 на olt, пока только непонятна ситуация как olt себя поведет при нагрузке.

[khatgit 22]

Цитата

Не совсем понятно зачем? Релеит бдком, на дхсп сервер, зачем ещё и на шлюзе это делать?

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

 

Цитата

l2 не вариант, на dhcp клиентские вланы не нужны, они и так будут на шлюзе, еще и кашу городить на dhcp. остановился пока на варианте l3 на olt, пока только непонятна ситуация как olt себя поведет при нагрузке.

Вы же что бы побороть один костыль - делаете другой.

Изменено 2022-08-11 12:20:12 пользователем khatgit

[forella 20]

41 минуту назад, khatgit сказал:

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

 

Вы же что бы побороть один костыль - делаете другой.

оно релеит юникастом если дать ip на l3 интерфейсе на бдком с этим можно смириться, но остается в клиентском влане броадкаст до поулчения ip, просто прийдется на шлюзе его дропать, почему он не пропадает после включения релея и назначения helper непонятно.

клиент в двух vlan одновременно запрашивает ip при включении, а перезапрашивает потом уже как нужно у helper.

 

[ISK 259]

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

l2 не вариант, на dhcp клиентские вланы не нужны, они и так будут на шлюзе, еще и кашу городить на dhcp.

В чём проблема навесить вланы на сервер? Неужели DHCP у Вас на таком тазе, что Вы даже дышать на него боитесь чтобы не развалился?

 

57 минут назад, forella сказал:

остановился пока на варианте l3 на olt, пока только непонятна ситуация как olt себя поведет при нагрузке.

Вот-вот. Это ж Вам не Циска, столько L3 интерфейсов прожевать. И да, вариант L3 подходит только для ону-роутеров, но это дороговато будет! И для Вас и для клиентов...

[forella 20]

15 часов назад, ISK сказал:

В чём проблема навесить вланы на сервер? Неужели DHCP у Вас на таком тазе, что Вы даже дышать на него боитесь чтобы не развалился?

 

Вот-вот. Это ж Вам не Циска, столько L3 интерфейсов прожевать. И да, вариант L3 подходит только для ону-роутеров, но это дороговато будет! И для Вас и для клиентов...

тут вопрос не в сложности поднять вланы на дхсп, а вопрос в том зачем они там нужны? прикрепил 2 схемы, красным это класическая схема all in one, но допустим ситуация один из серверов потух, сколько время восстановления? их может быть и больше серверов все зависит от нагрузки.

вторая схема где dhcp сервер отдельно + зеркально такой же запасной, шнурки переставил и дальше работаешь. если поднимать на dhcp сервере еще и клиентские вланы, зачем они там нужны если смысловой нагрузки они не несут, а бродкаст как минимум будет с них лететь, если 2-3 подсети ничего, а если их 100, 1000? Роль dhcp сервера ответить на запрос, и с помощью релея это можно организовать в одном влане, хоть сколь угодно много небыло клиентских вланов.