prohoji

Тут на форуме постоянно возникают вопросы об использовании китайского PON (OLT и ONT). Вроде оно работает, вполне даже неплохо. Однако меня вот напрягает эксплуатация сети на китайском железе в долгосрочной перспективе. К примеру, китайцы взяли и перестали производить данную линейку оборудования. Или в новой версии головы забили на совместимость со старыми абонентскими терминалами. Этот момент очень напрягает. В эзернете то все уже более-менее устаканилось и на доступ можно ставить что угодно от кого угодно лишь бы работало нормально. Эзернет то у всех одинаковый. А с PON как быть? Особенно если речь идет не о Huawei или Ericsson, а о всяком ноунейме. Вот тут http://forum.nag.ru/forum/index.php?showtopic=109910 человек ковыряется в железке с паяльником чтобы прикрутить к голове сторонние OLT... Что-то это напрягает в дальнейшей перспективе.

Прошивка подходит, да. У QTECH она даже поновей наговской. Только вот название и модель у меня тоже поменялась. Только мак остался тот же. Вот пациент: http://c2n.me/3qrQ429.jpg А вот что он сам о себе думает: QSW-2800-10T-AC Device, Compiled on Oct 21 14:46:39 2015 sysLocation Tvintel CPU Mac f8:f0:82:10:20:d5 Vlan MAC f8:f0:82:10:20:d4 SoftWare Version 7.0.3.5(R0217.0124) BootRom Version 7.1.3 HardWare Version 1.0.1 CPLD Version 1.2 Serial No.:SW003710D712000281 Copyright (C) 2015 by QTECH LLC All rights reserved Last reboot is warm reset. Uptime is 0 weeks, 3 days, 22 hours, 16 minutes NAME LEN VALUE ------------ ----- ------------------------------ SwitchName 15 QSW-2800-10T-AC VersionPre 0 VendNameEn 9 QTECH LLC VendNameBr 9 QTECH LLC VendWWW 20 http://www.qtech.ru/ VendLocate 43 Russia, Moscow, Novozavodskaya st 18, bld 1 CopyRight 31 Copyright (C) 2015 by QTECH LLC VendContact 12 www.qtech.ru WebLogo 2641 WebLogin 44384 WebFacebd 12701 WebBG 12701 WebLang 2 en VendorOid 17 1.3.6.1.4.1.27514 DeviceOid 26 1.3.6.1.4.1.27514.1.1.1.48 KeyNeed 4 0 BaseMac 6 00 1f ce 10 b0 00 CliStyle 3 0 HsrpNeed 4 0 DevType(ID) 4 18 ChassisCard 0 FileVersion 6 10.9.3 IMGPrefix 0 RomPrefix 0 HardWarePre 0 Prompt 0 UserName 0 PassWord 0 ManageIP 0

Да это понятно. Мы на китае вообще l3 не держим. Только циска, только хардкор. Это я просто к сведению написал. А вообще у меня циски используются как терминаторы абонентских вланов (dhcp + ip unnumbered), китай типа snr/qtech как л2-выносы на районах. Либо просто как sfp-коммутатор в одном шкафу с л3-свитчем. Так что от них надо хорошо уметь все что связано с л2, а л3 разве что для менеджмента нужен.

А с speed negotiation проблем не было? Сейчас собрал стенд. Пытаюсь поднять линк с SNR-S3650. Лампочка загорается, в логе вижу что трансивер воткнут, а порт не поднимется. Пробую воткнуть в циску 3750. Порт поднялся только после того как со стороны циски прописал жестко speed nonegotiate.

Добрый день! Кто использует эти коробки, поделитесь мнениями как они? Сеть IPoE, опция 82 + vlan на группу свитчей. Абоны l3-connected. Сейчас используем штук 150 SNR-2960/QTECH-2800 на доступе. Ну и наговские 2980/3650/2990 как л2-выносы. Вполне годные коробки. Как по надежности, так и по безглючности. 2910 видимо построен на каком-то другом чипсете и непонятно как себя поведет. Взял на пробу пару 24-портовых и пару 48-портовых. Сейчас вот сижу, тыкаю CLI. Честно говоря какой-то он dlink-style. Попробуем основные фичи настроить и потестить на стенде (storm control, dhcp snooping, ip source guard и т.д.). Правда как показывает практика, если на стенде все ок, то не значит, что в реальной жизни все будет так же.

