Перейти до

UA.PON v3.0


wladd

  

193 пользователя проголосовало

  1. 1. Планируете ли вы строить сети в частном секторе, в сельской местности ?

    • Да!
      187
    • Нет!
      6
  2. 2. Планируете ли вы использовать технологию PON или FTTX ?

    • PON
      119
    • FTTX
      74
  3. 3. Являетесь ли вы уже участником проекта UA.PON?

    • Да!
      22
    • Нет
      98
    • Планирую
      86


Рекомендованные сообщения

Кому лучше ?

Хотса, то можно.

Вижу что можно...

Но что это за бл%?:

Switch_config_epon0/1:1#epon onu port 2 ctc vlan mode trunk 487 ?
WORD -- old VLAN IDs such as (1,3,5,7) Or (1,3-5,7) Or (1-7)

Какой старый влан?

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 823
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Дорогие Друзья! Наконец то родилась третья версия Всеукраинского Проекта - UA.PON.V.3.0 GEPON оправдал себя как новая технология, новая веха в сете строительстве, новая эра оптического доступа! GEPON

А почему девушка голая? Да и еще в колено локтевой позиции? Что это символизирует ? "Мы вас поставим раком и разденем до гола?" И дерево со спины растет с корнем в виде руки Фреди Крюгера, + татуха н

Ипать у тя фантазия)))

Posted Images

2Ufm: Взял 1501 на тест, подключение 1 Г, но скорость макс до 100М, помню где-то писал, что нужно что-то вводить, чтобы адекватней работало, а что именно?

 

P.S Rate limit на download к пользователю работает нормально и на 1501 и на 1504, на аплоад на 1504 - работает если установить методом подбора значения в команеде rate-limit, на 1501 upload глючит - что ни введешь ограничит мегабит на 5-8. Если порт в 1501 переключить в 100мбит, аплоад почему-то прыгает в 10мбит (без каких-либо команд rate-limit)/

Ссылка на сообщение
Поделиться на других сайтах

2Ufm: Взял 1501 на тест, подключение 1 Г, но скорость макс до 100М, помню где-то писал, что нужно что-то вводить, чтобы адекватней работало, а что именно?

 epon sla upstream pir 1000000 cir 512
epon sla downstream pir 1000000 cir 512

Ссылка на сообщение
Поделиться на других сайтах
Switch_config_epon0/1:1#epon onu port 2 ctc vlan mode trunk 487 ?

WORD -- old VLAN IDs such as (1,3,5,7) Or (1,3-5,7) Or (1-7)

Какой старый влан?

 

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

Ссылка на сообщение
Поделиться на других сайтах

коллеги... по несчастью...

 

скажите у кого-нибудь получалось заставить ОЛТ дописать опцию82 (номер ЕПОН-порта)

да, знаю что номера ОНУшки не получить, но хоть так

Ссылка на сообщение
Поделиться на других сайтах

2Ufm: Взял 1501 на тест, подключение 1 Г, но скорость макс до 100М, помню где-то писал, что нужно что-то вводить, чтобы адекватней работало, а что именно?

 epon sla upstream pir 1000000 cir 512
epon sla downstream pir 1000000 cir 512

 

Спасибо! Этой командой правильно ограничивает скорость, как на 1501 так и на 1504. Главное, чтобы она другие онушки не затрагивала

Ссылка на сообщение
Поделиться на других сайтах

2Ufm: Взял 1501 на тест, подключение 1 Г, но скорость макс до 100М, помню где-то писал, что нужно что-то вводить, чтобы адекватней работало, а что именно?

 epon sla upstream pir 1000000 cir 512
epon sla downstream pir 1000000 cir 512

 

Спасибо! Этой командой правильно ограничивает скорость, как на 1501 так и на 1504. Главное, чтобы она другие онушки не затрагивала

Ссылка на сообщение
Поделиться на других сайтах

коллеги... по несчастью...

 

скажите у кого-нибудь получалось заставить ОЛТ дописать опцию82 (номер ЕПОН-порта)

да, знаю что номера ОНУшки не получить, но хоть так

там все просто, включается в пару команд. следуйте инструкции от производителя :)

Ссылка на сообщение
Поделиться на других сайтах
Switch_config_epon0/1:1#epon onu port 2 ctc vlan mode trunk 487 ?

WORD -- old VLAN IDs such as (1,3,5,7) Or (1,3-5,7) Or (1-7)

