Большое спасибо за статью, надеюсь будет продолжение :)
Насчет коммитов, в свое время получил очень важный совет, перед коммитом всегда делать show | compare. Это позволит посмотреть какие изменения были сделаны с последнего коммита. Учитывая вложенность конфигурации, недописанная команда по удалению сабинтерфейса может привести к удалению всех unit на интерфейсе. Делая такую проверку можно обезопасить себя от больших проблем =)
Это было бы очень полезным =)
В целом информации по настройки джниперов на порядок меньше чем Cisco. Сейчас столкнулся с этими железками — они очень интересные и много приятных фич в конфигурировании. Но куча всяких тонкостей которые пришлось постигать набивая шишки)
Ну эт смотря с какой стороны смотреть… Может на разных сайтах инфы и меньше, но документация на сайте джунипера мне кажется более понятной чем с сайта циско. Практически на каждый вопрос есть краткая статья в KB которая содержит всю необходимую информацию. Качество поиска по документации джунипера и циско я вообще и не сравниваю. Если кто-то когда-то пытался что-то найти поиском по сайту у циско меня поймет.
Не первый раз встречаю комментарий о том что документация по джуниперам сильно лучше цисковской. Вот честное слово, я после цисковского сайта вообще не могу что то найти по джуниперу. Видимо дело привычки, но нельзя сказать что я прям очень к цисковским докам привык.
за 1.5 года пользования Juniper у меня сложилось следующее впечатление о платформе:
Оборудование отличное, удобное, некоторые фишки очень клево сделаны, да и в целом приятно пользоваться. НО. Иногда как вылезет какая нибудь хрень и все впечатление смазывается. Как например глюченный ALG, который очень клевый, но все рекомендуют его отключать из за многочисленных багов (как то полдня траблшутил непрохождение sip трафика через ipsec, при том что я видел что трафик идет в туннель, но на другой стороне его не было)
или ограничения в route based ipsec (помоему работает только с одним encr domain со стороны джунипера) или то, что policy based ipsec не работает с nat (хотя я с дуру смог заставить его работать, но только если происходит инициирование туннеля со стороны клиента).
Но не смотря на все это — мне нравится джунипер) хотя бы за его commit confirmed =)
PS с документацией все равно у них как то заморочено) часть открыта, часть доступна только зарегистрированным. Пробовал зарегится на просто аккаунт — не дает почему то.
Я не знаю, что ты имеешь ввиду, но по-моему Junos OS — это самодостаточная сетевая ОС. Все, что ей необходимо по сетевой части: интерфейсы, протоколы, политики, фильтры т.д., а так же инструментарий для работы со всем этим у нее есть. Не понимаю, какие еще программы нужны?
Если ты имеешь ввиду, можно ли под нее писать любые проги как под Линукс, то ответ — нет. Это узкоспециализированная железяка, которую покупают под совершенно конкретные нужды. Если хочется писать программы, то можно поставить Линукс. Если нужен высокопроизводительный шлюз корпоративного/провайдерского масштаба, то покупаешь Джунипер или Циско.
Так что я не совсем понял, о каких программах идет речь, приведи пример.
Да нормально. Джуниперы реально рулят по сравнению с софтовыми шлюзами, поверь я знаю что говорю. Так что проси у начальства хотя бы Juniper SRX100 (стоит в пределах 20000 руб, правда у него 100Мбитные порты) и наслаждайся настройкой :)
С этого начинали все крутые спецы. В нашем деле единственное, что важно — это желание.
А еще у меня такое мнение сложилось: сисадмин без хорошего железа — только наполовину сисадмин. На хорошее железо надо настраиваться, о нем надо мечтать. И оно обязательно придет! :)
На роутерах остуствует понятие зон безопаности (кроме софтовой J серии), эту секцию можно было бы пропустить. Другой, более гибкий синтаксис бриджеваняи ( interface vlan -> irb, vlan -> bridge domain).
По теме — srx не слишком удобны в эксплуатации.
Особенно кластеры: безумно долгое применение конфигурации (и как следствие медленная работа скриптов), периодическая рассинхронизация, не работающий commit confirmed (который описан в конце статьи), отсутствие нормального ECMP.
Не совсем понятен смысл политики 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
А в чем проблема? Ну укажи влан 1. Все будет точно так же работать. Никакой привязки номера юнита (субинтерфейса) к номеру влана нет. Или ты что хочешь?
А сам-то пробовал указать там номер влна 1 вместо 3, а потом закоммитить конфиг?
Человека, кто в первый раз держит джун в руках (на кого ориентированны статьи подобного плана) это может сбить с толку.
Первый VLAN можно назначить только VLAN'у под названием default, при попытке назначить первый номер тому же vlan-trust при коммите получаешь ошибку: Non default VLANs cannot have vlan-id 1.
Начальная настройка маршрутизаторов Juniper SRX