Дело в деталях, наверное, ведь для того, чтобы понять чем отличаются между собой эти Link-State протоколы, вовсе не обязательно становиться CCIE.
Здесь речь идет о более обширном, глобальном и глубинном знании, которое далеко не всегда находит себя в повседневной практики многих инженеров.
А что, не практикуется ежедневно, имеет тенденцию вскоре забываться.
Ну и сама подготовка требует много времени, сил, отдачи.
От того, думаю, так мало людей дошли до конца.
Вообще об этом много говорилось и проект это наглядно показал.
Поздравляю финалистов марафона и всех причастных!
Спасибо Вам за ваши труды и мотивацию+вдохновение для других!
Серьезный и сложный путь к достойной цели.
Почему-же, с учетом количества доступных IPv6-адресов, в будущем, не должно быть проблем с тем, чтобы получить свой блок PI-адресов, далее по BGP анонсировать их обоим аплинком. Вот вам фейловер и балансировка! :)
Если же, речь о домашних пользователях, то есть такие вещи как NATv6 Prefix Translation, ну или же, обновлять по ICMPv6/DHCPv6 Анонсируемый префикс (получаемый от второго аплинка), в таком случае, адресация конечных машин будет неизменной. Просто, сменится префикс.
Добавлю по пункту 4.
В случае, если у ISP-1 нет инета. но он продолжает нормально обеспечивать локальную связь межуду магазинами и офисом, то магазины берут только интернет через ISP-2, а локальная связь между магазинами и офисом, продолжает работать через быстрый канал от ISP-1
Все правильно, поэтому в каждую торговую точку, был заведен второй провайдер (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. ТСД — представляет из себя мобильное устройство: КПК, с 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 выяснилось то, о чем эта статья.
Спасибо. Для себя уже этот момент уяснил, не Вы один сегодня дали такую рекомендацию.
Вероятно, в других проектах, которые будут попадаться мне на моем пути, попробую данное решение.
Можно, но для этого должен быть один общий DHCP-сервер, т.к. в каждом магазине своей роутер со своим DHCP и своей адресацией.
Кстати, вспомнил аргумент почему терминалы группы ревизии со статическим IP, это также сделано для того, чтобы за каждым сотрудником закрепить конкретный терминал, и на этот терминал можно было попасть удаленно сис.админам, в случае чего.
Ну, не совсем у нас, т.к. я работаю инженером технической поддержки в ISP, который как раз и организовывает связь между всеми магазинами предприятия, среди которых есть и супермаркеты. Ко мне обратились наши клиенты, я по мере своих знаний, умений и возможности реализовал проект. По тем требованиям и задачам, что передо мной стояли.
Изначально у них была плоская сеть, с одним большим l2 доменом, где в которой в одном месте поднимался интернет, а другие магазины в этой локальной сети уже брали интернет и остальные сервисы из офиса. Со временем сеть росла, дальше Вы знаете :)
В целом правильно, что используете туннели внутри провайдера.
Удивительно, но это далеко не единственная компания в нашем городе, имеющая более 5 разбросанных по городу точек, объединенных во едино, из тех, что являются нашими клиентами. А это и магазины и сети аптек.
Однако ни у кого нет сегментации, везде один l2. Правда, иногда вводят логическую адресацию разную, чтобы было проще ориентироваться и везде юзают статику.
Просто, я не очень корректно выразился, насчет полного down в офисе, это скорее очень большой Форс-Мажор, который, конечно, будут быстро исправлять. Просто единый DHCP-сервер для всех, это все-таки, пожалуй также узкое место, в плане автономности каждого магазина, с точки зрения работы сети. Ведь одной из главных целей, была также и автономность, чтобы сбой в офисе, или в каком-то из магазинов, как можно менее критично отражался на работе других магазинов.
Начну с ответа на P.S.
И да и нет. L2 там скорее полноценный: IP, GRE, пакеты ходят, PPPoE ходит. Однако, в некоторых местах точки подключены через PON-технологию.
О которой Вы можете прочитать здесь. Абонентские терминалы Huawei H810E, не пропускают OSPF пакеты со стороны OLT в сторону абонента.
Также были случаи, когда например со стороны абонента вверх не ходили DHCP-Offer пакеты.
Еще изначально по умолчанию, трафик в одном vlan между разными ONU подключенными к одной OLT не ходит, но это решается на olt специальной фичей. С OSPF пока не разобрались как активировать, но мысли куда копать есть.
Просто, среди наших клиентов, никто не использует dynamic routing. (По крайней-мере среди тех, кто подключен через PON)
Плюсов у него больше, чем минусов.
По поводу автономности, я просто привел пример с полным down в офисе, естественно, такого быть не должно.
Просто, кассы на этот счет автономны, и могут отпускать товар без связи с офисом, за наличку при отсутствии интернета, а учитывая что банковские карты нынче распространены, то интернет быть обязан, для обеспечение безналичных платежей.
Поэтому если связь с офисом пропадет, магазин в плане работы с клиентами будет работать и отпускать товар. Продажи не остановятся.
Тем не менее, не смотря на то, что кассы автономны, несколько раз в сутки они выполняют синхронизацию БД, по этому связь необходима, хоть и не постоянна.
Так-же ТСД, что находятся в магазинах, и выполняют прием товаров и другие обработки, тоже работают напрямую с серверами которые находятся в офисе.
Плюс, опять-же единый DHCP сервер для всех филиалов, это такая-себе точка отказа.
Скажем, если вдруг в офисе не будет света (а такое, уже было, во время внедрения) и, он полностью уйдет в down, то тогда устройства в магазинах перестанут получать DHCP.
Ведь изначально планировалось, чтобы магазины по максимуму были автономны. И не завис или от офиса, только если им не нужно с ним работать, например в БД по RDP, к примеру кассы у них автономны и должна оставаться возможность проведения безналичных платежей.
Так-же некоторые сотрудники, во время работы, регулярно фотографируют товары и передают их друг друг через WhatsApp, по этому если они не смогут получить DHCP это будет небольшой но все-таки проблемой.
А так, каждый филиал полностью автономен. В общем, игра компромиссов :)
Вариантов решения этой задачи несколько.
Одним из «сетевых» вариантов, было бы действительно туннелирование, о котором писали Выше, плюс отдельные Virtual-SSID с нужным VLAN, тогда бы, при перемещении между магазинами, именно мобильная группа была бы в едином broadcast-домен, такой себе end-to-end vlan. Но опять-же, требуются дополнительные устройства + плюс уменьшение mtu (не очень страшно) + риск петли, если какое-то из устройств — глюканет. Хотя, для этого есть STP. Либо делать туннелирование до конкретного IP, маршрут к которому будет меняться если пропадет основной канал.
Ваш сценарий мне понравился. Однако он требует настройки дополнительного решения, уже за пределами тех девайсов, что у меня были.
Если его брать, то только релить, т.к. на то, чтобы что-то дополнительно ставить в другие магазины они бы точно не пошли. А опыта работы с Windows DHCP + DNS у меня к сожалению нет.
Повторюсь, что проект был внедрен не сразу, так — чтобы по щелчку пальцев, щелк — все магазины работают по новому.
Моей задачей было организация отказоустойчивой сети, с соблюдением ряда жестких условиях, на случай всяких-разных аварий, об этом более подробно в первой статье.
По завершению проекта, когда сеть отказоустойчева — нет никакой необходимости возить сервер ревизии по магазинам. Но я писал, для чего это делается, т.к. у них были случаи, когда магазины лишали связи. Конечно — это форс-мажор и бывает не каждый раз
По этому, вариант оставить сервер ревизии в офисе, а мобильным ТСД для ревизии выдавать DHCP проблем нет. В целом это было бы правильнее. Но, т.к. все переводилось постепенно, то дизайн требовал уже предустановленного решения, чтобы работало и там, где переведено и там где не переведено.
Я не администрирую их сервера и сеть, я не работаю в той компании, это был частный проект, в котором я отвечал строго за связь и конвергетность.
Насчет отдельного виндового DHCP, я не являюсь администратором Windows, потому тут ничего на скорую руку предложить бы не смог.
В случае, единого DHCP, в голове рисуется дизайн, с DHCP-Relay на Микротиках, когда они будут запрашивать адреса, для всех подключаемых устройств в том или ином магазине.
И, в каждом из магазинов пул выдаваемых устройств должен быть разным.
Тогда да, если единый DHCP сервер, сможет правильно в зависимости от того, откуда прилетел request выдать IP- из верного пула. Плюс, обновлять запись в DNS, это вероятное решение.
Вообще, так сложилось, что в нашем маленьком городке многие предприятия где есть нечто вроде своей сети, любят назначать статику.
По факту DHCP им был нужен только для различных устройств пользователей — телефонов, например для обмена сообщениями через WhatsApp и только.
Была такая мысль. Однако, повторюсь, в каждом магазине, есть своя локальная сеть. В которой существует несколько точек доступа с идентичными SSID и паролями. Ранее, когда сеть была плоской на L2 проблем не было.
Теперь, каждый магазин это — отдельный, изолированный от общей сети broadcast-домен,
Так-же, между каждым из магазинов, и офисом существует по 2 канала связи, через разных провайдеров.
Для того, чтобы решить данную задачу с туннелированием L2 поверх L3, необходимо в каждом магазине по крайней-мере установить еще по одной беспроводной точки доступа, или настроить Virtual-AP, куда бы цеплялись устройства клиентов мобильной группы.
Имеющиеся точки доступа в магазинах не поддерживают VLAN и Virtual-AP, там вообще нет управляемых коммутаторов. Да и устройств в каждом из магазинов не так много и бродкаст-домен не большой.
Тянуть новые СКС и подключать отдельные точки доступа для мобильной группы. Или менять текущие точки доступа и ставить управляемые коммутаторы никто не будет.
Хотя это было бы безусловно красивее.
Ну и плюс, вопросы о надежности L2 поверх L3, которое будет загоняться еще в один туннель (когда магазин будет работать на резервном канале), то получаем вероятные проблемы с MTU. Но это не так страшно, как вероятность образования l2 петли.
Так-что, уж лучше Dinymac Routing.
Спасибо за статью! Хоть, на практике, к сожалению, еще не представлялось возможным поработать с MPLS.
Т.к. в нашем небольшом ISP и городе он попросту не используется.
Все равно читать интересно.
Особая благодарность за, назову это «Dual-Stack» — симбиоз настроек Cisco и Juniper.
Хорошо, допустим. А где будет хранится запись 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 сети и печатает ценники :)
Здесь речь идет о более обширном, глобальном и глубинном знании, которое далеко не всегда находит себя в повседневной практики многих инженеров.
А что, не практикуется ежедневно, имеет тенденцию вскоре забываться.
Ну и сама подготовка требует много времени, сил, отдачи.
От того, думаю, так мало людей дошли до конца.
Вообще об этом много говорилось и проект это наглядно показал.
Спасибо Вам за ваши труды и мотивацию+вдохновение для других!
Серьезный и сложный путь к достойной цели.
Если же, речь о домашних пользователях, то есть такие вещи как NATv6 Prefix Translation, ну или же, обновлять по ICMPv6/DHCPv6 Анонсируемый префикс (получаемый от второго аплинка), в таком случае, адресация конечных машин будет неизменной. Просто, сменится префикс.
В случае, если у ISP-1 нет инета. но он продолжает нормально обеспечивать локальную связь межуду магазинами и офисом, то магазины берут только интернет через ISP-2, а локальная связь между магазинами и офисом, продолжает работать через быстрый канал от ISP-1
А система работает следующим образом:
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. ТСД — представляет из себя мобильное устройство: КПК, с 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 выяснилось то, о чем эта статья.
Вероятно, в других проектах, которые будут попадаться мне на моем пути, попробую данное решение.
Кстати, вспомнил аргумент почему терминалы группы ревизии со статическим IP, это также сделано для того, чтобы за каждым сотрудником закрепить конкретный терминал, и на этот терминал можно было попасть удаленно сис.админам, в случае чего.
Изначально у них была плоская сеть, с одним большим l2 доменом, где в которой в одном месте поднимался интернет, а другие магазины в этой локальной сети уже брали интернет и остальные сервисы из офиса. Со временем сеть росла, дальше Вы знаете :)
В целом правильно, что используете туннели внутри провайдера.
Удивительно, но это далеко не единственная компания в нашем городе, имеющая более 5 разбросанных по городу точек, объединенных во едино, из тех, что являются нашими клиентами. А это и магазины и сети аптек.
Однако ни у кого нет сегментации, везде один l2. Правда, иногда вводят логическую адресацию разную, чтобы было проще ориентироваться и везде юзают статику.
И да и нет. L2 там скорее полноценный: IP, GRE, пакеты ходят, PPPoE ходит. Однако, в некоторых местах точки подключены через PON-технологию.
О которой Вы можете прочитать здесь. Абонентские терминалы Huawei H810E, не пропускают OSPF пакеты со стороны OLT в сторону абонента.
Также были случаи, когда например со стороны абонента вверх не ходили DHCP-Offer пакеты.
Еще изначально по умолчанию, трафик в одном vlan между разными ONU подключенными к одной OLT не ходит, но это решается на olt специальной фичей. С OSPF пока не разобрались как активировать, но мысли куда копать есть.
Просто, среди наших клиентов, никто не использует dynamic routing. (По крайней-мере среди тех, кто подключен через PON)
Плюсов у него больше, чем минусов.
По поводу автономности, я просто привел пример с полным down в офисе, естественно, такого быть не должно.
Просто, кассы на этот счет автономны, и могут отпускать товар без связи с офисом, за наличку при отсутствии интернета, а учитывая что банковские карты нынче распространены, то интернет быть обязан, для обеспечение безналичных платежей.
Поэтому если связь с офисом пропадет, магазин в плане работы с клиентами будет работать и отпускать товар. Продажи не остановятся.
Тем не менее, не смотря на то, что кассы автономны, несколько раз в сутки они выполняют синхронизацию БД, по этому связь необходима, хоть и не постоянна.
Так-же ТСД, что находятся в магазинах, и выполняют прием товаров и другие обработки, тоже работают напрямую с серверами которые находятся в офисе.
Скажем, если вдруг в офисе не будет света (а такое, уже было, во время внедрения) и, он полностью уйдет в down, то тогда устройства в магазинах перестанут получать DHCP.
Ведь изначально планировалось, чтобы магазины по максимуму были автономны. И не завис или от офиса, только если им не нужно с ним работать, например в БД по RDP, к примеру кассы у них автономны и должна оставаться возможность проведения безналичных платежей.
Так-же некоторые сотрудники, во время работы, регулярно фотографируют товары и передают их друг друг через WhatsApp, по этому если они не смогут получить DHCP это будет небольшой но все-таки проблемой.
А так, каждый филиал полностью автономен. В общем, игра компромиссов :)
Одним из «сетевых» вариантов, было бы действительно туннелирование, о котором писали Выше, плюс отдельные Virtual-SSID с нужным VLAN, тогда бы, при перемещении между магазинами, именно мобильная группа была бы в едином broadcast-домен, такой себе end-to-end vlan. Но опять-же, требуются дополнительные устройства + плюс уменьшение mtu (не очень страшно) + риск петли, если какое-то из устройств — глюканет. Хотя, для этого есть STP. Либо делать туннелирование до конкретного IP, маршрут к которому будет меняться если пропадет основной канал.
Ваш сценарий мне понравился. Однако он требует настройки дополнительного решения, уже за пределами тех девайсов, что у меня были.
Если его брать, то только релить, т.к. на то, чтобы что-то дополнительно ставить в другие магазины они бы точно не пошли. А опыта работы с Windows DHCP + DNS у меня к сожалению нет.
Моей задачей было организация отказоустойчивой сети, с соблюдением ряда жестких условиях, на случай всяких-разных аварий, об этом более подробно в первой статье.
По завершению проекта, когда сеть отказоустойчева — нет никакой необходимости возить сервер ревизии по магазинам. Но я писал, для чего это делается, т.к. у них были случаи, когда магазины лишали связи. Конечно — это форс-мажор и бывает не каждый раз
По этому, вариант оставить сервер ревизии в офисе, а мобильным ТСД для ревизии выдавать DHCP проблем нет. В целом это было бы правильнее. Но, т.к. все переводилось постепенно, то дизайн требовал уже предустановленного решения, чтобы работало и там, где переведено и там где не переведено.
Я не администрирую их сервера и сеть, я не работаю в той компании, это был частный проект, в котором я отвечал строго за связь и конвергетность.
Насчет отдельного виндового DHCP, я не являюсь администратором Windows, потому тут ничего на скорую руку предложить бы не смог.
В случае, единого DHCP, в голове рисуется дизайн, с DHCP-Relay на Микротиках, когда они будут запрашивать адреса, для всех подключаемых устройств в том или ином магазине.
И, в каждом из магазинов пул выдаваемых устройств должен быть разным.
Тогда да, если единый DHCP сервер, сможет правильно в зависимости от того, откуда прилетел request выдать IP- из верного пула. Плюс, обновлять запись в DNS, это вероятное решение.
Вообще, так сложилось, что в нашем маленьком городке многие предприятия где есть нечто вроде своей сети, любят назначать статику.
По факту DHCP им был нужен только для различных устройств пользователей — телефонов, например для обмена сообщениями через WhatsApp и только.
Теперь, каждый магазин это — отдельный, изолированный от общей сети broadcast-домен,
Так-же, между каждым из магазинов, и офисом существует по 2 канала связи, через разных провайдеров.
Для того, чтобы решить данную задачу с туннелированием L2 поверх L3, необходимо в каждом магазине по крайней-мере установить еще по одной беспроводной точки доступа, или настроить Virtual-AP, куда бы цеплялись устройства клиентов мобильной группы.
Имеющиеся точки доступа в магазинах не поддерживают VLAN и Virtual-AP, там вообще нет управляемых коммутаторов. Да и устройств в каждом из магазинов не так много и бродкаст-домен не большой.
Тянуть новые СКС и подключать отдельные точки доступа для мобильной группы. Или менять текущие точки доступа и ставить управляемые коммутаторы никто не будет.
Хотя это было бы безусловно красивее.
Ну и плюс, вопросы о надежности L2 поверх L3, которое будет загоняться еще в один туннель (когда магазин будет работать на резервном канале), то получаем вероятные проблемы с MTU. Но это не так страшно, как вероятность образования l2 петли.
Так-что, уж лучше Dinymac Routing.
Т.к. в нашем небольшом ISP и городе он попросту не используется.
Все равно читать интересно.
Особая благодарность за, назову это «Dual-Stack» — симбиоз настроек Cisco и Juniper.
Как работает 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 сети и печатает ценники :)
Сравнил в LSA множество маршрутов intra-area, которые имеются на Point-to-Point интерфейсах, примерно так:
Однако в таблице маршрутизации этих маршрутов нет. А вот, если я выключу правило, то они появляются!