Comments 32
Большое спасибо за статью, надеюсь будет продолжение :)
Насчет коммитов, в свое время получил очень важный совет, перед коммитом всегда делать show | compare. Это позволит посмотреть какие изменения были сделаны с последнего коммита. Учитывая вложенность конфигурации, недописанная команда по удалению сабинтерфейса может привести к удалению всех unit на интерфейсе. Делая такую проверку можно обезопасить себя от больших проблем =)
Насчет коммитов, в свое время получил очень важный совет, перед коммитом всегда делать show | compare. Это позволит посмотреть какие изменения были сделаны с последнего коммита. Учитывая вложенность конфигурации, недописанная команда по удалению сабинтерфейса может привести к удалению всех unit на интерфейсе. Делая такую проверку можно обезопасить себя от больших проблем =)
show | compare — классная вещь, согласен!
Вообще, хочу первым делом сделать жизненный мануал по CLI. :)
Вообще, хочу первым делом сделать жизненный мануал по CLI. :)
Это было бы очень полезным =)
В целом информации по настройки джниперов на порядок меньше чем Cisco. Сейчас столкнулся с этими железками — они очень интересные и много приятных фич в конфигурировании. Но куча всяких тонкостей которые пришлось постигать набивая шишки)
В целом информации по настройки джниперов на порядок меньше чем Cisco. Сейчас столкнулся с этими железками — они очень интересные и много приятных фич в конфигурировании. Но куча всяких тонкостей которые пришлось постигать набивая шишки)
Ну эт смотря с какой стороны смотреть… Может на разных сайтах инфы и меньше, но документация на сайте джунипера мне кажется более понятной чем с сайта циско. Практически на каждый вопрос есть краткая статья в KB которая содержит всю необходимую информацию. Качество поиска по документации джунипера и циско я вообще и не сравниваю. Если кто-то когда-то пытался что-то найти поиском по сайту у циско меня поймет.
Не первый раз встречаю комментарий о том что документация по джуниперам сильно лучше цисковской. Вот честное слово, я после цисковского сайта вообще не могу что то найти по джуниперу. Видимо дело привычки, но нельзя сказать что я прям очень к цисковским докам привык.
Согласен, я тоже после сайта Cisco на сайте Juniper все «ноги поломал».
К счастью, после понятия простой логики Junos жизнь становится лучше :-)
К счастью, после понятия простой логики Junos жизнь становится лучше :-)
за 1.5 года пользования Juniper у меня сложилось следующее впечатление о платформе:
Оборудование отличное, удобное, некоторые фишки очень клево сделаны, да и в целом приятно пользоваться. НО. Иногда как вылезет какая нибудь хрень и все впечатление смазывается. Как например глюченный ALG, который очень клевый, но все рекомендуют его отключать из за многочисленных багов (как то полдня траблшутил непрохождение sip трафика через ipsec, при том что я видел что трафик идет в туннель, но на другой стороне его не было)
или ограничения в route based ipsec (помоему работает только с одним encr domain со стороны джунипера) или то, что policy based ipsec не работает с nat (хотя я с дуру смог заставить его работать, но только если происходит инициирование туннеля со стороны клиента).
Но не смотря на все это — мне нравится джунипер) хотя бы за его commit confirmed =)
PS с документацией все равно у них как то заморочено) часть открыта, часть доступна только зарегистрированным. Пробовал зарегится на просто аккаунт — не дает почему то.
Оборудование отличное, удобное, некоторые фишки очень клево сделаны, да и в целом приятно пользоваться. НО. Иногда как вылезет какая нибудь хрень и все впечатление смазывается. Как например глюченный ALG, который очень клевый, но все рекомендуют его отключать из за многочисленных багов (как то полдня траблшутил непрохождение sip трафика через ipsec, при том что я видел что трафик идет в туннель, но на другой стороне его не было)
или ограничения в route based ipsec (помоему работает только с одним encr domain со стороны джунипера) или то, что policy based ipsec не работает с nat (хотя я с дуру смог заставить его работать, но только если происходит инициирование туннеля со стороны клиента).
Но не смотря на все это — мне нравится джунипер) хотя бы за его commit confirmed =)
PS с документацией все равно у них как то заморочено) часть открыта, часть доступна только зарегистрированным. Пробовал зарегится на просто аккаунт — не дает почему то.
Огромное спасибо за статью! Все описано достаточно детально и грамотно! А можно ли писать приложения для данного сетевого устройства, ведь как ни как им управляет ОС?
Скажем так, не программы, а все же скрипты. Да, можно.
Есть целая библиотека разнообразных скриптов под самые разные нужды: www.juniper.net/us/en/community/junos/script-automation/library/
Если есть желание, можешь почитать книги на эту тему: www.juniper.net/us/en/community/junos/training-certification/day-one/
(раздел Junos Automation)
Правда все на английском :)
Говорят, на Junos можно даже какие-то пакеты ставить, но это не пробовал, ибо зачем?
Есть целая библиотека разнообразных скриптов под самые разные нужды: www.juniper.net/us/en/community/junos/script-automation/library/
Если есть желание, можешь почитать книги на эту тему: www.juniper.net/us/en/community/junos/training-certification/day-one/
(раздел Junos Automation)
Правда все на английском :)
Говорят, на Junos можно даже какие-то пакеты ставить, но это не пробовал, ибо зачем?
Спасибо! Скрипты это очень замечательно! Но хотелось, что бы маршрутизатор выполнял именно программы написанные специально под его ОС, это позволило бы оптимизировать и модернизировать данное устройство под свои цели. Желание огромное, но времени мало, а я больше интересуюсь другим направлением, не хочу распыляться! Еще раз спасибо за информацию!
Я не знаю, что ты имеешь ввиду, но по-моему Junos OS — это самодостаточная сетевая ОС. Все, что ей необходимо по сетевой части: интерфейсы, протоколы, политики, фильтры т.д., а так же инструментарий для работы со всем этим у нее есть. Не понимаю, какие еще программы нужны?
Если ты имеешь ввиду, можно ли под нее писать любые проги как под Линукс, то ответ — нет. Это узкоспециализированная железяка, которую покупают под совершенно конкретные нужды. Если хочется писать программы, то можно поставить Линукс. Если нужен высокопроизводительный шлюз корпоративного/провайдерского масштаба, то покупаешь Джунипер или Циско.
Так что я не совсем понял, о каких программах идет речь, приведи пример.
Если ты имеешь ввиду, можно ли под нее писать любые проги как под Линукс, то ответ — нет. Это узкоспециализированная железяка, которую покупают под совершенно конкретные нужды. Если хочется писать программы, то можно поставить Линукс. Если нужен высокопроизводительный шлюз корпоративного/провайдерского масштаба, то покупаешь Джунипер или Циско.
Так что я не совсем понял, о каких программах идет речь, приведи пример.
Писать приложения можно. Для этого существует специальный SDK: developer.juniper.net/content/jdn/en/develop-overview/junos-space-sdk/getting-started.html
Существуют вполне вменяемые программы, например, для анализа уязвимостей сети.
Существуют вполне вменяемые программы, например, для анализа уязвимостей сети.
Спасибо, вы все разъяснили! Просто я больше чем Windows и файл сервера на FreeBSD не администрировал, ну еще циско понасиловал в Packet tracer да в GNS3, так что извините за некомпетентность)
у моего начальства тяжело новую мышку получить) Я работаю администратором в компьютерном классе у себя в ВУЗе, так что у меня 20 компов старый Allied Telesyn коммутатор, и сервер на FreeNAS) Чем богаты тем и радуемся)
Сочувствую, друг! Но, мне кажется, ты все же не всю жизнь собрался в этом классе сидеть? )
До получения диплома)
Спасибо за статью, с нетерпением жду продолжения.
Скажите, а если бы мы настраивали не firewall, а роутер, что бы изменилось в настройке?
Скажите, а если бы мы настраивали не firewall, а роутер, что бы изменилось в настройке?
По теме — srx не слишком удобны в эксплуатации.
Особенно кластеры: безумно долгое применение конфигурации (и как следствие медленная работа скриптов), периодическая рассинхронизация, не работающий commit confirmed (который описан в конце статьи), отсутствие нормального ECMP.
Особенно кластеры: безумно долгое применение конфигурации (и как следствие медленная работа скриптов), периодическая рассинхронизация, не работающий commit confirmed (который описан в конце статьи), отсутствие нормального ECMP.
Автор, спасибище, и пиши еще :)
Ты очень и очень вовремя! Как раз сегодня нужно будет вводить парк джуниперов в эксплуатацию
Ты очень и очень вовремя! Как раз сегодня нужно будет вводить парк джуниперов в эксплуатацию
Отличная статья, спасибо.
Не совсем понятен смысл политики trust-to-trust. Это аналогия VACL у Cisco?
Получается без её применения между интерфейсами на весь трафик неявный deny?
root@srx# commit check
При вводе команд синтаксис не проверяется?
Не совсем понятен смысл политики trust-to-trust. Это аналогия VACL у Cisco?
Получается без её применения между интерфейсами на весь трафик неявный deny?
root@srx# commit check
При вводе команд синтаксис не проверяется?
При вводе команд синтаксис проверяется, не проверяется семантика)
Еще конечно очень необычно (относительно cisco), что команды интерпретируются и конфиг совсем не похож на то, что было введено из режима конкурирования.
Есть ли «обратная совместимость», т.е. можно ли вводить интерпретированный результат находясь в режиме конкурирования, или необходимо редактировать конфигурационный файл?
Есть ли «обратная совместимость», т.е. можно ли вводить интерпретированный результат находясь в режиме конкурирования, или необходимо редактировать конфигурационный файл?
Можно.
Режим «конкурирования» ))), наверное все-таки «конфигурирования».
Можно вставлять форматированный конфиг либо в веб-интерфейс, либо тупо в консоль, после команды:
load merge terminal
Обратное преобразование тоже возможно. Можно вывести кусок конфиги в виде списка консольных команд (в виде «set ....»). Например:
show security policies | display set
Политика trust-to-trust нужна. Иначе откуда Джунипер узнает, можно ли хостам внутри этой зоны общаться друг с другом? За нас думать он не умеет и не должен.
Поэтому да, если политика не указана, стоит неявный deny.
Но это поведение можно изменить командой:
set security policies default-policy permit-all
Можно вставлять форматированный конфиг либо в веб-интерфейс, либо тупо в консоль, после команды:
load merge terminal
Обратное преобразование тоже возможно. Можно вывести кусок конфиги в виде списка консольных команд (в виде «set ....»). Например:
show security policies | display set
Политика trust-to-trust нужна. Иначе откуда Джунипер узнает, можно ли хостам внутри этой зоны общаться друг с другом? За нас думать он не умеет и не должен.
Поэтому да, если политика не указана, стоит неявный deny.
Но это поведение можно изменить командой:
set security policies default-policy permit-all
root@srx# set vlans vlan-trust vlan-id 3
В каждой статье по теме настройки джунипера повторяют пример с сайта джуна… Хоть бы кто-нить рассказал как на vlan.0 повесить не третий vlan, а 1-й.
А в чем проблема? Ну укажи влан 1. Все будет точно так же работать. Никакой привязки номера юнита (субинтерфейса) к номеру влана нет. Или ты что хочешь?
А сам-то пробовал указать там номер влна 1 вместо 3, а потом закоммитить конфиг?
Человека, кто в первый раз держит джун в руках (на кого ориентированны статьи подобного плана) это может сбить с толку.
Первый VLAN можно назначить только VLAN'у под названием default, при попытке назначить первый номер тому же vlan-trust при коммите получаешь ошибку: Non default VLANs cannot have vlan-id 1.
Человека, кто в первый раз держит джун в руках (на кого ориентированны статьи подобного плана) это может сбить с толку.
Первый VLAN можно назначить только VLAN'у под названием default, при попытке назначить первый номер тому же vlan-trust при коммите получаешь ошибку: Non default VLANs cannot have vlan-id 1.
Sign up to leave a comment.
Начальная настройка маршрутизаторов Juniper SRX