lirikoff

Добрый день. Попала в руки OLT C-Data FD1208S (fw 1.4 свежая) Столкнулся с тем, что шаблоны можно применять только к уже зарегистрированным ONU Однако в тех же C-DATA 11-й серии была возможность применить шаблоны ко всему дереву PON сразу. Пока что удалось найти лишь такой вариант применения OLT(config-interface-epon-0/0)# ont add 1 1 loid-auth 1234 ont-lineprofile-id 5 ont-srvprofile-id 5 OLT(config-interface-epon-0/0)# ont add 1 1 mac-auth 11:11:11:11:13:11 ont-lineprofile-id 5 ont-srvprofile-id 5 Если кто-нибудь сталкивался - сориентируйте есть ли в этой OLT возможность применить шаблоны на дерево целиком ? Спасибо

актуально

Товарищи, крайне необходимы примеры конфигурации по OLT FHL104C , в топике есть пост от wglazyrin , он писал, что располагает различной документацией Однако возможность написать ЛС самому автору заблокирована. Может кто-то еще сталкивался с этим зверем ?

Опыт работы в IT/Телеком - 7 лет. Старший инженер подразделения NOC За это время было разработано и внедрено множество проектов, среди которых: Разделение структуры операторской сети , для терминирования пользовательских широковещательных доменов на уровне агрегации. Повышение отказоустойчивости узлов агрегации на уровнях L1/L2/L3 - комбинирование LACP+BGP+OSPF Внедрение механизма защиты от широковещательных штормов без использования наиболее распространенного протокола spanning-tree. Защита операторской сети от несанкцианированного доступа как с пользовательской стороны, так и извне, без использования ACL Планирование и запуск сетевой структуры жилых комплексов с обеспечением отказоустойчивости по протоколу ERPS Получение лицензии на предоставление услуг VoIP, совместно с прохождением сертификации у надзорных органов внедрение в эксплуатацию проектов VoIP различной сложности Внедрение Multicast IPTV в операторскую сеть с нуля. Планирование и запуск проектов по обеспечению бесшовных WIFI зон ( wireless roaming) А также Прохождение процедуры регистрации новой операторской сети в RIPE Database и ее запуск в эксплуатацию с нуля BGP peering - подключение автономных систем к операторской сети, балансировка трафика, BGP blackhole Подключение распределенных объектов к сети оператора на уровне L3 Робота с сетевым оборудованием: Настройка L2/L4 коммутаторов независимо от вендора. Большой опыт работы с маршрутизаторами Cisco ASR 1000 series и Cisco Catalyst 6500 series различных конфигураций. Большой опыт работы с различим ассортиментом оборудования Mikrotik (SOHO маршрутизаторы, wireless-мосты, мощные маршрутизаторы серии CCR и тп) Хорошее знание Mikrotik RouterOS, в частности особенностей работы BGP/OSPF и подсистемы маршрутизации в целом. Опыт глубокого анализа трафика с помощью wireshark и tcpdump С радостью приму участие в различных масштабных (и не очень) проектах, связанных с сетевой инфраструктурой. Заинтересован только в удалённой работе. Контакты telegram: @hatterfix skype: hatterfix hatterfix@yandex.ru https://www.linkedin.com/in/hatterfix/

Добрый день. Регистрируемся в RIPE. В первичной форме есть поле Registration authority, непонятно что в нем указывать если статус юр. лица ООО/ЗАО И верно ли я понимаю, что в поле Valid legal registration document закрепляется выписка из ЕГРЮЛ ? Спасибо

hatter@atom:~$ traceroute 208.91.60.94 traceroute to 208.91.60.94 (208.91.60.94), 30 hops max, 60 byte packets 1 name (x.x.x.x) 0.457 ms 0.425 ms 0.491 ms 2 172.20.20.2 (172.20.20.2) 1.817 ms 2.219 ms 2.520 ms 3 172.30.30.2 (172.30.30.2) 7.193 ms 7.437 ms 10.246 ms 4 uplink (addr) 15.045 ms 15.254 ms 16.066 ms 5 addr (addr) 10.673 ms 11.220 ms 12.027 ms 6 addr (addr) 12.579 ms 10.453 ms 9.582 ms 7 6-1-5.bear1.Russia2.Level3.net (213.242.122.141) 29.363 ms 29.409 ms 29.661 ms 8 ae-1-60.edge3.Washington4.Level3.net (4.69.149.18) 142.146 ms 141.237 ms ae-2-70.edge3.Washington4.Level3.net (4.69.149.82) 142.593 ms 9 ae-1-60.edge3.Washington4.Level3.net (4.69.149.18) 141.803 ms 141.282 ms ae-2-70.edge3.Washington4.Level3.net (4.69.149.82) 142.544 ms 10 NETWORK-STR.edge3.Washington4.Level3.net (4.53.116.90) 141.126 ms 141.247 ms 140.817 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 *^C hatter@atom:~$ ping 208.91.60.94 PING 208.91.60.94 (208.91.60.94) 56(84) bytes of data. 64 bytes from 208.91.60.94: icmp_seq=1 ttl=246 time=137 ms 64 bytes from 208.91.60.94: icmp_seq=2 ttl=246 time=136 ms 64 bytes from 208.91.60.94: icmp_seq=3 ttl=246 time=137 ms ^C --- 208.91.60.94 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 136.963/137.060/137.159/0.434 ms

