[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) влить конфиг

 

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