Показаны сообщения с ярлыком Juniper EX. Показать все сообщения
Показаны сообщения с ярлыком Juniper EX. Показать все сообщения

четверг, 1 февраля 2018 г.

Juniper QFX полисить трафик транзитного VLAN

Задача: На Juniper QFX полисить трафик транзитного VLAN.

show interfaces ge-0/0/44
unit 0 {
    family ethernet-switching {
        interface-mode trunk;
        vlan {
            members [ 1 600 800-801 ];
        }
        filter {
            input ratelimit-vlan;
            output ratelimit-vlan;
        }
    }
}

среда, 6 сентября 2017 г.

Juniper EX3400 Virtual Chassis тестирование

Какие преимущества дает Virtual Chassis:
- большое количество портов доступа;
- отказоустойчивость за счет образования кольцевидной топологии включения коммутаторов (fault tolerance and high availability);
- отсутствие протокола STP;
- единый интерфейс управления всеми устройствами в VC.

Имеющееся оборудование в тесте:
2 коммутатора Juniper EX3400-48T (обычные RJ-45 порты)
1 коммутатор Juniper EX3400-48P (обычные RJ-45 порты + POE)
4 оптических трансивера QSFP+-40G-LR4 производитель - ITbiz и соответствующие патч-корды
Оптические аттенюаторы для ослабления мощности сигнала, так, как трансиверы на 10 км
1 Active Optical Cables (AOC)

Топология которая была построена:



Ключевые особенности схемы:
- Virtual Chassis порт строятся на 40 гбит/сек интерфейсах QSFP;
- режим конфигурации Virtual Chassis - Preprovisioned (в ручном режиме задано кто будет RE а кто будет Linecard);
- кольцевидное включение.

Схема установки трансиверов:
Member 0 port 0 -- AOC -- Member 1 port 1
Member 0 port 1 -- QSFP+-40G-LR4 & optical attenuator 4 dbm -- QSFP+-40G-LR4 & optical attenuator 4 dbm -- Member 2 port 1
Member 1 port 0 -- QSFP+-40G-LR4 & optical attenuator 4 dbm -- QSFP+-40G-LR4 & optical attenuator 4 dbm -- Member 2 port 0

Важно! Комфортным вариантом создания VC в Preprovisioned режиме является - подключения всех устройств между собой (в нашем случае QSFP порты уже находятся в режиме VC-Port) без включение питания, определение какой коммутатор у нас будет Master RE, составление списка всех серийных номеров коммутаторов, которые будут включаться в VC.
Далее - включаем наш Master RE, при этом все остальные коммутаторы еще выключены, настраиваем роли RE и роли Linecard на устройстве для серийных номеров, после включаем все остальные коммутаторы.

В случае правильной конфигурации, хороших оптических трансиверов, и когда все линки подняты топология будет выглядеть следующим образом:

root> show virtual-chassis

Preprovisioned Virtual Chassis
Virtual Chassis ID: 27ff.13e2.dd87
Virtual Chassis Mode: Enabled
                                                Mstr           Mixed Route Neighbor List
Member ID  Status   Serial No    Model          prio  Role      Mode  Mode ID  Interface
0 (FPC 0)  Prsnt    NXxxxxx90124 ex3400-48t     129   Master*      N  VC   1  vcp-255/1/0
                                                                           2  vcp-255/1/1
1 (FPC 1)  Prsnt    NY0xxxxx00367 ex3400-48p     129   Backup       N  VC   2  vcp-255/1/0
                                                                           0  vcp-255/1/1
2 (FPC 2)  Prsnt    NXxxxxx90029 ex3400-48t       0   Linecard     N  VC   1  vcp-255/1/0
                                                                           0  vcp-255/1/1

root> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
1/0         Configured         -1    Up           40000        1   vcp-255/1/1
1/1         Configured         -1    Up           40000        2   vcp-255/1/1

fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
1/0         Configured         -1    Up           40000        2   vcp-255/1/0
1/1         Configured         -1    Up           40000        0   vcp-255/1/0

fpc2:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
1/0         Configured         -1    Up           40000        1   vcp-255/1/0
1/1         Configured         -1    Up           40000        0   vcp-255/1/1

root> show virtual-chassis active-topology
fpc0:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  1                    1(vcp-255/1/0.32768)

  2                    2(vcp-255/1/1.32768)

fpc1:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  2                    2(vcp-255/1/0.32768)

fpc2:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  1                    1(vcp-255/1/0.32768)

root> show chassis hardware | match "fpc|Xcvr"
FPC 0            REV 17   650-059881   NXxxxxx90124      EX3400-48T
  CPU                     BUILTIN      BUILTIN           FPC CPU
    Xcvr 0       REV 01   740-032986   06Jxxxxx0212    QSFP+-40G-SR4
    Xcvr 1       REV 01   740-032986   06Jxxxxx5202     QSFP+-40G-LR4
FPC 1            REV 17   650-059857   NY0xxxxx00367      EX3400-48P
  CPU                     BUILTIN      BUILTIN           FPC CPU
    Xcvr 0       REV 01   740-032986   06Jxxxxx5201     QSFP+-40G-LR4
    Xcvr 1       REV 01   740-032986   06Jxxxxx0212    QSFP+-40G-SR4
FPC 2            REV 17   650-059881   NXxxxxx90029      EX3400-48T
  CPU                     BUILTIN      BUILTIN           FPC CPU
    Xcvr 0       REV 01   740-032986   06Jxxxxx5203     QSFP+-40G-LR4
    Xcvr 1       REV 01   740-032986   06Jxxxxx5204     QSFP+-40G-LR4

Тест 1 - Физическое извлечение из member 0 port 1 трансивера.
Активная топология перестроилась через оставшийся интерфейс.

