Комментарии 40
Спасибо!
1. Кто знает про relo in / relo can, тот и так знает; а кто не знает, тот из Вашего описания не очень поймет. Без обид.
Хотя бы упомяните «relo can».
2. В описании про «правильную очередность», я бы упомянул, что в современных IOS-ах «наконец-то» можно вставлять строки в access-list-ы не перегружая их полностью.
Хотя бы упомяните «relo can».
2. В описании про «правильную очередность», я бы упомянул, что в современных IOS-ах «наконец-то» можно вставлять строки в access-list-ы не перегружая их полностью.
Спасибо за новую статью!
Еще бы написали, что шаг правил можно менять.
Причем новое правило добавляется сразу после последнего, даже если перед двумя последними 100000 номеров.
Я не определил максимальный номер правила, но я смог получить номера длиной в три миллиона. (была такая необходимость)
Еще бы написали, что шаг правил можно менять.
Причем новое правило добавляется сразу после последнего, даже если перед двумя последними 100000 номеров.
Я не определил максимальный номер правила, но я смог получить номера длиной в три миллиона. (была такая необходимость)
НЛО прилетело и опубликовало эту надпись здесь
А не проще вместо «sh run | tee http:// 1.1.1.1», если уж надо на экран получить весь конфиг, сказать «term len 0» и затем«sh run»? :)
Если память не изменяет, то хотел бы еще сказать, что при изменении акцесс-листа, он начинает работать по новой схеме только после выхода из режима конфигурации этого самого листа.
Да, и кстати метод копипаста — конечно же прост, но стоило бы упомянуть, что злоупотреблять им нельзя.
Как например, скопировать из блокнота весь конфиг и вставить его через телнет или консоль. Часть команд пропадает либо не успевает примениться.
Я уже пару раз поплатился за это =)
Как например, скопировать из блокнота весь конфиг и вставить его через телнет или консоль. Часть команд пропадает либо не успевает примениться.
Я уже пару раз поплатился за это =)
Если сидишь на хардверной консоли то бывает(непредсказуемые результаты), обычно вешаю адрес и захожу телнетом.
Кстати, тоже верно.
Если надо поменять конфиг полностью, лучше залить его не в running, а как файл в startup и перегрузить железку.
В примерах я везде использую только кусочки небольшие, по несколько строчек. На практике бывает, что кусок текста более 50 строк не влезает полностью и начинается расколбас :(
Если надо поменять конфиг полностью, лучше залить его не в running, а как файл в startup и перегрузить железку.
В примерах я везде использую только кусочки небольшие, по несколько строчек. На практике бывает, что кусок текста более 50 строк не влезает полностью и начинается расколбас :(
Расскажите как в PuTTY бороться со случайным кликом правой кнопкой мыши — бывает такие поэмы в конфиг заносишь)
Умоляю, продолжайте :) Тем, что можно использовать wr вместо copy run start вы перевернули мой мир.
Ого, спасибо ) Вроде мелочи, а вроде и удобней работать. Хотя из мелочей и складывается наша жизнь…
Честно не представляю в каких ситуациях может потребоваться ребут по расписанию. Вы не могли бы пример привести?
Честно не представляю в каких ситуациях может потребоваться ребут по расписанию. Вы не могли бы пример привести?
Таких случаев — миллион =).
Есть такие изменения параметров, которые начинают действовать только после ребута (Например, на каталисте изменение mtu требует перезагрузки, если не ошибаюсь). Если устройство в рабочей сети, то так просто это не сделаешь. Вот и приходится ставить ребут по расписанию. Например часа в 4 утра, когда проходит минимальный трафик.
Есть такие изменения параметров, которые начинают действовать только после ребута (Например, на каталисте изменение mtu требует перезагрузки, если не ошибаюсь). Если устройство в рабочей сети, то так просто это не сделаешь. Вот и приходится ставить ребут по расписанию. Например часа в 4 утра, когда проходит минимальный трафик.
Ниже верно написали: живое железо перегружать не всегда можно «по желанию», а сидеть до 3 часов ночи — не охота :)
Например, изменение sdm profile на коммутаторе, system mtu и др.
Второй пример: когда надо подстраховаться.
Меняем конфиг удалённо, на площадке нет квалифицированного персонала или доступа, что получится заранее неизвестно. Проще поставить reload in 10 (мин) и в случае пропадания связи через 10 минут получить обратно железку, чем долго рвать на себе волосы
Третий пример: на живом железе какой то незначительный сбой, требующий перезагрузки (подвисли терминальные сессии, не отвечает какой-нить сервис). Редко, но бывает…
Например, изменение sdm profile на коммутаторе, system mtu и др.
Второй пример: когда надо подстраховаться.
Меняем конфиг удалённо, на площадке нет квалифицированного персонала или доступа, что получится заранее неизвестно. Проще поставить reload in 10 (мин) и в случае пропадания связи через 10 минут получить обратно железку, чем долго рвать на себе волосы
Третий пример: на живом железе какой то незначительный сбой, требующий перезагрузки (подвисли терминальные сессии, не отвечает какой-нить сервис). Редко, но бывает…
Я бы, кстати, сюда добавил краткий рассказ о бекапе конфигов и cron.
Мне кажется, что вместо tee 1.1.1.1 проще использовать ter len 0
ip access-list ex 101
Вещь полезная а я все по привычке с CCNA делают так
1. Выключаю ip access-group
2. Копирую в блокнот лист
3. Редактирую его
4. Удаляю лист на роутере
5. вставляю на роутер
6. включаю ip access-group
иногда еще reload in ставлю если большой правлю.
Рекомендация та же, что и для route-map
Не надо делать первый шаг.
Надо поменять название (или номер) ACL (удобно автозаменой в блокноте)
Тога 6 пункт просто применит новый ACL, а на время правки будет работать старый, не оставляя неприкрытой циску
Не надо делать первый шаг.
Надо поменять название (или номер) ACL (удобно автозаменой в блокноте)
Тога 6 пункт просто применит новый ACL, а на время правки будет работать старый, не оставляя неприкрытой циску
можно я слегка позлорадствую?
> Лучше всего сначала снять их с использования, потом изменить, потом повесить снова. Связано это с тем, что все изменения вы вносите сразу же в состояние железки.
я категорически согласен с тем что поставленное в продакшн оборудование (не важно цизко это или сервер или что еще) никак не подлежит к какой-либо модификации: реконфигурация «на лету», апдейт софта и прочее. однако, за частую приходиться делать весьма не безопасные вещи «на лету». и вот тут, как вобщем и не только тут, крайне роляет предсказуемость реакции системы на действия. в этом плане, цизко не очень то предсказуема. но, извините, кто вам даст снять «офисную» c2811 чтобы поправить роутмап и оставить при этом весь офис без работы? я понимаю что критические работы надо проводить в нерабочее время. но с каких пор правка таких мелочей к этому относится? вобщем не та вещь, за которую стоит платить ценой личного времени. ну да ладно.
> Иногда то, что уже работает (например, подгружено в оперативку) конфликтует с новым конфигом. Не редки ситуации, когда железка уходит в перезагрузку после попытки изменения конфига.
воистину так. иногда блядь вставленный модуль в цизку уводит эту цизку с «правильным» иосом в ребут. действительно надежное решение, да. (это сарказм какбе)
> 1. Копируем из конфига существующий route-map
> 2. Вставляем его в блокнот.
> 3. Меняем ему имя в блокноте
>…
дооо! я так думаю cisco действительно никогда не будет конкурентом тем же juniper, как раз вот с таким вот сифилисом. кстате, вы не правильный алгоритм избрали. т.е. почти не правильный. мой опыт показывает, что помимо «скрипта» вносимых изменений надо делать аналогичный для их отката. и как же меня достает полдня рисовать буквы в блокноте. :(
про reboot in|at|cancel хорошая и полезная тонкость. только вот не всегда ее получится применить. одно дело какая вшивая c1800 в офисе в каком гавножопске, а другое дело что-то вроде catalyst 6500 и выше. оно какбе не 5 секунд закружается. простой в оказании сервиса успеют заметить все.
можно еще много мусолить. но единственный верный вариант в этом случае это полное резервирование устройства, например по hsrp или glbp. пока вы мусолите одну, все работают на другой. меняете роли и мусолите вторую. ну или как-то так. нервные клетки целее будут.
кстате, про предсказуемость реакции. практика показывает, что брендовый писироутир на FreeBSD гораздо более предсказуем чем любая cisco. это никак не повод к холивару, каждое решение имеет свою нишу, но как минимум повод задуматься на тему «стоит ли брать в мелкий офис гирлянду цисок или таке обойтись бсдой с прокурвами?» :)
> Лучше всего сначала снять их с использования, потом изменить, потом повесить снова. Связано это с тем, что все изменения вы вносите сразу же в состояние железки.
я категорически согласен с тем что поставленное в продакшн оборудование (не важно цизко это или сервер или что еще) никак не подлежит к какой-либо модификации: реконфигурация «на лету», апдейт софта и прочее. однако, за частую приходиться делать весьма не безопасные вещи «на лету». и вот тут, как вобщем и не только тут, крайне роляет предсказуемость реакции системы на действия. в этом плане, цизко не очень то предсказуема. но, извините, кто вам даст снять «офисную» c2811 чтобы поправить роутмап и оставить при этом весь офис без работы? я понимаю что критические работы надо проводить в нерабочее время. но с каких пор правка таких мелочей к этому относится? вобщем не та вещь, за которую стоит платить ценой личного времени. ну да ладно.
> Иногда то, что уже работает (например, подгружено в оперативку) конфликтует с новым конфигом. Не редки ситуации, когда железка уходит в перезагрузку после попытки изменения конфига.
воистину так. иногда блядь вставленный модуль в цизку уводит эту цизку с «правильным» иосом в ребут. действительно надежное решение, да. (это сарказм какбе)
> 1. Копируем из конфига существующий route-map
> 2. Вставляем его в блокнот.
> 3. Меняем ему имя в блокноте
>…
дооо! я так думаю cisco действительно никогда не будет конкурентом тем же juniper, как раз вот с таким вот сифилисом. кстате, вы не правильный алгоритм избрали. т.е. почти не правильный. мой опыт показывает, что помимо «скрипта» вносимых изменений надо делать аналогичный для их отката. и как же меня достает полдня рисовать буквы в блокноте. :(
про reboot in|at|cancel хорошая и полезная тонкость. только вот не всегда ее получится применить. одно дело какая вшивая c1800 в офисе в каком гавножопске, а другое дело что-то вроде catalyst 6500 и выше. оно какбе не 5 секунд закружается. простой в оказании сервиса успеют заметить все.
можно еще много мусолить. но единственный верный вариант в этом случае это полное резервирование устройства, например по hsrp или glbp. пока вы мусолите одну, все работают на другой. меняете роли и мусолите вторую. ну или как-то так. нервные клетки целее будут.
кстате, про предсказуемость реакции. практика показывает, что брендовый писироутир на FreeBSD гораздо более предсказуем чем любая cisco. это никак не повод к холивару, каждое решение имеет свою нишу, но как минимум повод задуматься на тему «стоит ли брать в мелкий офис гирлянду цисок или таке обойтись бсдой с прокурвами?» :)
Прости за ответный сарказм: изобилие ругательного сленга не прибавляет веса твоим очень правильным и разумным словам.
ИМХО, более взвешенная позиция меньше отталкивает.
Спорить не буду. Ибо много правильного: и про откаты, и про правку мелочей «на лету», и про то, что резервирование решает часть проблем.
Но чтобы как то уравновесить всёж скажу:
1. Не так часто надо ребутить циски при нормальных настройках. Это миф, рождённый виндолюбителями
2. упомянутый 6500 можно ребутить помодульно
3. Почти никакое недорогое железо не любит втыкания модулей «на лету»
4. Для неоставляния офиса без работы как раз и придуман метод со вторым route-map (crypto-map, ACL и т.д.) Либо через ребут можно откатить, либо через обратное применение старой конструкции, которая на время отладки остаётся в конфиге
ИМХО, более взвешенная позиция меньше отталкивает.
Спорить не буду. Ибо много правильного: и про откаты, и про правку мелочей «на лету», и про то, что резервирование решает часть проблем.
Но чтобы как то уравновесить всёж скажу:
1. Не так часто надо ребутить циски при нормальных настройках. Это миф, рождённый виндолюбителями
2. упомянутый 6500 можно ребутить помодульно
3. Почти никакое недорогое железо не любит втыкания модулей «на лету»
4. Для неоставляния офиса без работы как раз и придуман метод со вторым route-map (crypto-map, ACL и т.д.) Либо через ребут можно откатить, либо через обратное применение старой конструкции, которая на время отладки остаётся в конфиге
ну там где я все таки выругался — это те места где я «напоролся» по молодости общения с cisco, но впрочем и не только с cisco, тут вы правы)
вобщем-то со всем что вы упомянули я согласен или почти согласен с оговорками, так что не буду особо комментировать :)
скажу что забыл сказать в первом посте. данная статья уже интереснее, описаны хоть и тривиальные, но все таки полезные «хитрости». кому-то эта статья облегчит жизнь. =) вобщем ждем следующего .)
вобщем-то со всем что вы упомянули я согласен или почти согласен с оговорками, так что не буду особо комментировать :)
скажу что забыл сказать в первом посте. данная статья уже интереснее, описаны хоть и тривиальные, но все таки полезные «хитрости». кому-то эта статья облегчит жизнь. =) вобщем ждем следующего .)
полезная штука сохранение старых конфигов
archive
path tftp://IP/cisco-backup/$h-$t
write-memory
при каждом выполнении write-memory на tftp сохраняется конфиг в формате hostname-date-time-№
и попутно вопрос существует ли метод расшифровки enable secret 5?
archive
path tftp://IP/cisco-backup/$h-$t
write-memory
при каждом выполнении write-memory на tftp сохраняется конфиг в формате hostname-date-time-№
и попутно вопрос существует ли метод расшифровки enable secret 5?
Метод 5 — это не шифрование, а хэширование (MD5)
А хеш тем и отличается, что его нельзя обратно «дехешировать»
Поэтому пароли типа secret нельзя «расшифровать».
ЗЫ ПОэтому, кстати, нельзя использовать пользователя типа
user secret для подключения, скажем, по CHAP
А хеш тем и отличается, что его нельзя обратно «дехешировать»
Поэтому пароли типа secret нельзя «расшифровать».
ЗЫ ПОэтому, кстати, нельзя использовать пользователя типа
user secret для подключения, скажем, по CHAP
Добавлю, что разрядность «соли» при хешировании достаточно большая,
поэтому порядок скорости при попытке взлома «подбором по словарю» около 100 паролей в минуту,
что на практике неприменимо.
поэтому порядок скорости при попытке взлома «подбором по словарю» около 100 паролей в минуту,
что на практике неприменимо.
еще один способ удобно редактировать acl, рутмапы и прочая — подгружать их с tftp
то есть на tftp создается файлик с отредактированным acl, etc. и потом copy tftp: running-config
ну и не нужно забывать про отложенный reload конечно, от ошибок никто не застрахован
то есть на tftp создается файлик с отредактированным acl, etc. и потом copy tftp: running-config
ну и не нужно забывать про отложенный reload конечно, от ошибок никто не застрахован
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Курс молодого бойца: тонкости настроек маршрутизаторов и коммутаторов