Вот конфиг пиров: group external-peers { type external; advertise-inactive; log-updown; neighbor x.x.x.x { description BGP-ASxxxx; import [ allow-default allow-fw deny-bogons deny-private-as drop-all-other ]; export [ allow-us-22 allow-us-23 next-hop-self drop-all-other ]; peer-as xxxx; } neighbor y.y.y.y { description BGP-ASyyyy; import [ allow-default allow-fw deny-bogons deny-private-as drop-all-other ]; export [ allow-us-22 next-hop-self drop-all-other ]; peer-as yyyy; } } Вот show bgp neighbor по одному из аплинков: Peer: x.x.x.x+179 AS xxxxx Local: x.x.x.x+54430 AS xxxx Description: ASxxxx Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ allow-us-22 next-hop-self drop-all-other ] Import: [ allow-default allow-fw deny-bogons deny-private-as drop-all-other ] Options: <Preference AdvertiseInactive LogUpDown PeerAS LocalAS Refresh> Holdtime: 90 Preference: 170 Local AS: xxxx Local System AS: xxxx Number of flaps: 0 Peer ID: 10.0.0.19 Local ID: xx.xx.xx.xx Active Holdtime: 90 Keepalive Interval: 30 Group index: 2 Peer index: 0 BFD: disabled, down Local Interface: ge-1/0/1.0 NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Stale routes from peer are kept for: 300 Peer does not support Restarter functionality NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as xxxx) Peer does not support Addpath Table inet.0 Bit: 10002 RIB State: BGP restart is complete Send state: in sync Active prefixes: 63242 Received prefixes: 557652 Accepted prefixes: 557652 Suppressed due to damping: 0 Advertised prefixes: 2 Last traffic (seconds): Received 0 Sent 17 Checked 6 Input messages: Total 122679 Updates 122499 Refreshes 0 Octets 11696368 Output messages: Total 192 Updates 2 Refreshes 0 Octets 3767 Output Queue[0]: 0 Trace options: none Trace file: /var/log/bgp.log size 0 files 3

Добрый день! Есть один juniper mx. На него приходят 2 fill view от аплинков. Иногда надо менять анонсы своих сетей аплинкам с целью балансировки входящего трафика. Т.е. править export policy на нейборах. Очень напрягает, что при коммите происходит полный разрыв сессии с нейбором и последующий влив full view. Можно ли как-то управлять анонсами без разрыва сесии?

Добрый вечер! Хочу побить сеть на VRF чтобы отдельно маршрутизировать менеджмент и клиентов. Сейчас в сети крутиться OSPF, циски редистрибьютят в ядро connected-сети и все хорошо. Но все в одной таблице маршрутизации, что не очень удобно в плане управления доступом и т.д. Клиенты подключены через ip unnumbered + dhcp. Есть немного статики. Могу ли я внутри каждого VRF-а запустить свой процесс OSPF и вообще чем это чревато? И будет ли внутри vrf нормально работать ip unnumbered + dhcp и редистрибьюция dhcp-маршрутов через OSPF?

А, ну я так и понял. Покурил форумы - видимо не я один такими вопросами задавался. Удивительно, что на достаточно старых 3750 все работает замечательно.

Добрый день! Втыкнул в шеститонник несколько НАГовских CWDM SFP. Работают нормально, но по ним не видно DDM. Циска на sh int gi3/18 transceiver говорит, что Module 3 doesn't support DOM. При этом те же модули стояли в 3750 и там все было хорошо. Это какое-то ограничение шеститонника или я что-то делаю не так? Карточка WS-X6748-SFP, IOS 12.2(33)SXI13. На соседней карточке WS-X6708-10GE DDM на SFP+, воткнутых в коверторы X2->SFP+ работает нормально. Это какое-то ограничение карточки 6748 или я что-то делаю не так?

К сожалению возможности поменять оборудование нет. Специфика организации такова, что этот процесс растянется но длительное время. А завести такую схему надо уже сейчас.

По l2 не получится т.к. /24 сетка нарезана на кучку /30 - /28 сетей. Плюс между сетками ходит много трафика. Так что тащить это все на бордер не очень хочется.

Добрый день! Сразу извиняюсь за глупый вопрос. Есть вот такая сетка: Сейчас весь трафик между ядром и бордером ходит через шейпер. Т.е. как из интернета в локалку, так и из локалки в интернет. Шейпер (линуксовый сервак с кваггой) анонсирует в ядро дефолт с бОльшим локал-преференсом и поэтому трафик от абонентов ходит именно через него в обход прямого линка. Аналогично шейпер анонсирует в бордер маршруты до локальной /22 сетки с большим локал преференсом и поэтому трафик к абонентам идет от бордера в ядро именно через шейпер. Таким образом если шейпер падает, то трафик от и к клиентам начинает просто ходить по прямому линку. Сейчас возникла необходимость пустить одну /24 сетку в обход шейпера. И тут возник затык. Допустим я анонсирую одну /24 сетку из ядра прямо в бордер. Входящий трафик пойдет мимо шейпера. А как быть с исходящим? Дефолт то у меня анонсируется один. Просто нужный выбирается путем установки локал преференса. Знаю, что вопрос глупый. Но я над ним уже целый день ломаю голову, но ничего кроме как использовать PBR не придумал...