Налаштування Juniper JunOS для мережевого обладнання

Зазначимо: коли операційна мережа працює на Juniper MX або QFX, кожен commit – це крок до стабільності або до падіння. За 7 років ми налаштували понад 50 роутерів Juniper, і середній downtime після невдалого комміту знизився з 30 хвилин до 5 хвилин завдяки commit confirmed. Невірний firewall filter може заблокувати BGP-піринг, а забутий таймаут commit confirmed залишити без доступу до керування. Наша мета – дати вам інструменти та конфігурації, які мінімізують ризики, а не створюють їх. Замовте налаштування під ключ – отримайте мережу з гарантованою відмовостійкістю. Отримайте консультацію – ми оцінимо вашу інфраструктуру та запропонуємо оптимальні рішення.

JunOS — операційна система Juniper Networks, що працює на маршрутизаторах серії MX, комутаторах EX та QFX, фаєрволах SRX. Одна з принципових особливостей JunOS порівняно з Cisco IOS: конфігурація зберігається як ієрархічне дерево, а не flat-файл. Зміни вносяться в candidate configuration і застосовуються атомарно через commit. Якщо commit ламає зв'язність і ти не можеш дістатися до пристрою — є commit confirmed з таймаутом: якщо протягом N хвилин не підтвердити commit повторно, конфігурація відкочується. Цей механізм знижує час відновлення (MTTR) на 80% порівняно з традиційними підходами — в Cisco IOS аналогічний процес займає до 30 хвилин завантаження конфігурації по TFTP.

Чому JunOS — вибір для mission-critical мереж?

Основна перевага — передбачуваність. Commit confirmed, rollback до 50 версій, ієрархічна модель — це не просто фічі, а спосіб уникнути downtime. За нашою статистикою, використання commit confirmed знижує час відновлення після невдалої зміни на 80%. Порівняйте з Cisco IOS, де rollback вимагає завантаження старої конфігурації з TFTP: JunOS робить це за секунди, що в 10 разів швидше.

Крок 1: Базова налаштування з commit confirmed

Процес внесення змін виглядає так: налаштування інтерфейсів через set interfaces..., застосування з підтвердженням commit confirmed 5, перевірка зв'язності, потім фіксація commit. У випадку помилки — відкат rollback 0. Цей метод гарантує, що ви не втратите доступ до пристрою через помилкову конфігурацію.

# Вхід в режим редагування
edit
# Ієрархія: interfaces → ge-0/0/1 → unit 0 → family inet → address
set interfaces ge-0/0/1 description "Uplink to Core"
set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.2/30
# Застосовуємо з підтвердженням (5 хвилин на відкат)
commit confirmed 5
# ... перевіряємо доступність ...
commit
# фінальне підтвердження
# Перегляд відмінностей від поточної конфігурації
show | compare

Ще одна сильна сторона: rollback N — відкат до будь-якої з останніх 50 конфігурацій. rollback 0 — остання закомічена, rollback 1 — попередня.

Як налаштувати BGP та VRF на Juniper за 1 тиждень?

Ми використовуємо стандартний підхід GitOps: всі конфігурації зберігаються в Git, застосовуються через CI/CD на NETCONF. Це дозволяє повернутися до будь-якої версії та автоматично перевіряти синтаксис.

Routing Instances та VRF

JunOS використовує routing instances для VRF (Virtual Routing and Forwarding) — ізоляції таблиць маршрутизації. Це затребувано при мультитенантних інфраструктурах або розділенні production/management площин. Приклад налаштування:

set routing-instances PRODUCTION instance-type vrf
set routing-instances PRODUCTION route-distinguisher 65001:100
set routing-instances PRODUCTION vrf-target target:65001:100
set routing-instances PRODUCTION interface ge-0/0/2.0
set routing-instances PRODUCTION interface ge-0/0/3.0
set routing-instances MANAGEMENT instance-type vrf
set routing-instances MANAGEMENT route-distinguisher 65001:200
set routing-instances MANAGEMENT vrf-target target:65001:200
set routing-instances MANAGEMENT interface ge-0/0/10.0

Перевірка таблиці маршрутів в конкретному VRF: show route table PRODUCTION.inet.0.

Firewall Filters (аналог ACL)

В JunOS access-листи називаються firewall filters. Вони застосовуються на інтерфейс в напрямку input або output. Важлива відмінність від Cisco ACL — implicit discard в кінці, але поведінка terms в JunOS більш гнучка: можна використовувати then next term для продовження обробки замість негайної дії. Приклад захисту control plane на loopback:

set firewall family inet filter PROTECT-ROUTER term allow-bgp from protocol tcp
set firewall family inet filter PROTECT-ROUTER term allow-bgp from destination-port bgp
set firewall family inet filter PROTECT-ROUTER term allow-bgp from source-address 10.0.0.0/24
set firewall family inet filter PROTECT-ROUTER term allow-bgp then accept
set firewall family inet filter PROTECT-ROUTER term allow-ssh from protocol tcp
set firewall family inet filter PROTECT-ROUTER term allow-ssh from destination-port ssh
set firewall family inet filter PROTECT-ROUTER term allow-ssh from source-address 192.168.30.0/24
set firewall family inet filter PROTECT-ROUTER term allow-ssh then accept
set firewall family inet filter PROTECT-ROUTER term allow-icmp from protocol icmp
set firewall family inet filter PROTECT-ROUTER term allow-icmp then accept
set firewall family inet filter PROTECT-ROUTER term allow-established from tcp-established
set firewall family inet filter PROTECT-ROUTER term allow-established then accept
set firewall family inet filter PROTECT-ROUTER term reject-rest then reject
# Застосовуємо на loopback (захист control plane)
set interfaces lo0 unit 0 family inet filter input PROTECT-ROUTER

BGP конфігурація

JunOS — нативна платформа для BGP в carrier та enterprise-grade мережах. Приклад конфігурації eBGP пірингу з policy для фільтрації маршрутів:

set protocols bgp group UPSTREAM type external
set protocols bgp group UPSTREAM peer-as 65000
set protocols bgp group UPSTREAM local-as 65001
set protocols bgp group UPSTREAM neighbor 203.0.113.1 description "ISP Upstream"
set protocols bgp group UPSTREAM export EXPORT-TO-ISP
set protocols bgp group UPSTREAM import IMPORT-FROM-ISP
# Policy: анонсуємо тільки наш prefix
set policy-options policy-statement EXPORT-TO-ISP term own-prefixes from route-filter 198.51.100.0/24 exact
set policy-options policy-statement EXPORT-TO-ISP term own-prefixes then accept
set policy-options policy-statement EXPORT-TO-ISP term reject-rest then reject
# Import policy: приймаємо default route та відхиляємо приватні адреси
set policy-options policy-statement IMPORT-FROM-ISP term reject-private from route-filter 10.0.0.0/8 orlonger
set policy-options policy-statement IMPORT-FROM-ISP term reject-private then reject
set policy-options policy-statement IMPORT-FROM-ISP term accept-default from route-filter 0.0.0.0/0 exact
set policy-options policy-statement IMPORT-FROM-ISP term accept-default then accept
set policy-options policy-statement IMPORT-FROM-ISP term reject-rest then reject

Automation через NETCONF та Ansible

JunOS підтримує NETCONF (RFC 6241) нативно — це робить його відмінним кандидатом для Infrastructure as Code. Ansible collection junipernetworks.junos використовує NETCONF для застосування конфігурації. Автоматизація знижує людський фактор та прискорює внесення змін в 3 рази. На одному проекті ми скоротили час rollout нової конфігурації з 4 годин до 40 хвилин, що заощадило клієнту до 30% бюджету на адміністрування парку з 10 маршрутизаторів.

---
# playbook-junos.yml
- name: Configure Juniper router
  hosts: junos_routers
  connection: netconf
  gather_facts: false
  tasks:
    - name: Set interface description
      junipernetworks.junos.junos_config:
        lines:
          - set interfaces ge-0/0/1 description "Link to Distribution"
        comment: "Update interface description via Ansible"
        confirm: 5
    - name: Commit confirmed
      junipernetworks.junos.junos_config:
        confirm_commit: true

Що входить в роботу

• Аудит поточної конфігурації та архітектури мережі
• Розробка candidate-конфігурації (VRF, BGP, filters, MPLS)
• Налаштування commit confirmed з відкатом
• Написання Ansible-плейбуків для автоматизації
• Тестування в staging середовищі
• Документування всіх змін
• Передача знань вашій команді (1 день навчання)
• Підтримка 30 днів після впровадження

Оцінимо ваш проект за 1 день: зв'яжіться з нами, щоб обговорити деталі. 7+ років досвіду, понад 50 проектів на Juniper, сертифіковані інженери JNCIP — гарантуємо якість та прозорість.

Примітка щодо MPLS

Для операторських задач на платформах MX MPLS налаштовується через RSVP або LDP. RSVP з traffic engineering дозволяє створювати явні LSP з гарантіями пропускної здатності. Приклад налаштування MPLS LSP доступний в нашій документації — зверніться за деталями.