Вскрытие пока не делал, чтобы не потерять гарантию если вылезут явные проблемы.
Чуть позже, возможно, полезу внутрь и дополню статью.
Железка нынче стОит в розницу 3600-4000р.
Вот и выйдет что у тебя выйдет не 1 Simple Queue, а 6 как минимум для каждого диапазона с выбранной маской.
Ничего подобного. Диапазон IP-адресов заносится единожды в address-list и по нему проводятся дальнейшие действия с маркировкой пакетов.
Метод описанный Louie с предварительным использованием «action=mark-connection» и последующей маркировкой по критерию «connection-mark=upload» более эффективен и, вот почему: все транзитные пакеты проверяются на принадлежность ранее помеченному соединению (1 критерий), а не списку IP-адресов. Хотя address-list, это аналог линуксового ipset, но проверка принадлежности к connection должна быть быстрее, чем проверка по хэшу IP-адреса и сверка со списком. Особенно, когда этих проверок две (два правила), одно для SRC-IP, другое для DST-IP.
Далее, simple queue позволяет в одном правиле ограничить сразу и upload и download (если нужно), а не расползаться по двум веткам дерева — правила в дереве не учитывают направление трафика.
Как писал выше в комментариях, во-первых, simple queue не позволяет ограничивать трафик по имени маркированных пакетов. Во-вторых, он не позволяет ограничивать трафик по диапазону из нескольких IP-адресов
Во-первых, simple queue вполне позволяет ограничивать трафик по имени маркированых пакетов. Смотрите параметр «packet-marks=». В winbox вкладка «advanced». Если у Вас не сработало, вероятно или Вы что-то сделали не так или набрели на некий баг.
Во-вторых, прямо по диапазону ограничить не даёт и tree. Для диапазонов используется маркировка пакета в firewall-mangle.
В simple queue можно легко ввести ограничение по IP или подсети. Их нужно указать в «target=» сколько угодно, через запятую в консоли. Либо в winbox кликнув справа от поля ввода на символ «стрелка вниз».
И, да, для simple queue нужно обязательно указывать target. Относительно target считается направление upload/download.
Наблюдал одного провайдера, у которого долгое время было жесткое правило «Один IP = один MAC». Потом узнал, что ограничение было связано как-то с их биллингом. То ли самописный он был, то ли просто специалистов по настройке этого биллинга небыло в штате.
Интересный способ. Главное, относительно простой.
Но к сожалению, для vrrp-интерфейса невозможно задать произвольный MAC-адрес, т.к. он определен стандартом «0000:5E00:01xx, где xx — номер группы VRRP».
Из других моментов: vrrp пытается искать соседа по мультикасту и трафик может быть перехвачен с последующим захватом роли master. Версия VRRP v3 включаемая по-умолчанию не поддерживает аутентификацию, что настораживает.
Если делать это на том же роутере, где на основном интерфейсе поднят DHCP-сервер то, dhcp-client не получает IP.
1) Когда провайдер даёт два IP с привязкой к разным макам на одном физическом порту.
2) Имитировать физическое присутствие некоего оборудования на площадке, фактически висящего в другой отдаленной сети — не зависит от удаленного маршрутизатора, т.к. не требует L2 туннелирования через EoIP или VPLS.
В данном случае с dhcp не всё получится, т.к. в arp-reply идет работа с заранее известным IP-адресом. Нормально dhcp-client отработает только на основном интерфейсе «bridge-local»
Мне кажется Вы недооцениваете мощность процессора. На неоптимизированной системе «из коробки», при наличии простого фаервола прирост нагрузки CPU составил в среднем +2%, в редких пиках подскакивал до +10%. См. результат теста в конце статьи.
Конечно, процессор всегда нагружается при дополнительной обработке пакетов. Но иногда приходится с этим смириться, если нет другого варианта.
Кстати, вот пример вопроса на соседнем ресурсе: toster.ru/q/276217
Альтернатива — в разрыв линка установить отдельный свитч и два патч-корда в два разных порта МТ, или в один порт на два VLAN опять же, через внешний «умный» свитч.
Бывают единичные случаи, когда бывшие работодатели ссылаются на факты, которые явно негативно характеризуют соискателей
К сожалению, видимо Вы судите по данным одного (или нескольких близких к Вам) регионов.
В России есть несколько «суровых промышленных» и добывающих регионов, где в порядке вещей считается вслед ушедшему сотруднику давать самые гадкие характеристики. Просто потому, что он «посмел уйти от нас таких крутых и красивых». Полубарские-полубандитские замашки руководства исходящего из принципа «из нашего казино просто так не уходят». Они особенно ярко выражаются в небольших городах, с одним-двумя градообразующими предприятиями, руководство которых (небезосновательно, кстати) мнит себя «хозяевами городов». В плохом смысле этого словосочетания. У соседей в добывающем регионе часто такая беда. Справедливости ради сказать — не сплошная. И информацию порой удавалось добывать неофициально, у бывших коллег «по горизонтали», т.к. запрос к руководству и HR почти гарантированно приносил поток грязи.
может быть чревато — ежегодный отпуск+полный учебный отпуск каждую сессию=отсутствие на работе 2 месяца в году
Главная проблема работодателей и HR, это отношение к людям как к материальному ресурсу. Как к деньгам или к автоматам по обслуживанию бизнеса. Порочное стремление использовать рабочее время каждого нанятого человека на 99,9% закладывает серьезную бомбу как под отдельные бизнес-процессы, так и под бизнес в целом.
Приличные компании, при управлении материальными ресурсами предусматривают, резервы по оборудованию. Простой пример — в ИТ для отказоустойчивости, принято иметь дублирующее оборудование. Cold standby-сервера, это норма. Компании помельче, вместо резервных серверов, бывает держат критический ЗИП для оборудования. При этом менеджмент не воет, что «вон у вас лежат четыре SAS-HDD купленные за наши $$$ и ничего не делают». В своих автомобилях директора и HR-менеджеры тоже возят запасное колесо, и никто не пищит, про лишний вес и неоправдвнный расход бензина.
Но как только дело касается людей, понимание необходимого резервирования моментально исчезает. Имея отдел, где HR расчитал штат с загрузкой сотрудников хотя бы 95%, имеем над бизнесом серьезную угрозу в случае выхода одного из сотрудников из строя (по любой причине). Кто виноват? Жадность. Жадность и непредусмотрительность. Привычка «отжимать» из человека по-максимуму. Абсолютное непонимание, что выйти из строя может не только техника, но и человек.
Отсюда и все негативные проявления. Начиная с проблемами выхода в очередной отпуск( «а кто работать будет?»), продолжая выходами на больничные, выездами сотрудников на конференции и обучение, и заканчивая «проблемным увольнением» сотрудника.
При наличии соединения с Интернетом, проще использовать сервис www.random.org
У него есть API, можно запросами получать данные нужного формата в plaintext, чтобы использовать в скриптах.
К сожалению, иногда в функционале бриджей проскакивал «неуловимый баг». По непонятной причине иногда трафик разных Vlan'ов висящих в одном бридже начинал смешиваться. Т.е. трафик Vlan11 мог «протекать» в Vlan22 и наоборот. В новых версиях вроде, пофиксили, но лично я на всякий случай стараюсь избегать «замыкания» нескольких vlan в общий бридж.
Немного уточню:
В старых CCR1009 (из «CCR» только в них) был свитч-чип. После модернизации, в новых версиях CCR1009 свитч-чип убрали. Теперь его нет ни в одном из устройств линейки CCR
Смешались в кучу вланы, бриджи. Автор малость перемудрил со схемой и недораскрыл тему.
Возникает вопрос: зачем создавать «br3-trunk», когда vlan-интерфейсы отлично навешиваются прямо на порт «Ether8» («ether8-trunk»)?
Вот, за dude обидно.
Чуть позже, возможно, полезу внутрь и дополню статью.
Железка нынче стОит в розницу 3600-4000р.
В критерии недурно бы добавить «connection-state=new», чтобы соединение маркировалось единожды в момент его установки.
Ничего подобного. Диапазон IP-адресов заносится единожды в address-list и по нему проводятся дальнейшие действия с маркировкой пакетов.
Метод описанный Louie с предварительным использованием «action=mark-connection» и последующей маркировкой по критерию «connection-mark=upload» более эффективен и, вот почему: все транзитные пакеты проверяются на принадлежность ранее помеченному соединению (1 критерий), а не списку IP-адресов. Хотя address-list, это аналог линуксового ipset, но проверка принадлежности к connection должна быть быстрее, чем проверка по хэшу IP-адреса и сверка со списком. Особенно, когда этих проверок две (два правила), одно для SRC-IP, другое для DST-IP.
Далее, simple queue позволяет в одном правиле ограничить сразу и upload и download (если нужно), а не расползаться по двум веткам дерева — правила в дереве не учитывают направление трафика.
Во-первых, simple queue вполне позволяет ограничивать трафик по имени маркированых пакетов. Смотрите параметр «packet-marks=». В winbox вкладка «advanced». Если у Вас не сработало, вероятно или Вы что-то сделали не так или набрели на некий баг.
Во-вторых, прямо по диапазону ограничить не даёт и tree. Для диапазонов используется маркировка пакета в firewall-mangle.
В simple queue можно легко ввести ограничение по IP или подсети. Их нужно указать в «target=» сколько угодно, через запятую в консоли. Либо в winbox кликнув справа от поля ввода на символ «стрелка вниз».
И, да, для simple queue нужно обязательно указывать target. Относительно target считается направление upload/download.
Но к сожалению, для vrrp-интерфейса невозможно задать произвольный MAC-адрес, т.к. он определен стандартом «0000:5E00:01xx, где xx — номер группы VRRP».
Из других моментов: vrrp пытается искать соседа по мультикасту и трафик может быть перехвачен с последующим захватом роли master. Версия VRRP v3 включаемая по-умолчанию не поддерживает аутентификацию, что настораживает.
Если делать это на том же роутере, где на основном интерфейсе поднят DHCP-сервер то, dhcp-client не получает IP.
2) Имитировать физическое присутствие некоего оборудования на площадке, фактически висящего в другой отдаленной сети — не зависит от удаленного маршрутизатора, т.к. не требует L2 туннелирования через EoIP или VPLS.
Кстати, вот пример вопроса на соседнем ресурсе: toster.ru/q/276217
Альтернатива — в разрыв линка установить отдельный свитч и два патч-корда в два разных порта МТ, или в один порт на два VLAN опять же, через внешний «умный» свитч.
К сожалению, видимо Вы судите по данным одного (или нескольких близких к Вам) регионов.
В России есть несколько «суровых промышленных» и добывающих регионов, где в порядке вещей считается вслед ушедшему сотруднику давать самые гадкие характеристики. Просто потому, что он «посмел уйти от нас таких крутых и красивых». Полубарские-полубандитские замашки руководства исходящего из принципа «из нашего казино просто так не уходят». Они особенно ярко выражаются в небольших городах, с одним-двумя градообразующими предприятиями, руководство которых (небезосновательно, кстати) мнит себя «хозяевами городов». В плохом смысле этого словосочетания. У соседей в добывающем регионе часто такая беда. Справедливости ради сказать — не сплошная. И информацию порой удавалось добывать неофициально, у бывших коллег «по горизонтали», т.к. запрос к руководству и HR почти гарантированно приносил поток грязи.
Главная проблема работодателей и HR, это отношение к людям как к материальному ресурсу. Как к деньгам или к автоматам по обслуживанию бизнеса. Порочное стремление использовать рабочее время каждого нанятого человека на 99,9% закладывает серьезную бомбу как под отдельные бизнес-процессы, так и под бизнес в целом.
Приличные компании, при управлении материальными ресурсами предусматривают, резервы по оборудованию. Простой пример — в ИТ для отказоустойчивости, принято иметь дублирующее оборудование. Cold standby-сервера, это норма. Компании помельче, вместо резервных серверов, бывает держат критический ЗИП для оборудования. При этом менеджмент не воет, что «вон у вас лежат четыре SAS-HDD купленные за наши $$$ и ничего не делают». В своих автомобилях директора и HR-менеджеры тоже возят запасное колесо, и никто не пищит, про лишний вес и неоправдвнный расход бензина.
Но как только дело касается людей, понимание необходимого резервирования моментально исчезает. Имея отдел, где HR расчитал штат с загрузкой сотрудников хотя бы 95%, имеем над бизнесом серьезную угрозу в случае выхода одного из сотрудников из строя (по любой причине). Кто виноват? Жадность. Жадность и непредусмотрительность. Привычка «отжимать» из человека по-максимуму. Абсолютное непонимание, что выйти из строя может не только техника, но и человек.
Отсюда и все негативные проявления. Начиная с проблемами выхода в очередной отпуск( «а кто работать будет?»), продолжая выходами на больничные, выездами сотрудников на конференции и обучение, и заканчивая «проблемным увольнением» сотрудника.
У него есть API, можно запросами получать данные нужного формата в plaintext, чтобы использовать в скриптах.
В старых CCR1009 (из «CCR» только в них) был свитч-чип. После модернизации, в новых версиях CCR1009 свитч-чип убрали. Теперь его нет ни в одном из устройств линейки CCR
Возникает вопрос: зачем создавать «br3-trunk», когда vlan-интерфейсы отлично навешиваются прямо на порт «Ether8» («ether8-trunk»)?