root> show virtual-chassis active-topology
fpc0:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  1                    1(vcp-255/1/0.32768)

  2                    1(vcp-255/1/0.32768)

fpc1:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  2                    2(vcp-255/1/0.32768)

fpc2:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    1(vcp-255/1/0.32768)

  1                    1(vcp-255/1/0.32768)


Тест 2 - включение member 0 port 1 трансивера.
Активная топология вернулась к штатному режиму (member 2 с member 0 в приоритете через port 1).

root> show virtual-chassis active-topology
fpc0:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  1                    1(vcp-255/1/0.32768)

  2                    2(vcp-255/1/1.32768)

fpc1:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  2                    2(vcp-255/1/0.32768)

fpc2:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  1                    1(vcp-255/1/0.32768)

Тест 3 - физический разрыв оптического линка без изъятия трансивера между member 1 и member 2 (Member 1 port 0 -- Member 2 port 0)
Активная топология перестроилась - member 2 имеет достижимость к member 0,1 только через port 1; member 2 имеет достижимость к member 0,3 только через port 1

root> show virtual-chassis active-topology
fpc0:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  1                    1(vcp-255/1/0.32768)

  2                    2(vcp-255/1/1.32768)

fpc1:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  2                    0(vcp-255/1/1.32768)

fpc2:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  1                    0(vcp-255/1/1.32768)

Тест 4 - возврат оптического линка разорванного в тесте 3.
Активная топология вернулась к штатному кольцеобразному виду.

root> show virtual-chassis active-topology
fpc0:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  1                    1(vcp-255/1/0.32768)

  2                    2(vcp-255/1/1.32768)

fpc1:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  2                    2(vcp-255/1/0.32768)

fpc2:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  1                    1(vcp-255/1/0.32768)

Тест 5 - отключение member 1.
Member 1 и member 2 видят друг друга только через единый линк.

root> show virtual-chassis

Preprovisioned Virtual Chassis
Virtual Chassis ID: 27ff.13e2.dd87
Virtual Chassis Mode: Enabled
                                                Mstr           Mixed Route Neighbor List
Member ID  Status   Serial No    Model          prio  Role      Mode  Mode ID  Interface
0 (FPC 0)  Prsnt    NXxxxxx90124 ex3400-48t     129   Master*      N  VC   2  vcp-255/1/1
1 (FPC 1)  NotPrsnt NY0xxxxx00367
2 (FPC 2)  Prsnt    NXxxxxx90029 ex3400-48t       0   Linecard     N  VC   0  vcp-255/1/1

root> show virtual-chassis active-topology
fpc0:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  2                    2(vcp-255/1/1.32768)

fpc2:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

Тест 6 - включение member 1.
После загрузки member 1 топология вернулась к штатному состоянию.

root> show virtual-chassis

Preprovisioned Virtual Chassis
Virtual Chassis ID: 27ff.13e2.dd87
Virtual Chassis Mode: Enabled
                                                Mstr           Mixed Route Neighbor List
Member ID  Status   Serial No    Model          prio  Role      Mode  Mode ID  Interface
0 (FPC 0)  Prsnt    NXxxxxx90124 ex3400-48t     129   Master*      N  VC   1  vcp-255/1/0
                                                                           2  vcp-255/1/1
1 (FPC 1)  Prsnt    NY0xxxxx00367 ex3400-48p     129   Backup       N  VC   2  vcp-255/1/0
                                                                           0  vcp-255/1/1
2 (FPC 2)  Prsnt    NXxxxxx90029 ex3400-48t       0   Linecard     N  VC   1  vcp-255/1/0
                                                                           0  vcp-255/1/1

root> show virtual-chassis active-topology
fpc0:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  1                    1(vcp-255/1/0.32768)

  2                    2(vcp-255/1/1.32768)

fpc1:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  2                    2(vcp-255/1/0.32768)

fpc2:
--------------------------------------------------------------------------
  Destination ID        Next-hop

  0                    0(vcp-255/1/1.32768)

  1                    1(vcp-255/1/0.32768)

вторник, 28 февраля 2017 г.

Juniper DACBO (direct-attach copper breakout cables), твины, брейкаут кабеля и т.д.

Для того, чтобы получить из 40 гбит/сек (QSFP) интерфейса - 4 интерфейса 10 гбит/сек (SFP+) используются брейк-аут кабеля (direct-attach copper breakout cables).



Для начала необходимо понять, поддерживает ли конкретная модель данный тип кабеля, смотрим Interface Support for the...
В нашем примере будет QFX10002:



Далее смотрим, на каких конкретно портах поддерживается данный тип кабелей:

Конфигурация для работы DACBO кабеля выглядит следующим образом:

root> show interfaces terse | match xe- 
xe-0/0/0:0              up    down
xe-0/0/0:1              up    down
xe-0/0/0:2              up    up
xe-0/0/0:2.0            up    up   inet     10.10.10.1/24   
xe-0/0/0:3              up    down

root> show configuration chassis   
fpc 0 {
    pic 0 {
        port 0 {
            channel-speed 10g;
        }
    }
}

root> show configuration interfaces xe-0/0/0:2 
unit 0 {
    family inet {
        address 10.10.10.1/24;
    }
}

root> ping 10.10.10.10 rapid count 500 size 1453 
PING 10.10.10.10 (10.10.10.10): 1453 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- 10.10.10.10 ping statistics ---
500 packets transmitted, 500 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.367/2.531/14.736/0.825 ms

понедельник, 20 февраля 2017 г.

Juniper EX Q-in-Q

Пример конфигурации Q-in-Q на свитчах Juniper EX.


Client-Switch-01:
set version 12.3R12.4
set system host-name Client-01
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members vl-10
set interfaces vlan unit 10 family inet address 10.10.10.1/24
set vlans vl-10 vlan-id 10
set vlans vl-10 l3-interface vlan.10


