Дело в том, что я непросто это их головы взял, это действительно для меня на данный момент проблема.
сравните LSA таблицу маршруты intra-area и маршруты какие пападают в таблицу маршрутизации
Я просто привел пример, с /32 понятно, вы не боитесь, что когда нибудь, кем нибудь может распространится дефолтный маршрут ext-2, особенно если всё же избавитесь в перспективе от huawei и проблем с мультикастом в L2 сегменте не будет
Я конечно не знаю насколько у вас всё в схвачено, но best practice в фильтрах ospf всё таки с начало "что то разрешать", а потом всё запрещать, иначе от одного неверного действия можете получить неработающую сеть, вспомните яндекс…
я бы сделал как нибудь так.
Не знаю почему вы так агрессивно настроены, но если любое ПО ожидает от вас XML данные, а вы ей шлёте JSON, не удивляйтесь, что любое ПО некорректно работает.
[sarcasm]Вы же прекрасно понимаете, что открыть файл DWG с помощь Wireshark не получиться, и почему-то все до сих пор сидят и не озвучивают это проблему в Wireshark и кстати ровно наоборот sniff не откроется в коммерческом продукте AutoCAD[/sarcasm]
И если честно, то выглядит со стороны киви примерно так «нам от мониторинга нужно, раз, два, три … +100500»
В ваше программном обеспечение, не было завялено такого функционала, и мы наделали костылей, а теперь Zabbix учесть все наши недовольства и доделать.
Исходники открыты, что останавливает?
Согласен.
Если ты хочешь чегото большего бери напильник и делай сам.
А по поводу unsupported в sh скриптах, так надо было писать скрипты так, чтобы вывод был всегда supported =)
Примерно на пальцах, говорим про винду
у вас есть уже кластер hyper-v из двух нод и общего строрейджа
поднимаете две виртуальные машины, и к обоим подключаем виртуальный диск кворума (сейчас не вспомню как в hyper-v это опция звучит в настройках жёсткого диска)
далее на виртуальным машинах поднимайте роль кластера с общим IP адресом ну и настраивайте его под свои нужны.
при выключении одной из физических нод, у вас в виртуальном кластере выпадет одна из нод и у вас отработает ваш виртуальный кластер, простоя минимум в худшем случае пару пакетов
на hyper-v пока такое не возможно самим гипервизором, да и наврятли microsoft сделает в ближайшее время такую возможность.
если у вас виртуальная машина на windows, то поднимайте кластер майкрософта уже на виртуальных машина. если у вас linux то смотрите в сторону keepalived
=))) вы же понимаете, к чему я виду =)
давайте по другому
1) запрос
мой хост 192.168.0.100:45555 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100:45555->60.0.0.1:45555))->Хост назначения(8.8.8.8:80)
2) запрос ajax или полученеи картинок и т.п.д
мой хост 192.168.0.100:41111 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100:41111->???.???.???.???:41111))->Хост назначения(8.8.8.8:80)
в итоге получим два соединения, и не факт что, второе выйдет с адреса 60.0.0.1
на PAT, конечно же нет, но я говорю о другом нюансе.
мой хост 192.168.0.100/24 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100->60.0.0.1))->Хост назначения(8.8.8.8)
хост 8.8.8.8 с учётом моего IP адреса создал cookie.
вопрос в следующем, если я через некоторое время (но меньшее жизни куки), обращусь к хосту 8.8.8.8, каков шанс, что мой трафик уйдёт с адрес 60.0.0.1, а не 50.0.0.1??
Правильно ли я понял, в итоге получается обычный ECMP.
B* 0.0.0.0/0 [20/0] via 60.0.0.2 (ISPB), 00:00:20
[20/0] via 50.0.0.2 (ISPA), 00:00:20
Первый же сайт, типо одноклассников, который учитывает в сессии ip адрес, и тут же вы получите факап. в виде разъяренных пользователей, которые должны будут каждые N минут вводить логин и пароль.
просто подключившись к хабу/свичу сетевой адаптер будет получать пакеты всех находящихся в этом сегменте сети
Всё же коммутатор, отправляет фрэймы в нужный интерфейс, если нету воздействия из вне.
А вещание в радио среде, не позволяет выборочно отправлять фрэймы конкретному получателю.
методом проб и ошибок нашёл как это модно сделать, но к сожалению только на MikroTik
Дело в том, что я непросто это их головы взял, это действительно для меня на данный момент проблема.
сравните LSA таблицу маршруты intra-area и маршруты какие пападают в таблицу маршрутизации
Я просто привел пример, с /32 понятно, вы не боитесь, что когда нибудь, кем нибудь может распространится дефолтный маршрут ext-2, особенно если всё же избавитесь в перспективе от huawei и проблем с мультикастом в L2 сегменте не будет
это не заметка, а официальная документация, микротик не умеет фильтровать маршруты intra-area
Я конечно не знаю насколько у вас всё в схвачено, но best practice в фильтрах ospf всё таки с начало "что то разрешать", а потом всё запрещать, иначе от одного неверного действия можете получить неработающую сеть, вспомните яндекс…
я бы сделал как нибудь так.
не работает
[sarcasm]Вы же прекрасно понимаете, что открыть файл DWG с помощь Wireshark не получиться, и почему-то все до сих пор сидят и не озвучивают это проблему в Wireshark и кстати ровно наоборот sniff не откроется в коммерческом продукте AutoCAD[/sarcasm]
И если честно, то выглядит со стороны киви примерно так «нам от мониторинга нужно, раз, два, три … +100500»
В ваше программном обеспечение, не было завялено такого функционала, и мы наделали костылей, а теперь Zabbix учесть все наши недовольства и доделать.
Исходники открыты, что останавливает?
Если ты хочешь чегото большего бери напильник и делай сам.
А по поводу unsupported в sh скриптах, так надо было писать скрипты так, чтобы вывод был всегда supported =)
у вас есть уже кластер hyper-v из двух нод и общего строрейджа
поднимаете две виртуальные машины, и к обоим подключаем виртуальный диск кворума (сейчас не вспомню как в hyper-v это опция звучит в настройках жёсткого диска)
далее на виртуальным машинах поднимайте роль кластера с общим IP адресом ну и настраивайте его под свои нужны.
при выключении одной из физических нод, у вас в виртуальном кластере выпадет одна из нод и у вас отработает ваш виртуальный кластер, простоя минимум в худшем случае пару пакетов
если у вас виртуальная машина на windows, то поднимайте кластер майкрософта уже на виртуальных машина. если у вас linux то смотрите в сторону keepalived
так как в RFC по ecmp явным образом не сказано учитывается ли порты src и dst при расчёте хеша
давайте по другому
1) запрос
мой хост 192.168.0.100:45555 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100:45555->60.0.0.1:45555))->Хост назначения(8.8.8.8:80)
2) запрос ajax или полученеи картинок и т.п.д
мой хост 192.168.0.100:41111 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100:41111->???.???.???.???:41111))->Хост назначения(8.8.8.8:80)
в итоге получим два соединения, и не факт что, второе выйдет с адреса 60.0.0.1
мой хост 192.168.0.100/24 ->default gateway(192.168.0.1->SRCNAT(192.168.0.100->60.0.0.1))->Хост назначения(8.8.8.8)
хост 8.8.8.8 с учётом моего IP адреса создал cookie.
вопрос в следующем, если я через некоторое время (но меньшее жизни куки), обращусь к хосту 8.8.8.8, каков шанс, что мой трафик уйдёт с адрес 60.0.0.1, а не 50.0.0.1??
Первый же сайт, типо одноклассников, который учитывает в сессии ip адрес, и тут же вы получите факап. в виде разъяренных пользователей, которые должны будут каждые N минут вводить логин и пароль.
ткните носом пожалуйста в законодательный акт, где можно про это почитать!
Всё же коммутатор, отправляет фрэймы в нужный интерфейс, если нету воздействия из вне.
А вещание в радио среде, не позволяет выборочно отправлять фрэймы конкретному получателю.