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

qelso

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

    29
  • Joined

  • Last visited

About qelso

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

Recent Profile Visitors

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

  1. @Victor Tkachenko, @ShyLion, спасибо!
  2. @Victor Tkachenko, спасибо за ответ. Планируется допиливать HA? Если да, то какие сроки?
  3. @Victor Tkachenko , проконсультируйте, пожалуйста по сабжу. Интересный момент, в описании и гайдах есть VSF в качестве стека, однако, специалист из коммерческого отдела уточнил эту информацию у отдела развития, ему ответили что ПО S2995G на данный момент не поддерживает High Availability стекирование. Кому верить?
  4. @ShyLion, вариант с dhcp relay + option 82 + isc dhcp тоже прорабатываем, но, скорее всего, клиент не согласится, т.к. бюджетное предприятие, не ясно кто будет обслуживать dhcp сервер и будет ли под него машина/виртуалка, к тому же по деньгам там не разгуляешься. Хотелки в первом посте. Конечно, если dhcp сервер на SNR вообще "никакой", то будет предлагать выносить его на отдельный сервер.
  5. Доброго всем времени суток! Хотим собрать ядро на L3 свитчах в среднего размера организации (~250 компьютеров, ~15 серверов). Организация из тех где нужно импортозамещение. От ядра нужно немного: -терминация L3 (svi) для подсетей -dhcp сервер этих подсетях -маршрутизация (хватит и статической) -резервирование (VRRP или стэк) Не спрашивайте почему так, заказчику этого достаточно, остальная инфраструктура, вроде, уже есть (NAT, Firewall и т.п.) Наткнулся на этого "зверя" SNR-S2995G-12FX, судя по характеристикам умеет много, цена просто отличная. Понятно что это ОЕМ из Китая, но ничего плохого в этом не вижу (есть опыт работы с 2990G, 2970) Собственно просьба и вопросы: Те кто уже использовал/использует поделитесь, пожалуйста, отзывами об этом свитче. Нет ли откровенных глюков или сложностей с ним? Можно ли запускать несколько dhcp серверов в разных вланах? Все ли в порядке с роутингом? Насколько стабилен и удобен VSF (стэк)? Или все-таки лучше юзать VRRP? Также интересны комментарии инженеров из НАГа, если тут таки есть, то, пожалуйста, не стесняйте, ответьте на эти же вопросы)
  6. @v_r, не знаю, пока нет времени продумывать это. Пусть пока так работает. Но за совет, спасибо. Тему можно считать закрытой.
  7. @Mystray, @orlik, чтобы клиенты из этого vrf могли ходить только на разрешенные хосты. Решили пока забить, т.к. ничего страшного не должно произойти. Но за наводку спасибо, буду иметь ввиду.
  8. @v_r , спасибо. Но мне это не подходит, данный джун не ABR. Не смотря на это попробовал заюзать area-range вместе с network-summary-import - не помогло.
  9. @vvertexx , верное замечание. Сразу не обратил внимание, LSA5 фильтруются. Помимо разрешенных в policy-options маршрутов, прилетают LSA 3, которые согласно policy-options, не должны попадать в таблицу. Видимо, @orlik прав: The filtering is done only on external routes in OSPF. The intra-area and interarea routes are not considered for filtering. Коллеги подсказывают: "you are correct in that you cannot filter intra-area routes with the ospf import statement. However, you could configure the routes as martians under routing-options to prevent them from being installed in the routing table." Но что-то не хочется городить. Есть идеи, помимо the routes as martians? Или смириться?
  10. Привет всем! Столкнулся с проблемой, не работает policy-options на import маршрутов в ospf. Juniper MX80, JUNOS 12.3R4.6 routing-instances { NextOne { instance-type vrf; interface xe-0/0/0.4015; interface xe-0/0/0.4019; protocols { ospf { export ospf-vrf-NextOne-export; import ospf-vrf-NextOne-import; area 0.0.0.0 { interface xe-0/0/0.4015 { metric 150; authentication { md5 19 key "***"; ## SECRET-DATA } } interface xe-0/0/0.4019 { metric 150; authentication { md5 20 key "***"; ## SECRET-DATA } } } } } } } policy-options { policy-statement ospf-vrf-NextOne-import { term 1 { from { protocol ospf2; route-filter 83.167.66.225/32 exact; route-filter 83.167.66.226/32 exact; route-filter 10.100.101.118/32 exact; route-filter 83.167.66.1/32 exact; route-filter 83.167.66.5/32 exact; route-filter 83.167.66.9/32 exact; route-filter 83.167.66.10/32 exact; route-filter 83.167.66.16/32 exact; route-filter 83.167.66.19/32 exact; route-filter 83.167.72.1/32 exact; route-filter 83.167.81.1/32 exact; route-filter 83.167.88.1/32 exact; route-filter 10.100.101.44/30 orlonger; route-filter 83.167.65.0/24 orlonger; route-filter 83.167.66.160/29 orlonger; route-filter 83.167.66.164/30 orlonger; } then accept; } term 2 { then reject; } } } Но в NextOne.inet.0 попадают маршруты, которые не должны туда попадать Пробовал менять policy: policy-options { policy-statement ospf-vrf-NextOne-import { term 2 { then reject; } } Однако, в NextOne.inet.0 попадают все те же маршруты. Ребята-джуноводы, помогите, пожалуйста, советом. Как отфильтровать import ospf маршруты?
  11. ShumBor, pppoetest, Victor Tkachenko, спасибо за советы! На данный момент поднял 1G линк (отдельным волокном) между snr и другим ядром. И забираю по нему только мультикаст. На mx80 убрал 4040 и igmp. Ошибки упали в разы, клиенты довольны. Схема временная. На 7600 ядрах QoS настроен, на Juniper нет, не дошли руки. В другой ветке форума Джуноводы также посоветовали настроить QoS.
  12. Спасибо! Ребят, а в общем конфиг IGMP+PIM что я кинул верный? В продакш можно оставлять? Telesis , что посоветует по QoS? Есть какие-то подводные камни или там все по учебнику?
  13. QoS на MX80 не настроен. Вроде как QoS не поддерживается на встроенных 10G интерфейсах, кроме них в джуне нет других. Поправьте если ошибаюсь.
  14. Всем доброго времени суток! Имею Juniper MX80 в качестве ядра, с него же вещается iptv в сторону клиентов. На MX80 настроены PIM (в сторону ядер с источниками мультикаста, xe-0/0/3.4046 и xe-0/0/2.4045) и IGMP (в сторону агрегаций и свитчей доступа, xe-0/0/1.4040). Juniper является igmp querier'ом. На агрегациях и доступе только igmp snooping, без querier'a. Некоторые пользователи жалуются на рассыпание картинки. Утилизация портов в норме, до пика далеко. Думал проблема в агрегации или доступе, однако, на других ядрах (Cisco 7600) вроде все нормально. Конфиг на агрегациях и на доступе (что работают либо через MX80, либо через 7600) одинаков. Что наводит на мысль о проблеме на MX80. Поделитесь, пожалуйста, конфигом, советом, лучшей практикой для Juniper MX80 IGMP+PIM. Мой конфиг: xe-0/0/1 { description to_agg; vlan-tagging; encapsulation flexible-ethernet-services; unit 4040 { vlan-id 4040; family inet { address 10.48.48.1/20; } } } protocols { igmp { maximum-transmit-rate 10000; interface xe-0/0/1.4040 { version 2; promiscuous-mode; } } pim { rp { static { address 10.10.10.1 { group-ranges { 238.1.0.0/18; } override; } address 10.20.20.1 { group-ranges { 239.32.0.0/18; } override; } } } interface lo0.0 { mode sparse; version 2; } interface xe-0/0/1.4040 { mode sparse; version 2; } interface xe-0/0/3.4046 { mode sparse; version 2; } interface xe-0/0/2.4045 { mode sparse; version 2; } } }