prosto_mail

Забыл за TPLink - гавно неимоверное... с прошивками бяда, и с CPU тоже - на пустом месте 100% В работе: T1600G-28TS TP-Link T2600G-28 TS 2.0

Не кошмарьте! А то сон люди потеряют.... ухудшится здоровье. Указанная Вами проблема — это банальная нехватка пропускной способности... а не микробёрсты... Давайте посмотрим на схему (должна понравиться многим ;)): INTERNET <-10G-> CCR1036 (бордер) <-10G-> QFX-5100 (ядро) <-10G-> CRS328-4C-20S-4S+RM (агрегация) <-1G-> RB260GS (уровень доступа) <-1G-> AC1200 (хомячок) И теперь два варианта за которые платит хомячок: 1. 100 гривен за 100 мегабит - откуда взяться микробёрстам? Бордер нарежит соточку.... у хомячка гигабит... можно конечно сюда добавить и ещё 20 хомячков... но это уже перегруз канала в гигабит... ))) 2. 700 гривен за гигабит... по сути гигабит тоже дойдёт без приключений... но тут есть нюанс [передаём пламенный привет мультикасту ))))] Нюанс заключается в том, а что же такое на самом деле микробёрс? Микробёрст(microburst). Это такой очень короткий период времени, когда количество принимаемых устройством данных становится больше чем интерфейс способен отправить. т.е. для того чтобы получить микробёрст на 10G интерфейсе.... нужно чтобы чихнуло 11 портов на 1g (к примеру...), а в случае аплинка на гигабит.... или два гигабитных порта или опять же таки 11 стомегабитных... Таким образом микробёрст с подавляющей вероятностью может оказывать влияние на трафик ОТ КЛИЕНТА.... И начинается он на роутере AC1200 ))) потом может перейти на RB260... а если народ таки напряжётся - то и до CRS328 дойдёт.... Но тут нужно понимать чем таки отличается МИКРОБЁРСТ от ПЕРЕГРУЗКИ.... По мне - ситуация что микробёрст оказывает такое влияние, что рассыпается мультикаст или игры плющит менее вероятна по сравнению с ситуацией: "когда рак на горе свистнет". Помимо того что такую ситуацию призван сглаживать буфер коммутатора, есть ещё мнение что с этим можно бороться ещё с помощью CoS... Но тут есть подводные камни: трафик нужно маркировать... чем? у меня свичи доступа трафик фильтруют... какая ещё маркировка.... С другой стороны если сеть построена на PPPoE, L2TP, PPTP - то тут то и маркировать нечего... С третьей - абон подымает туннель до своего сервера, а там внутри VoIP... Да и сам VoIP может по разным портам ездить... В конечном итоге механизм CoS то ещё удовольствие... А вот что действительно может сказываться на VoIP, играх.... на том что не буфферизируется, так это Head-of-line blocking (в кратце) Как конкретный свич справляется с microburst & Head-of-line blocking может рассказать механизм работы кэша(а не его размер) и другие примочки для борьбы с указанными эффектами, а это знают только инженеры которые проектируют коммутационную матрицу. Нам же суждено только экспериментально понять насколько оно глючное... ;) Теперь что касается рекомендаций по оборудованию. 1. Разделяй и властвуй. Самый лучший вариант - вилан на абонента, вновь передаём пламенный привет мультикасту... И этот пункт красноречиво говорит - что нужна хорошая топология сети, а не 10 коммутаторов в паровозике... 2. Свич без консольного порта - простая мыльница. 3. Де юре - CISCO (не LinkSys.. ) является стандартом отрасли... но со времён 2511 есть один нюанс - нужен правильный IOS... Де факто - Juniper круче (FreeBSD foreva!). 4. Отдельно упомянем буфер свича. QFX5100 Ethernet Switch: Intelligent Buffer Management: The QFX5100 switches have a total of 12 MB shared buffers. While 25% of the total buffer space is dedicated, the rest is shared among all ports and is user configurable. The intelligent buffer mechanism in the QFX5100 effectively absorbs traffic bursts while providing deterministic performance, significantly increasing performance over static allocation. В кратце: а фих его знает как оно работает.... но фсё будет пучком... QFX5200 Switch Тут уже скромно: Total packet buffer16 MB (QFX5200-32C) & 22 MB (QFX5200-48Y) Повторюсь: никакого буфера не хватит чтобы трафик с 20 одногиговых портов впихнуть в один 10Ж порт... и важен механизм работы этого кэша(о котором мы ничего не знаем). Но да, в свете всего выше перечисленного лучше брать те модели у которых кешь больше... и если она ПРОДОЛЖИТЕЛЬНОЕ время не страдает фигнёй - значит не прогадали... и можно брать дальше. 5. Поддержка софта. Можно понабирать хуавеев... хыпы.... деллов... а потом не знать где найти прошивку чтоб полечить проблему... За 20 лет эксплуатации разного оборудования - самая адекватная поддержка - это D-Link. Huawey - нужно к кому-то идти на поклон. Mikrotik - можно связаться и добиться подтверждения проблемы в адекватные сроки... но вот решение проблемы - сроки не адекватные. Какой свич взять в ядро - тут только два варианта: Juniper (причина описана выше), CISCO. С поддержкой такого рода оборудования - туго... Ну и третий вариант - на что денег хватит... но это не правильно... Свичи для агрегации и доступа... просто пройдёмся по известным брендам: D-Link: самый лучший свич - это des-3526, но бяда с конденсаторами... серия des-3028 - самая провальная из-за проблемы хэширования. серия des-1210 - тормоз, в общем работает... но список исправлений напрягает... серия des-32xx - нравится, в модели DES-3200-28F при установке гиговых модулей в порты от 1 до 24-го обязательно зажать скорость на 100/full-duplex серия DGS-36xx - гуд! используем как L3. У этих свичей можно поднять 100 мегабитный линк в гиговом оптическом порту (модуль 1g): серия DGS-3420-XX/SC - используем как L3 - в зависимости от прошивки чудеса начинались от 1200 абонов на свич... DGS-3000-28SC - кушать не просит DGS-1510-28XS/ME - кушать не просит DGS-3120-24SC - кушать не просит DXS-1210-xxx - гавно... нельзя узнать что за модуль стоит, нет ddm D-Link для меня лучше всех остальных из-за сапорта, простоты настройки (серия ME, а где циско-лайк CLI - ужос, управлять оборудованием через WEB - моветон...) и фильтрации трафика - луче нигде нет... Во время когда utorrent переходил на UDP протокол очень выручала фильтрация PacketContent... Из приколов: теперь у меня есть два модуля DEM-310GT, потому как дэлинк на отрез отказывался признавать проблему со свичами DGS-1510-20L/ME. С модулями - признал и оперативно исправил... Huawey, HP S2326TP-EI - гораздо лучше JD320B, хотя казалось бы... одно и тоже железо..., нельзя проверить длинну кабеля. S6324-EI - рабочая лошадка, не без сюрпризов... найти прошивку на хуавейные свичи то ещё занятие... EdgeCore ECS4210-12T - он очень маленький. вот проверка длинны кабеля (хотя кабеля нет): sh cable-diagnostics interface ethernet 1/5 TF : Test failed OK : OK ON : Open IAS: Intra-Short IRS: Inter-Short NT : Not tested NS : Not supported UN : Unknown Port Type Link Pair A Pair B Pair C Pair D Last Status meters meters meters meters Update -------- ---- -------- -------- -------- -------- -------- ------------------- Eth 1/ 5 GE Down NT (0) NT (0) NT (0) NT (0) А вот тут кабель есть: sh cable-diagnostics interface ethernet 1/1 TF : Test failed OK : OK ON : Open IAS: Intra-Short IRS: Inter-Short NT : Not tested NS : Not supported UN : Unknown Port Type Link Pair A Pair B Pair C Pair D Last Status meters meters meters meters Update -------- ---- -------- -------- -------- -------- -------- ------------------- Eth 1/ 1 GE Up NT (0) NT (0) NT (0) NT (0) Были и другие приколы с ёжиками(другими моделями).... поэтому в конечном итоге используем только ECS4210-12T в нескольких местах из-за их размера и портов. Прошивки - это боль... Вспомнил что за прикол..... в то время проверял хэширование и залил заявленное количество маков... то что их меньше - это понятно.... но вот то что их количество изменялось.... т.е свич говорит 4561 мак... делаешь тут же повторный запрос - 4500, опять спрашиваешь... 4543... опять запрос - 4542... естественно никакого трафика на свич не было... Запросы были заданы свичу после работы nemesis. На этом и закончилось общение с эджекорами.... DELL,HP,Juniper Надцать лет назад выбирали 10G в ядро.... Победил qfx5100-48s-6q, DELL-HP на фоне Juniper выглядели бледно. Mikrotik Тут можно брать роутеры и wifi... свичи от микротика - ни в коем разе брать нельзя... они не от мира сего... исключением может быть свич с пое - если нужно запитать по пое другие микроты... ну или RB260GS - 35$ за 5 гиговых портов и один модульный... когда начинает его плющить - ставим des-1210-10/ME и проблема уходит... Экзотические: Фаундари, BDCOM, Элтекс.... Фаундари в своё время любил УарНет... Элтекс - росийское.... со всеми вытекающими BDCOM - только не свичи... ИТОГ: Волков бояться - в лес не ходить... И не поступать как в анекдоте: отрывает Петька мухе все ноги (крылья оторваны изначально) и говорит: — Муха, ПОЛЗИ! А муха не ползёт.... из чего делает заключение: "При отрывании всех ног, муха теряет слух". P.S. Это ещё не рассматривалась проблема с хэшированием.... ? P.P.S по большому счёту порекомендовать что либо - трудная задача по простой причине: у тебя оборудование используется так(такой функционал), а у спрашивающего - совсем по другому и в другой топологии сети... У всех свичей проблемы.... потому важна поддержка и тестирование... а не то что у кого-то оно "пашет и есть не просит".

