• 0
    Бывают единичные случаи, когда бывшие работодатели ссылаются на факты, которые явно негативно характеризуют соискателей

    К сожалению, видимо Вы судите по данным одного (или нескольких близких к Вам) регионов.
    В России есть несколько «суровых промышленных» и добывающих регионов, где в порядке вещей считается вслед ушедшему сотруднику давать самые гадкие характеристики. Просто потому, что он «посмел уйти от нас таких крутых и красивых». Полубарские-полубандитские замашки руководства исходящего из принципа «из нашего казино просто так не уходят». Они особенно ярко выражаются в небольших городах, с одним-двумя градообразующими предприятиями, руководство которых (небезосновательно, кстати) мнит себя «хозяевами городов». В плохом смысле этого словосочетания. У соседей в добывающем регионе часто такая беда. Справедливости ради сказать — не сплошная. И информацию порой удавалось добывать неофициально, у бывших коллег «по горизонтали», т.к. запрос к руководству и HR почти гарантированно приносил поток грязи.
    Рекомендации, рекомендательные письма, скрипты для проверки рекомендаций — опыт HR-практика
  • 0
    может быть чревато — ежегодный отпуск+полный учебный отпуск каждую сессию=отсутствие на работе 2 месяца в году

    Главная проблема работодателей и HR, это отношение к людям как к материальному ресурсу. Как к деньгам или к автоматам по обслуживанию бизнеса. Порочное стремление использовать рабочее время каждого нанятого человека на 99,9% закладывает серьезную бомбу как под отдельные бизнес-процессы, так и под бизнес в целом.
    Приличные компании, при управлении материальными ресурсами предусматривают, резервы по оборудованию. Простой пример — в ИТ для отказоустойчивости, принято иметь дублирующее оборудование. Cold standby-сервера, это норма. Компании помельче, вместо резервных серверов, бывает держат критический ЗИП для оборудования. При этом менеджмент не воет, что «вон у вас лежат четыре SAS-HDD купленные за наши $$$ и ничего не делают». В своих автомобилях директора и HR-менеджеры тоже возят запасное колесо, и никто не пищит, про лишний вес и неоправдвнный расход бензина.

    Но как только дело касается людей, понимание необходимого резервирования моментально исчезает. Имея отдел, где HR расчитал штат с загрузкой сотрудников хотя бы 95%, имеем над бизнесом серьезную угрозу в случае выхода одного из сотрудников из строя (по любой причине). Кто виноват? Жадность. Жадность и непредусмотрительность. Привычка «отжимать» из человека по-максимуму. Абсолютное непонимание, что выйти из строя может не только техника, но и человек.
    Отсюда и все негативные проявления. Начиная с проблемами выхода в очередной отпуск( «а кто работать будет?»), продолжая выходами на больничные, выездами сотрудников на конференции и обучение, и заканчивая «проблемным увольнением» сотрудника.
    Рекомендации, рекомендательные письма, скрипты для проверки рекомендаций — опыт HR-практика
  • 0
    При наличии соединения с Интернетом, проще использовать сервис www.random.org
    У него есть API, можно запросами получать данные нужного формата в plaintext, чтобы использовать в скриптах.
    Скрипт, который пишет другой скрипт и настраивает роутеры
  • 0
    К сожалению, иногда в функционале бриджей проскакивал «неуловимый баг». По непонятной причине иногда трафик разных Vlan'ов висящих в одном бридже начинал смешиваться. Т.е. трафик Vlan11 мог «протекать» в Vlan22 и наоборот. В новых версиях вроде, пофиксили, но лично я на всякий случай стараюсь избегать «замыкания» нескольких vlan в общий бридж.
    Настройка VLAN на операционной системе routerOS
  • 0
    Немного уточню:
    В старых CCR1009 (из «CCR» только в них) был свитч-чип. После модернизации, в новых версиях CCR1009 свитч-чип убрали. Теперь его нет ни в одном из устройств линейки CCR
    Настройка VLAN на операционной системе routerOS
  • +1
    switch сhip в маршрутизаторах серии CCR отсутствует. Всё делается ресурсами CPU.
    Настройка VLAN на операционной системе routerOS
  • 0
    Смешались в кучу вланы, бриджи. Автор малость перемудрил со схемой и недораскрыл тему.
    Возникает вопрос: зачем создавать «br3-trunk», когда vlan-интерфейсы отлично навешиваются прямо на порт «Ether8» («ether8-trunk»)?
    Настройка VLAN на операционной системе routerOS
  • 0
    С asterisk, вроде упростили. Для прохода через nat сделали pjsip. Но я его еще не пробовал применять пока. Небыло необходимости.
    Dual Wan и особенности реализации NetWatch в MikroTik
  • 0
    «Ну нельзя же делать такой простой и наглядный интерфейс к iptables! Его же любой тупица освоит и мы без работы останемся!»
    То есть да, надо просто представлять себе, как работает линуксовый iptables и стек IP (маршрутизация, NAT и всё такое)

    Я Вам больше скажу. Шапочно знаком с несколькими админами в небольших предприятиях, которые начинали с роутеров на винде [+керио | +иса] и переходили на линукс через микротик, ибо там логика уже линуксовая, а интерфейс наглядно-виндовый. У тех из них, с кем общался главная претензия оказывалась как раз к линуксовой консоли, за «отсутствие наглядности как в винбоксе». Бывает и такое, да…
    Dual Wan и особенности реализации NetWatch в MikroTik
  • 0
    Увы, в отличие от Вас, есть граждане которые считают, что «вот сиско надо изучать, а всё остальное я и сам знаю». Потом напоровшись на грабли собственного незнания граждане кричат, что «микротик не работает, надо было брать сиско».
    Касательно QuickSet — он предназначен исключительно для стартового, базового конфигурирования. Если в микротике уже прописана какая-то работающая сложная конфигурация, QuickSet для дополнения параметров использовать нельзя, т.к. он может тупо накатить свои параметры без учета уже имеющихся.
    Dual Wan и особенности реализации NetWatch в MikroTik
  • +1
    Оборудование MikroTik базируется на Linux. Если есть понимание того, как реализована работа Ethernet + IP в Linux-Based системах, то ничего особенно сложного в настройке MikroTik нет. Официальная вики достаточно бодро обновляется, там же есть «examples».
    Также есть community в соцсетях и форумы. На том же forum.nag.ru есть целых два раздела посвященных исключительно mikrotik.

    Как я понял в данном варианте конфигурации, если пакеты ISP1 теряет через раз, то канал подключения будет скакать туда-сюда хаотично?

    Не слишком хаотично. Есть чёткий критерий, по которому оценивается доступность канала. Этот критерий используется при «легком конфигурировании одним крыжиком»:
    If no response from gateway is received for 10 seconds, request times out. After two timeouts gateway is considered unreachable.

    Если хочется оценивать доступность канала по-другому — никто не мешает написать скрипт.
    Dual Wan и особенности реализации NetWatch в MikroTik
  • 0
    «Подкрашивание» пакетов фаерволом, во-первых кушает ресурсы и может требовать отдельной таблицы роутинга. Во-вторых это еще одна область настройки, что в случае смены правил может привести к неочевидным сбоям, а так всё в одном разделе "/ip route" настроено и никуда более лазать не нужно. В третьих, модификация от базовой, описанной в статье минимальна — +1 строка конфига (1 доп.маршрут).
    Dual Wan и особенности реализации NetWatch в MikroTik
  • 0
    Ха. У нас в операторах связи такие «спецы» работают, что аж страшно за отрасль реально.
    Чел на НАГе с 13(!) летним стажем со статусом «VIP» морозит:
    несмешной текст вообще
    В копилку сисадмина. Мокротик настроить нормально можно только после 5 сбросов в заводские настройки. Инет в настройке мокротика не помогает даже в типовых случаях, ибо из пяти инструкций — ни одна на другую не похожа. Если вы сумели настроить мокротик с 4-го раза — вы клон Сааба, а если с первого, то вы прадедушка Сааба :)

    Просто на неделе притащили микротик для настройки в типовом режиме бытового роутера. Я сразу послал клиента в пешее эротическое, а техдир — закусился. Гимнастика его мозга продолжалась 3 дня, из них — два выходных дома :) Но он — победил адское поделие :)

    Пруф на текст
    Dual Wan и особенности реализации NetWatch в MikroTik
  • 0
    Можно. К сожалению, далеко не все владеют навыком написания скриптов к микротику. Постоянно встречаю деятелей, которым настройка оборудования сложнее домашнего TP-Linka создает проблемы. От микротика эти люди вообще впадают в шок или истерику. Куда уж им в скрипте результаты анализировать и обрабатывать.
    Dual Wan и особенности реализации NetWatch в MikroTik
  • 0
    У дефолтных маршрутов как раз указана опция check-gateway.
    /ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping

    Это помогает активировать/деактивировать сам маршрут.
    Netwatch этого не понимает. Он пользутестя результатом — перестроенным на запасной маршрутом.
    Насколько знаю, в feature request к MikroTik'у давно висит запрос явно указывать интерфейс, с которого будет пинговать NetWattch. Вот, только когда они это реализуют — неизвестно.
    Dual Wan и особенности реализации NetWatch в MikroTik
  • 0
    Прямо заинтриговали. В системе несколько областей. В том числе не тупиковых. ASBR взаимодействует с quagga. Всё живет нормально. Возможно дело в правильной настройке ABR, инстансов и Area Ranges?
    За исключением глюка, когда сразу после интенсивной настройки/переконфигурации, требуется рестартовать инстанс, других не попадалось.
    Поделитесь примерами топологии и конфигов при закольцовывании. Можно в личку, поскольку чуть оффтоп.
    Настройка FullMesh сети на Mikrotik через EoIP туннели
  • 0
    Немного странный выбор pseudo-wire технологии туннелирования, когда для этого есть IPIP/GRE/L2TP и прочие протоколы точка-точка? Были какие-то проблемы с реализацией OSPF/BGP на линках? Изначально EoIP совсем не для этого предназначен.
    Так любят строить туннели наши «азиатские партнеры» из Индонезии и близлежащих к ней стран. Там некоторые вообще как дети — набриджуют EoIP туннелей в огромный broadcast-домен и чего-то с ним шаманят, извращаются…
    Настройка FullMesh сети на Mikrotik через EoIP туннели
  • 0
    Таким образом нас перестали пугать технические работы у провайдера, а также периодические проблемы с проходимостью GRE пакетов по определенным направлениям

    Тут автор сам себе противоречит. Протокол EoIP работает на основе инкапсуляции L2-трафика внутрь GRE-пакетов. Достаточно внимательно посмотреть с помощью torch либо сделать tcpdump на транзитном маршрутизаторе.
    Настройка FullMesh сети на Mikrotik через EoIP туннели
  • 0
    Я этого и не предлагаю. Это предложил shadowalone. Вы не тому отвечаете.
    MikroTik. Правильный dst nat при использовании 2-х и более провайдеров
  • +1
    Автор поста как раз vlan-ы НЕ использует, у него всё здраво. Это shadowalone что-то про интерфейсы с именами «vlan» написал.
    MikroTik. Правильный dst nat при использовании 2-х и более провайдеров
  • +2
    Вместо того что-бы маркировать (routing-mark=) в данном случае запросто можно обойтись:
    /ip route rules
    раскидав по таблицам маршрутизации.

    Давайте представим нормальную ситуацию, когда все внешние шлюзы считаются доступными.
    Обратите внимание — сеть маскарадится в три направления, т.е. web-сервер не имеет своего белого IP. Это важно, т.к. в ответе web-сервера src-ip меняется в зависимости от направления.
    Поскольку маршрутизация тогда будет идти попакетно, на основе src-ip, все ответы web-сервера пойдут через один и тот же шлюз, первым указанный в таблице, куда его приведет /ip route rule (при src=192.168.0.83 адрес web-сервера). Пусть это будет как у автора «95.11.29.254»
    Тогда клиент обратившийся ко второму внешнему IP, через второго провайдера (5.35.59.162/27 interface=ISP2 ) всё равно будет получать ответы WEB-сервера через ISP1 с IP 95.11.29.254 и соединение не установится.

    Установка соединения при предложенном /ip route rule
    Tcp-Запрос клиента:
    (src-ip: 1.1.1.1:52000, dst-ip:5.35.59.162:80) -> dst-nat -> routing -> (src-ip: 1.1.1.1:52000, dst-ip:192.168.0.83:80)

    Ответ web-сервера:
    (src-ip: 192.168.0.83:80, dst-ip:1.1.1.1:52000) -> routing-> src-nat -> (src-ip: 95.11.29.254:80, dst-ip:1.1.1.1:52000)

    Клиент запросивший соединение с 5.35.59.162:80, получит ответ с 95.11.29.254:80 и обломится.
    MikroTik. Правильный dst nat при использовании 2-х и более провайдеров
  • 0
    Подумайте как следует над строчками
    /ip address
    add address=95.11.29.240/24 interface=ISP1 network=95.11.29.0
    add address=5.35.59.162/27 interface=ISP2 network=5.35.59.160

    Посмотрите как строится адресация на вашем PPPoE. Сравните.
    MikroTik. Правильный dst nat при использовании 2-х и более провайдеров
  • 0
    Вы не знает разницы между соединениями точка-точка и подключением через обычный ethernet при наличии broadcast-домена. Это разные случаи и методики маршрутизации и адресации будут разные.
    MikroTik. Правильный dst nat при использовании 2-х и более провайдеров
  • +2
    Это не проблема конфига. Это проблема упоротых провайдеров не умеющих нормально обеспечить отказоустойчивость для основных типов клиентских устройств.
    Если провайдер настолько упорот, он может завести хоть 65533 gateway, только сообщать о них клиентам он как будет? Выдавать по DHCP каждые 10 секунд? Или упорно слать icmp-redirect?
    Интерфейс в качестве gateway на broadcast-интерфейсе? Это тоже надо очень сильно упороться.

    MikroTik. Правильный dst nat при использовании 2-х и более провайдеров
  • 0
    Чтобы блокировать UDP 67 (L3+L4) нужно порт(ы) выводить в софтварный бридж и использовать для фильтрации CPU. Это сильно снизит пропускную способность. Люди сделавшие фильтр на CPU, потом ноют «фиговый свитч, что-то гигабит не прокачивается».
    Моё решение сохраняет ресурсы процессора, перекладывая задачу на аппаратный свитч-чип.
    Отстрел чужих DHCP-серверов на коммутаторе MikroTik CRS
  • 0
    Между появлением DHCP-сервера в сети и срабатыванием алерта действительно есть небольшой временной лаг. По моим сведениям, алертер микротика срабатывает на DHCPOFFER, то есть до завершения процедуры выдачи адреса DHCP — до прохождения DHCPREQUEST, DHCPACK (именно из DHCPOFFER берется IP-адрес DHCP-сервера). По идее чужой DHCP должен быть изолирован на этой стадии, но временные издержки на запуск и исполнение скрипта, действительно могут дать интервал для одного клиента.
    Скрипт делался как решение на случай «вообще нет DHCPsnooping'а». У людей вон, вообще грустно — тупые свитчи на выносах стоят.
    Отстрел чужих DHCP-серверов на коммутаторе MikroTik CRS
  • 0
    Если перед ним тупой свитч, трафик злодея микротик равно отрубит. Точнее не пропустит через себя. Но те, кто подключен к тому же тупому свитчу и общаются со злодеем напрямую будут видеть чужой DHCP.
    В любом случае — тупой свитч, это беда, там уже не важно, что стоит выше — cisco, huawei, d-link или mikrotik.
    Отстрел чужих DHCP-серверов на коммутаторе MikroTik CRS
  • +1
    Безусловно вручную. Такой вариант предполагает возможность некоей «профилактической работы» с пользователем-вредителем. Это минимальные издержки по сравнению с тем, что вредитель если его вовремя не остановить, может оставить без связи несколько десятков человек.
    В общем-то, ничто не мешает написать еще один скрипт, который будет убирать маки из $stubvid при исчезновении их из массива алертера.
    Отстрел чужих DHCP-серверов на коммутаторе MikroTik CRS
  • –1
    «только один из двух специалистов этих сфер деятельности указал, что у них бывают конфликты.» *facepalm*
    Простите, у Вас с понятием «презентабельность выборки» всё в порядке? Вы ничего не перепутали?
    Когда один человек дает от 2% до 50% разброса результатов, такая выборка точно не может быть презентабельной и не может даже примерно отражать реальную ситуацию.
    Насколько разработчики конфликтные — инфографика по результатам опроса на «Моем круге»