EX3300-1(Q-in-Q Endpoint, Side A):
set version 12.3R12.4
set system host-name EX3300-1
set chassis alarm management-ethernet link-down ignore
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members vl-3001
set interfaces ge-0/1/0 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/1/0 unit 0 family ethernet-switching vlan members all
set protocols lldp interface all
set ethernet-switching-options dot1q-tunneling ether-type 0x8100
set vlans vl-10 vlan-id 10
set vlans vl-11 vlan-id 11
set vlans vl-12 vlan-id 12
set vlans vl-20 vlan-id 20
set vlans vl-22 vlan-id 22
set vlans vl-3001 vlan-id 3001
set vlans vl-3001 dot1q-tunneling customer-vlans 10-12
set vlans vl-3001 dot1q-tunneling customer-vlans 20
set vlans vl-3001 dot1q-tunneling customer-vlans 22
set vlans vl-3001 dot1q-tunneling customer-vlans native


EX3300-2 (Transit-Switch):
set version 12.3R12.4
set system host-name EX3300-2
set chassis alarm management-ethernet link-down ignore
set interfaces ge-0/1/0 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/1/0 unit 0 family ethernet-switching vlan members vl-3001
set interfaces ge-0/1/1 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/1/1 unit 0 family ethernet-switching vlan members vl-3001
set protocols lldp interface all
set vlans vl-3001 vlan-id 3001


EX3300-3 (Q-in-Q Endpoint, Side B):
set version 12.3R12.4
set system host-name EX3300-3
set chassis alarm management-ethernet link-down ignore
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members vl-3001
set interfaces ge-0/1/0 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/1/0 unit 0 family ethernet-switching vlan members all
set protocols lldp interface all
set ethernet-switching-options dot1q-tunneling ether-type 0x8100
set vlans vl-10 vlan-id 10
set vlans vl-11 vlan-id 11
set vlans vl-12 vlan-id 12
set vlans vl-20 vlan-id 20
set vlans vl-22 vlan-id 22
set vlans vl-3001 vlan-id 3001
set vlans vl-3001 dot1q-tunneling customer-vlans 10-12
set vlans vl-3001 dot1q-tunneling customer-vlans 20
set vlans vl-3001 dot1q-tunneling customer-vlans 22
set vlans vl-3001 dot1q-tunneling customer-vlans native


Client-Switch-02:
set version 12.3R12.4
set system host-name Client-02
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members vl-10
set interfaces vlan unit 10 family inet address 10.10.10.2/24
set vlans vl-10 vlan-id 10
set vlans vl-10 l3-interface vlan.10

Ссылка на оригинал: Configuring Q-in-Q Between Two EX3300

среда, 8 февраля 2017 г.

STP шпаргалка JNCIS-ENT

STP разработан в Institute of Electrical and Electronics Engineers (IEEE) в 1998 году. Протокол определяется стандартом 802.1D.
Основная задача STP - не допускать loop в L2 сети путем просчета оптимального места и обрыва линка в этом месте, дальнейшего контроля состояния линков для оперативной перестройки топологии в случаи изменения состояние магистральных интерфейсов.
Существующие версии STP:
- Rapid Spanning Tree Protocol (RSTP)
- Multiple Spanning Tree Protocol (MSTP)
- VLAN Spanning Tree Protocol (VSTP)

Как это работает:
- свитчи обмениваются BPDU, шлют пакеты на мультикастовый ethernet-адрес 01-80-c2-00-00-00
- выбирается root bridge
- определяются роли портов по отношению к root bridge
- строится дерево, граф

Из чего состоит BPDU:
- DST MAC multicast адрес зарезервированный для STP (01-80-c2-00-00-00)
- SRC MAC адрес исходящего интерфейса
- размер
- LLC header который имеет destination service access point (DSAP) которой относится к root bridge

BPDU не имеет никакой VLAN метки.

Существует 2 типа BPDU:
- configuration BPDUs - для определения топологии, рута, назначения портов
- TCN BPDUs - изменения топологии

Процесс определения Root Bridge базируется на значении BID, который состоит из: настроенного приоритета (Bridge ID) и уникального идентификатора устройства (МАК адреса). Чем меньше приоритет BID - тем больше шанс стать root. Если приоритеты одинаковые, выбирается наименьший МАК адрес. 
В начале выборов каждый коммутатор считает себя корневым, о чем и заявляет всем остальным с помощью BPDU, в котором представляет свой идентификатор как ID корневого свича. При этом, если он получает BPDU с меньшим Bridge ID, он перестает хвастаться своим и покорно начинает анонсировать полученный Bridge ID в качестве корневого. В итоге, корневым оказывается тот свич, чей Bridge ID меньше всех.

Роли портов в STP


- все порты на root bridge в designated и forwarding состоянии
- root порты на остальных свитчах смотрят на root bridge и находятся в состоянии forwarding, root bridge никогда не имеет root портов. Root port выбирается суммированием скорости всех интерфейсов на пусти к RB, чем выше скорость - тем меньше cost: порт 10 мбит/сек - cost = 2,000,000, порт 10 гбит/сек - cost = 2000. Если скорости одинаковые выбирается порт с меньшим значением port ID (номер порта).
- designated порты находятся в forwarding состоянии
- все остальные порты находятся в blocking состоянии. Когда порт в данном состоянии он не отправляет BPDU, но слушает входящие BPDU.

В 2004 году вышел документ IEEE 802.1D-2004, который описывает механизм RSTP. Данный протокол имеет приемущество над STP за счет быстрого процесса сходимости сети.

В RSTP меняются роли портов:
- появляется новый тип Alternate (он подстраховывает root порт и принимает BPDU) по факту это порт, который смотрит тоже на RB, но имеет cost чуть выше основного.
- Block меняется на Backup, это порт который смотрит в LAN сегмент.