Какой старый влан?

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

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

 

Записки постороннего (часть первая).

 

Схема стенда:

D-Link DGS-3626g
[port2]
|
[GE0/1]
BDCom P3310B (10.1.0B Build 9545)
[EPON0/1]
|
BDCom P1004 (10.0.8A1082)
|
[uNI:1] - MAG250
[uNI:2] - tcpdump

 

Эксперимент 1:

!
interface GigaEthernet0/1
switchport trunk vlan-allowed 410,487,1008-1009
switchport trunk vlan-untagged none
switchport mode trunk
switchport pvid 487
!
!
interface EPON0/1
epon bind-onu mac fcfa.f796.174e 1
switchport trunk vlan-allowed 487,1008-1009
switchport trunk vlan-untagged none
switchport mode trunk
!
interface EPON0/1:1
onu-configuration
description test onu 1
epon onu port 1 ctc vlan mode tag 1009
epon onu port 1 loopback detect
epon onu port 1 ctc mcst tag-stripe enable
epon onu port 1 ctc mcst mc-vlan add 487
!!onu-configuration-end
!
vlan 410
name mgmt-kino
!
vlan 487
name iptv-kino
!
vlan 1008
name mikh50
!
vlan 1009
name ryaz100
!
vlan 1,410,487,1008-1009
!
ip mcst enable
ip mcst mc-vlan 487 range 239.11.0.0 - 239.11.1.255
!

Кофигурация простая - с L3 коммутатора, выполняющего роль PIM SM роутера, подаем на OLT четыре влана - управление, мультикастовый и два "пациентских". Управляющий влан осаживаем на OLTе (создаем управляющий IP интефейс), а остальные три через ЕПОН порт отправляем в первое дерево. MVR, в иcполнении BDCom-а настроен - в первом порту тестовой ONU живет MAG-250 который бодренько крутит тестовый поток. Во второй порт воткнут сниффер для наблюдения за происходящим.

 

Так как второй порт ONU никаким особым образом не конфигурировался, то значит он находится в "transparent mode" (в разрезе вланов).

С L3 коммутатора пытаемся пинговать три несуществующих хоста в трех вланах - мультикастовом и двух "пациентских", что вызывает порождение ARP запросов типа who-has "вася" в рамках этих вланов.

 

На сниффере наблюдаем ожидаемую картину - arp запросы в тегированном виде:

15:35:47.773905 fc:75:16:b8:a4:01 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1008, p 7, ethertype ARP, Request who-has 10.79.188.188 tell 10.79.188.1, length 46
15:35:49.942103 fc:75:16:ba:28:04 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 487, p 7, ethertype ARP, Request who-has 172.31.28.28 tell 172.31.28.254, length 46
15:35:49.942527 fc:75:16:ba:28:02 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1009, p 7, ethertype ARP, Request who-has 10.79.194.194 tell 10.79.192.2, length 46

 

Эксперимент 2:

!
interface GigaEthernet0/1
switchport trunk vlan-allowed 410,487,1008-1009
switchport trunk vlan-untagged none
switchport mode trunk
switchport pvid 487
!
!
interface EPON0/1
epon bind-onu mac fcfa.f796.174e 1
switchport trunk vlan-allowed 487,1008-1009
switchport trunk vlan-untagged none
switchport mode trunk
!
interface EPON0/1:1
onu-configuration
description test onu 1
epon onu port 1 ctc vlan mode tag 1009
epon onu port 2 ctc vlan mode tag 487
epon onu port 1 loopback detect
epon onu port 1 ctc mcst tag-stripe enable
epon onu port 1 ctc mcst mc-vlan add 487
!!onu-configuration-end
!
vlan 410
name mgmt-kino
!
vlan 487
name iptv-kino
!
vlan 1008
name mikh50
!
vlan 1009
name ryaz100
!
vlan 1,410,487,1008-1009
!
ip mcst enable
ip mcst mc-vlan 487 range 239.11.0.0 - 239.11.1.255
!

В конфигурацию внесены изменения - epon onu port 2 ctc vlan mode tag 487.

Согласно bdcom\Configuration Manual\23-ONU Management Settings.pdf (раздел 3.2, стр. 26, "tag mode") ожидаем поведения "Forward the packet to the corresponding UNI port according to VID, remove the tag; if the VLAN ID of a downlink tagged packet is not the configured VID, this packet will be dropped." - Т.е. "пакет форвардится на соответствующий UNI порт с соответсвующим влан тегом, при этом тег удаляетя; если нужный влан тег не обнаружен - пакет дропается". Т.е. на выходе из второго порта мы должны наблюдать нетегированные ARP запросы в 487 влане и все - т.е. 2й UNI порт это классический access port в терминологии Cisco.

 

