[smart85]

Коллеги, приветствую!

на старичке ЕХ4200 возникли проблемы с коммитом:

 

# commit check
fpc2:
configuration check succeeds
fpc3:
configuration check succeeds
fpc4:
configuration check succeeds
fpc5:
configuration check succeeds
fpc6:
configuration check succeeds
fpc7:
configuration check succeeds

коммичу
 

# commit comment "add ID IN prefix-list"
fpc2:
configuration check succeeds
fpc3:
error: could not copy to juniper.save+
fpc2:
error: remote commit-configuration failed on fpc3
fpc4:
commit complete
fpc5:
commit complete
fpc6:
commit complete
fpc7:
commit complete
fpc2:
error: commit failed

опа, и похоже это из-за заполненного /var/rundb на fpc3

 

> show system storage | match rundb
/dev/md18               118M        87M        21M       80%  /var/rundb
/dev/md18               118M       107M       1.6M       99%  /var/rundb
/dev/md18               118M        76M        33M       70%  /var/rundb
/dev/md18               118M        75M        33M       69%  /var/rundb
/dev/md18               118M        78M        30M       72%  /var/rundb
/dev/md18               118M        78M        31M       71%  /var/rundb

{backup:3}

 

99% used, начал искать решение, и нашел такое: https://supportportal.juniper.net/s/article/Junos-Commit-Error-error-could-not-copy-to-juniper-save?language=en_US

 

Какие могут быть подводные камни? или тру файлы на fpc3, запускаю на нем mgd -I и они будут перегенерены с master re ? этот fcp в роли backup re в стеке 

 

Спасибо за внимание, всего вам наилучшего!

 

[smart85]

и еще вопрос, а ваши RU учетки не заблокировали на https://iam-signin.juniper.net/signin ?

 

мне пишет: Невозможно выполнить вход

[smart85]

Убрал коммит объемный, добавил только filter input на иф, попробовал коммит, и:

# commit confirmed 7
fpc2:
configuration check succeeds
fpc3:
error: could not copy to juniper.save+
fpc2:
error: remote commit-configuration failed on fpc3
fpc4:
error: could not copy to juniper.save+
fpc2:
error: remote commit-configuration failed on fpc4
fpc5:
error: could not copy to juniper.save+
fpc2:
error: remote commit-configuration failed on fpc5
fpc6:
error: could not copy to juniper.save+
fpc2:
error: remote commit-configuration failed on fpc6
fpc7:
error: could not copy to juniper.save+
fpc2:
error: remote commit-configuration failed on fpc7
error: commit failed

{master:2}[edit]

и место поубавилось и на остальных мемберах стека, кроме мастера

> show system storage | match rundb
/dev/md18               118M        87M        21M       80%  /var/rundb
/dev/md18               118M       107M       1.6M       99%  /var/rundb
/dev/md18               118M        98M        11M       90%  /var/rundb
/dev/md18               118M        98M        11M       90%  /var/rundb
/dev/md18               118M       101M       7.1M       93%  /var/rundb
/dev/md18               118M       100M       8.5M       92%  /var/rundb

{master:2}

WTF? коммичу очень большие префикс листы через load set /path/to/file/with/set/commands

[pfexec]

В 01.07.2022 в 15:53, mse.rus77 сказал:

 

WTF? коммичу очень большие префикс листы через load set /path/to/file/with/set/commands

а зачем большие префикс листы на свиче?

[smart85]

В 02.07.2022 в 22:39, pfexec сказал:

а зачем большие префикс листы на свиче?

нужно отфильтровать входящий трафик на xe интерфейсе порезав пакеты с большого множества сетей, и этот xe на 4200

btw, вопрос, какие есть варианты борьбы с SYN flood DDoS ?

[smart85]

Коллеги, здравствуйте!