Сравнение STP и RSTP:

STP (802.1d)RSTP (802.1w)
В уже сложившейся топологии только корневой свич шлет BPDU, остальные ретранслируютВсе свичи шлют BPDU в соответствии с hello-таймером (2 секунды по умолчанию)
Состояния портов
— блокировка (blocking)
— прослушивание (listening)
— обучение (learning)
— перенаправление\пересылка (forwarding)
— отключен (disabled)
— отбрасывание (discarding), заменяет disabled, blocking и listening
— learning
— forwarding
Роли портов
— корневой (root), участвует в пересылке данных, ведет к корневому свичу
— назначенный (designated), тоже работает, ведет от корневого свича
— неназначенный (non-designated), не участвует в пересылке данных
— корневой (root), участвует в пересылке данных
— назначенный (designated), тоже работает
— дополнительный (alternate), не участвует в пересылке данных
— резервный (backup), тоже не участвует
Механизмы работы
Использует таймеры:
Hello (2 секунды)
Max Age (20 секунд)
Forward delay timer (15 секунд)
Использует процесс proposal and agreement (предложение и соглашение)
Свич, обнаруживший изменение топологии, извещает корневой свич, который, в свою очередь, требует от всех остальных очистить их записи о текущей топологии в течение forward delay timerОбнаружение изменений в топологии влечет немедленную очистку записей
Если не-корневой свич не получает hello- пакеты от корневого в течение Max Age, он начинает новые выборыНачинает действовать, если не получает BPDU в течение 3 hello-интервалов
Последовательное прохождение порта через состояния Blocking (20 сек) — Listening (15 сек) — Learning (15 сек) — ForwardingБыстрый переход к Forwarding для p2p и Edge-портов
Основная суть в том, что при изменении топологии - нам не приходиться заново пересчитывать все связи а достаточно лишь переключиться на заранее подготовленный резерв.

Некоторые материалы были позаимствованы: https://habrahabr.ru/post/143768/

Port Security for switched devices (подготовка JNCIS-ENT)

MAC Address Limit

По умолчанию порты на EX не настроены на MAC limiting.

Существует 2 метода MAC limiting:
- когда свитч достигает максимального количества МАК для порта, остальные фреймы отбрасываются
- указать конкретные МАК-и которые могут быть изучены на данном порту.

MAC Move Limiting

Используется дл ограничения количества раз когда МАК адрес может поменять порт за которым он находится. Эта функция поможет от MAC sppofing и L2 петель. Включается функционал как per VLAN, так и per interface.

Какие бывают действия при нарешениях MAC политик:
- drop
- log
- shutdown

При конфигурации ethernet-switching-options и port-error-disable можно установить время автоматического поднятия порта после блокировки типом shutdown.
В ручном режиме порт можно поднять командой: clear ethernet-switching port-error interface

Примеры настроек:


Проверка:



понедельник, 5 декабря 2016 г.

High Availability Junos (подготовка JNCIS-ENT)

Рассмотрение GR, GRES, NSR, BFD

Graceful Restart (GR) - возможность выполнить перезагрузку демона маршрутизации (rpd) без перестроения топологии. Простыми словами: если для протоколов (OSPF, IS-IS, BGP, RIP, RSVP, LDP, MSDP, PIM) включен функционал GR, то при перезагрузки роутинг демона мы не потеряем соседство с маршрутизатором и не будет пересчитывать топологию.
Как включается данный функционал для каждого отдельного протокола: https://www.juniper.net/techpubs/en_US/junos15.1/topics/task/configuration/graceful-restart-for-routing-protocols-configuring.html


GR helper - режим включенный по умолчанию на устройствах. Это тот самый сосед, который ничего не расскажет про перезагрузку процесса другим в сети.
GR’s restarting router mode - не включен по умолчанию. Это и есть та самая возможность перезагрузки процессов без информация остальных.

Условия для выполнения GR:
- сетевая топология стабильна
- соседи настроены для взаимодействия
- не один из соседей не находится в состоянии GR
- grace период не просрочен



GR helper можно отключить глобально.
Болея специфическая конфигурация - предпочтительна. 
Как пример:
Можно отключить GR глобально, но включить для BGP.
Можно включить GR глобально, но отключить для OSPF.

Graceful RE Switchover - возможность включить поддержку смены ролей RE (master RE/backup RE) без простоя трафика. Естественной такой функционал будет работать, если у нас установлено 2 RE и GRES предусмотрен спецификацией конкретной модели оборудования.

В случае падения master RE без активированого GRES - PFE перезагружается, все физические интерфейсы переопределяются новой RE. Перезагружается rpd, теряются все соседства и идет перестроение топологии.

В случае падения master RE с активированной функцией GRES - PFE и интерфейсы не перезагружаются, перезагружается только процесс rpd. Чтоб RPD не перезагружался GRES настройку надо комбинировать с NSR или GR.

Алгоритм работы:
1. RE0 находится в состоянии мастер, RE1 находится в состоянии резервной
2. Когда GRES активирован - конфигурация и служебная информация синхронизированы между RE, они обмениваются keepalive пакетами
3. Если резервная RE на протяжении 2-х секунд не получает keepalive от мастер RE, они считает себя главной
4. PFE переподключается с RE0 на RE1
5. Новая мастер RE и PFE синхронизируются, если надо RE отправляет state update сообщения к PFE

show chassis routing-engine - проверка состояний и ролей

Конфигурация при разных RE:
groups {
    re0 {
        system {
            host-name spice-re0;
        }
        interfaces {
            fxp0 {
                unit 0 {
                    family inet {
                        address 192.168.69.155/21;
                    }
                }
            }
        }
    }
    re1 {
        system {
            host-name spice-re1;
        }
        interfaces {
            fxp0 {
                unit 0 {
                    family inet {
                        address 192.168.70.72/21;
                    }
                }
            }
        }
    }
    global;
}
apply-groups [ re0 re1 ];

