khatgit
-
Всього повідомлень
66 -
Приєднався
-
Останній візит
-
Дней в лидерах
4
Тип контенту
Профили
Форум
Календарь
Сообщения додав khatgit
-
-
Цитата
Чи стикався хтось з такою помилкою і що вона означає ?)
Значить, що не вистачає ресурсів)))
Покажіть вивід результату команд:
show resource show gpon profile tcont show gpon remote-onu capability gpon_onu-1/1/3:5
-
Цитата
Наскільки це взагалі реально поставити таку кількість обладнання резервного живлення в кожен будинок?
Чи це маркетинговий хід і в реальності буде генератор тільки на оптичних вузлах і "Ви не так зрозуміли"?
Генератора в звичайних будинках точно не будет. Не факт що i на оптичних вузлах буде.
А от плата резервного живлення + аккумулятор на 12 Ah (або інша ємність), что просто UPS - це вже більш реалістичний сценарій. Питання скiльки воно на акб проживе.
Ну i нажухать, що резервування є - також можуть запросто.
-
Я б почав з того, що у вас gepon olt та gpon onu.
Ну і якщо ця ону вміє працювати і як gepon (в специфікаціях це не заявлено) - я б подивився рiвень ONU Tx level та OLT Tx level. Бо так не зрозуміло або це з оптикою проблеми, або несправний лазер в ону, або в олт модуль +++.
-
Спробуйте іншу gpon sfp.
- 1
-
Цитата
Я не поновод, но знаю, что в ОНУ веб-морда есть.
И айпишник тоже назначается для управления.
И никто реально это не делает?
Я при тестах деяких ону - заходив на їхній web-інтерфейс. Там можна переглядати статус ону. Ті ж рівні оптичних сигналів і т.д. Можна оновити прошивку.
є і деякі налаштування. Наприклад той же dhcp-сервер включити і перевести в режим роутера (тільки у мене сумніви стосовно того - як воно буде працювати). Ще є якісь налаштування безпеки/фейрволл (принцип роботи якого не зрозумілий). Можно налаштували vlan на eth порту і т.д. Але налаштування - "жити кукуєву кількість часу" немає)))).
-
Цитата
Прошло +- 30 дней и к нам приехал представитель Укртелекома подписывать Публичный договор оферты или как-то так, точно не помню.
Вот вы этот договор и внимательно прочитайте. Там должно быть четко прописано, что провайдер вам должен, а что нет.
ЦитатаТак что мешает тогда поставить пароль и дать его соседям чтобы пользовались?
Я точно не знаю как у Укртелекома - но у большинства провайдеров в договоре есть пункт, согласно которому абоненту запрещается раздавать интернет. При нарушении этого условия - провайдер в одностороннем порядке имеет право разорвать договор.
То есть как вам писали ранее - если Укртелеком это заметит, то можете остаться без интернета вовсе.
Что касается работы интернет провайдеров - вам нужно понять один момент. Это бизнес. Никто не будет вам предоставлять интернет себе в убыток. Бизнес должен приносить прибыть.
Сейчас цены растут на все - потому вполне закономерно, что и вам абонплату поднимают. И то, что где-то абонплата больше, а где-то меньше - вполне объяснимо. Например до одного села нужно тянуть кабель 2 км, а до другого 10км - провайдеру же никто не продаст 10км кабеля по цене как за 2км. Это будет влиять и на конечную стоимость. Так же влияет кол-во абонентов. Провайдеру нужно поставить какое-то конечное оборудование, в которое он будет включать абонентов. Это оборудование имеет какую-то стоимость(само оборудование + его обслуживание) не зависимо от того - будет в него включен 1 или 5 абонентов. И таких нюансов очень много. Ну и опять же влияет конкуренция. Если кроме укртелекома нет никого, то зачем им давать вам дешевый тариф и ничего не зарабатывать, вы же все равно к другому провайдеру не уйдете.
Я бы на вашем месте пробовал искать альтернативы - обзванивать провайдеров, которые есть в соседних селах и т.п.
- 2
- 1
-
Цитата
Після того, як прописуєш в конфігурацію ONU loopback-detection recovery-time (10 - 65535) - рядок не з'являється в конфігурації ONU.
Можливо хтось стикався з подібним та зможе підказати вирішення?
Не знаю на якому софті у вас OLT - але у себе на OLT я не бачу можливості налаштувати loopback-detection recovery-time для ону.
У мене доступно:
epon onu port 1 loopback detect epon onu port 1 ctc loopback detect epon onu port 1 ctc notify loopback
Начебто бачив можливість налаштування такого на других OLT, але не на BDCOM P3310C / P3608-2TE.
В даному випадку loopback-detection - це функціонал який апаратно реалізований на ону. Тобто саме ону відправляє лупбекдетекшен фрейми.
Тому в вашому випадку можна спробувати:
- На деяких ону loopback-detection recovery-time можна налаштовувати з web-інтерфейсу ону;
- Поміняти прошивку на ону;
- Якщо прошивки, на якій цей функціонал працює як треба - нема, то довбати виробника ону(щоб зробили прошивку з потрібним recovery-time).
- Забити болт. Добре, якщо loopback-detection взагалі працює.
-
Цитата
а почему у вас микрот маршрутизирует 10.90.0.90 во все вланы?
Кто сказал, что маршрутизирует? Анкнов юникаст летит себе по всем интерфейсам бриджа и все..
-
Цитата
Не совсем понятно зачем? Релеит бдком, на дхсп сервер, зачем ещё и на шлюзе это делать?
Т.к. вы сами писали, что на бдком релей нормально не работает - я вам предложил вариант релеить на шлюзе, то есть убрать ip helper на бдкоме и настроить на шлюзе. А не релеить на двух девайсах одновременно.
Цитатаl2 не вариант, на dhcp клиентские вланы не нужны, они и так будут на шлюзе, еще и кашу городить на dhcp. остановился пока на варианте l3 на olt, пока только непонятна ситуация как olt себя поведет при нагрузке.
Вы же что бы побороть один костыль - делаете другой.
- 1
-
Цитата
посоветовали поднимать dhcp сервер на шлюзе в каждом влане да и все, но так не получится, шлюз это оттдельный физический сервер а dhcp это другой
Ну так поднимите на шлюзе не dhcp сервер, а dhcp relay(dhcp-helper).
-
Не совсем так. Точнее совсем не так! Ну, по крайней мере, в моих случаях: последние 4 байта серийника онушки абсолютно не зависят от её mac. Опять же, от слова совсем. Пример: GP3600-16B, серийник фоксгейтовской онушки FGXP:00664429, а последние цифры mac, на минуточку, 3f:8c.
Хм... странно. Я тестировал на нескольких разных ону и там оно совпадало. Единственное это все xpon ону, которые работают на epon и gpon
Но в любом случае спасибо за информацию - буду иметь ввиду.
-
Теперь вопрос про 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) и первый виртуал порт.
- 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-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 !
- 1
-
Какое-то описание у вас дурацкое - читаешь и ничего не понятно. По какому критерию вы определяете, что lan порт ону не работает?
Я бы предположил, что в этом порту не поднимается линк - но в вашем же комментарии есть вывод команды "show gpon interface gpoN 0/1:1 onu port 1 state", которая говорит что линк есть.
P.S. - прошивка 10.3.0D build 81888 кривая. Там есть проблемы с применением onu-vlan profile - вроде как этот баг исправлен на 89045.
-
Хз сработает ли для модели 3510-28f, но у других моделей edge-core - если подключится консольным кабелем к коммутатору и просто его ребутнуть - при загрузке в определенный момент появляется сообщение
Press [P] to print out the detail provision
Если в этот момент на коммутатор отправить "P" - то он собственно выведет конфиг(сможете скопировать), который загружает. Но пароль там будет в зашифрованном виде.
- 1
- 1
-
2 часа назад, Kirjan сказал:
Здравствуйте.
Раз тут столько знатоков, подсобите, пожалуйста.
Есть два коммутатора, все с настроенным мультикастом, один из них Querier.
По факту наблюдаем следующее:
когда приёмник-передатчик потока сидят на коммутаторе Querier, всё норм;
но когда приёмник(и)-передатчик(и) пересаживаем на второй коммутатор ( non-Cuerier ), наблюдаем суммарное количество пакетов, уходящее по "аплинку" к коммутатору Querier,
примерное равное пакетам всех передатчиков мультикаста.
Ну и это количество пакетов также видим, как входящее в коммутатор Querier,
в котором нет ни одного приёмника, кроме патчкорда, соединяющего коммутаторы.
И сам вопрос - это нормально, или нет? Когда все пакеты идут к Querier коммутатору, забивая весь канал связи.
Если нет, то как это можно интерпретировать, для общения с забугорной техподдержкой?
И в чём именно может быть проблема, или её можно как-то вылечить?
Разбирайтесь как работает igmp snooping. Например почитайте rfc 4541
The switch supporting IGMP snooping must maintain a list of multicast routers and the ports on which they are attached. This list can be constructed in any combination of the following ways: a) This list should be built by the snooping switch sending Multicast Router Solicitation messages as described in IGMP Multicast Router Discovery [MRDISC]. It may also snoop Multicast Router Advertisement messages sent by and to other nodes. b) The arrival port for IGMP Queries (sent by multicast routers) where the source address is not 0.0.0.0. The 0.0.0.0 address represents a special case where the switch is proxying IGMP Queries for faster network convergence, but is not itself the Querier. The switch does not use its own IP address (even if it has one), because this would cause the Queries to be seen as coming from a newly elected Querier. The 0.0.0.0 address is used to indicate that the Query packets are NOT from a multicast router. c) Ports explicitly configured by management to be IGMP-forwarding ports, in addition to or instead of any of the above methods to detect router ports.
Если первый коммутатор отправляет IGMP Queries - то на втором коммутаторе порт, который смотрит в сторону первого коммутатора должен числится как мультикаст роутер для соответствующего vlan-id.
2.1.2. Data Forwarding Rules 1) Packets with a destination IP address outside 224.0.0.X which are not IGMP should be forwarded according to group-based port membership tables and must also be forwarded on router ports. This is the main IGMP snooping functionality for the data path. One approach that an implementation could take would be to maintain separate membership and multicast router tables in software and then "merge" these tables into a forwarding cache
Весь мультикаст трафик, который не относится к 224.0.0.0/24 или IGMP должен отправляться в мультикаст роутер порты.
-
Обратный трафик и не должен ходить через через http-redirect.
У вас сервер 192.168.168.6 с роутером взаимодействует через интерфейс, который скорее всего находится в inet.0, но никак не в http-redirect - там интерфейсов быть не может. Вот и обратный трафик у нас должен тогда ходить в inet.0.
-
День добрый.
Главный вопрос - зачем Access-internal маршруты вам нужны в forwarding?
Тут или я не понимаю, что вы хотите сделать - или вы не понимаете что такое instance-type forwarding, для чего он нужен и как он работает.
Из вашего конфига в vrf type forwarding должен быть только один маршрут - к 192.168.168.6.
-
Не знаю как BDCOM P3616-2TE, но что бы оно работало на на 3310B/C я настраивал следующим образом.
Что бы все пролезло.
system mtu 1976
Аплинк:
interface GigaEthernet0/5 switchport trunk vlan-allowed 8,25,237 switchport trunk vlan-untagged none switchport mode dot1q-tunnel-uplink
epon порт:
interface EPON0/1 switchport mode dot1q-translating-tunnel switchport pvid 25 switchport trunk vlan-allowed add 25
Далее глобально на самом олт(тут точно не помню, но если предварительно не настроить аплинк - есть вероятность, что потеряете управление к олту):
dot1q-tunnel
Далее настройка ону. То, что вы привели в примере - это когда от абонента прилетает нетегированный трафик и на ону навешивается тег 250. Тегированного трафика от абонента там быть не может. Что бы от абонента получать тегированный трафик и потом добавлять на него второй тег с влан 25 - нужно настраивать так:
interface EPON0/1:1 epon onu port 1 ctc vlan mode trunk 100 200,300,500
В данном примере если от абонента прилетит нетегированный трафик - то ону добавит тег 100, а потом олт добавит второй тег 25. Так же на порту разрешены тегированные вланы 200,300 и 500. Олт на них тоже добавит второй тег с vlan-id 25. Но эти вланы(200,300 и 500) как бы нужно согласовывать с клиентом.
Что бы вланы с клиентом не согласовывать - ону можно настраивать так:
interface EPON0/1:1 epon onu port 1 ctc vlan mode transparent
В конфиге оно отображаться не будет(т.к. это дефолтные настройки). При этом через езернет порт ону будет разрешен теггированный трафик с любым vlan-id. Второй вариант чреват последствиями - вы же не будите использовать целый epon порт olt, для включения одного клиента? Там будут другие ону с другими вланами. И как бы возможен такой исход, что клиент из epon0/1:1 захочет использовать такой же vlan-id, как вы назначили на epon0/1:2 или epon0/1:3. И если так случится - ничего хорошего из этого не выйдет. Ну и к этому клиенту будет лететь броадкаст из ваших вланов не зависимо от того использует он их или нет.
Ну и опять же - если для других ону под этим epon портом вы хотите использовать другие вланы, то при конфиге выше - олт и на другие вланы добавит второй тег с vlan-id 25. Что бы на другие вланы второй тег не добавлять можно настроить:
interface EPON0/1 switchport trunk vlan-allowed add 237 switchport dot1q-translating-tunnel mode flat translate 237 237 0 (или switchport dot1q-translating-tunnel mode flat translate 1to1 237 237 0)
Но тут есть ограничение. Таких вланов, на которые олт не будет добавляться второй тег - можно настроить ограниченное количество.
И еще один важный момент. Если вы используете ip dhcp-relay snooping + ip verify source например для vlan-id 237 - не уверен, что оно будет работать при использовании QinQ
- 4
- 2
-
tiger.blob - это драйвер пон-интерфейсов. Я сомневаюсь что он с:
SQL error: mB
связан. У олта в памяти еще лежит файл config.db - вот его попробуйте удалить. В нем конфиги для llid хранятся - олт его должен пересоздать если выполнить команду write database или write all
- 1
-
Привет.
Точно так же - в конфиге порта добавляете командой lacp.
Конфиг портов, которые будут входить в один и тот же порт-ченел должен быть одинаковый и скорость линка.
К какому портченелу относится линк - коммутатор сам определит по LACP PDU.
Vty-0# show running-config interface ethernet 1/25 interface ethernet 1/25 no negotiation switchport broadcast packet-rate 1000 switchport allowed vlan add 1 untagged switchport ingress-filtering switchport acceptable-frame-types tagged switchport mode trunk switchport allowed vlan add 3010-3016 tagged lacp ! Vty-0# show running-config interface ethernet 1/26 interface ethernet 1/26 no negotiation switchport broadcast packet-rate 1000 switchport allowed vlan add 1 untagged switchport ingress-filtering switchport acceptable-frame-types tagged switchport mode trunk switchport allowed vlan add 3010-3016 tagged lacp ! Vty-0# show running-config interface ethernet 1/27 interface ethernet 1/27 no negotiation switchport broadcast packet-rate 1000 switchport multicast packet-rate 1000 switchport allowed vlan add 1 untagged switchport ingress-filtering switchport acceptable-frame-types tagged switchport mode trunk switchport allowed vlan add 2020-2024,3010-3016 tagged lacp ! Vty-0# show running-config interface ethernet 1/28 interface ethernet 1/28 no negotiation switchport broadcast packet-rate 1000 switchport multicast packet-rate 1000 switchport allowed vlan add 1 untagged switchport ingress-filtering switchport acceptable-frame-types tagged switchport mode trunk switchport allowed vlan add 2020-2024,3010-3016 tagged lacp ! Eth 1/25 Up 1 0 10Gfull 10GBASE SFP+ 2 Eth 1/26 Up 1 0 10Gfull 10GBASE SFP+ 2 Eth 1/27 Up 1 0 10Gfull 10GBASE SFP+ 1 Eth 1/28 Up 1 0 10Gfull 10GBASE SFP+ 1 Trunk 1 Uplink Up 1 0 10Gfull 10GBASE SFP+ 1 Trunk 2 Downlink Up 1 0 10Gfull 10GBASE SFP+ 2
- 1
-
Крутил что-то похожее.
Только без диплексора - просто оптический вход + RF выход. Так ему если на вход подавать большую оптическую мощность (где-то -2 дБм, если не изменяет память) - то вроде даже нормально работает. Но стоит понизить уровень оптической где-то на 3 децибела - аналоговое ТВ работает очень плохо, с очень сильным шумом, а DVB-C - так вообще сигнал не лочит.
У депса в характеристиках написано: Рабочий уровень входного оптического сигнала -18…0 дБм - как-то слабо верится.
-
Цитата
Сама голова, я так понимаю, этого делать не умеет?
Вы той командой настраиваете шторм-контрол на первом езернет порту onu, соответственно и реализуется оно на onu.
На голове можно настроить:
Switch# config Switch_config#interface ePON 0/1 Switch_config_epon0/1#storm-control broadcast threshold ? <1-655350> -- Enter Integer part of storm suppression level(PPS) Switch_config_epon0/1#storm-control broadcast threshold 128
Но это ограничение как бы будет на весь epon-port.
Возможно вам поможет если настроить:
Switch#config Switch_config#filter enable Switch_config#filter threshold arp 20 Switch_config#interface ePON 0/1 Switch_config_epon0/1#filter arp
Там вроде он подсчитывает кол-во arp-ов для конкретного мак-адреса. Хотя я точно не уверен - проверять нужно. Но если это так и от клиента все летит с одного мак-а - может помочь.
Посмотреть можно:
Switch#show filter
-
Привет.
Если мне не изменяет память, то настройки типа:
epon onu port 1 storm-control mode 4 threshold 256
Аппаратно реализуются на самой ону. И могут просто не поддерживаться или криво работать на какой-то прошивке.
ZTE C620 error 222377
в PON
Опубліковано: · Відредаговано khatgit
Була схожа проблема на с610 при спробі зареєструвати ону (також була помилка %Error 222377: Not enough resources).
Але там по виводу show resource було видно, що уперлися в ліміт. Через дистрибьютора зверталися до сапорту вендора - вирішилося встановленням патчу, який збільшував значення в resource.