В общем все, попал( откатил все префикс-листы, но коммит теперь сделать не могу, все fpc за исключением мастера ругаются на

 

error: remote commit-configuration failed on fpcX

 

и на них заполнился /var/rundb

 

 

Подскажите, пожалуйста, как можно решить проблему?

[azhur]

Сходу в голову приходят 2 варианта:

1. Попытаться уменьшить глубину истории конфигов и закоммитить это простое изменение. Если сработает - ждать пока автоматика подчистит лишнее и место освободится за счёт удаления старых версий конфигов.

2. Скопировать текущую конфигурацию "на внешнее хранилище" и сделать сброс на заводские, после чего перенастроить с нуля. И чтобы такое не повторилось, опять же уменьшить глубину истории.

[smart85]

В 11.07.2022 в 07:06, azhur сказал:

Сходу в голову приходят 2 варианта:

1. Попытаться уменьшить глубину истории конфигов и закоммитить это простое изменение. Если сработает - ждать пока автоматика подчистит лишнее и место освободится за счёт удаления старых версий конфигов.

2. Скопировать текущую конфигурацию "на внешнее хранилище" и сделать сброс на заводские, после чего перенастроить с нуля. И чтобы такое не повторилось, опять же уменьшить глубину истории.

1) ничего не дает коммитить, пробовал еще убрать system commit synchronize. 
2) походу остается да, это(

[smart85]

Коллеги, приветствую!

Пожелайте мне удачи, согласовал работы по обновлению ПО, и попробую, что есть Nonstop Software Upgrade on EX Series Virtual Chassis

По результатам отпишусь с описанием работ, вдруг кому пригодится.

[vvertexx]

В 19.07.2022 в 16:57, mse.rus77 сказал:

попробую, что есть Nonstop Software Upgrade on EX Series Virtual Chassis

удачи.

PS: она Вам понадобится

[smart85]

В 19.07.2022 в 15:50, vvertexx сказал:

удачи.

PS: она Вам понадобится

есть какие-то нюансы? подвох ждать со всех сторон?

[azhur]

В 19.07.2022 в 16:57, mse.rus77 сказал:

Nonstop Software Upgrade on EX Series Virtual Chassis

Цитата

• Upgrading member switches one at a time in other EX Series Virtual Chassis while permitting traffic to continue to flow through the members that are not being upgraded.

To achieve minimal disruption to traffic, you must configure link aggregation groups (LAGs) such that the member links of each LAG reside on different line cards or Virtual Chassis members. When one member link of a LAG is down, the remaining links are up, and traffic continues to flow through the LAG.

То есть свитчи в стеке ребутаются строго по очереди. Чтобы клиент этого не заметил, он должен быть подключен LAG-ом из портов на разных свитчах из стека (например ge-0/0/0 + ge-1/0/0).

[smart85]

Коллеги, приветствую!
Обновление ПО не помогло, софт обновился, не без проблем (fpc6 упал в лоадер, пришлось в флехи ставить JunOS).

И интересный момент, пока fpc6 был в таком состоянии и был физически подключен стековым кабелем к другим мемберам, весь стек лежал, мастер был, как LC, остальные мемберы NoPrst. Отключил и стек собрался.

 

request system zeroize похоже теперь мой путь, но дока гласит, что в VC надо сначала вывести девайс из стека и только потом зероайзить его, а вывести из стека я не могу, ибо коммит не канает.

 

Верно понимаю, что остается один и жесткий путь, а именно:

1) подготовить конфиг для заливки через load set 

2) разобрать физически весь стек

3) на каждом мембере с LCD морды выполнить reset to factory defaults
4) собрать стек обратно

5) влить конфиг

 

Если есть какие-то инфе варианты с меньшим простоем, прошу подсказать, пожалуйста.

[smart85]

Коллеги, здравствуйте!

В общем разжился 4 ЕХ4200 и собрал стенд. На бою у меня 6 штук в стеке, на стенде эмулировал master re (fpc2) и line-card (fpc6), думаю этого достаточно.

 

Две железки в одном стеке, и влил туда конфиг, который сломал коммиты. Из интересного: на стенде у меня уже обновленный JunOS 12.3R12.4 (на боевом ядре 12.3R9.4) и несмотря на заявление, что такое поведение ядра вызвано багом 12.3R9.4, при заливке конфига на 12.3R12.4 девай так же окукливается:

 

 

root@EX4200-TST-BAD# commit
warning: Could not connect to fpc-1 : Can't assign requested address
warning: Cannot connect to other RE, ignoring it
configuration check succeeds
fpc6:
error: could not open configuration database (juniper.data+)
fpc2:
error: remote commit-configuration failed on fpc6
error: commit failed

{master:2}[edit]

 

Две другие железки образовали у меня fpc0 (master) и fpc1 (backup) - как раз данные номера fpc на боевом ядре не используются, там идет fpc2 - fcp6. Туда я накатил отредактированный конфиг, коммиты идут, все прекрасно.

 