Эта конфигурация позволяет задать разные Hostname и разные MNG IP для разных RE.

Чтоб синхронизировать конфигурация между разными RE необходимо сохранять конфигурацию через commit synchronize, либо задать автоматический коммит в конфигурации:
{master}[edit system]
user@R1-re0# set commit synchronize

Не забываем, что поменять отношения master/backup можно и в ручном режиме, например чтоб вытащить RE  и тд. - request chassis routing-engine master switch


Когда GRES активирован появляется баннер - master или backup в CLI.

Nonstop Active Routing - функционал для оборудования с резервированием по RE который позволяет при синхронизировать rdp данные между двумя RE. Такая возможность нам дает практически идеальную смену master RE и backup RE отношений.
Использовать одновременно NSR и GR нельзя.


Процесс RPD запускается на backup RE.
При изменении mastership ролей пиры подключенные к данному устройство об этом ничего не узнают.

NSR проверятся через команду: show task replication

BFD - Bidirectional Forwarding Detection
Большинство протоколов уже имеют встроенные функции по обнаружению ошибок на каналах логических, так и физических. Например, определение что OSPF сосед стал недостижим с интервалами по умолчанию может занят до 40 секунд! Это критично!
Решением такой проблемы стает протокол BFD - Bidirectional Forwarding Detection, своеобразная надстройка над протоколом маршрутизации, которая позволяет с помощью keepalive пакетов определять живучесть соседа. Такой процесс может занимать меньше секунды.




Можно установить transmit и receive интрвалы отдельно или сразу вместе. Не рекомендуется ставить интервал меньше 300 мс, высока вероятность ложных срабатываний. Логика работы такая: если 3 BDF hello не пришло - значит соединение помечено как не успешное.
Периодические пакеты в некоторых моделях Junos называются - periodic packet management (PPM) в BFD. По умолчанию они включены в Junos.

Проверка: show bfd session

VRRP - Virtual Router Redundancy Protocol, протокол резервирование основного шлюза. На нескольких устройствах настраивается функционал VRRP, одно из устройство выступает основным шлюзом остальные резервные для сегмента сети. Протокол стандартизирован - RFC 2338.

Аналог протокола VRRP у Cisco называется - Hot Standby Router Protocol (HSRP).

VRRP Router - маршрутизатор на котором запущен протокол (это может быть как Master, так и Backup маршрутизатор).
Master Router - маршрутизатор принимающий пакеты от сегмента сети и отвечающий на arp запросы.
Backup Router - маршрутизатор который отслеживает состояние Master и готов принять на себя трафик в случае сбоя Master. Таких маршрутизаторов может быть несколько.
Virtual Router - виртуальный IP адрес, который является шлюзом по умолчанию для сегмента сети обычно называемого VIP. VR имеет идентификатор который состоит из virtual router identifier (VRID) и virtual IP (VIP) address.

VRRP v2 использует common advertisement packet для взаимодействия между VRRP маршрутизаторами. Такие пакеты ходят по мультикаст адресу 224.0.0.18 и имеют TTL 255.
Временной интервал пересылки таких пакетов - 1 секунда, по умолчанию. Данный интервал можно править руками в пределах 1 - 255 секунд.  Также, можно установить fast-interval и настроить время пересылки в пределах от 100-999 мс.

При пересылке служебных пакетов и при ответе клиенту arp используется виртуальный MAC адрес, формат которого: 00-00-5E-00-01-VRID.

Выбор VRRP Master Router происходит по приоритету, который может быть от 1-255. Чем выше значение - тем выше приоритет. По умолчанию всем маршрутизаторам устанавливается значение в 100, кроме маршрутизатора который имеет VIP адрес.





По умолчанию VIP не отвечает на ICMP, чтоб включит возможность отвечать необходимо добавить accept-date в конфигурацию VRRP.

понедельник, 28 ноября 2016 г.

Тунелирование Junos, GRE, IPIP (Подготовка JNCIS-ENT)

Туннелирование обеспечивает связь между удаленными подсетями поверх сети Интернет.
Данный подход к организации может быть полезным, ели:
- необходимо сделать прозрачную видимость между подсетями с адресами из RFC 1918
- конечные подсети имеют отличный от IP протокола (через Интернет передается только IP, напоминаю)

Дальнейшая статься будет рассматривать только незащищенные протокол (не такие как IPSec):
- GRE
- IP-IP

Логика работы: пакет приходит на граничный маршрутизатор сети, на котором настроен тунель, маршрутизатор инкапсулирует данный пакет вместе с заголовком и передает в сеть Интернет, принимающий маршрутизатор выполняет процес деинкапсуляция пакета и передает его дальше по сети получателю.

GRE может инкапсулировать IP, IPX, AppleTalk. Также, может выполнять инкапсуляцию ipv6 и MPLS трафика. Изначально разработан Cisco, но поддерживается множеством вендоров. Описан в RFC 1702.
GRE добавляет 24 байта к заголовку пакета. Такой пакет имеет IP protocol type 47. Сам пакет не меняет, только изменяется TTL, чтоб пакет не бегал по сети вечно.

IP-IP протокол предназначен для инкапсуляции IP трафика в IP трафик. К заголовку добавляется 20 байт. Опять же в основном пакете меняется TTL. Протокол описан в RFC 2003.

Имена интерфейсов:
gr-x/y/z в GRE
ip-x/y/z в IP-IP
Буковки обозначают сервисную карту, которая будет делать процесс инкапсуляции трафик. На MX, такой функционал выполняет FPC карточка. MX Tunnel Services Overview

