Настройка Virtual chassis на Juniper QFX5100

Автор: | 24.11.2020

Сегодня поговорим об альтернативе MCLAG от Juniper — Virtual Chassis.
С помощью Virtual Chassis можно управлять несколькими устройствами как единым целым, иметь несколько Routing Engine в стеке, а так же использовать graceful Routing Engine switchover (GRES) и Nonstop Active Routing(NSR).

Буду рассматривать вариант с двумя коммутаторами, оба одинаковой модели — QFX5100-48S.
Настраиваем вариант — pre-provisioned, т.е роли коммутаторов заранее определены и зафиксированы.

Перед началом настройки Virtual chassis нам понадобится список серийных номеров, посмотреть можно так:

qfx01> show virtual-chassis                               

Virtual Chassis ID: a1a4.efda.4891
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    TA3700000001 qfx5100-48s-6q 128   Master*      N  VC

Member ID for next new member: 1 (FPC 1)

Virtual-chassis стек может состоять из разных моделей коммутаторов — это Mixed mode. В нашем случае модели одинаковые, так что нам нужен fabriс mode.

Перед началом конфигурации проверяем режим virtual-chassis:

qfx01> show virtual-chassis mode 
fpc0:
--------------------------------------------------------------------------
Current mode : Virtual Chassis with similar devices
Future mode after reboot : Virtual Chassis with similar devices

Если режим не тот, который нам нужен, меняем:

 qfx01>request virtual-chassis mode fabric local reboot

Теперь нужно определить роли коммутаторов.
Так как коммутаторы у нас одинаковые, будем использовать их в роли Routing Engine. Это даст функционал GRES/NSR/NSB и резерв Control-plane, в случае выхода одного коммутатора из строя.

Определяем роли коммутаторов:

#Конфиг qfx01
system {
    commit synchronize;
}
chassis {
    redundancy {
        graceful-switchover;
    }
}
routing-options {
    nonstop-routing;
}
protocols {
    layer2-control {
        nonstop-bridging;
    }
}
virtual-chassis {
    preprovisioned;
    no-split-detection;
    member 0 {                          
        role routing-engine;
        serial-number TA3700000001;
    }
    member 1 {
        role routing-engine;
        serial-number TA3700000002;
    }
}             

Нужно сказать пару слов, зачем используется no-split-detection:

При использовании split-detection и стека из двух коммутаторов, при выходе из строя одного из коммутаторов, оставшийся перейдет в режим line-card. При этом ни одного активного RE не останется и все порты FPC будут отключены.
BEST PRACTICE по рекомендации Juniper — отключить split-detection при использовании стека из двух коммутаторов. Этот функционал нужен при наличии в стеке более 2 устройств.
Цитата из мануала:

We recommend that you disable split detection for a two-member Virtual Chassis configuration if you think the backup router or switch is more likely to fail than the Virtual Chassis port interfaces to the backup router or switch. Configuring redundant Virtual Chassis ports on different line cards in each member router or switch reduces the likelihood that all Virtual Chassis port interfaces to the backup router or switch can fail.

Добавляем порты в VC:

qfx01>request virtual-chassis vc-port set pic-slot 0 port 48
Port conversion initiated,  use show virtual-chassis vc-port to verify
qfx01>request virtual-chassis vc-port set pic-slot 0 port 49
Port conversion initiated,  use show virtual-chassis vc-port to verify

Смотрим что получилось:

qfx01> show virtual-chassis vc-port 
fpc0:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
0/48        Configured         -1    Down         40000
0/49        Configured         -1    Down         40000

На этом конфиг первого свитча готов. Повторяем все тоже самое на втором коммутаторе и смотрим, что получилось:

qfx01> show virtual-chassis 

Preprovisioned Virtual Chassis
Virtual Chassis ID: a1a4.efda.4891
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    TA3700000001 qfx5100-48s-6q 129   Master*      N  VC   1  vcp-255/0/48
                                                                           1  vcp-255/0/49
1 (FPC 1)  Prsnt    TA3700000002 qfx5100-48s-6q 129   Backup       N  VC   0  vcp-255/0/48
                                                                           0  vcp-255/0/49

Мы получили шасси с резервируемым RE, 96 портов 10G и 8 портов 40G (2 порта 40G заняты под VC).

Что бы попасть в консоль свитча, который работает как backup, воспользуемся командой:

qfx01>request session member 1
root@qfx01:BK:1% cli 
warning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.
warning: Use of interactive commands should be limited to debugging and VC Port operations.
warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.
warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.
warning: Please logout and log into the VC-M to use CLI.
{backup:1}
root@qfx01>

Проверим репликацию и готовность к GRES:

{backup:1}
root@qfx01>show system switchover                            
fpc1:
--------------------------------------------------------------------------
Graceful switchover: On
Configuration database: Ready
Kernel database: Ready
{backup:1}
root@qfx01>show task replication
Stateful Replication: Enabled
RE mode: Backup

Все работает как и должно, Virtual Chassis собран, RE синхронизированы.

Как удалить коммутатор из Virtual Chassis ?
Если коммутатор работает в режиме Master RE, то нужно перевести активный RE на тот коммутатор, который останется в работе.

qfx01> request chassis routing-engine master switch check
# Тут коммутатор должен ответить Switchover Ready, 
# но на софте 18.4R2-S5.4 этого не происходит, просто
# возвращается пустая строка.
qfx01> request chassis routing-engine master switch
Toggle mastership between routing engines ? [yes,no] (no) yes

Обесточить отключаемый коммутатор. Отключить все линки.
Теперь можно удалить конфигурацию отключенного коммутатора.

{master:1}
root@qfx01> configure 
Entering configuration mode

{master:1}[edit]
root@qfx01# del virtual-chassis member 1

{master:1}[edit]
root@qfx01# commit 
configuration check succeeds
commit complete

Удалить конфигурацию VC портов:

{master:0}
root@qfx01>request virtual-chassis vc-port delete pic-slot 0 local port 48
Port deletion initiated, use cmd show virtual-chassis vc-port to verify
root@qfx01>request virtual-chassis vc-port delete pic-slot 0 local port 49 
Port deletion initiated, use cmd show virtual-chassis vc-port to verify

После этого коммутатор будет удален из VC, порты освобождены.

Подписаться
Уведомить о

0 комментариев
Старые
Новые
Межтекстовые Отзывы
Посмотреть все комментарии