На сниффере же наблюдаем:

16:37:58.078762 fc:75:16:ba:28:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.31.28.28 tell 172.31.28.254, length 46
16:37:58.079182 fc:75:16:ba:28:02 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1009, p 7, ethertype ARP, Request who-has 10.79.194.194 tell 10.79.192.2, length 46
16:37:59.910210 fc:75:16:b8:a4:01 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1008, p 7, ethertype ARP, Request who-has 10.79.188.188 tell 10.79.188.1, length 46

Опа! Нежданчик! - Обнаружен заброс бродкастного трафика из вланов 1008 и 1009, которого быть не должно.

 

Эксперимент 3:

!
interface GigaEthernet0/1
switchport trunk vlan-allowed 410,487,1008-1009
switchport trunk vlan-untagged none
switchport mode trunk
switchport pvid 487
!
!
interface EPON0/1
epon bind-onu mac fcfa.f796.174e 1
switchport trunk vlan-allowed 487,1008-1009
switchport trunk vlan-untagged none
switchport mode trunk
!
interface EPON0/1:1
onu-configuration
description test onu 1
epon onu port 1 ctc vlan mode tag 1009
epon onu port 2 ctc vlan mode trunk 487 1008
epon onu port 1 loopback detect
epon onu port 1 ctc mcst tag-stripe enable
epon onu port 1 ctc mcst mc-vlan add 487
!!onu-configuration-end
!
vlan 410
name mgmt-kino
!
vlan 487
name iptv-kino
!
vlan 1008
name mikh50
!
vlan 1009
name ryaz100
!
vlan 1,410,487,1008-1009
!
ip mcst enable
ip mcst mc-vlan 487 range 239.11.0.0 - 239.11.1.255
!

В конфигурацию внесены изменения - epon onu port 2 ctc vlan mode trunk 487 1008.

В мануале bdcom\Configuration Manual\23-ONU Management Settings.pdf на тему vlan mode trunk обнаружен болт на 18. Однако судя по подсказкам CLI и stan77, на сниффере мы должны увидеть нетегированные пакеты (идущие в 487 влане) и тегированные пакеты в влане 1008 - и все! Пакеты в влане 1009 должны отсутсвовать.

 

На сниффере же наблюдаем ту же картину, как и в эксперименте 2:

16:40:27.916171 fc:75:16:b8:a4:01 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1008, p 7, ethertype ARP, Request who-has 10.79.188.188 tell 10.79.188.1, length 46
16:40:30.084295 fc:75:16:ba:28:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.31.28.28 tell 172.31.28.254, length 46
16:40:30.084716 fc:75:16:ba:28:02 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1009, p 7, ethertype ARP, Request who-has 10.79.194.194 tell 10.79.192.2, length 46

Опаньки! Как говориться - Добрый вечер! :)

Опять заброс широковещательного трафика из 1009-го влана.

 

Резюме:

В наличии имеем криво реализованную коммутацию на L2 уровне. Баг не смертельный - заброса юникастного трафика не просиходит (я проверял - просто тут описывать не стал).

Однако господа, реализующие схему vlan per customer (с Catalist-ом выше OLT-а) я вас поздравляю - ARP запросы вашего L3 свича дублируются и размазываются тонким слоем во все ONU дерева.

 

 

P.s. на этом на сегодня все - завтра я планирую разобрать шедевральное поведение MVR-а в реализации BDCom. :facepalm:

Ссылка на сообщение
Поделиться на других сайтах

 

Резюме:

В налчии имеем криво реализованную коммутацию на L2 уровне. Баг не смертельный - заброса юникастного трафика не просиходит (я проверял - просто тут описывать не стал).

Однако господа, реализующие схему vlan per customer (с Catalist-ом выше OLT-а) я вас поздравляю - ARP запросы вашего L3 свича дублируются и размазываются тонким слоем во все ONU дерева.

 

 

P.s. на этом на сегодня все - завтра я планирую разобрать шедевральное поведение MVR-а в реализации BDCom. :facepalm:

