Jump to content
Калькуляторы

lirikoff

Пользователи
  • Content Count

    24
  • Joined

  • Last visited

About lirikoff

  • Rank
    Абитуриент

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Добрый день. Попала в руки 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 возможность применить шаблоны на дерево целиком ? Спасибо
  2. Товарищи, крайне необходимы примеры конфигурации по OLT FHL104C , в топике есть пост от wglazyrin , он писал, что располагает различной документацией Однако возможность написать ЛС самому автору заблокирована. Может кто-то еще сталкивался с этим зверем ?
  3. Опыт работы в 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/
  4. Добрый день. Регистрируемся в RIPE. В первичной форме есть поле Registration authority, непонятно что в нем указывать если статус юр. лица ООО/ЗАО И верно ли я понимаю, что в поле Valid legal registration document закрепляется выписка из ЕГРЮЛ ? Спасибо
  5. 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
  6. Усе, особенности 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
  7. Апдейт: убрал 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 результата не дает
  8. Попробовал добавить 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
  9. Интерфейс, апдейты по ним проставлены
  10. copy-attributes уже добавлены, вывод show ip bgp уже с ними. Ранее,на момент когда выкладывал конфиг, было без них
  11. 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...
  12. СТАТИКА НЕ НУЖНА, специально ж это отметил даже )
  13. Готовые решения никто, конечно не отменял, но , например, некоторые компании, предоставляющие свои системы фильтрации, используют в них как раз-таки инъектирование маршрутов, в случае , если реализация идет без зеркалирования всего трафика на железо. А любое готовое решение стоит денег, хотя каких-либо сверхсекретных механизмов в нем нет. Отталкиваясь от этого, я считаю, весьма оправданным поиск альтернативных решений. Тем более кто гарантирует, что в готовых решениях отсутствуют подводные камни.
  14. Собственно сама цель всех плясок с бубном основывается на требованиях роскомндадзора по фильтрации ресурсов. Планируется ткнуть прозрачный роутер между ядром и пограничником, и используя анонсирование /32 в сторону ядра заруливать запросы на ресурсы реестра на данный роутер, внутри которого соответственно проходила бы необходимая обработка. Тестово использую кошку, чтоб проработать схему. Статика совсем не интересна. И не думаю, что стоит сразу лишаться рук за подобное. Если у вас есть наработки в плане подробного руления, или какие-либо другие решения, как отделить трафик из реестра от основного потока - буду только благодарен за инфо.