Обязательными для конфигурации являются tunnel’s destination и source адреса.
По молчанию туннели полностью stateless, т.е. они ничего не знают о состоянии второго соседа. Если там интерфейс будет в состоянии Down, или устройство вообще будет не достижимо, на другой стороне устройство будет в Up.
Чтоб такого не было, необходимо использовать Keep Alive механизм в GRE или BFD.

Чтоб по тунелям бегали пакеты размером больше 1500, необходимо их фрагментировать, если стоит бит запрещающий фрагментацию, его можно снять установив clear-dont-fragment в конфигурации.

Пример простой конфигурации GRE:


Дополнительные параметры конфигурации:
- copy-tos-to-outer-ip-header чтоб поставить метку в GRE пакет;
- allow-fragmentation - по дефолту, пакет больше чем MTU будет отброшен, что чтоб он принимался в дальнейшую обработку необходимо включить данный функционал;
- clear-dont-fragment-bit - чтоб фрагментировать пакеты даже с битом запрещающим это делать;
- key - для проверки целостности

Дополнительно можно установить Path MTU discovery (PMTUD) - функционал который определяет максимальный размер MTU на туннеле.




Static, Aggregate, Generated маршруты в Junos (JNCIS-ENT подготовка)

Статические маршруты задаются в разделе: edit routing-options. По умолчанию статические маршруты имеют приоритет (preference) - 5.

Маршрут может быть указан на:
- IP адрес
- если интерфейс Point-To-Point, то можно указать название интерфейса (st0.0 например)
- пакеты могут быть отправлены в bit bucket. Если указываем отправлять в reject - в ответ отправителю пакета будет отправлено ICMP сообщение, если указываем discard - пакет будет просто отброшен без информирования отправителя
- можно отправлять трафик в другую табличку маршрутизации через next-table.

Статический маршрут находится в табличке RIB, пока он не будет удален, или не станет неактивен. Одна из возможных причин, когда маршрут не активен - next hop адрес стает недостижим.

С использованием опции qualified-next-hop можно прописать маршрут для одной подсети на 2 разных next-hop.

root@Mordor240> show configuration routing-options
static {
    route 0.0.0.0/0 {
        next-hop 109.108.xx.yy;
        qualified-next-hop 192.168.x.uu {
            metric 5;
        }
    }
    route 192.168.120.0/24 next-hop st0.0;
}

ipv6 маршрут указывается следующим образом:
set routing-options rib inet6.0 static route 2001:db8::5/128 next-hop 2001:db8:0:1:2a0:a502:0:19da

При необходимости для всех статических маршрутов можно поменять приоритет в категории defaults:
set routing-options static defaults preference 20
Данный приоритет будет изменение только на маршрутах, где приоритет не указан руками.

Пример:


Ответ: будет выбран next-hop - 172.30.25.5.

Aggregate routes - маршруты, которые объединяют в себе несколько маршрутом в меньшей маской. Например 192.168.1.0/24, 192.168.2.0/24... можно агрегировать в маршрут 192.168.0.0/20. Тем самым мы уменьшим количество записей в табличках маршрутизаторов соседей.

Чтоб агрегированный маршрут присутствовал в табличке маршрутизации, надо чтоб хотя бы 1 маршрут contributing был активен.

По умолчанию агрегированный маршрут имеет приоритет 130 и помечается как - reject. Когда маршрутизатор получает пакет, он обрабатывает его по принципу "more specific route", если он не находит такой маршрут - пакет отбрасывается.




Увидеть contributing  маршруты их которых состоит агрегированный маршрут:


Generated routes похожи на aggregate routes. Они тоже считаются активные когда хотя бы один contributing маршрут активен.
Отличием является то, что generated маршруты имеют конкретный next-hop, который определяется primary contributing route. А primary маршрут в свою очередь - маршрут который имеет лучший-минимальный приоритет.




Martian Addresses - подсети/адреса которые некогда не маршрутизируется между разными AS.
• 0.0.0.0/8
• 127.0.0.0/8
• 128.0.0.0/16
• 191.255.0.0/16
• 192.0.0.0/24
• 223.255.255.0/24
• 240.0.0.0/4


root> show route martians

inet.0:
             0.0.0.0/0 exact -- allowed
             0.0.0.0/8 orlonger -- disallowed
             127.0.0.0/8 orlonger -- disallowed
             192.0.0.0/24 orlonger -- disallowed
             240.0.0.0/4 orlonger -- disallowed
             224.0.0.0/4 exact -- disallowed
             224.0.0.0/24 exact -- disallowed

Martian Addresses могут правится, в них можно удалить/добавить маршруты.

Таблицы маршрутизации в Junos

В Junos есть возможность создавать отдельные инстранси маршрутизации - routing instance внутри одного устройства и задавать параметры обмена маршрутной информацией между ними.
Основной инстанс это master, куда входят: inet.0 и inet6.0 таблицы маршрутизации.

В Junos можна создать следующие инстансы для разных задач:
• forwarding: Used to implement filter-based forwarding for common Access Layer applications;
• l2vpn: Used in Layer 2 VPN implementations;
• no-forwarding: Used to separate large networks into smaller administrative entities;
• virtual-router: Used for non-VPN-related applications such as system virtualization;
• vpls: Used for point-to-multipoint LAN implementations between a set of sites in a VPN; and
• vrf: Used in Layer 3 VPN implementations.

Juniper routing instances на Хабре

Для обмена маршрутной информацией между инстансами используются routing information base (RIB) группы. Также, можно явно указывать таблички экспорта и импорта в инстансе: instance-import, instance-export и auto-export.
Маршрутизацию между отдельными инстансами можно сделать с помощью логических туннельных интерфейсов: lt-fpc/pic/port.

Demystifying Juniper's rib-groups на Хабре

вторник, 31 мая 2016 г.

NEW Juniper EX2300 & 3400 Overview and SKU





EX2300-C - Компактный, тихий (Fanless operation) и энергоэффективный свитч.