Когда я с этой проблемой обращался в bdcom, мне было сказано, что это не бага, это фича, это сделано для какого-то большого китайского клиента, и никто ради меня, простого хлопчика, ничего менять не будет. Я вот думаю, что в связи с увеличением объёмов Владу стоит еще раз потрясти bdcom. Потому что ARP_овые бродкасты ходят не только между вланами, но и между портами ONU с включенным (точнее - с невыключенным) traffic segmentation.

Ссылка на сообщение
Поделиться на других сайтах

Влад, я конечно дико извиняюсь, но Вы выкладываете результаты теста, которые довольно часто содержать фразу "команда работает" - у меня вопрос: так "команда работает" или все же функционал конфигурируемый этой командой работает? Т.е. производилось серьезное тестирование работоспособности функционала?

Ссылка на сообщение
Поделиться на других сайтах

Резюме:

В налчии имеем криво реализованную коммутацию на L2 уровне. Баг не смертельный - заброса юникастного трафика не просиходит (я проверял - просто тут описывать не стал).

Однако господа, реализующие схему vlan per customer (с Catalist-ом выше OLT-а) я вас поздравляю - ARP запросы вашего L3 свича дублируются и размазываются тонким слоем во все ONU дерева.

P.s. на этом на сегодня все - завтра я планирую разобрать шедевральное поведение MVR-а в реализации BDCom. :facepalm:

Когда я с этой проблемой обращался в bdcom, мне было сказано, что это не бага, это фича, это сделано для какого-то большого китайского клиента, и никто ради меня, простого хлопчика, ничего менять не будет. Я вот думаю, что в связи с увеличением объёмов Владу стоит еще раз потрясти bdcom. Потому что ARP_овые бродкасты ходят не только между вланами, но и между портами ONU с включенным (точнее - с невыключенным) traffic segmentation.

тов Гайджин - добро пожаловать в Скайп!

добавьте меня пожалуйста w.glazyrin

Мы с вами вместе навалим инженерам БДКОМ про баг и про фичу еще раз.

Ссылка на сообщение
Поделиться на других сайтах

Влад, я конечно дико извиняюсь, но Вы выкладываете результаты теста, которые довольно часто содержать фразу "команда работает" - у меня вопрос: так "команда работает" или все же функционал конфигурируемый этой командой работает? Т.е. производилось серьезное тестирование работоспособности функционала?

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

Тест по старкому будет обновлен завтра уточнениями различного рода. Тем более что мы не продаем ЭТО оборудование.

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

 

Больше коструктива господа!

Ссылка на сообщение
Поделиться на других сайтах

Когда я с этой проблемой обращался в bdcom...

Ага... Значит я на эти грабли не первый наступил - это радует, а то зачастую как раскопаешь какой нибудь глюк, а его никто с роду не видел.

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

... мне было сказано, что это не бага, это фича, это сделано для какого-то большого китайского клиента, и никто ради меня, простого хлопчика, ничего менять не будет. Я вот думаю, что в связи с увеличением объёмов Владу стоит еще раз потрясти bdcom...

Вы сами обращались к китайцам? - Если да, то хотелось бы увидеть ответ. (Возможно он конечно где то в недрах веток UA.PON хранится, но если честно господа, то их так в перемешку завали техническим, коммерческими и околопоновыми вопросами, что там найти что либо тяжело. Третью версию прочитал всю, вторую до 15 страници, до первой не знаю доберусь ли - не кажется ли вам, господа, что надо как то разбить темы по направлениям?)

 

Что же касается фичи - мы же с Вами прекрасно понимаем, что это бред - какой нафиг клиент, глюк же классический. Не должен коммутатор себя так вести, как впрочем и полезного применения подобной "фиче" ни один суперпупер телеком не найдет ибо его быть просто не может.

 

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

Кстати, если уж зашел, разговор о возможностях братьев наших желтолицых, то у меня вопрос - в нерешенных проблемах значится вопрос о изменении механизма прошивки ONUшек. Так вот мне интересно, а просто попросить их добавить флеша в OLT или прикрутить к OLTу USB (SD Card) порт не проще бы было? - Они же с софтом не дружат, зато паяют быстро. Я не думаю что это сильно бы удорожало OLT.

 

Потому что ARP_овые бродкасты ходят не только между вланами, но и между портами ONU с включенным (точнее - с невыключенным) traffic segmentation.

Если честно, то мне кажется, что traffic segmentation тут вторично - включай его, не включай, результат один будет если ARPы сами по себе по вланам размазываются. Т.е. если починить первое, то второе само вылечится.