Спасибо. Проблема с пропаданием конфигурации онушек не решается... Не всё так однозначно... Новая прошивка ставиться тогда когда в старой точно есть баги с которыми столкнулись или в новой прошивке есть функционал необходимый в работе... Но вот что однозначно - вендору фиолетовы проблемы клиентов... ибо выпускать глючные прошивки - эт перебор... Особенно нравиться то что оказывается откатится назад уже нельзя....

А у кого-нибудь есть прошивка для P3310C новее 10.1.0E 36957?

Есть ли у кого прошивка для P3310C новее Version 10.1.0E Build 36957? Ибо на этой прошивке голова теряет конфигурацию онушки после загрузки по пропаданию питания... Онушки бидикомовские, других нет. Теряет по странному: когда теряет одну строку вида "epon onu port 1 ctc vlan mode tag 3038 priority 0", когда от конфига остаётся только это: Current configuration: ! interface EPON0/2:62 А на попытку ввести конфигурацию вручную, выдаёт такое: This ONU(EPON0/2:62) is not auto-configured. Are you sure to use absent-config-mode(y/n)?

Нашёл для P3310C MIB Температура модулей: .1.3.6.1.4.1.3320.101.107.1.6 Уровень сигнала от OLT на ONU - такойже как и у P3310B: .1.3.6.1.4.1.3320.101.10.5.1.5 Уровень сигнала от ONU на OLT: .1.3.6.1.4.1.3320.101.108.1.3 На всякий случай список интерфейсов: .1.3.6.1.4.1.3320.9.64.4.1.1.2 Остаётся только сохранение конфигурации по SNMP и сброс на TFTP по тому же SNMP - кто-то это знает?