12 10/100/1000BASE-T
2 SFP+ 10GbE uplink ports
Размеры: 10.98 inches wide and 9.4 inches deep
PoE/PoE+
Virtual Chassis support 4 device
Energy Efficient Ethernet (EEE) support for GbE access ports
Packet-Switching Capacities (Maximum with 64-Byte Packets) - 64 Gbps
Layer 2/Layer 3 Throughput (Mpps) (Maximum with 64 Byte Packets) - 47 Mpps (wire speed)
Maximum MAC addresses in hardware: 16,000

SKU:
EX2300-C-12T
EX2300-C-12T-VC
EX2300-C-12P
EX2300-C-12P-VC

EX2300 - Решение для Enterprise и уровня доступа. Обладает богатым функционалом POE - 802.3af Class 3 Power over Ethernet (PoE) and 802.3at PoE+





24 10/100/1000BASE-T (48 портовые ожидаются позже)
4x1GbE SFP/10GbE SFP+
Complete Layer 2 and basic Layer 3 switching capabilities are available
POE 15.4 watts of standards-based 802.3af, Class 3 PoE to a maximum of 24 ports or 30 watts of standards-based 802.3at PoE+ to a maximum of 24 ports, based on a total system budget of 740 watts
Virtual Chassis 4 devices
Packet-Switching Capacities (Maximum with 64-Byte Packets) -  128 Gbps
Layer 2/Layer 3 Throughput (Mpps) (Maximum with 64 Byte Packets) - 95 Mpps (wire speed)
Maximum MAC addresses in hardware: 16,000

SKU:
EX2300-24T
EX2300-24T-VC
EX2300-24P
EX2300-24P-VC
EX2300-24T-DC
EX2300-48T
EX2300-48T-VC
EX2300-48P
EX2300-48P-VC
EX2300-24T-TAA
EX2300-24P-TAA
EX2300-48T-TAA
EX2300-48P-TAA

EX3400 - Гибкое решения с 24 или 48 портами и 40Gbps Unlink портами.




24-port and 48-port 10/100/1000BASE-T
4 GbE/10GbE SFP/SFP+
2 40GbE QSFP+
Cooling options offer both front-to-back and back-to-front airflows
Two redundant, field-replaceable power supplies each provide up to 920 watts of power.

SKU:
EX3400-24T
EX3400-24P
EX3400-24T-DC
EX3400-48T
EX3400-48P
EX3400-48T-AFI
EX3400-24T-TAA
EX3400-24P-TAA
EX3400-48T-TAA
EX3400-48P-TAA

понедельник, 30 мая 2016 г.

Как наплодить префиксов в BGP Juniper

Задача: протестировать RIB/FIB устройства с использованием Juniper для генерации префиксов.

Для начала создадим универсальный список префиксов. Я обычно беру любой Juniper MX и выполняю: show route | display xml | match "<rt-destination>" | no-more. Команда вывод список префиксов в формате <rt-destination>70.36.9.0/24</rt-destination>. Не нужные символы в скобках удаляются в блокноте с помощью замены (Ctrl+H). В итоге мы получаем красивый список адресов в формате:
70.36.6.0/24
70.36.30.0/24
70.38.0.0/17
...

Далее будем использовать Excel. Копируем список адресов с блокнота и вставляем во второй столбец документа Excel. 
Первый столбец документа Excel заполняем "     route " именно с таким количеством пробелов, как в примере.
Третий столбец заполняем " discard;".

Далее копируем все активное содержимое Excel документа и вставляем в блокнот, у нас должны получиться следующие строчки:
"     route 1.22.51.0/24 discard;"
"     route 1.22.52.0/24 discard;"
"     route 1.22.53.0/24 discard;"
"     route 1.22.54.0/24 discard;"

В самом начале документа блокнота вставляем:
routing-options {
    static {

В самом конце документа вставляем:
}
}

В конечном виде, наш блокнот будет выглядеть следующим образом:
routing-options {
    static {
     route 1.22.51.0/24 discard;
     route 1.22.52.0/24 discard;
     route 1.22.53.0/24 discard;
     route 1.22.54.0/24 discard;
     ....
     route 69.18.230.0/23 discard;
     route 69.18.232.0/22 discard;
}
}

Сохраняем все это дело в .txt формате. По сути мы получили кусок конфиги, который необходимо засунуть в Juniper. Для этого через FTP, SCP копируем наш txt файлик на Juniper в /var/tmp/.

Заходим в режим конфигурации на Juniper:

root> configure                                 
Entering configuration mode

[edit]
root# load merge "/var/tmp/100k routes.txt" relative    
load complete

[edit]
root# commit and-quit 

commit complete
Exiting configuration mode

root> 

Commit будет выполняться в зависимости от размера файла. 100к маршрутов комитит 3-4 минуты.

Если мы по ошибке залили битый файл и не тот, файл всегда можно удалить из CLI с помощью: file delete "/var/tmp/100k routes.txt"

пятница, 27 мая 2016 г.

Troubleshooting Juniper MX и не только, диагностика и анализ использования ресурсов

Что делать когда Juniper сам по себе перезагрузился? Каким образом проверить использование системных ресурсов на устройстве? Как выполнять Troubleshooting работы Juniper?


1. Самое первое, что стоит проверить после перезагрузки устройства - show chassis routing-engine значение "Last reboot reason" в котором в штатном режиме должно быть - "Router rebooted after a normal shutdown" Но, стоит понимать, что это определение не говорит о том, что проблем не было, это лишь поможет понять, увидел ли проблему JunOS или нет, что может упростить процесс анализа.
Я на своей практике замечал следующие состояние: "could not be determined", "panic:ehci_abort_xfer: not in process context", "0x1:power cycle/failure".