Усе, особенности route-reflectot - из-за того что next-hop приходит от источника, где есть сеть чистый next-hop self на reflector-client не применяется но если отдавать роут мап с префиксом и set ip next hop -атрибут меняется, все проходит, пингуется и трассируется Ядро show ip cef exact-route x.x.x.x 208.91.60.94 x.x.x.x -> 208.91.60.94 => IP adj out of VlanX, addr 172.20.20.2 Прозрачный роутер x.x.x.x -> 208.91.60.94 => IP adj out of FastEthernet0/0.Y, addr 172.30.30.2 border x.x.x.x -> 208.91.60.94 => IP adj out of GigabitEthernet0/3.Z, addr uplink

Апдейт: убрал adv-map за ненадобностью, т к сети анонсируются в обе стороны при использовании route-reflector client на прозрачном роутере в сторону обоих neighbor Но появилась еще одна незадача, если на ядре посмотреть маршрут пакета то он почему-то уходит в ноль show ip cef exact-route x.x.x.x 208.91.60.94 x.x.x.x -> 208.91.60.94 => Null0 ( откуда он берется, на всякий случай проверил проверил - маршрута нет) Снова обращу внимание: на ядро от прозрачного прилетает 208.91.60.94/32 c next hop 172.30.30.2, применение next hop self результата не дает

Попробовал добавить adv-map - анонс не идет, хотя статус активный show ip bgp neighbors 172.20.20.1 | include Condition-map Condition-map from-out, Advertise-map to-in, status: Advertise конф neighbor 172.20.20.1 advertise-map to-in exist-map from-out ip prefix-list from-out seq 5 permit 208.91.60.0/22 ip prefix-list to in seq 5 208.91.60.94/32 route-map from-out permit 10 match ip address prefix-list from-out route-map to-in permit 10 match ip address prefix-list to-in

Интерфейс, апдейты по ним проставлены

copy-attributes уже добавлены, вывод show ip bgp уже с ними. Ранее,на момент когда выкладывал конфиг, было без них

show ip bgp 208.91.60.94 BGP routing table entry for 208.91.60.94/32, version 4 Paths: (1 available, best #1, table default) Not advertised to any peer x y z o, (injected path from 208.91.60.0/22) 172.30.30.2 from 172.30.30.2 (x.x.x.x) Origin IGP, metric 0, localpref 100, valid, internal, best теперь думаю над тем как injected сделать видимым в sh ip route...

СТАТИКА НЕ НУЖНА, специально ж это отметил даже )

Готовые решения никто, конечно не отменял, но , например, некоторые компании, предоставляющие свои системы фильтрации, используют в них как раз-таки инъектирование маршрутов, в случае , если реализация идет без зеркалирования всего трафика на железо. А любое готовое решение стоит денег, хотя каких-либо сверхсекретных механизмов в нем нет. Отталкиваясь от этого, я считаю, весьма оправданным поиск альтернативных решений. Тем более кто гарантирует, что в готовых решениях отсутствуют подводные камни.

Собственно сама цель всех плясок с бубном основывается на требованиях роскомндадзора по фильтрации ресурсов. Планируется ткнуть прозрачный роутер между ядром и пограничником, и используя анонсирование /32 в сторону ядра заруливать запросы на ресурсы реестра на данный роутер, внутри которого соответственно проходила бы необходимая обработка. Тестово использую кошку, чтоб проработать схему. Статика совсем не интересна. И не думаю, что стоит сразу лишаться рук за подобное. Если у вас есть наработки в плане подробного руления, или какие-либо другие решения, как отделить трафик из реестра от основного потока - буду только благодарен за инфо.