Ссылка на сообщение
Поделиться на других сайтах

тов Гайджин - добро пожаловать в Скайп!

добавьте меня пожалуйста w.glazyrin

Мы с вами вместе навалим инженерам БДКОМ про баг и про фичу еще раз.

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

 

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

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

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

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

Тест по старкому будет обновлен завтра уточнениями различного рода. Тем более что мы не продаем ЭТО оборудование.

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

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

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

Больше коструктива господа!

Завтра не обещаю - гости приезжают, а вот послезавтра чего нибудь накопаю. :)

Ссылка на сообщение
Поделиться на других сайтах

Проблему тов Гайджин, я полностью изучил и изложил на англиском языке инженерам БДКОМ.

Завтра узнаем их мнение. Судя то описанию - это непорядок.

Да. и еще, "обязательно накапывайте" это обогащает наш проект.

Ссылка на сообщение
Поделиться на других сайтах

Влад, я всегда рад накапывать, ты-же знаешь. Но BDCOM на каждый чих требуют предоставить им показывать ж#пу и риносить унитаз. А я не люблю делать работу, цель которой я не понимаю. Вот например:

имеем настройки ONU:

pon2.sw.mgn_config_epon0/3:63#show ru int e0/3:63
Building configuration...
Current configuration:
!
interface EPON0/3:63
onu-configuration
 epon onu port 3 ctc vlan mode tag 3333
 epon onu port 4 ctc vlan mode tag 4000
 no epon onu spanning-tree
!!onu-configuration-end

И имеем на 4-том порту вот такой п-ц:

ufm@ufm-ws /mnt/ufm/Documents/LDAP/Magnus $ sudo tcpdump -eni eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
11:16:25.841161 fc:fa:f7:9d:02:f9 > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:f9, length 46
11:16:25.852119 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.119 tell 192.168.1.1, length 42
11:16:25.855643 fc:fa:f7:9d:02:5b > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:5b, length 46
11:16:25.855663 fc:fa:f7:9d:02:6c > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:6c, length 46
11:16:25.855669 fc:fa:f7:9d:02:54 > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:54, length 46
11:16:25.855675 fc:fa:f7:9d:02:fd > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:fd, length 46
11:16:25.855679 fc:fa:f7:9d:02:6d > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:6d, length 46
11:16:25.855684 fc:fa:f7:9d:02:5f > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:5f, length 46
11:16:25.855688 fc:fa:f7:9d:02:d8 > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:d8, length 46
11:16:25.884662 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.2 tell 192.168.1.1, length 42
11:16:25.937308 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.101 tell 192.168.1.1, length 42
11:16:25.960796 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.201 tell 192.168.1.1, length 42
11:16:26.073268 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.3 tell 192.168.1.1, length 42
11:16:26.106997 00:25:90:53:35:5e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 53, p 0, ethertype ARP, Request who-has 31.129.160.86 tell 31.129.160.85, length 42
11:16:26.161216 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.8 tell 192.168.1.1, length 42
11:16:26.165957 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.130 tell 192.168.1.1, length 42
11:16:26.172954 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.100 tell 192.168.1.1, length 42
11:16:26.186186 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.5 tell 192.168.1.1, length 42
11:16:26.259921 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.10 tell 192.168.1.1, length 42

 

И сейчас BDCOM скажет - покажите конфиг. А я не хочу показывать конфиг, я привёл _достаточно_ информации для того, что бы было понятно, что происходит лажа.

Ссылка на сообщение
Поделиться на других сайтах

Ну так это то-же что и уважаемый Гайджин писал. Да, это лажа и это недопустимо. И действительно - причем тут остальной конфиг вообще. Вот бы еще китайцы это понимали.

Ссылка на сообщение
Поделиться на других сайтах

Кстати, Влад, любимый тобой PHICOMM. Сильно лучше, да, но не без косяков:

12:27:15.673154 da:76:74:01:30:c1 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 60: vlan 1120, p 0, ethertype IPv4, 0.0.0.0 > 224.0.0.1: igmp query v2
12:27:15.875886 00:27:22:48:45:68 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 60: vlan 888, p 0, ethertype IPv4, 0.0.0.0 > 224.0.0.1: igmp query v2

 

Настройка ровно такая-же.

Ссылка на сообщение
Поделиться на других сайтах

Описал про все про это.