Из интересного: я попробовал сразу объединить все 4 железки стековым кабелем, использую preprovisioned конфигурацию virtual-chassis`а и в итоге два стека работают в одной физике параллельно, выглядит это так:

на новом стеке (fpc0 + fcp1):
 

root@EX4200-TST-NEW-> show virtual-chassis

Preprovisioned Virtual Chassis
Virtual Chassis ID: 0843.890a.3b25
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    B***75 ex4200-24f 129  Master*      N  1  vcp-0
1 (FPC 1)  Prsnt    B***77 ex4200-24f 129  Backup       N  0  vcp-1
-          Unprvsnd BM***33 ex4200-24t <--- master старого стека
-          Unprvsnd BM***26 ex4200-24t <--- line-card нового стекак

{master:0}

 

старый стек (fpc2 + fcp6):

 

root@EX4200-TST-BAD> show virtual-chassis

Preprovisioned Virtual Chassis
Virtual Chassis ID: 2acf.9123.7ece
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
2 (FPC 2)  Prsnt    BM***26 ex4200-24t 129  Master*      N  6  vcp-0
6 (FPC 6)  Prsnt    BM***33 ex4200-24t   0  Linecard     N  2  vcp-1
-          Unprvsnd B***77 ex4200-24f <--- backup нового стека
-          Unprvsnd B***75 ex4200-24f <--- master нового стека

{master:2}

 

Далее определил работы так:

0) Ко всем девайсам я подключен через консоль с Serial over Network сервера ALTUSEN (просто божественная штука!)

 

1) на старом стеке на master re и backup re гашу vcp порты:

request virtual-chassis vc-port set interface vcp-0 disable

request virtual-chassis vc-port set interface vcp-1disable

соответственно master и backup перестают видеть друг друга и line-card`s тоже, на lin-card`ы я теперь без проблем зайду с консоли, мастера и бэкапа они не видят.

 

2) подключаюсь к консоли остальных line-card стека, логинюсь

 

3) на новом стеке активирую member`ов из старого стека в virtual-chassis, но не коммичу сразу.

 

{master:0}[edit virtual-chassis]
root@EX4200-TST-NEW# activate member 2

{master:0}[edit virtual-chassis]
root@EX4200-TST-NEW# activate member 6

 

4) на всех девайсах старого стека запускаю request system zeroize

root@EX4200-TST-BAD> request system zeroize
warning: System will be rebooted and may not boot without configuration
Erase all data, including configuration and log files? [yes,no] (no) yes

warning: ipsec-key-management subsystem not running - not needed by configuration.
warning: zeroizing fpc6


root@EX4200-TST-BAD> request system zeroize
warning: System will be rebooted and may not boot without configuration
Erase all data, including configuration and log files? [yes,no] (no) yes

warning: ipsec-key-management subsystem not running - not needed by configuration.
warning: zeroizing fpc2

 

5) Жду начала загрузки девайсов из п. 4, и на новом стеке коммичу конфиг с новыми member`ами

{master:2}

root@EX4200-TST-NEW# commit
fpc0:
configuration check succeeds
fpc1:
commit complete
fpc0:
commit complete

{master:0}[edit virtual-chassis]

vc в этот момент выглядит так:

 

root@EX4200-TST-NEW# run show virtual-chassis

Preprovisioned Virtual Chassis
Virtual Chassis ID: 0843.890a.3b25
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    B***75 ex4200-24f 129  Master*      N  1  vcp-0
1 (FPC 1)  Prsnt    B***77 ex4200-24f 129  Backup       N  0  vcp-1

{master:0}[edit virtual-chassis]

 

по наблюдению, стеку нужно 3-5 минут для того, чтобы обработать новых member`ов, по истечении этого времени наблюдается такая картина:

 

root@EX4200-TST-NEW# run show virtual-chassis

Preprovisioned Virtual Chassis
Virtual Chassis ID: 0843.890a.3b25
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    BR***75 ex4200-24f 129  Master*      N  1  vcp-0
                                                                 6  vcp-1
1 (FPC 1)  Prsnt    BR***77 ex4200-24f 129  Backup       N  2  vcp-0
                                                                 0  vcp-1
2 (FPC 2)  Prsnt    B***26 ex4200-24t   0  Linecard     N  6  vcp-0
                                                                 1  vcp-1
6 (FPC 6)  Prsnt    B***33 ex4200-24t   0  Linecard     N  0  vcp-0
                                                                 2  vcp-1

{master:0}[edit virtual-chassis]

 

Девайсы старого стека стали линейными картами в новом.

На всякий случай делаю перезапуск всех member`ов

 

root@EX4200-TST-NEW# run request system reboot all-members
Reboot the system ? [yes,no] (no) yes


Rebooting fpc1

Rebooting fpc2

Rebooting fpc6

Вроде все гладко, как на бою пройдет, отпишусь.