Когда начинаешь работать с коммутаторами Juniper EX-серии, сталкиваешься с особенностями их работы.
Общий смысл в non-stop, что обновление производится по частям, а не на всех коммутаторах в VC разом. Stop случается на коммутаторе, который попадает под обновление. Начинается все в VC с коммутатора, который выполняет роль backup RE. Следующими идут и перегружаются линейные карты. Ну а под финал обновляется мастер.
Случайно обнаружил, что в версии 12.3 для EX-серии появилась команда auto-snapshot. Как это выглядит:
Интересно, что в Cisco есть режим порта tunnel, а тут только trunk|access.
Если на коммутаторе настроен dot1q-tunnel влан, то в портах этого влана нельзя включить dhcp snooping, даже если конкретно для этого влана снупинг не нужен. Таким образом, ставим крест на таких фичах: dhcp snooping, arp-insprection, source-guard.
Пример трансляции, где с удаленного коммутатора, подключенного к порту EX'а ge-1/0/1, передается три влана: 100,400,900. На EX'e уже имеются вланы 100,400, поэтому требуется трансляция 3100<->100, 3400<->400. При этом во влане 100 передаются фреймы с двумя тегами (QinQ) и требуется поменять внешнюю метку. Влан 900 передается без изменений тега, точнее c заменой 1:1.
Обратите внимание, что из-за LCD Menu в EX4200 устанавливать трансиверы и особенно вот этот конкретный twinax было очень неудобно. Он упирается в корпус, вытаскивать неудобно, так как хлыстик силиконовый пришлось отрезать.
Virtual-Chassis из N коммутаторов EX4200
Как-то один из ex4200 после отключения питания загрузился с альтернативного раздела, где хранилась резервная копия с предыдущей версией junos, которая была установлена ранее. Вот похожая ситуация, где видно разные версии ПО на разных слайсах.
root@ex> show system snapshot media internalЧто надо сделать после удачного обновления junos на стеке
fpc0:
--------------------------------------------------------------------------
Information for snapshot on internal (/dev/da0s1a) (backup)
Creation date: Nov 15 21:40:43 2011
JUNOS version on snapshot:
jbase : 11.4R1.6
jcrypto-ex: 11.4R1.6
jdocs-ex: 11.4R1.6
jkernel-ex: 11.4R1.6
jroute-ex: 11.4R1.6
jswitch-ex: 11.4R1.6
jweb-ex: 11.4R1.6
jpfe-ex42x: 11.4R1.6
Information for snapshot on internal (/dev/da0s2a) (primary)
Creation date: Jan 6 00:25:21 2013
JUNOS version on snapshot:
jbase : ex-11.4R5.7
jcrypto-ex: 11.4R5.7
jdocs-ex: 11.4R5.7
jkernel-ex: 11.4R5.7
jroute-ex: 11.4R5.7
jswitch-ex: 11.4R5.7
jweb-ex: 11.4R5.7
jpfe-ex42x: 11.4R5.7
fpc1:
--------------------------------------------------------------------------
Information for snapshot on internal (/dev/da0s1a) (backup)
Creation date: Nov 15 21:40:49 2011
JUNOS version on snapshot:
jbase : 11.4R1.6
jcrypto-ex: 11.4R1.6
jdocs-ex: 11.4R1.6
jkernel-ex: 11.4R1.6
jroute-ex: 11.4R1.6
jswitch-ex: 11.4R1.6
jweb-ex: 11.4R1.6
jpfe-ex42x: 11.4R1.6
Information for snapshot on internal (/dev/da0s2a) (primary)
Creation date: Jan 6 00:25:21 2013
JUNOS version on snapshot:
jbase : ex-11.4R5.7
jcrypto-ex: 11.4R5.7
jdocs-ex: 11.4R5.7
jkernel-ex: 11.4R5.7
jroute-ex: 11.4R5.7
jswitch-ex: 11.4R5.7
jweb-ex: 11.4R5.7
jpfe-ex42x: 11.4R5.7
{master:0}
ex>request system snapshot slice alternate all-membersВот нормальная работа стека
root@ex# run show virtual-chassisОдин из свичей мастер routing-engine, а второй backup. У меня один из свичей был с обновленной ос 12.2, а второй загрузился с альтернативного слайса с версией 11.2. Выглядело так. Второй свич не коммутировал, его ЖК меню не показывало ничего. Сам коммутатор перевелся в режим linecard с ограниченным набором команд. На мастере выглядело так, что подключен свич inactive linecard. Похожая ситация возникает при подключении в VC коммутаторов с разными версиями ПО. Чтобы восстановить работоспособность, пришлось разобрать стек, обновить софт, собрать стек. Можно и не разбирая обновить софт на всем VC сразу, либо на отдельном коммутаторе.
Virtual Chassis ID: 6f31.d04e.5d2c
Virtual Chassis Mode: Enabled
Mstr Mixed Neighbor List
Member ID Status Serial No Model prio Role Mode ID Interface
0 (FPC 0) Prsnt serial_a ex4200-24f 255 Master* N 1 vcp-0
1 vcp-1
1 (FPC 1) Prsnt serial_b ex4200-48t 255 Backup N 0 vcp-0
0 vcp-1
Member ID for next new member: 2 (FPC 2)
ex> show virtual-chassisЕсли требуется подключить новый коммутатор с отличной версией Junos, то обновить можно непосредственно с шасси:
Preprovisioned Virtual Chassis
Virtual Chassis ID: c481.426d.c9ec
Virtual Chassis Mode: Enabled
Mstr Mixed Neighbor List
Member ID Status Serial No Model prio Role Mode ID Interface
0 (FPC 0) Prsnt BR021149 ex4200-24f 129 Master* N 3 vcp-0
1 vcp-1
1 (FPC 1) Prsnt BR021148 ex4200-24f 0 Linecard N 2 vcp-0
0 vcp-1
2 (FPC 2) Inactive BR021247 ex4200-24f 129 Linecard N 1 vcp-0
3 vcp-1
3 (FPC 3) Inactive BR021245 ex4200-24f 0 Linecard N 0 vcp-0
2 vcp-1
{master:0}
root> request system software add src/jinstall-ex-4200-version-domestic-signed.tgz
Retrieving software images. This process can take several minutes. Please be patient..
Checking pending install on fpc1
Checking pending install on fpc2
Checking pending install on fpc3
Checking pending install on fpc0
[пропущено]
ex> request system reboot all-members
Reboot the system ? [yes,no] (no) yes
Rebooting fpc1
Rebooting fpc2
Rebooting fpc3
*** FINAL System shutdown message from root@ ***
System going down IMMEDIATELY
Shutdown NOW!
ex>request system software add validate member 3 <образ junos>Можно настроить резервирование коммутаторов:
ex>request system reboot member 3
root@ex> show configuration virtual-chassisМожно подключиться к конкретному коммутатору в шасси:
preprovisioned;
no-split-detection;
member 0 {
role routing-engine;
serial-number serial_a;
}
member 1 {
role routing-engine;
serial-number serial_b;
}
ex>request session member 3Чтобы конфигурация автоматически записывалась во все коммутаторы VC необходимо выполнять вместо commit:
ex#commit synchronizeлибо в конфигурацию в разделе system добавить:
ex> show configuration system | match commitНемного про выключение коммутаторов. Или точнее сказать коробок с FreeBSD, которые выполняют типичную процедуру выключения. Опасаясь повредить разделы файловой системы, периодически выполняю:
commit synchronize;
ex>request system power-offЕсли команда выполняется на шасси, то "выключается" все шасси. Если тыкать кнопки в LCD Menu, то выключается конкретный коммутатор, но в обоих случаях не происходит выключения. На меню отображается "HALTING..." и без консоли вообще невозможно понять можно коммутатор выключать или нет. Для EX-ов, команда power-off аналогична halt'у. Коробка по питанию не выключается, остается в режиме ожидания нажатия любой клавиши для перезагрузки.
Virtual-Chassis из N коммутаторов EX3300
В коммутаторах серии 3300 два крайних порта (0/1/2 и 0/1/3) по-умолчанию настроены для организации VC через оптику, так как шасси не имеет выделенных VC-портов. Удаление, к слову, производится через некоторое время после выполнения команд, а не моментально.ex3300> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
PIC / Port
1/2 Configured -1 Down 1000
1/3 Configured -1 Down 1000
ex3300> request virtual-chassis vc-port delete pic-slot 1 port 2
ex3300> request virtual-chassis vc-port delete pic-slot 1 port 3
ex3300> show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
{master:0}
ex3300>
GRES
http://kb.juniper.net/InfoCenter/index?page=content&id=KB21368. Настройки по-умолчанию не позволяют на ходу менять мастера VC без небольшого перерыва связи. Предположу, что такая ситуация возможна в случае, когда member 0 был назначен в качестве RE с бОльшим приоритетом, а загрузился позже всех. У циски игра с приоритетами мастера приводила к тому, что "мелкий" мастер при включении коммутатора с бОльшим приоритетом отправлялся в перезагрузку. Поэтому на цисковских стеках я приоритеты не менял. Тут же единственную пользу в переназначении мастера в VC я увидел в том, что мне привычнее подключаться в консоль мастера, чем в другой коммутатор и ждать несколько секунд приглашения. А вообще эта фича необходима для обновления ПО на VC без перезагрузки коммутаторов (ISSU). Смена мастера без GRES:ex> show configuration virtual-chassisВключение GRES.
preprovisioned;
member 0 {
role routing-engine;
serial-number serial_a;
}
member 1 {
role routing-engine;
serial-number serial_b ;
}
{master:1}
ex> show virtual-chassis
Preprovisioned Virtual Chassis
Virtual Chassis ID: 3352.7ae0.1f1f
Virtual Chassis Mode: Enabled
Mstr Mixed Neighbor List
Member ID Status Serial No Model prio Role Mode ID Interface
0 (FPC 0) Prsnt serial_a ex4200-24t 129 Backup N 1 vcp-0
1 vcp-1
1 (FPC 1) Prsnt serial_b ex4200-24t 129 Master* N 0 vcp-0
0 vcp-1
{master:1}
ex> request chassis routing-engine master switch check
warning: Traffic will be interrupted while the PFE is re-initialized
Standby Routing Engine is not ready for graceful switchover.
Command aborted. Not ready for mastership switch, try after 73 secs.
ex> request chassis routing-engine master switch check
warning: Traffic will be interrupted while the PFE is re-initialized
Standby Routing Engine is not ready for graceful switchover.
{master:1}
ex>
Amnesiac (ttyu0)
login: ex
Password:
--- JUNOS 12.3R1.7 built 2013-01-26 01:32:53 UTC
ex@:RE:0% cli
{master:0}
ex> show virtual-chassis
Preprovisioned Virtual Chassis
Virtual Chassis ID: 3352.7ae0.1f1f
Virtual Chassis Mode: Enabled
Mstr Mixed Neighbor List
Member ID Status Serial No Model prio Role Mode ID Interface
0 (FPC 0) Prsnt serial_a ex4200-24t 129 Master* N 1 vcp-0
1 vcp-1
1 (FPC 1) Prsnt serial_b ex4200-24t 129 Backup N 0 vcp-0
0 vcp-1
{master:0}
ex>
ex# set chassis redundancy graceful-switchoverЧастые переключения не допускаются.
ex> request chassis routing-engine master switch check
{master:0}
ex>
Amnesiac (ttyu0)
login: ex
Logging to master
Password:
--- JUNOS 12.3R1.7 built 2013-01-26 01:32:53 UTC
ex@:RE:1% cli
{master:1}
ex> show virtual-chassis
Preprovisioned Virtual Chassis
Virtual Chassis ID: 3352.7ae0.1f1f
Virtual Chassis Mode: Enabled
Mstr Mixed Neighbor List
Member ID Status Serial No Model prio Role Mode ID Interface
0 (FPC 0) Prsnt serial_a ex4200-24t 129 Backup N 1 vcp-0
1 vcp-1
1 (FPC 1) Prsnt serial_b ex4200-24t 129 Master* N 0 vcp-0
0 vcp-1
{master:1}
ex> request chassis routing-engine master switch check
Command aborted. Not ready for mastership switch, try after 170 secs.
NSSU
Раз,два.Общий смысл в non-stop, что обновление производится по частям, а не на всех коммутаторах в VC разом. Stop случается на коммутаторе, который попадает под обновление. Начинается все в VC с коммутатора, который выполняет роль backup RE. Следующими идут и перегружаются линейные карты. Ну а под финал обновляется мастер.
ex> request system software nonstop-upgrade /var/tmp/jinstall-ex-4200-12.3R3.4-domestic-signed.tgzПоэтому, если нет резервирования по линиям связи, использовать NSSU большого смысла нет. На обновление VC из 4 коммутаторов и последующие снапшоты уходит более часа.
warning: NSR not active
ex# set routing-options nonstop-routing
ex> request system software nonstop-upgrade /var/tmp/jinstall-ex-4200-12.3R3.4-domestic-signed.tgz
Chassis ISSU Check Done
ISSU: Validating Image
ISSU: Preparing Backup RE
Installing image on other FPC's along with the backup
Checking pending install on fpc1
Pushing bundle to fpc1
split-detection
В общем, если коммутаторов 2, то обязательно:root@ex> show configuration virtual-chassisПо-умолчанию split-detection включен. Это означает, что VC при потере одного коммутатора из двух или двух из четырех, оставшиеся будут автоматически переведены в режим линейных карт. Если коммутаторов 4, то допускается одновременное выключение только одного коммутатора.
no-split-detection;
Восстановление основного раздела диска
login: rootНужно выполнить пару команд и перезагрузить.
Password:
***********************************************************************
** **
** WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE **
** **
** It is possible that the active copy of JUNOS failed to boot up **
** properly, and so this device has booted from the backup copy. **
** **
** Please re-install JUNOS to recover the active copy in case **
** it has been corrupted. **
** **
***********************************************************************
ex>request system snapshot slice alternate all-membersall-members - опционально, если коммутатор всего один. Вторая команда перезагружает коммутатор. Очень неудобно обнаруживать подобную ошибку после пропадания питания и осозновать необходимость дополнительной перезагрузки.
ex>request system reboot slice alternate
Случайно обнаружил, что в версии 12.3 для EX-серии появилась команда auto-snapshot. Как это выглядит:
--- JUNOS 12.3R1.7 built 2013-01-26 01:32:53 UTCДа, сразу на двух коммутаторах такое несчастье. Причем, предупреждение выпадает, если проблема случилась на мастере, а если ошибка на одном из коммутаторов VC, то ошибку можно обнаружить посмотрев текущий список предупреждений.
***********************************************************************
** **
** WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE **
** **
** It is possible that the primary copy of JUNOS failed to boot up **
** properly, and so this device has booted from the backup copy. **
** **
** Please re-install JUNOS to recover the primary copy in case **
** it has been corrupted and if auto-snapshot feature is not **
** enabled. **
** **
***********************************************************************
{master:0}
ex> show system alarms
2 alarms currently active
Alarm time Class Description
2013-01-26 12:05:39 GMT-8 Minor Host 1 Boot from backup root
2013-01-26 12:05:37 GMT-8 Minor Host 0 Boot from backup root
{master:0}
ex> show system alarmsВключение автоснапшота
1 alarms currently active
Alarm time Class Description
2013-01-26 03:59:00 UTC Minor Host 3 Boot from backup root
ex> show system auto-snapshot
Auto-snapshot Configuration: Disabled
Auto-snapshot State: Disabled
{master:0}
ex> configure
Entering configuration mode
{master:0}[edit]
ex# set system auto-snapshot
{master:0}[edit]
ex# commit and-quit
fpc0:
configuration check succeeds
fpc1:
commit complete
fpc2:
commit complete
fpc3:
commit complete
fpc0:
commit complete
Exiting configuration mode
{master:0}
ex> show system auto-snapshot
Auto-snapshot Configuration: Enabled
Auto-snapshot State: Disabled
Настройка удаленного доступа
authentication-order [ tacplus password ];В данном примере подключиться можно и локальной учеткой при доступном tacacs-сервере. В этом основное отличие от Cisco IOS. Другим отличием является обязательное наличие учетной записи remote для работы пользователей tacacs'а. Конечно, на коммутаторе можно указать source-address, но нужно помнить, что некорректно заданный source, либо смена адреса, приведет к неработоспособности сервиса на коммутаторе. Заводить локальных пользователей настоятельно рекомендуется, в общем. Ну еще помнить, что для пользователя root по-умолчанию удаленный доступ закрыт.
tacplus-server {
10.0.0.1 {
timeout 2;
single-connection;
}
}
accounting {
events [ login change-log interactive-commands ];
destination {
tacplus {
server {
10.0.0.1 {
timeout 2;
single-connection;
}
}
}
}
}
login {
user remote {
full-name "All remote users";
uid 2004;
class super-user;
}
}
services {
ssh {
root-login deny;
protocol-version v2;
connection-limit 15;
rate-limit 10;
}
telnet {
connection-limit 15;
rate-limit 10;
}
}
ex# set system tacplus-server 10.0.0.1 source-address ?Если требуется только tacacs, то password требуется удалить. При недоступности tacacs'а будет проверяться локальная база пользователей.
Possible completions:
Use specified address as source address
MTU
MTU увеличивается на физических интерфейсах, а не на шасси в целом. Похоже на настройку портов на 6500-серии у Сisco, в общем.L3 интерфейсы
Коммутатор имеет один mac-адрес для всех логических L3-интерфейсов. Изменить mac-адрес на интерфейсе нельзя.Двойное тегирование и трансляция вланов
Одновременно на одном порту нельзя настроить трансляцию вланов и dot1q-tunnel. Режим порта в обоих случаях может быть только access. Особенно удивляет это в случае трансляции вланов, но тем не менее, работает так, как нужно. При трансляции в порту разрешены только те вланы, которые явно указаны, поэтому если для части вланов трансляция не требуется, то настраивать трансляцию 1:1 для влана приходится все равно, так как порт не транковый и все вланы там не разрешены.Интересно, что в Cisco есть режим порта tunnel, а тут только trunk|access.
Если на коммутаторе настроен dot1q-tunnel влан, то в портах этого влана нельзя включить dhcp snooping, даже если конкретно для этого влана снупинг не нужен. Таким образом, ставим крест на таких фичах: dhcp snooping, arp-insprection, source-guard.
Пример трансляции, где с удаленного коммутатора, подключенного к порту EX'а ge-1/0/1, передается три влана: 100,400,900. На EX'e уже имеются вланы 100,400, поэтому требуется трансляция 3100<->100, 3400<->400. При этом во влане 100 передаются фреймы с двумя тегами (QinQ) и требуется поменять внешнюю метку. Влан 900 передается без изменений тега, точнее c заменой 1:1.
ex> show ethernet-switching interfaces ge-1/0/1 detail | match "3400|900|100|mode"Пример с туннелем. Сначала задается ether-type. Потом настраивается перемычка, где в один из портов настроен транком и в нем разрешены только те вланы, которые необходимо "упаковать". Второй порт настраивается access'ом, а влан определяется как dot1q-tunneling. В обоих портах отключается STP, т.к. нет в нем необходимости. На всех портах коммутатора, которые передают вланы с двумя тегами, увеличено MTU.
Interface: ge-1/0/1.0, Index: 10, State: up, Port mode: Access
vl3400, 802.1Q Tag: 3400, Mapped Tag: 400, swap, unblocked
vl900, 802.1Q Tag: 900, Mapped Tag: 900, swap, unblocked
vl100, 802.1Q Tag: 3100, Mapped Tag: 100, swap, dot1q-tunneled, unblocked
{master}
ex> show configuration vlans vl3400
vlan-id 3400;
interface {
ge-1/0/1.0 {
mapping {
400 {
swap;
}
}
}
}
{master}
ex> show configuration vlans vl3100
vlan-id 3100;
interface {
ge-1/0/1.0 {
mapping {
100 {
swap;
}
}
}
}
dot1q-tunneling;
{master}
ex> show configuration vlans vl900
vlan-id 900;
interface {
ge-1/0/1.0 {
mapping {
900 {
swap;
}
}
}
}
{master}
ex> show configuration interfaces ge-1/0/1.0
family ethernet-switching;
{master}
ex> show configuration ethernet-switching-options
dot1q-tunneling {
ether-type 0x8100;
}
ex> show configuration interfaces ge-1/0/47
mtu 9100;
unit 0 {
description "LOOP Dot1Q-tunnel";
family ethernet-switching;
}
{master:0}
ex> show configuration interfaces ge-1/0/46
mtu 9100;
unit 0 {
description "LOOP Customer trunk";
family ethernet-switching {
port-mode trunk;
vlan {
members [ c10 c20 c30 c40 ];
}
}
}
{master:0}
ex> show ethernet-switching interfaces ge-1/0/47.0 detail
Interface: ge-1/0/47.0, Index: 70, State: up, Port mode: Access
Ether type for the interface: 0x8100
VLAN membership:
s100, 802.1Q Tag: 100, dot1q-tunneled, untagged, unblocked
Number of MACs learned on IFL: 16
{master:0}
ex> show configuration vlans s100
vlan-id 100;
interface {
ge-1/0/47.0;
}
dot1q-tunneling;
{master:0}
ex> show configuration protocols mstp
configuration-name REGION;
revision-level 1;
bridge-priority 4k;
interface ge-1/0/46.0 {
disable;
}
interface ge-1/0/47.0 {
disable;
}
Подготовка к настройке
Заметил, что оптимальным для меня способом подготовки нового коммутатора после обновления ПО, является удаление большей части конфигурации:ex>configureПривыкаю использовать MSTP вместо RSTP. На EX-3300 к тому же удаляются vcp-порты, если в них нет необходимости.
ex#delete interfaces
ex#delete vlans
ex#delete protocols rstp
ex#<копипаст собственных настроек>
ex#commit
>
SFP
Производитель не запрещает использовать трансиверы сторонних производителей, но при их использовании не гарантирует стабильную работу организованных с их помощью каналов связи. В примере ниже показано использование родного 10G-SR трансивера и twinax кабеля, который поставлялся с сервером.root> show chassis hardware | match "SFP\+"
PIC 1 REV 07 711-026017 CH0212428171 2x 10GE SFP+
Xcvr 0 REV 01 740-021308 ANA0LFK SFP+-10G-SR
Xcvr 2 NON-JNPR APF1212003315M SFP+-10G-CU3M
PIC 1 REV 07 711-026017 CH0212417264 2x 10GE SFP+
Xcvr 0 REV 01 740-021308 ANC084G SFP+-10G-SR
Xcvr 2 NON-JNPR APF12120032YDE SFP+-10G-CU3M