А кто-нибуть может подсказать по SNMP для BDCOM P3310C, интересует (привожу так как это делается на P3310B): Сохранить конфигурацию: snmpset -v2c -c ksee 192.168.0.79 .1.3.6.1.4.1.3320.20.15.1.1.0 i 1 Сохранить на TFTP: snmpset -v2c -c ksee 192.168.0.79 .1.3.6.1.4.1.3320.101.20.1.1.2.1 i 2 snmpset -v2c -c ksee 192.168.0.79 .1.3.6.1.4.1.3320.101.20.1.1.3.1 a 192.168.0.111 snmpset -v2c -c ksee 192.168.0.79 .1.3.6.1.4.1.3320.101.20.1.1.6.1 s startup-config snmpset -v2c -c ksee 192.168.0.79 .1.3.6.1.4.1.3320.101.20.1.1.7.1 s 0000 snmpset -v2c -c ksee 192.168.0.79 .1.3.6.1.4.1.3320.101.20.1.1.8.1 i 2 Уровень сигнала от ONU на OLT .1.3.6.1.4.1.3320.9.183.1.1.5.x Уровень сигнала от OLT на ONU .1.3.6.1.4.1.3320.101.10.5.1.5.x Температура модуля: .1.3.6.1.4.1.3320.9.183.1.1.13

