Comments 38
Первое что пришло в голову, а почему не использовать ДНС имена?.. Трафик к 53-му порту заворачивается легко и принтер легко найти.
Добрый вечер! Только сейчас увидел Ваш комментарий.
Не совсем понял, что именно Вы имели ввиду, под использованием DNS-имен.
И как 53-й порт поможет отыскать местонахождение принтера.
Не совсем понял, что именно Вы имели ввиду, под использованием DNS-имен.
И как 53-й порт поможет отыскать местонахождение принтера.
Хорошо, допустим. А где будет хранится запись DNS-имени устройства?
Как работает DNS? Он по символьному имени к примеру printer.local должен вернуть актуальный IP-адрес принтера (наприер 192.168.3.3).
Каким образом, сервер DNS будет знать актуальный IP-адрес принтера? Кроме как, если его забить в ручную?
Это в том случае, если принтер имеет статический IP-адрес, впрочем в нашем случае, принтер как раз и имеет статический IP-адрес.
Далее, даже если мы создадим статическую A-запись DNS с этим IP на DNS-сервере,
printer.local = 192.168.3.3
Мы получим аналогичную ситуацию, откуда нам знать, в каком из магазинов в данный момент будет находится устройство с DNS-именем printer.local и заданным к этому имени IP: 192.168.3.2
Вот, если бы, принтер умел автоматически после получения динамического IP информировать сервер DNS о том, что его IP был изменен, (что-то вроде DDNS на Soho-ротуреах), тогда да.
Но, это обычный маленький ручной принтер, который всего-лишь цепляется к Wi-Fi сети и печатает ценники :)
Как работает DNS? Он по символьному имени к примеру printer.local должен вернуть актуальный IP-адрес принтера (наприер 192.168.3.3).
Каким образом, сервер DNS будет знать актуальный IP-адрес принтера? Кроме как, если его забить в ручную?
Это в том случае, если принтер имеет статический IP-адрес, впрочем в нашем случае, принтер как раз и имеет статический IP-адрес.
Далее, даже если мы создадим статическую A-запись DNS с этим IP на DNS-сервере,
printer.local = 192.168.3.3
Мы получим аналогичную ситуацию, откуда нам знать, в каком из магазинов в данный момент будет находится устройство с DNS-именем printer.local и заданным к этому имени IP: 192.168.3.2
Вот, если бы, принтер умел автоматически после получения динамического IP информировать сервер DNS о том, что его IP был изменен, (что-то вроде DDNS на Soho-ротуреах), тогда да.
Но, это обычный маленький ручной принтер, который всего-лишь цепляется к Wi-Fi сети и печатает ценники :)
Можно переключить терминалы на dhcp. В микротике есть возможность запускать скрипт при выдаче Ip адреса. А в скрипте биндидь ip и dns запись.
Можно, но для этого должен быть один общий DHCP-сервер, т.к. в каждом магазине своей роутер со своим DHCP и своей адресацией.
Кстати, вспомнил аргумент почему терминалы группы ревизии со статическим IP, это также сделано для того, чтобы за каждым сотрудником закрепить конкретный терминал, и на этот терминал можно было попасть удаленно сис.админам, в случае чего.
Кстати, вспомнил аргумент почему терминалы группы ревизии со статическим IP, это также сделано для того, чтобы за каждым сотрудником закрепить конкретный терминал, и на этот терминал можно было попасть удаленно сис.админам, в случае чего.
1. можно сделать обновление в одном, двух, трех и пр dns сервером. уверен, что внутренний dns сервер (и не один есть). если он не будет работать, то будет плохо не только инвентаризации.
2. не составляет труда выдавать конкретные адреса для конкретных терминалов. кроме того, мы же будем подключаться к terminal2.domain.local
я не критикую, а показываю еще один способ решения задачи. кстати, судя по всему, у вас привязки во многом к ip адресам, а не к dns именам. хоть это может показаться более надежным — в действительности это плохо. dns очень простая, где-то не очень нужная, а где-то прямо необходимая служба. кроме того, она позволяет более гибко резервировать оборудование и распределять нагрузку.
2. не составляет труда выдавать конкретные адреса для конкретных терминалов. кроме того, мы же будем подключаться к terminal2.domain.local
я не критикую, а показываю еще один способ решения задачи. кстати, судя по всему, у вас привязки во многом к ip адресам, а не к dns именам. хоть это может показаться более надежным — в действительности это плохо. dns очень простая, где-то не очень нужная, а где-то прямо необходимая служба. кроме того, она позволяет более гибко резервировать оборудование и распределять нагрузку.
фильтр
не работает
add action=discard chain=ospf-in ospf-type=intra-area
не работает
Note that internal RIP filtering is done using prefix lists [and internal (intra-area) OSPF filtering is not supported yet]
Я конечно не знаю насколько у вас всё в схвачено, но best practice в фильтрах ospf всё таки с начало "что то разрешать", а потом всё запрещать, иначе от одного неверного действия можете получить неработающую сеть, вспомните яндекс…
я бы сделал как нибудь так.
/routing filter
add action chain=ospf-out prefix=192.168.3.0/24 prefix-length=32 action=accept
add action chain=ospf-out action=discard
add action chain=ospf-in prefix=192.168.3.0/24 prefix-length=32 action=accept
add action chain=ospf-in action=discardВозможно, но я предпочел фильтровать все, для запрета. Т.к. не вижу никакого смысла разрешать хоть какую-нибудь сеть, т.к. все равно в данном дизайне мне ненужно чтобы маршрутизаторы в магазинах получали по OSPF хоть какой-то маршрут.
Вернее, получать они его в OSPF-database все равно будут, т.к. это Link-state-protocol, но мне не нужно чтобы маршруты из OSPF Database устанавливались в Routing-table.
Вернее, получать они его в OSPF-database все равно будут, т.к. это Link-state-protocol, но мне не нужно чтобы маршруты из OSPF Database устанавливались в Routing-table.
Кстати, данное правило:
Как раз позволит другим магазинам видеть сервер ревизии и Wi-Fi Printer, т.к. оно разрешает установку маршрута в Routing-Table из OSPF-Database любого адреса из пула 192.168.3.0/24 с префиксом /32.
add action chain=ospf-in prefix=192.168.3.0/24 prefix-length=32 action=accept
add action chain=ospf-in action=discard
Как раз позволит другим магазинам видеть сервер ревизии и Wi-Fi Printer, т.к. оно разрешает установку маршрута в Routing-Table из OSPF-Database любого адреса из пула 192.168.3.0/24 с префиксом /32.
Хмм, у меня прекрасно работает и добавляется.
Интересную заметку Вам выдает роутер:
У Вас, случаем ospf-in не используется в роли prefix-lists для фильтрации маршрутов в роутере RIP?
Дело в том, что протокол RIP действительно не поддерживает типы ospf-маршрутов. Т.к. он не имеет никакого понятия о логике работы OSPF, при этом прекрасно умеет работать с Prefix-lists
Интересную заметку Вам выдает роутер:
Note that internal RIP filtering is done using prefix lists [and internal (intra-area) OSPF filtering is not supported yet]
У Вас, случаем ospf-in не используется в роли prefix-lists для фильтрации маршрутов в роутере RIP?
Дело в том, что протокол RIP действительно не поддерживает типы ospf-маршрутов. Т.к. он не имеет никакого понятия о логике работы OSPF, при этом прекрасно умеет работать с Prefix-lists
это не заметка, а официальная документация, микротик не умеет фильтровать маршруты intra-area
Хмм, там справа по ссылке заметка:
У меня в 6-й ветке, все прекрасно фильтруется.
Собственно в решении оно именно так и используется.
Нет, правда, если интересно, попробуйте собрать стенд и проверить.
Applies to RouterOS: v3, v4 +
У меня в 6-й ветке, все прекрасно фильтруется.
Собственно в решении оно именно так и используется.
Нет, правда, если интересно, попробуйте собрать стенд и проверить.
Дело в том, что я непросто это их головы взял, это действительно для меня на данный момент проблема.
сравните LSA таблицу маршруты intra-area и маршруты какие пападают в таблицу маршрутизации
Я об этом и говорил, что OSPF LSA Database они и будут — это норма.
Сравнил в LSA множество маршрутов intra-area, которые имеются на Point-to-Point интерфейсах, примерно так:
Однако в таблице маршрутизации этих маршрутов нет. А вот, если я выключу правило, то они появляются!
Сравнил в LSA множество маршрутов intra-area, которые имеются на Point-to-Point интерфейсах, примерно так:
28 10.30.40.18/32 intra-area 20 10.20.30.1 VPN-OFFICE
29 10.30.40.46/32 intra-area 30 10.20.30.1 VPN-OFFICE
30 10.30.40.254/32 intra-area 40 10.20.30.1 VPN-OFFICE
32 192.168.3.252/32 ext-1 40 10.20.30.1 VPN--OFFICE
Однако в таблице маршрутизации этих маршрутов нет. А вот, если я выключу правило, то они появляются!
А не проще было сделать L2 тунелирование поверх L3 для заданных сервисов? И проще главное намного. У микротика есть простые средства для этого. ИМХО это сильно правильнее чем плодить адовые костыли с маршрутизацией. Которые грозят потенциальными проблемами и дальнейшему нагромождению костылей.
Была такая мысль. Однако, повторюсь, в каждом магазине, есть своя локальная сеть. В которой существует несколько точек доступа с идентичными SSID и паролями. Ранее, когда сеть была плоской на L2 проблем не было.
Теперь, каждый магазин это — отдельный, изолированный от общей сети broadcast-домен,
Так-же, между каждым из магазинов, и офисом существует по 2 канала связи, через разных провайдеров.
Для того, чтобы решить данную задачу с туннелированием L2 поверх L3, необходимо в каждом магазине по крайней-мере установить еще по одной беспроводной точки доступа, или настроить Virtual-AP, куда бы цеплялись устройства клиентов мобильной группы.
Имеющиеся точки доступа в магазинах не поддерживают VLAN и Virtual-AP, там вообще нет управляемых коммутаторов. Да и устройств в каждом из магазинов не так много и бродкаст-домен не большой.
Тянуть новые СКС и подключать отдельные точки доступа для мобильной группы. Или менять текущие точки доступа и ставить управляемые коммутаторы никто не будет.
Хотя это было бы безусловно красивее.
Ну и плюс, вопросы о надежности L2 поверх L3, которое будет загоняться еще в один туннель (когда магазин будет работать на резервном канале), то получаем вероятные проблемы с MTU. Но это не так страшно, как вероятность образования l2 петли.
Так-что, уж лучше Dinymac Routing.
Теперь, каждый магазин это — отдельный, изолированный от общей сети broadcast-домен,
Так-же, между каждым из магазинов, и офисом существует по 2 канала связи, через разных провайдеров.
Для того, чтобы решить данную задачу с туннелированием L2 поверх L3, необходимо в каждом магазине по крайней-мере установить еще по одной беспроводной точки доступа, или настроить Virtual-AP, куда бы цеплялись устройства клиентов мобильной группы.
Имеющиеся точки доступа в магазинах не поддерживают VLAN и Virtual-AP, там вообще нет управляемых коммутаторов. Да и устройств в каждом из магазинов не так много и бродкаст-домен не большой.
Тянуть новые СКС и подключать отдельные точки доступа для мобильной группы. Или менять текущие точки доступа и ставить управляемые коммутаторы никто не будет.
Хотя это было бы безусловно красивее.
Ну и плюс, вопросы о надежности L2 поверх L3, которое будет загоняться еще в один туннель (когда магазин будет работать на резервном канале), то получаем вероятные проблемы с MTU. Но это не так страшно, как вероятность образования l2 петли.
Так-что, уж лучше Dinymac Routing.
А IP-адреса жестко заданы на всех ТСД (их адрес и адрес сервера)? Не увидел этого момента в статье.
Ужас, костыли, тлен :( Почему DHCP-то нельзя для ревизионной группы этой? У вас же для остальных устройств в этом магазине есть DHCP?
А про принтер — виндовый DHCP умеет в DNS регистрировать, вообще никаких проблем с этим нет. Даже если у вас там и не виндовый, то скриптом искать нужные MACи в DHCP DB и обновлять DNS записи точно проще, чем «возить за собой» подсеть по филиалам.
А про принтер — виндовый DHCP умеет в DNS регистрировать, вообще никаких проблем с этим нет. Даже если у вас там и не виндовый, то скриптом искать нужные MACи в DHCP DB и обновлять DNS записи точно проще, чем «возить за собой» подсеть по филиалам.
Повторюсь, что проект был внедрен не сразу, так — чтобы по щелчку пальцев, щелк — все магазины работают по новому.
Моей задачей было организация отказоустойчивой сети, с соблюдением ряда жестких условиях, на случай всяких-разных аварий, об этом более подробно в первой статье.
По завершению проекта, когда сеть отказоустойчева — нет никакой необходимости возить сервер ревизии по магазинам. Но я писал, для чего это делается, т.к. у них были случаи, когда магазины лишали связи. Конечно — это форс-мажор и бывает не каждый раз
По этому, вариант оставить сервер ревизии в офисе, а мобильным ТСД для ревизии выдавать DHCP проблем нет. В целом это было бы правильнее. Но, т.к. все переводилось постепенно, то дизайн требовал уже предустановленного решения, чтобы работало и там, где переведено и там где не переведено.
Я не администрирую их сервера и сеть, я не работаю в той компании, это был частный проект, в котором я отвечал строго за связь и конвергетность.
Насчет отдельного виндового DHCP, я не являюсь администратором Windows, потому тут ничего на скорую руку предложить бы не смог.
В случае, единого DHCP, в голове рисуется дизайн, с DHCP-Relay на Микротиках, когда они будут запрашивать адреса, для всех подключаемых устройств в том или ином магазине.
И, в каждом из магазинов пул выдаваемых устройств должен быть разным.
Тогда да, если единый DHCP сервер, сможет правильно в зависимости от того, откуда прилетел request выдать IP- из верного пула. Плюс, обновлять запись в DNS, это вероятное решение.
Вообще, так сложилось, что в нашем маленьком городке многие предприятия где есть нечто вроде своей сети, любят назначать статику.
По факту DHCP им был нужен только для различных устройств пользователей — телефонов, например для обмена сообщениями через WhatsApp и только.
Моей задачей было организация отказоустойчивой сети, с соблюдением ряда жестких условиях, на случай всяких-разных аварий, об этом более подробно в первой статье.
По завершению проекта, когда сеть отказоустойчева — нет никакой необходимости возить сервер ревизии по магазинам. Но я писал, для чего это делается, т.к. у них были случаи, когда магазины лишали связи. Конечно — это форс-мажор и бывает не каждый раз
По этому, вариант оставить сервер ревизии в офисе, а мобильным ТСД для ревизии выдавать DHCP проблем нет. В целом это было бы правильнее. Но, т.к. все переводилось постепенно, то дизайн требовал уже предустановленного решения, чтобы работало и там, где переведено и там где не переведено.
Я не администрирую их сервера и сеть, я не работаю в той компании, это был частный проект, в котором я отвечал строго за связь и конвергетность.
Насчет отдельного виндового DHCP, я не являюсь администратором Windows, потому тут ничего на скорую руку предложить бы не смог.
В случае, единого DHCP, в голове рисуется дизайн, с DHCP-Relay на Микротиках, когда они будут запрашивать адреса, для всех подключаемых устройств в том или ином магазине.
И, в каждом из магазинов пул выдаваемых устройств должен быть разным.
Тогда да, если единый DHCP сервер, сможет правильно в зависимости от того, откуда прилетел request выдать IP- из верного пула. Плюс, обновлять запись в DNS, это вероятное решение.
Вообще, так сложилось, что в нашем маленьком городке многие предприятия где есть нечто вроде своей сети, любят назначать статику.
По факту DHCP им был нужен только для различных устройств пользователей — телефонов, например для обмена сообщениями через WhatsApp и только.
Ну, вообще говоря, сервер тоже мог бы быть на DHCP, и можно было бы и дальше его возить по филиалам. Можно либо релеить DHCP в центральный офис, либо ставить контроллеры домена в филиалы, которые будут локально раздавать DHCP, регистрировать на своих локальных DNS, и синхронизировать DNS-записи между собой.
Прекрасно понимаю ситуацию, вы решали и решили задачу с помощью доступных вам инструментов. Ничего плохого тут не хочу сказать. Просто в результате получились костыли :) Которые поддерживать несколько сложнее чем более стандартные решения.
А статика повсюду это печаль — администраторы усложняют жизнь сами себе на ровном месте.
Прекрасно понимаю ситуацию, вы решали и решили задачу с помощью доступных вам инструментов. Ничего плохого тут не хочу сказать. Просто в результате получились костыли :) Которые поддерживать несколько сложнее чем более стандартные решения.
А статика повсюду это печаль — администраторы усложняют жизнь сами себе на ровном месте.
Вариантов решения этой задачи несколько.
Одним из «сетевых» вариантов, было бы действительно туннелирование, о котором писали Выше, плюс отдельные Virtual-SSID с нужным VLAN, тогда бы, при перемещении между магазинами, именно мобильная группа была бы в едином broadcast-домен, такой себе end-to-end vlan. Но опять-же, требуются дополнительные устройства + плюс уменьшение mtu (не очень страшно) + риск петли, если какое-то из устройств — глюканет. Хотя, для этого есть STP. Либо делать туннелирование до конкретного IP, маршрут к которому будет меняться если пропадет основной канал.
Ваш сценарий мне понравился. Однако он требует настройки дополнительного решения, уже за пределами тех девайсов, что у меня были.
Если его брать, то только релить, т.к. на то, чтобы что-то дополнительно ставить в другие магазины они бы точно не пошли. А опыта работы с Windows DHCP + DNS у меня к сожалению нет.
Одним из «сетевых» вариантов, было бы действительно туннелирование, о котором писали Выше, плюс отдельные Virtual-SSID с нужным VLAN, тогда бы, при перемещении между магазинами, именно мобильная группа была бы в едином broadcast-домен, такой себе end-to-end vlan. Но опять-же, требуются дополнительные устройства + плюс уменьшение mtu (не очень страшно) + риск петли, если какое-то из устройств — глюканет. Хотя, для этого есть STP. Либо делать туннелирование до конкретного IP, маршрут к которому будет меняться если пропадет основной канал.
Ваш сценарий мне понравился. Однако он требует настройки дополнительного решения, уже за пределами тех девайсов, что у меня были.
Если его брать, то только релить, т.к. на то, чтобы что-то дополнительно ставить в другие магазины они бы точно не пошли. А опыта работы с Windows DHCP + DNS у меня к сожалению нет.
Плюс, опять-же единый DHCP сервер для всех филиалов, это такая-себе точка отказа.
Скажем, если вдруг в офисе не будет света (а такое, уже было, во время внедрения) и, он полностью уйдет в down, то тогда устройства в магазинах перестанут получать DHCP.
Ведь изначально планировалось, чтобы магазины по максимуму были автономны. И не завис или от офиса, только если им не нужно с ним работать, например в БД по RDP, к примеру кассы у них автономны и должна оставаться возможность проведения безналичных платежей.
Так-же некоторые сотрудники, во время работы, регулярно фотографируют товары и передают их друг друг через WhatsApp, по этому если они не смогут получить DHCP это будет небольшой но все-таки проблемой.
А так, каждый филиал полностью автономен. В общем, игра компромиссов :)
Скажем, если вдруг в офисе не будет света (а такое, уже было, во время внедрения) и, он полностью уйдет в down, то тогда устройства в магазинах перестанут получать DHCP.
Ведь изначально планировалось, чтобы магазины по максимуму были автономны. И не завис или от офиса, только если им не нужно с ним работать, например в БД по RDP, к примеру кассы у них автономны и должна оставаться возможность проведения безналичных платежей.
Так-же некоторые сотрудники, во время работы, регулярно фотографируют товары и передают их друг друг через WhatsApp, по этому если они не смогут получить DHCP это будет небольшой но все-таки проблемой.
А так, каждый филиал полностью автономен. В общем, игра компромиссов :)
Начну с ответа на P.S.
И да и нет. L2 там скорее полноценный: IP, GRE, пакеты ходят, PPPoE ходит. Однако, в некоторых местах точки подключены через PON-технологию.
О которой Вы можете прочитать здесь. Абонентские терминалы Huawei H810E, не пропускают OSPF пакеты со стороны OLT в сторону абонента.
Также были случаи, когда например со стороны абонента вверх не ходили DHCP-Offer пакеты.
Еще изначально по умолчанию, трафик в одном vlan между разными ONU подключенными к одной OLT не ходит, но это решается на olt специальной фичей. С OSPF пока не разобрались как активировать, но мысли куда копать есть.
Просто, среди наших клиентов, никто не использует dynamic routing. (По крайней-мере среди тех, кто подключен через PON)
Плюсов у него больше, чем минусов.
По поводу автономности, я просто привел пример с полным down в офисе, естественно, такого быть не должно.
Просто, кассы на этот счет автономны, и могут отпускать товар без связи с офисом, за наличку при отсутствии интернета, а учитывая что банковские карты нынче распространены, то интернет быть обязан, для обеспечение безналичных платежей.
Поэтому если связь с офисом пропадет, магазин в плане работы с клиентами будет работать и отпускать товар. Продажи не остановятся.
Тем не менее, не смотря на то, что кассы автономны, несколько раз в сутки они выполняют синхронизацию БД, по этому связь необходима, хоть и не постоянна.
Так-же ТСД, что находятся в магазинах, и выполняют прием товаров и другие обработки, тоже работают напрямую с серверами которые находятся в офисе.
И да и нет. L2 там скорее полноценный: IP, GRE, пакеты ходят, PPPoE ходит. Однако, в некоторых местах точки подключены через PON-технологию.
О которой Вы можете прочитать здесь. Абонентские терминалы Huawei H810E, не пропускают OSPF пакеты со стороны OLT в сторону абонента.
Также были случаи, когда например со стороны абонента вверх не ходили DHCP-Offer пакеты.
Еще изначально по умолчанию, трафик в одном vlan между разными ONU подключенными к одной OLT не ходит, но это решается на olt специальной фичей. С OSPF пока не разобрались как активировать, но мысли куда копать есть.
Просто, среди наших клиентов, никто не использует dynamic routing. (По крайней-мере среди тех, кто подключен через PON)
Плюсов у него больше, чем минусов.
По поводу автономности, я просто привел пример с полным down в офисе, естественно, такого быть не должно.
Просто, кассы на этот счет автономны, и могут отпускать товар без связи с офисом, за наличку при отсутствии интернета, а учитывая что банковские карты нынче распространены, то интернет быть обязан, для обеспечение безналичных платежей.
Поэтому если связь с офисом пропадет, магазин в плане работы с клиентами будет работать и отпускать товар. Продажи не остановятся.
Тем не менее, не смотря на то, что кассы автономны, несколько раз в сутки они выполняют синхронизацию БД, по этому связь необходима, хоть и не постоянна.
Так-же ТСД, что находятся в магазинах, и выполняют прием товаров и другие обработки, тоже работают напрямую с серверами которые находятся в офисе.
Ну, не совсем у нас, т.к. я работаю инженером технической поддержки в ISP, который как раз и организовывает связь между всеми магазинами предприятия, среди которых есть и супермаркеты. Ко мне обратились наши клиенты, я по мере своих знаний, умений и возможности реализовал проект. По тем требованиям и задачам, что передо мной стояли.
Изначально у них была плоская сеть, с одним большим l2 доменом, где в которой в одном месте поднимался интернет, а другие магазины в этой локальной сети уже брали интернет и остальные сервисы из офиса. Со временем сеть росла, дальше Вы знаете :)
В целом правильно, что используете туннели внутри провайдера.
Удивительно, но это далеко не единственная компания в нашем городе, имеющая более 5 разбросанных по городу точек, объединенных во едино, из тех, что являются нашими клиентами. А это и магазины и сети аптек.
Однако ни у кого нет сегментации, везде один l2. Правда, иногда вводят логическую адресацию разную, чтобы было проще ориентироваться и везде юзают статику.
Изначально у них была плоская сеть, с одним большим l2 доменом, где в которой в одном месте поднимался интернет, а другие магазины в этой локальной сети уже брали интернет и остальные сервисы из офиса. Со временем сеть росла, дальше Вы знаете :)
В целом правильно, что используете туннели внутри провайдера.
Удивительно, но это далеко не единственная компания в нашем городе, имеющая более 5 разбросанных по городу точек, объединенных во едино, из тех, что являются нашими клиентами. А это и магазины и сети аптек.
Однако ни у кого нет сегментации, везде один l2. Правда, иногда вводят логическую адресацию разную, чтобы было проще ориентироваться и везде юзают статику.
Просто, я не очень корректно выразился, насчет полного down в офисе, это скорее очень большой Форс-Мажор, который, конечно, будут быстро исправлять. Просто единый DHCP-сервер для всех, это все-таки, пожалуй также узкое место, в плане автономности каждого магазина, с точки зрения работы сети. Ведь одной из главных целей, была также и автономность, чтобы сбой в офисе, или в каком-то из магазинов, как можно менее критично отражался на работе других магазинов.
2 канала — при автономной работе магазинов это излишне, мало того подавляющее большинство кассового ПО позволяют работать без постоянного подключения к кассовому серверу. Работа с ревизиями так это вообще песня — это просто адъ и треш — носить сервер на ревизии (вот бы наши сисадмины порадовались бы :) ), причем у ревизоров есть ТСД (!!!!) наличие доступа к некому серверу ревизий тут вообще не имеет какой-либо обоснованности, т.к. обычно (если подходить к вопросу правильно) — ревизия это снятие фактических остатков, никаких серверов в «онлайн» доступе для этого не надо, достаточно загрузить нужный набор номенклатуры и ШК (ну я в общем случае — возможны варианты).
И еще во-первых я бы отказался от VPN ISP по многим причинам — вполне реально (если уж речь у вас про mikrotik) сделать vpn относительно недорого на mikrotik (к примеру 1100 голова, 951UI или G в качестве магазинских), во-вторых делать ОДИН DHCP сервер это как то сверх моего понимания — магазин может работать на «свистке», либо быть вдали от жизни (у нас например +500 км от Салехарда есть магазин — на каком-то мысе :) ), и если нет связе то все капут?
И еще во-первых я бы отказался от VPN ISP по многим причинам — вполне реально (если уж речь у вас про mikrotik) сделать vpn относительно недорого на mikrotik (к примеру 1100 голова, 951UI или G в качестве магазинских), во-вторых делать ОДИН DHCP сервер это как то сверх моего понимания — магазин может работать на «свистке», либо быть вдали от жизни (у нас например +500 км от Салехарда есть магазин — на каком-то мысе :) ), и если нет связе то все капут?
Вы наверное не читали первую статью, эта статья является продолжением первой, скорее даже не продолжение а дополнением, так как задачи и проблемы описаны в первой статье, а здесь лишь некоторые дополнительные нюансы, возникшие при решении первостепенных задач.
Я не системный администратор работающий в той компании, я человек со стороны, которого пригласили решить проблемы с сетью.
Попробую вкратце:
1. ТСД — представляет из себя мобильное устройство: КПК, с Windows Mobile (6.x) на борту, сканером штрихкодов, и Wi-Fi сетевым адаптером.
Оно работает по принципу: устройство подключается к Wi-Fi, имея статический IP (или получая по DHCP), далее по RDP через сеть, подключается к серверу в офисе. Затем человек работает с БД.
2. Кассы работают автономно, как Вы и указали, однако тем не менее, им необходимо, периодическая синхронизация цен с БД расположенной в офисе, синхронизация остатков. Для закрытия и открытия магазина, так-же требуется синхронизация.
3. Изначально все магазины подключены к одному ISP, где получают от него транзиутную сеть, а не выделенный интернет на каждый магазин.
Прежде всего, это просто дешевле, услуга организации локальной сети у провайдера, стоит дешевле, чем предоставление интернета в каждый магазин. Да и им, на первом этапе это было проще. До тех пор, пока сеть не разрослась.
4. По-скольку магазины все были в одной сети, предоставленной провайдером, то считайте, подключены к одному коммутатору, естественно DHCP был один и в офисе.
В офис, от провайдера заходят 2 линка (считайте Dual-homed схема), но переключение между линками осуществлялось вручную.
Какие здесь могут быть проблемы, с таким дизайном:
1. Нет связи между конкретным магазином и ISP. Результат в магазине нет инета, платежи не проходят, нет связи с сервером для ТСД.
2. Нет связи между линком 1 от ISP с офисом, во всех магазинах повторение ситуации N1, пока админы вручную не переключат линк с медика на PON-терминал. В таком случае все работает, за исключением DHCP для мобильных устройств сотрудников в магазине.
3. Нет интернета у ISP. Локалка работает, платежи через безнал не прохдят.
4. Полный ахтунг, нету обоих линков от ISP к офису. Комментировать последствия думаю не надо.
Что было сделано, можете прочитать в 1-й статье, повторюсь эта статья лишь дополнение к той. И да, как раз таки в офисе был установлен Mikrotik RB 1100, а в филиалах Mikrotik hEx (он по мощнее чем 951UI/G), однако было решено, что:
A. Магазины по прежнему в приоритете берут интернет (для проведения онлайн платежей) из офиса.
B. В случае, если нет связи с офисом, берут интерет через резерв.
C. Должна быть связь с офисом для синхронизации касс и работы ТСД.
И да, после внедрения Mikrotik DHCP в каждом магазине раздавался отдельный своим роутером, находящимся в самом магазине.
Уже после начала перевода магазинов на Mikrotik выяснилось то, о чем эта статья.
Я не системный администратор работающий в той компании, я человек со стороны, которого пригласили решить проблемы с сетью.
Попробую вкратце:
1. ТСД — представляет из себя мобильное устройство: КПК, с Windows Mobile (6.x) на борту, сканером штрихкодов, и Wi-Fi сетевым адаптером.
Оно работает по принципу: устройство подключается к Wi-Fi, имея статический IP (или получая по DHCP), далее по RDP через сеть, подключается к серверу в офисе. Затем человек работает с БД.
2. Кассы работают автономно, как Вы и указали, однако тем не менее, им необходимо, периодическая синхронизация цен с БД расположенной в офисе, синхронизация остатков. Для закрытия и открытия магазина, так-же требуется синхронизация.
3. Изначально все магазины подключены к одному ISP, где получают от него транзиутную сеть, а не выделенный интернет на каждый магазин.
Прежде всего, это просто дешевле, услуга организации локальной сети у провайдера, стоит дешевле, чем предоставление интернета в каждый магазин. Да и им, на первом этапе это было проще. До тех пор, пока сеть не разрослась.
4. По-скольку магазины все были в одной сети, предоставленной провайдером, то считайте, подключены к одному коммутатору, естественно DHCP был один и в офисе.
В офис, от провайдера заходят 2 линка (считайте Dual-homed схема), но переключение между линками осуществлялось вручную.
Какие здесь могут быть проблемы, с таким дизайном:
1. Нет связи между конкретным магазином и ISP. Результат в магазине нет инета, платежи не проходят, нет связи с сервером для ТСД.
2. Нет связи между линком 1 от ISP с офисом, во всех магазинах повторение ситуации N1, пока админы вручную не переключат линк с медика на PON-терминал. В таком случае все работает, за исключением DHCP для мобильных устройств сотрудников в магазине.
3. Нет интернета у ISP. Локалка работает, платежи через безнал не прохдят.
4. Полный ахтунг, нету обоих линков от ISP к офису. Комментировать последствия думаю не надо.
Что было сделано, можете прочитать в 1-й статье, повторюсь эта статья лишь дополнение к той. И да, как раз таки в офисе был установлен Mikrotik RB 1100, а в филиалах Mikrotik hEx (он по мощнее чем 951UI/G), однако было решено, что:
A. Магазины по прежнему в приоритете берут интернет (для проведения онлайн платежей) из офиса.
B. В случае, если нет связи с офисом, берут интерет через резерв.
C. Должна быть связь с офисом для синхронизации касс и работы ТСД.
И да, после внедрения Mikrotik DHCP в каждом магазине раздавался отдельный своим роутером, находящимся в самом магазине.
Уже после начала перевода магазинов на Mikrotik выяснилось то, о чем эта статья.
hEx без WiFi, в нашем случае никак не катит, т.к. ТСД работают через Wifi.
а вот RB1100 изначально думали менять на что-то из CCR, в итоге по результатам опытной эксплуатации признали это не целесообразным т.к. 1100 прекрасно справляется с нашим количеством торговых объектов.
и все таки мне кажется вся эта система излишне дорогая и не надежная (падение одного/двух линков — инет из офиса — например, элементарно — нет электричества несколько часов) фактически накрывает все медным тазом (я включаю в это и объем авральных работ со стороны сисадминов).
я не знаю чем думают сисадмины этой компании, но вам следовало бы на это указать, и предложить интернет в магазинах непосредственно, это бы повысило автономность торговых объектов как минимум в части розничной продажи — что собственно и является приоритетом.
а вот RB1100 изначально думали менять на что-то из CCR, в итоге по результатам опытной эксплуатации признали это не целесообразным т.к. 1100 прекрасно справляется с нашим количеством торговых объектов.
и все таки мне кажется вся эта система излишне дорогая и не надежная (падение одного/двух линков — инет из офиса — например, элементарно — нет электричества несколько часов) фактически накрывает все медным тазом (я включаю в это и объем авральных работ со стороны сисадминов).
я не знаю чем думают сисадмины этой компании, но вам следовало бы на это указать, и предложить интернет в магазинах непосредственно, это бы повысило автономность торговых объектов как минимум в части розничной продажи — что собственно и является приоритетом.
Все правильно, поэтому в каждую торговую точку, был заведен второй провайдер (ADSL, Rostelecom), от которого они берут чистый интернет. (Без локальной сети)
А система работает следующим образом:
1. В штатном режиме, магазин берет интернет из офиса, через локальную сеть провайдера (в магазине это единственный линк через ISP1, а в офисе это линк 1 от ISP1)
2. В офис приходят 2 линка от ISP-1 (основной и резерв именно от ISP1 ) + еще один линк от ISP-2, если падает 1-й линк ISP-1, то магазины берут инет c офиса через 2-й линк по ISP-1.
3. Если в офисе падают оба линка от ISP-1 то все магазины берут интернет от ISP-2 (локальные ADSL модемы, каждый в своем магазине), и так-же имеют связь с офисом по VPN через мир по каналу ISP-2 (ADSL)
4. Если в офисе есть 2 линка с ISP-1 и локальная сеть работает штатно, но у ISP-1 не работает интернет, тогда офис работает через ISP2, а все магазины берут инет не от Офиса (который уже сидит на ISP2) а через свои локально подключенные модемы ADSL через ISP-2.
Об этом я подробно писал в первой статье.
Wi-Fi точки доступа в каждом магазине уже были свои :) На момент начала работ. В каждом из магазинов было от 2 до 4х точек доступа.
А система работает следующим образом:
1. В штатном режиме, магазин берет интернет из офиса, через локальную сеть провайдера (в магазине это единственный линк через ISP1, а в офисе это линк 1 от ISP1)
2. В офис приходят 2 линка от ISP-1 (основной и резерв именно от ISP1 ) + еще один линк от ISP-2, если падает 1-й линк ISP-1, то магазины берут инет c офиса через 2-й линк по ISP-1.
3. Если в офисе падают оба линка от ISP-1 то все магазины берут интернет от ISP-2 (локальные ADSL модемы, каждый в своем магазине), и так-же имеют связь с офисом по VPN через мир по каналу ISP-2 (ADSL)
4. Если в офисе есть 2 линка с ISP-1 и локальная сеть работает штатно, но у ISP-1 не работает интернет, тогда офис работает через ISP2, а все магазины берут инет не от Офиса (который уже сидит на ISP2) а через свои локально подключенные модемы ADSL через ISP-2.
Об этом я подробно писал в первой статье.
Wi-Fi точки доступа в каждом магазине уже были свои :) На момент начала работ. В каждом из магазинов было от 2 до 4х точек доступа.
Добавлю по пункту 4.
В случае, если у ISP-1 нет инета. но он продолжает нормально обеспечивать локальную связь межуду магазинами и офисом, то магазины берут только интернет через ISP-2, а локальная связь между магазинами и офисом, продолжает работать через быстрый канал от ISP-1
В случае, если у ISP-1 нет инета. но он продолжает нормально обеспечивать локальную связь межуду магазинами и офисом, то магазины берут только интернет через ISP-2, а локальная связь между магазинами и офисом, продолжает работать через быстрый канал от ISP-1
Sign up to leave a comment.
Как я ловил Wi-Fi принтер по OSPF, корпоративная сеть на MikroTik часть 2