Похоже БДКОМ не в курсе. Сказали что проблема давно решена.

Привел еще один пример, отругал и потребовал тестить. Думаю разрешится проблем.

Ссылка на сообщение
Поделиться на других сайтах

Описал про все про это.

Похоже БДКОМ не в курсе. Сказали что проблема давно решена.

Привел еще один пример, отругал и потребовал тестить. Думаю разрешится проблем.

на 1501 этой проблемы нет.

Ссылка на сообщение
Поделиться на других сайтах
Гость
Эта тема закрыта для публикации сообщений.
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від AlinaQuan
      Title: "Unraveling the Wonders of PON Networks: A Brief History and EPON OLT 4-Port Product Showcase!"
      Hey everyone! 👋 Let's dive into the fascinating journey of PON networks and check out our star product: EPON OLT 4-Port! 🌟
      Once upon a time, in the realm of networking, there arose a need for faster, more efficient connections. Enter PON (Passive Optical Network), a revolutionary technology that changed the game! 💡
      PON's story begins with its humble origins, evolving from traditional Ethernet setups to the lightning-fast Fiber Optic realm. Imagine data zooming through optical fibers like magic! ✨
      Now, let's shine the spotlight on our hero: EPON OLT 4-Port! This mighty device is the heart of your PON network, serving as the gateway to high-speed internet dreams. With four ports to connect and empower your network, it's a powerhouse of connectivity! 💪
       
      But wait, there's more! EPON OLT 4-Port isn't just about speed; it's also about reliability and scalability. Whether you're a small business or a bustling enterprise, this gem scales effortlessly to meet your needs. It's like having a superhero at your service 24/7! 🦸‍♂️💨
      So, dear friends, as we journey through the annals of networking history, let's embrace the marvels of PON and bask in the glory of EPON OLT 4-Port. Faster connections, smoother operations, and endless possibilities await! 🚀
      Join the PON revolution today with EPON OLT 4-Port – where dreams meet connectivity, one fiber at a time! ✨ #PONPower #EPON #FastConnections
    • Від AlinaQuan
      FTTR (Fiber to the Room) - це проект зв'язку, спрямований на забезпечення високошвидкісного та надійного підключення до мережі в приміщеннях, таких як готелі, лікарні, офісні будівлі тощо. Основна мета мережі FTTR полягає в тому, щоб розширити оптичну мережу до кожної кімнати або кожної робочої зони, щоб забезпечити користувачів високоякісним підключенням до мережі в будь-якому місці.
      Основні кроки у реалізації мережі FTTR зазвичай включають наступне:
      Планування та проектування: Спочатку потрібно провести місцевий огляд і планування мережі, визначити обсяг покриття мережі, шляхи прокладання оптичного кабелю та підключення кінцевих точок тощо.
      Прокладання оптичного кабелю: Наступним кроком є прокладання оптичного кабелю. Це може включати внутрішнє або зовнішнє прокладання оптичного кабелю, щоб забезпечити підключення до кожної кімнати або робочої зони.
      Встановлення кінцевих пристроїв: Встановлення оптичних кінцевих пристроїв у кожній кімнаті або робочій зоні. Ці пристрої відповідають за перетворення оптичного сигналу в доступний для використання мережевий сигнал і надають мережевий інтерфейс для підключення пристроїв користувачів.
      Управління та обслуговування мережі: Після завершення будівництва мережі необхідно здійснювати управління та обслуговування мережі, щоб забезпечити стабільність та надійність мережі. Це включає моніторинг продуктивності мережі, оперативне вирішення проблем і ремонт тощо.
      Під час реалізації мережі FTTR необхідно комплексно враховувати такі фактори, як будівельна конструкція, потреби користувачів та бюджет, щоб забезпечити відповідність мережі потребам користувачів та забезпечити зручне використання.
       
    • Від AlinaQuan
      An ONU with a CATV port serves as a gateway for IPTV services. It connects the fiber optic network to the user's premises, allowing the delivery of television content over the internet protocol. The CATV port enables the reception of television signals, which can be distributed to TVs within the home via traditional coaxial cables.
       
      And the VOIP port on an ONU facilitates Voice over Internet Protocol (VOIP) services. It enables the transmission of voice calls over the internet, converting analog voice signals into digital data packets that can be transmitted over the network. This port allows users to make phone calls using their internet connection instead of traditional telephone lines.
       
      Here, Exw Shenzhen 1600UAH (Shipping cost and tariff not included) you will get a WIFI 6 ONU with CATV, VOIP, USB port!
       
       
      For whole price, just contact viber/whatsapp/wechat by +8618086327779 for more details!
       
    • Від AlinaQuan
      Привіт усім!
      Сьогодні я хочу поділитися з вами деякою інформацією про PON (Passive Optical Network), а також про переваги використання GPON (Gigabit Passive Optical Network) у проектах FTTH (Fiber to the Home).
       
      PON - це технологія передачі даних, яка використовує оптичні волокна для передачі сигналів до кінцевих користувачів без необхідності використання активного обладнання на шляху. Це дозволяє зменшити витрати на енергію та обслуговування мережі.
       
      Звіт про PON мережеву архітектуру та порівняння GPON, EPON і XGSPON у вигляді таблиці зображений нижче:
       
      Однією з найпопулярніших реалізацій PON є GPON. GPON забезпечує велику пропускну здатність і високу якість обслуговування для кінцевих користувачів. У FTTH проектах використання GPON має численні переваги, такі як зменшення витрат на інфраструктуру, покращення якості послуг та забезпечення масштабованості мережі.
      У моделі GPON мережі є два основних компонента: GPON OLT (Optical Line Terminal) та GPON ONU (Optical Network Unit). GPON OLT знаходиться на стороні провайдера і забезпечує з'єднання зі структурою оптичної мережі. GPON ONU розташовується на стороні користувача і використовується для підключення до оптичної мережі.
       
      При будівництві XGSPON мережі, хоча вона забезпечує найвищу на сьогоднішній день швидкість передачі даних, пристрої XGSPON OLT та XGSPON ONU, які використовуються в ній, мають високу вартість, що не є оптимальним вибором для домашніх мереж. Таким чином, на сьогоднішній день, GPON здається найбільш вигідним рішенням для мережі!
       
      Примітка: усе це перекладено програмним забезпеченням. Ласкаво просимо вказати на це, якщо є проблеми з граматикою чи орфографією.
       
    • Від AlinaQuan
      In the world of fiber optic technology, two terms you might come across are GPON and XGSPON. But what do they mean, and how are they different? Let's dive in and explore these fascinating technologies in simple terms!
       
      What is GPON?
      GPON stands for Gigabit Passive Optical Network. It's a widely used technology for delivering high-speed internet and other services over fiber optic cables. GPON operates by splitting the fiber optic signal into multiple channels, allowing for efficient transmission of data to multiple users simultaneously. It's like having multiple lanes on a highway, ensuring smooth traffic flow even during peak hours.
       
      What is XGSPON?
      XGSPON, on the other hand, stands for 10-Gigabit-capable Passive Optical Network. As the name suggests, XGSPON takes things up a notch by offering even faster speeds than GPON. With XGSPON, data can be transmitted at speeds of up to 10 gigabits per second (Gbps), making it ideal for bandwidth-intensive applications like ultra-high-definition video streaming and virtual reality gaming.
       
      Key Differences:
      Speed: The main difference between GPON and XGSPON is the speed they offer. While GPON typically provides speeds of up to 2.5 Gbps downstream and 1.25 Gbps upstream, XGSPON can deliver speeds of up to 10 Gbps in both directions.
      Bandwidth: With its higher speed capabilities, XGSPON offers greater bandwidth for handling large amounts of data traffic. This makes it well-suited for scenarios where multiple users require ultra-fast internet access simultaneously.
      Compatibility: GPON and XGSPON are not directly compatible with each other. Upgrading from GPON to XGSPON typically requires replacing the optical line terminal (OLT) equipment at the service provider's end, as well as upgrading the customer premises equipment (CPE) such as ONUs or ONTs.
      Conclusion
       
      In summary, GPON and XGSPON are both powerful technologies for delivering high-speed internet over fiber optic networks. While GPON offers impressive speeds suitable for most residential and small business applications, XGSPON takes things to the next level with its blazing-fast speeds and increased bandwidth capacity. Whether you're streaming your favorite shows, gaming online, or running a business, these technologies pave the way for a connected future where speed knows no bounds!

       
      And there you have it – a simple breakdown of the differences between GPON and XGSPON. Keep exploring, keep innovating, and let's continue to ride the wave of fiber optic technology into the future! 🌐✨
       
      Contact Whatsapp / Viber / Wechat +86 18086327779 for more details!

×
×
  • Створити нове...