В том то и дело, что нету там префикса ни статикой, ни на интерфейсе, т к при null0 или же активном интерфейсе пакет естественно уходит в них. А в моем случае необходимо, чтобы роутер выступал прозрачно, по факту получая большой префикс /22 от одного, а далее с помощью inject из этого префикса вычлиняется /32, заносится в таблицу и уже этот /32 должен анонсироваться дальше. Подчеркну, именно префикс /32 Собственно конфиг: bgp inject-map INJECT exist-map MATCH-THIS network x.x.x.x mask 255.255.255.255 neighbor 172.20.20.1 activate neighbor 172.20.20.1 prefix-list inner in neighbor 172.20.20.1 prefix-list outer out neighbor 172.30.30.2 activate exit-address-family ip prefix-list INJECT seq 5 permit x.x.x.x/32 ! ip prefix-list LEARNED seq 5 permit y.y.y.y/22 ! ip prefix-list ROUTE-SOURCE seq 5 permit z.z.z.z/32 route-map INJECT permit 10 set ip address prefix-list INJECT route-map MATCH-THIS permit 10 match ip address prefix-list LEARNED match ip route-source prefix-list ROUTE-SOURCE show ip bgp BGP table version is 6, local router ID is 172.20.20.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>io.o.o.o/23 172.20.20.1 0 100 0 i * ix.x.x.x/22 z.z.z.z 0 100 0 a b c d i * ix.x.x.x/32 z.z.z.z 0 ? show ip bgp injected-paths BGP table version is 6, local router ID is 172.20.20.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * ix.x.x.x/32 z.z.z.z 0 ? 172.20.0.0/16 is variably subnetted, 2 subnets, 2 masks C 172.20.20.0/29 is directly connected, FastEthernet0/0.70 L 172.20.20.2/32 is directly connected, FastEthernet0/0.70 172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks C 172.30.30.0/29 is directly connected, FastEthernet0/0.90 L 172.30.30.1/32 is directly connected, FastEthernet0/0.90 o.o.o.o/23 is subnetted, 1 subnets B o.o.o.o [200/0] via 172.20.20.1, 00:16:33 PS: Просьба модераторам одобрить пару моих сообщений , чтобы можно было продолжать обсуждение, спасибо.

Естественно имеется. Анонс , тем не менее, не уходит

Появилась задача анонсировать соседнему роутеру префикс /32 по BGP внутри AS Для решения решил применить injected route на основе route-map с префиксами После некоторого времени плясок с бубном /32 в таблице BGP появился, но в adv routes не уходит (анонсирую префиксом). Вопрос: как анонсировать ?

Спасибо, попробуем, о результатах отпишусь. А насчет проблем с MAC-адресами нет информации? Кстати, в 1,4,0,0 не отображаются медные линки через веб-интерфейс

Добрый день. За последнее время выявили несколько проблем с коммутаторами 3528M-V2 1) У коммутаторов с прошивкой V1.2.0.6 на 248-й день аптайма гаснет линк на входящем оптическом порту, помогает просто переподключить оптический модуль - линк поднимается, перезагрузка не требуется. Оборудования попадало много - было довольно неприятно. 2) При перепрошивке на версию 3,2,2 в некоторых случаях после перезагрузки -- гастнут линки на абсолютно всех портах, горит только power и diag, помогает повторная перезагрузка. -- через 30-40 секунд после загрузки перестает пинговаться, все линки активны, помогает перезагрузка 3) Не видит маки на порту, от которого подключен еще один коммутатор - при этом оба работают нормально. Кто сталкивался? Есть ли решения ? с чем может быть связано ?

Добрый день. Интересует ваше мнение о различных моделях SIP Мини АТС, кто чем пользуется, плюсы и минусы. Также интересует мнение о конкретной модели Grandstream UCM6102, если кто использовал.

Суть в том, что почти везде пишется про избыточные соединения и задействование резервных каналов... А если их нет ? Меня же интересует реализация возможности отключения порта на уровне агрегации в том случае, если на уровне доступа образовалось кольцо(либо между соседним оборудованием, либо в пределах портов одного коммутатора

И все-таки хотелось бы понять в правильном ли направлении я мыслю Смотрите, если брать касательно указанной на рисунке сети( с учетом что в ядре только один роутер R2) выходит, что 1) для такой сети R2 нужно сделать корнем( в терминологии Designated Root Bridge) 2) Далее на коммутаторах D4 и D5 выставляются корневые порты(Root Port - т. е. порты подключенные к R2) 3)т к D4 и D5 обслуживают разные подсети(в каждой подсети свои VLAN), то каждый из них нужно сделать назначенным мостом(Designated Bridge) т к владелец этого статуса считается главным в обслуживании данного сегмента локальной сети 4) Все порты коммутаторов D4 и D5 , к которым подключено оборудование уровня доступа, нужно сделать назначенными портами(Designated Port) Все ли верно или же я ошибаюсь? И еще остаются несколько моментов - следует ли как-то дополнительно настраивать VLAN для STP И как верно расставить веса(применительно к указанной схеме)

Добрый день. Имеется такой вопрос: Появилась необходимость защитить сеть от вероятности возникновения колец. Сеть разбита на Vlan'ы В иерархии на уровне ядра и агрегации стоят CISCO, а на уровне доступа, как-правило, Edge-Core Задача состоит в том, чтобы , в случае возникновения кольца на уровне доступа(Между двумя Edge-Core ) исключить вероятность распространения кольца на уровень агрегации. Схематично примерно так - только на уровне явдра один роутер Петля выделена черным между S4 и S5, соответственно отражено распространение на уровень агрегации D3 Нужно понять как можно использовать STP для решения поставленной задачи. Может кто сталкивался с подобными проблемами. Поделитесь решением или маиериалами.