Замерил потребляемую мощность, получается: 100-110 mA - просто включена онушка. 130-140 mA - если подключить к ней комп. Прокачка трафика на скорости 100 fullduplex (в обе строноы одновременно) потребление мощности не изменила.

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

Спасибо за пояснение! Была такая догадка... Хорошо, отмазка по первой команде принимается. Обратим внимание на вывод второй команды: show epon interface epon 0/3:3 onu ctc optical-transceiver-diagnosis received power(DBm): -34.0 А мы знаем, что чувствительность приёмника онушки задекларирована в -26Dbm. Вот и возникает резонный вопрос - как она может работать при уровне сигнала в -34Dbm.... И второй момент. Сегодня получили партию BDCOM P1501C1 с блоками питания 12V 0.5A. До этого были 12V 1A. Поставщик аргументирует тем что из-за снижения цен на ону она комплектуется худшим блоком питания... Дай бог чтобы только ним, но возникает резонное ощущение что с новым блоком питания онушка может работать плохо по простой причине - не хватает мощности блока питания... Так хватит или в притык? А может не хватит?

А как такое может быть? sh epon optical-transceiver-diagnosis interface epon0/3:3 interface RxPower(dBm) ----------- -------------- epon0/3:3 -38.2 show epon interface epon 0/3:3 onu ctc optical-transceiver-diagnosi operating temperature(degree): 42 supply voltage(V): 3.3 bias current(mA): 14.5 transmitted power(DBm): 1.4 received power(DBm): -34.0 show epon interface epoN 0/3:3 onu ctc basic-info ONU Vender ID : BDCM ONU MODEL ID : 151C ONU ID : fcfa.f7ec.4f24 Hardware Version : A0 Software Version : 10.0.17A 1017 Firmware Version : 0x0006000f00010006 Chipset Vendor ID : CS Chipset MODEL ID : 0x8032 Chipset Revision : 160 Chipset Date : 11/01/29 Onu type : SFU Support multillid : Not supported Protection type : Not supported Number of Pon : 1 Number of slot : 0 Support 1 types of port: Number of GE port : 1 Battery Backup : 0

СТЁРЛО! Спасибо за совет!