На правах рекламы совета, большинство падений оборудования связано с недавно внесенными изменениями в сеть/работу устройства и т.д. Какие действия выполнялись на Juniper можно проверить по commits (история внесений изменений в конфигурацию устройства):
show system commit  - кто и когда коммитил
show configuration | compare rollback 2 - сравнить текущую конфигурацию системы с конфигурацией в файле  rollback 2
show system rollback compare 4 3 - сравнить 2 файла конфигурации

2. Проверим файлы с логами: show log messages | find "FreeBSD Project". Не забываем, что если у нас устройство генерирует большое количество записей, то просматриваем все имеющиеся файлы логов (messages.0.gz, messages.1.gz и тд.) пока не найдем желаемое. Читаем логи за 15 минут до падения устройства и анализируем.
Для того чтобы удобно работать с логами, необходимо использовать достаточный уровень логирования, например - set system syslog file messages any notice. Рекомендуется не включать полное логирование "any any", такое логирование со временем просто "убьет" flash drive на routing-engine. Если мы хотим логировать всё-всё-всё - syslog сервер нам в помощь.

Заметим, что в случае, если устройство перезагружено администратором в логах будет следующие записи:
May 17 17:15:04  EX3200 mgd[45517]: UI_REBOOT_EVENT: System rebooted by 'admin'
May 17 17:15:10  EX3200 shutdown: reboot by admin:

В случае, если мы замечаем, что устройство жалуется на конкретный процесс (daemon), в KB Juniper мы можем найти описание процессов: List of Junos OS Processes

Не мало важный момент это - использование traceoptions на Juniper (debug). Включение traceoptions для сервисов, протоколов, процессов и тд. значительно помогает в настройке/troubleshooting, но, это может вылезть "боком", трейсы довольно трудоемкий процесс и кушает много системных ресурсов. Поэтому, в штатном режиме использовать traceoptions не стоит и + это убьет flash drive в 10 раз быстрее... Когда flash drive плохо, возникает похожая ошибка - g_vfs_done():da1s1f[WRITE(offset=962772992, length=16384)]error = 5, она может возникнуть в процессе работы, загрузки устройства, либо работы с файловой системой.
Проверяем не было ли создано системой core-dumps файлов (это дампы памяти, которая система может сделать в случаи crash определенного демона rpd, etc).
show system core-dumps

Содержание данных файлов трудно проанализировать самостоятельно, поэтому, зачастую создается тикет в JTAC и данные файлы заливаются на FTP Juniper, в последующем анализируются инженерам. FAQ в KB Juniper по добавления файлов.
TT (trouble ticket) можно открыть при наличии активного сервисного контракта у Juniper Networks - Serial Number Entitlement Search

3. Проверим версию установленного JunOS:
show version

Не нужно гнаться за самой последней веткой и версией софта а использовать recommend (http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476&actp=search)
Важный момент, возможно уже существует описание бага по причине которого и произошла перезагрузка оборудования, данную информацию можно проверить в в PROBLEM REPORT SEARCH - https://prsearch.juniper.net/InfoCenter/index?page=prsearch. Для входа требуется регистрация.
Информация и FAQ по обновлению JunOS

3. Большинство устройств Juniper имеют модульную архитектуру и разделение по плоскости управления и обработки трафика (control & data plane), правда это разделение не всегда аппаратное. Выполняем типичную проверку состояния компонентов устройства (Routing-engine, Flexible PIC Concentrator, tfeb, ethernet-switch, компоненты и функции устройства могут отличаться в зависимости от серии и модели устройства). Таким образом мы попытаемся локализовать проблему.

show chassis hardware - список всех компонентов (само шасси, платы (модуля), блоки питания, фаны). Это исключительно список активных компонентов. Если карта сейчас упала или перезагружается здесь она отображена не будет, пока она полностью не загрузиться и не будет инициализирована.

show chassis routing-engine  - состояние Routing-engine (мозгов устройства), если используется резервирование, одна RE в состоянии Master, вторая RE в состоянии Backup. Здесь обращаем внимание на использование оперативной памяти и CPU.
Рекомендации по настройка отказоустойчивость по RE - Configuring Routing Engine Redundancy

show chassis alarms и show system alarms - комментарии излишни, система сама может показать проблему, если она ее заметила.

show chassis fpc detail - информация о состоянии и нагрузки линейных карт.

show chassis fpc pic-status - информация о состоянии pic модулей, которые вставлены в fpc карты.

show chassis pic fpc-slot 0 pic-slot 2 - информация о состоянии и загрузки конкретной pic карты, в примере это MS-MIC-16G на mx10-t.

show chassis environment - температура ASIC чипов (LU (XL), MQ (XM), QX (XQ) - это типы чипов на Juniper Trio Chipset для MX) тип чипа зависит от модели и архитектуры устройства). При нормальных условиях функционирования устройства температура не должна превышать 60 градусов по Цельсию. Если все блоки питания подключены к сети, напротив PEM будет указано - OK, если блок питания присутствует, но питание не подается - Absent. В штатном режиме, все fan должны крутиться на нормальной скорости, это отображается как - Spinning at normal speed.

На больших железках MX240 +  все участвующие в обработке трафика компоненты связываются между собой через встроенный в SCB ethernet-switch. Выполнив команду show chassis ethernet-switch statistics мы можем посмотреть нет ли ошибок на служебных интерфейсах.

5. Настройки защиты control plane. По умолчанию, Juniper MX например, не имеет никаких ограничений по протоколам, портам, к которым могут обращаться снаружи. Учитывая тот факт, что существует большое количество уязвимостей как JunOS CVE Vulnerability Juniper, так и уязвимостей в протоколах. Правильное решение данной проблемы - настроить фильтры для трафика, который может обращаться к control plane нашего устройства.
Официально у Juniper есть следующая литература:
http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/securing-routing-engine/