Статья ни о чем! Где примеры работы с FortiAnalyzer?
Вообще продукт интересный, но поддержка мне так и не смогла объяснить почему на канале 100Мб и его загрузки в 20%, по ForiAnalyzer у меня каждые 10 минут в течении суток выкачивалось под 50Гб трафика.
Про использование SD-WAN для выхода в интернет, тут все хорошо, т.к. наружу адрес натится и вернется через того же провайдера что и ушел.
А вот при использовании между двумя офисами тут не все так просто, ибо sd-wan в одном офисе ничего не знает про sd-wan в другом. Поэтому когда трафик уходи из одного офиса в другой по выбранным критериям в офисе, по одному каналу, то не факт что он вернется по этому же самому а не другому.
Подскажите есть-ли какой-то механизм заставить отправлять ответ, через тот же канал через который пришло соединение?
Проблема с удаленной настройкой оборудования у вас явно преувеличина.
При редкой необходимости всегда найдется человек с ноутбуком и тимвьювером.
При постоянной необходимости можно тем же Mikrotik LtAP mini, а это тебе и консоль, и сеть через две независимые симки, и вся мощь RouterOS.
Более того, считаю обязательным при размещении сетевого оборудования на удаленных площадках, в тех же датацентрах, иметь независимый от общей сети консольный доступ.
Но облако вещь полезная, только аргументы, в очередной раз, не оптимальные используете.
Ну и не нашел в статье указания где ваше облако находится, а тут может и роскомнадзор «нечайно» блокирнуть, и с чем тогда останутся ваши клиенты?
«выбор определяется текущими потребностями и пониманием, что в любой момент на том же самом оборудовании можно начать двигаться в сторону более продвинутой технологии.»
Что-то ни слова о финансовой составляющей. А если посчитать стоимость владения/лицензирования SD-WAN от Cisco, то сразу «протрезвеешь» и останешься на классическом DMVPN :)
Кстати, а чего сравнение со старой моделью FortiGate и почему именно 100E серии?
Новый 100F Firewall 20 Gbps, Thread 1Gbps, и, таки, два блока питания :)
Ну и по портам, обычный SFP для центрального узла, это не серьезно!
Отсутствие второго блока питания это существенный минус.
Из статьи не понял, CLI имеется? без неё это совсем не серьезно.
И есть ли пробная версия, чтобы можно было в живую пощупать перед покупкой?
Некоторые производителя предоставляют и это реально удобно.
После публикации статьи сайт zyxel лёг :)
Интересно с облаком также будет?
502 ERROR
The request could not be satisfied.
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
Request ID: HAnDlVGtSSTBblGZUpS7OarvV0-bht-gJQ59XASAoemwOXakFpbK3g==
Не понимаю к чему ссылки невпопад или листинги с оборудования.
Вопрос был простой: знаете ли вы чем отличается Cisco 2960RХ от Cisco 2960Х.
Ответ такой же простой: RX означает собран в/для России, не путать с XR.
Все верно вам сказали. pbr это костыль, которого лучше избегать.
Из своего опыта неоднократно убеждался, разбирая чужие конфиги, как грузит pcu под 100%. Не забывайте коммутатор, всегда останется коммутатором, хоть и третьего уровня.
Так упорно делаете акцент на Cisco 2960RХ, интересно а знаете чем отличается от Cisco 2960Х?
Ну и конечно умиляет «были найдены две коробки с коммутаторами Cisco 3850» ;-)
По мне статья какая-то совсем теоретическая.
Мне интереснее было бы увидеть как другие решают такие насущные для меня проблемы:
1. Адресация. Невозможно заранее точно знать сколько будет устройств в филиалах. Неоднократно сталкивался когда из маленького филиала вырастает огромнейший перевалочный центр, и приходится выдавать дополнительные подсети. Сам для небольших филиалов использую 24 маску (внутри филиала режу на меньшие подсети для сегментирования). Это удобно и для единообразия и для остальных, т.к. один филиал это один октек в адресе. Но остается проблема с разрастанием филиала.
Ну и занимать весь rfc1918, как в вашем примере, я бы не стал. Надо максимально компактно подсеть планировать. Чтобы всю вашу подсеть можно было одной маской «накрыть». А то вдруг столкнетесь с слиянием компаний.
2. Вы указали один «центр». Конечно все зависит от задачи, но обычно, лучше иметь два «цетра» и между ними несколько каналов, и не через интернет.
3. Каналы. Интересно посмотреть как у других реализована работа с каналами. Согласитесь, при наличии нескольких каналов, одновременно использовать только один — иррационально! Как происходит переключение при отказе одного из каналов? Как отслеживается качество канала, при переключении на него? Например после отвала основного канала он восстанавливается, но скорость или задержки большие, или «флапает». Нет же смысла на такой канал важный трафик пускать!
4. QOS. Интересно посмотреть реализацию когда в центр, к примеру, с двумя по 500Мбит, лезут 200 филиалов по 10-20Мбит.
5. Вообще не затронута тема централизованной авторизации. Неужто все локально? Хотя бы radius или какие еще есть варианты? Нужно же разделить доступ по уровню и регионам. Тут тоже есть свои нюансы.
6. Единообразный конфиг. Как-то при задаче развертывания большого количества единообразных устройств я даже целое веб-приложение писал, чтобы ввел параметры каналов, внутренние адреса, и получил готовый конфиг. Упрощенная версия доступна на mikrotikwizard.com. К сожалению сайт давно забросил. Если кому интересно, готов отдать в хорошие руки.
Это только часть проблем с которыми сталкиваешься на практике :)
На мой взгляд не оптимальное решение.
во-первых не любое сетевое оборудование имеет возможность авторизации по ключу.
во-вторых если делать, то делать все единообразное, для простоты поддержки. У Вас же получается что часть по ftp, часть другим образом. Да и использование у cisco только сохраненную конфигурацию не оптимально.
Сам давно использую самописный скрипт на expect, который просто сохраняет текущий sh run, с помощью cvs организована работа с версиями, ну и viewvc как веб-интерфейс.
В итоге получилось универсальное решение с поддержкой практически любого оборудования, где возможно посмотреть конфиг по ssh (cisco, hpe, juniper, mikrotik, и пр.).
Все крутится на Linux, скрипт запускается по крону в качестве аргумента файл со списком серверов, что позволяет иметь несколько списков и разные устройства опрашивать с разным периодом. При изменении конфигурации отправляется письмо на почту.
Ну и для большей секурности, для авторизации, использую сервер Tacacs+, и пользователь который собирает конфиги ограничен в правах и может только конфиг посмотреть.
1. Я не спрашивал про ваш конфиг, я просил показать график загрузки процессора. Да и не корректно сравнивать 100 и 30-40 Мбит.
2. Если на провайдере не получается протестировать — подключите в 3 и 4 порт два компьютера, и запустите iperf. Думаю 100Мбит вы не получите.
Вообще продукт интересный, но поддержка мне так и не смогла объяснить почему на канале 100Мб и его загрузки в 20%, по ForiAnalyzer у меня каждые 10 минут в течении суток выкачивалось под 50Гб трафика.
А вот при использовании между двумя офисами тут не все так просто, ибо sd-wan в одном офисе ничего не знает про sd-wan в другом. Поэтому когда трафик уходи из одного офиса в другой по выбранным критериям в офисе, по одному каналу, то не факт что он вернется по этому же самому а не другому.
Подскажите есть-ли какой-то механизм заставить отправлять ответ, через тот же канал через который пришло соединение?
При редкой необходимости всегда найдется человек с ноутбуком и тимвьювером.
При постоянной необходимости можно тем же Mikrotik LtAP mini, а это тебе и консоль, и сеть через две независимые симки, и вся мощь RouterOS.
Более того, считаю обязательным при размещении сетевого оборудования на удаленных площадках, в тех же датацентрах, иметь независимый от общей сети консольный доступ.
Но облако вещь полезная, только аргументы, в очередной раз, не оптимальные используете.
Ну и не нашел в статье указания где ваше облако находится, а тут может и роскомнадзор «нечайно» блокирнуть, и с чем тогда останутся ваши клиенты?
Что-то ни слова о финансовой составляющей. А если посчитать стоимость владения/лицензирования SD-WAN от Cisco, то сразу «протрезвеешь» и останешься на классическом DMVPN :)
Новый 100F Firewall 20 Gbps, Thread 1Gbps, и, таки, два блока питания :)
Ну и по портам, обычный SFP для центрального узла, это не серьезно!
Из статьи не понял, CLI имеется? без неё это совсем не серьезно.
И есть ли пробная версия, чтобы можно было в живую пощупать перед покупкой?
Некоторые производителя предоставляют и это реально удобно.
Интересно с облаком также будет?
502 ERROR
The request could not be satisfied.
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
Request ID: HAnDlVGtSSTBblGZUpS7OarvV0-bht-gJQ59XASAoemwOXakFpbK3g==
Вопрос был простой: знаете ли вы чем отличается Cisco 2960RХ от Cisco 2960Х.
Ответ такой же простой: RX означает собран в/для России, не путать с XR.
Из своего опыта неоднократно убеждался, разбирая чужие конфиги, как грузит pcu под 100%. Не забывайте коммутатор, всегда останется коммутатором, хоть и третьего уровня.
Ну и конечно умиляет «были найдены две коробки с коммутаторами Cisco 3850» ;-)
Видимо вы не умеете его «готовить» :)
Все с наступающим Новым Годом!
Я пока, лучше хорошего скрипта не придумал. Скрипт проверяет наличие и качество каналов, а там уже, регулирует критичный или вторичный трафик.
Мне интереснее было бы увидеть как другие решают такие насущные для меня проблемы:
1. Адресация. Невозможно заранее точно знать сколько будет устройств в филиалах. Неоднократно сталкивался когда из маленького филиала вырастает огромнейший перевалочный центр, и приходится выдавать дополнительные подсети. Сам для небольших филиалов использую 24 маску (внутри филиала режу на меньшие подсети для сегментирования). Это удобно и для единообразия и для остальных, т.к. один филиал это один октек в адресе. Но остается проблема с разрастанием филиала.
Ну и занимать весь rfc1918, как в вашем примере, я бы не стал. Надо максимально компактно подсеть планировать. Чтобы всю вашу подсеть можно было одной маской «накрыть». А то вдруг столкнетесь с слиянием компаний.
2. Вы указали один «центр». Конечно все зависит от задачи, но обычно, лучше иметь два «цетра» и между ними несколько каналов, и не через интернет.
3. Каналы. Интересно посмотреть как у других реализована работа с каналами. Согласитесь, при наличии нескольких каналов, одновременно использовать только один — иррационально! Как происходит переключение при отказе одного из каналов? Как отслеживается качество канала, при переключении на него? Например после отвала основного канала он восстанавливается, но скорость или задержки большие, или «флапает». Нет же смысла на такой канал важный трафик пускать!
4. QOS. Интересно посмотреть реализацию когда в центр, к примеру, с двумя по 500Мбит, лезут 200 филиалов по 10-20Мбит.
5. Вообще не затронута тема централизованной авторизации. Неужто все локально? Хотя бы radius или какие еще есть варианты? Нужно же разделить доступ по уровню и регионам. Тут тоже есть свои нюансы.
6. Единообразный конфиг. Как-то при задаче развертывания большого количества единообразных устройств я даже целое веб-приложение писал, чтобы ввел параметры каналов, внутренние адреса, и получил готовый конфиг. Упрощенная версия доступна на mikrotikwizard.com. К сожалению сайт давно забросил. Если кому интересно, готов отдать в хорошие руки.
Это только часть проблем с которыми сталкиваешься на практике :)
во-первых не любое сетевое оборудование имеет возможность авторизации по ключу.
во-вторых если делать, то делать все единообразное, для простоты поддержки. У Вас же получается что часть по ftp, часть другим образом. Да и использование у cisco только сохраненную конфигурацию не оптимально.
Сам давно использую самописный скрипт на expect, который просто сохраняет текущий sh run, с помощью cvs организована работа с версиями, ну и viewvc как веб-интерфейс.
В итоге получилось универсальное решение с поддержкой практически любого оборудования, где возможно посмотреть конфиг по ssh (cisco, hpe, juniper, mikrotik, и пр.).
Все крутится на Linux, скрипт запускается по крону в качестве аргумента файл со списком серверов, что позволяет иметь несколько списков и разные устройства опрашивать с разным периодом. При изменении конфигурации отправляется письмо на почту.
Ну и для большей секурности, для авторизации, использую сервер Tacacs+, и пользователь который собирает конфиги ограничен в правах и может только конфиг посмотреть.
Делал ГОСТовое шифрование на Дионисах, там как-то все проще с ditun-ами.
2. Если на провайдере не получается протестировать — подключите в 3 и 4 порт два компьютера, и запустите iperf. Думаю 100Мбит вы не получите.