Будем честными - привязка нужна дабы абонент не ушёл к другому. Привязка никак не решит возврат устройства. Рассмотрим гепотетический вариант: 350 гривен подключение и девайс в аренду. Конкуренция приводит к тому что абонент имеет выбор из нескольких провайдеров у которых: 1 провайдер - подключение 1200 грн (полностью оплачивает ОНУ) 2 провайдер - 350 гривен (оплачивает часть ОНУ) 3 провайдер - 360 гривен (оплачивает часть ОНУ) 4 провайдер - 340 гивен (оплачивает часть ОНУ) Первому провайдеру привязка не нужна в принципе. А ~350 гривен - не такой уж и большой порог дабы удержать абонента. Поэтому абонента может удержать только хорошо предоставляемая услуга. Так же необходимо рассмотреть и с другой стороны - с точки зрения построения сети. Ведь тот из провайдеров кто прийдёт первым к "голодающим" без интернета абонентам - получит большое преимущество и подключать по 350 он не станет... Если человек заплатит 1200 за подключение, он будет ещё платить 350 при весьма плохой услуге... Что хорошо в BDCOM - это то что взял из коробки ONU подключил в сеть - и всё работает! А ещё делать какие-то манипуляции, лочить, разлочить - только усложнение самой лучшей схемы включения абонента! Лучше всего сконцентрироваться на роботоспособности оборудования. Вот к примеру у меня опять проблема: Есть статистика по интерфейсу (к примеру): sh interface epoN 0/3:2 Имеет вид: EPON0/3:2 is up, line protocol is up Ifindex is 86, unique port number is 13 Hardware is GigaEthernet-LLID, address is fcfa.f73a.1f11 (bia fcfa.f73a.1f11) MTU 1500 bytes, BW 1000000 kbit, DLY 2000 usec Encapsulation ARPA Full-duplex, 1000Mb/s flow-control off 5 minutes input rate 14249 bits/sec, 16 packets/sec 5 minutes output rate 211081 bits/sec, 27 packets/sec Received 57562289 packets, 14382389293 bytes 28863 broadcasts, 18698 multicasts 0 discard, 117440512 error, 0 PAUSE Вот мне её нужно стереть дабы сбросить счётчик ошибок. Команды clear interface epoN 0/3:2 - нет, а команда clear l2 counters interface epoN 0/3:2 не понятно что делает... Не ребутать же устройство! P.S. В полне возможно что я придумал почему привязка ONU будет контрпродуктивная: имеем OLT со 138 абонентами. И вот в прекрасное утро этот OLT загибается, а на его место по ряду причин ставим новый OLT который в онушках не зарегестрирвован...

Спасибо! РАБОТАЕТ! Есть ещё одна заморочка: EPON0/3:2 is up, line protocol is up Ifindex is 86, unique port number is 13 Hardware is GigaEthernet-LLID, address is fcfa.f73a.1f11 (bia fcfa.f73a.1f11) MTU 1500 bytes, BW 1000000 kbit, DLY 2000 usec Encapsulation ARPA Full-duplex, 1000Mb/s flow-control off 5 minutes input rate 17805 bits/sec, 12 packets/sec 5 minutes output rate 135105 bits/sec, 16 packets/sec Received 10468677 packets, 2018723014 bytes 5375 broadcasts, 5458 multicasts 0 discard, 100663296 error, 0 PAUSE 0 align, 0 FCS, 0 symbol 0 carriersense Received oam 103121 infomation, 0 unique, 0 duplicate 0 request, 0 response, 53 specific, 0 unsupported 0 lost Received mpcp 0 frame, 0 timeout 214574595 request, 214574595 ack, 0 report 0 gate, 0 register Transmited 18794912 packets, 23578749454 bytes 0 broadcasts, 0 multicasts 0 discard, 0 error, 0 PAUSE 0 sqettest, 0 deferred 0 single, 0 multiple, 0 excessive, 0 late Transmited oam 103932 infomation, 0 unique, 0 duplicate 0 request, 0 response, 43 specific, 0 unsupported Transmited mpcp 0 discovery window 0 request, 0 ack, 0 report 103961 gate, 1304505870 register Имеем 100663296 error (набежало за день) при том что уровни сигналов в норме: interface RxPower(dBm) ----------- -------------- epon0/3:2 -20.8 operating temperature(degree): 38 supply voltage(V): 3.2 bias current(mA): 14.3 transmitted power(DBm): 1.7 received power(DBm): -18.1 Стоит не больше полу-года: ONU Vender ID : BDCM ONU MODEL ID : 1005 ONU ID : fcfa.f7d8.b2ba Hardware Version : B0 Software Version : 10.0.16A 1037 Firmware Version : 0x0006000f00010007 Chipset Vendor ID : CO Chipset MODEL ID : 0x8032 Chipset Revision : 160 Chipset Date : 11/01/29 Onu type : SFU Support multillid : Not supported Protection type : Not supported Number of Pon : 1 Number of slot : 0 Support 1 types of port: Number of FE port : 4 Battery Backup : 0 Что бы это могло быть? И можно ли эти ошибки по SNMP получить?

Приветсвую! Подскажите пожалуйста как настроить P3310B дабы с консоли по таймауту не выкидывал?