Перейти до

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 этой проблемы нет.

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

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