Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
Красиво, емко, нужно — было приятно прочесть. Только один вопрос (пожалуйста, товарищи-Хабровчане, давайте без холиваров ну хоть в этот раз): почему D-Link, а не Cisco?
Не заработали денег на Cisco еще :-)
А в домовых сетях бывает Cisco? На аксес левеле я обычно вижу Huawei или Dlink.
Бывает. Покупают б/у на ebay и ставят.
Dell ставим, Linksys ставим — по цене не сильно дороже Длинков, зато не записываешься в пожизненные бесплатные бетатестеры компании. Хуавей — очень неплохое железо, нет смысла сравнивать этих вендоров даже близко. ИМХО
Да и у самой Циски есть относительно не дорогие коммутаторы. Но мать же вашу, сколько стоят оптические трансиверы для них (приличный стоит дороже коммутатора). Это же мрак. А D-Link-овские на сдачу отсыпают.
Трансиверы никто не запрещает использовать других вендоров, с ними проблем не очень много даже с относительно дешевыми. Фирменные на критичные узлы, на остальные что попроще. Основная проблема длинков — очень кривая прошивка, в которой даже задекларированные возможности работают не полностью. Из недавнего, попросили помочь с сеткой, небольшая совсем, 2 десятка коммутаторов D-Link DES-3200-26, прошивка 4.00.024 (это важно, на других ветках говорят проблем меньше). Извините, но это мрак мало того что DHCP snooping работает через раз (точнее раз из 5, пришлось городить костыль на access profile) так еще при использовании dhcp relay в связке с option 82 получаем не веселую картину, все вроди как работает, но при скачке напряжения сразу после поднятия свича, на него идет запрос на получение DHCP от абонентов, свич увидев такое счастье начинает флудить этими запросами на всю сеть, другие свичи радостно подхватывают эстафету и сеть ложится, почему так происходит выяснить не удалось, но всплывала проблема раз в неделю, железо тупо ложило само себя, пришлось выносить каждую свечку в отдельный вилан. И таких проблем море, если использовать хоть что-то сложнее банальных vlan в структуре сети.
Если в небольшой сети время и желание заниматься регулярными перепрошивками свичей еще есть (ответ вендора: «вот в следующей починили — проверяйте», одно починили другое сломали.) то когда количество таких железяк переваливает за несколько сотен, даже не тысяч, заниматься с ними регулярным сексом уже не выходит. Так что экономия очень спорная, часто принимается решение поставить б/у циски и делы 10 летней давности привезенные с США, чем новенькие длинки за те же деньги и не иметь проблем с их обслуживанием, они просто работают.
Если в небольшой сети время и желание заниматься регулярными перепрошивками свичей еще есть (ответ вендора: «вот в следующей починили — проверяйте», одно починили другое сломали.) то когда количество таких железяк переваливает за несколько сотен, даже не тысяч, заниматься с ними регулярным сексом уже не выходит. Так что экономия очень спорная, часто принимается решение поставить б/у циски и делы 10 летней давности привезенные с США, чем новенькие длинки за те же деньги и не иметь проблем с их обслуживанием, они просто работают.
Cisco в домовых сетях на уровне доступа — это из области фантастики. Недопустимо дорого.
DLink, Zyxel, и ещё куча других гораздо менее понятных брендов.
DLink, Zyxel, и ещё куча других гораздо менее понятных брендов.
Думаю, первый показатель — разница в цене. Когда идешь по пути постоянного расширения — деньги уходят на покупку очередных абонентов.
Во-вторых, на тот момент именно этих коммутаторов во всей сети было больше.
А мне, как программисту и человеку, ступившему в неизвестную ранее область, было вообще без разницы, на чем строить сеть — это решение сверху. И надо сказать, в тех.поддержке D-Link всегда внимательно относились к нашим вопросам. Однажды только была ситуация, выслали нам прошивку для DES 3526, а как оказалось, прошивка занимала больше отведенного ей места. Ночью обновили, а утром монтажники собирали по всем населенным пунктам трупы и везли в офис. Дело в том, что обычно ребята из D-Link'а вместе с файлом прошивки высылали текстовый файл, в котором указывали конкретные особенности этой прошивки — в тот раз они этого не сделали. А мы допустили оплошность, не проверив вручную на одном коммутаторе.
Во-вторых, на тот момент именно этих коммутаторов во всей сети было больше.
А мне, как программисту и человеку, ступившему в неизвестную ранее область, было вообще без разницы, на чем строить сеть — это решение сверху. И надо сказать, в тех.поддержке D-Link всегда внимательно относились к нашим вопросам. Однажды только была ситуация, выслали нам прошивку для DES 3526, а как оказалось, прошивка занимала больше отведенного ей места. Ночью обновили, а утром монтажники собирали по всем населенным пунктам трупы и везли в офис. Дело в том, что обычно ребята из D-Link'а вместе с файлом прошивки высылали текстовый файл, в котором указывали конкретные особенности этой прошивки — в тот раз они этого не сделали. А мы допустили оплошность, не проверив вручную на одном коммутаторе.
«А мне, как программисту и человеку, ступившему в неизвестную ранее область, было вообще без разницы, на чем строить сеть — это решение сверху. „
Здорово. Первичен должен быть выбор архитектуры с учетом тех сервисов, которые будут предоставляться сейчас и в перспктиве. От этого отталкиваются и ищут железо с нужным функционалом и разумной ценой. Послезавтра захотите IPTV какое-нибудь или другую допуслугу и вдруг окажется, что сеть для этого совершенно не готова. Ну хорошо, допустим не захотите никогда. Но в статье о подобных вещах вообще ни слова. Полностью отсутсвует ход мысли в духе — задача -> поиск решения -> выбор из альтернатив оптимального.
Здорово. Первичен должен быть выбор архитектуры с учетом тех сервисов, которые будут предоставляться сейчас и в перспктиве. От этого отталкиваются и ищут железо с нужным функционалом и разумной ценой. Послезавтра захотите IPTV какое-нибудь или другую допуслугу и вдруг окажется, что сеть для этого совершенно не готова. Ну хорошо, допустим не захотите никогда. Но в статье о подобных вещах вообще ни слова. Полностью отсутсвует ход мысли в духе — задача -> поиск решения -> выбор из альтернатив оптимального.
Охх. кто ж без тестов на паре сначала тестовых устройств, а потом на небольшой группе из продакшена такое вываливает сразу на всю сеть?
Каюсь. Изначально все так и было, постепенно поняли, что система налажена, сбросили задачу на Zabbix. И практически сразу обожглись. Благо, добра такого (3526) — единицы. Собственно, без прикрас об этом и написал — надеюсь на наших ошибках кто-то научится не расслабляться.
Нельзя полагаться на что либо.
В некоторых компаниях за нарушение регламента — увольнение по статье.
В некоторых компаниях за нарушение регламента — увольнение по статье.
Это приходит с опытом. Регламент ввели несколько позже. До увольнений не доходило, но пару раз штрафы некоторым сотрудникам вкатывали. Небольшие, скорее для воспитания.
Жаль что поздно догадались.
У меня обычно приход на новую работу ознаменуется написанием политик ИТ по компании, по процедурам ИТ отдела и подписанием их приказом по компании. с распространением по сотрудникам.
Соответственно все процедуры максимально документируются, рисуются SLA.
Но это да, приходит с опытом.
У меня обычно приход на новую работу ознаменуется написанием политик ИТ по компании, по процедурам ИТ отдела и подписанием их приказом по компании. с распространением по сотрудникам.
Соответственно все процедуры максимально документируются, рисуются SLA.
Но это да, приходит с опытом.
Скажите, а откуда берётся скилл написания всего этого?
Я, вроде, неплохой инженер, но если бы встала такая задача — не знал бы даже, с какой стороны подойти.
Я, вроде, неплохой инженер, но если бы встала такая задача — не знал бы даже, с какой стороны подойти.
вначале — о себе.
Потом — как это делалось многими моими знакомыми
последний блок -как это делается в идеале по мировым практикам.
Потом — как это делалось многими моими знакомыми
последний блок -как это делается в идеале по мировым практикам.
Много текста
Не скажу за всех, скажу за себя:
— развлекаться с компьютерами я начал еще с 7 лет.
и начинал с MS-DOS. сначала игры, потом в школе обьединил Lantastic (6х286 пк) с стоящей «на сервере» (1х486) Win3.11 for WG в одну сеть.
Потом вся линейка 9x, и рабочие станции NT с 2000й. потом в 2005 добавилась фря и линукса. Соответственно граблей было много от идиотских и разных до феерических и сложных, что приходилось дергать сертифицированных по данной технологии знакомых.
С доменом фактически столкнулся уже в прошлом году, пришлось много чего в компании переделывать в ИТ инфраструктуре, т.к. она фактически была заброшена и меня брали как раз на администратора- инженера, который будет тестить и внедрять новый функционал, т.к. до меня домен был только общей системой авторизации на рабочих станциях. Соответственно писалась документация по всему, что, где и как я настраивал, какие групповые политики, какие сервисы — буквально со скриншотами каждого шага настройки с описанием что, где, зачем и почему. Потом высчитывались временные интервалы SLA и зависимости — если упадет такой то сервис — время поднятия, если упадет такой-то сервер — какие сервисы это затронет и сколько будет заниматься восстановление из бекапа либо же развертыванияе с нуля/либо же перенос виртуалки. Причем оно реально выполнялось — т.е. мы знали, например, что полный бекап файлопомойки если её не разбить на части — выполняется больше 2х суток.
На последнем месте работы вообще полностью с нуля развернул за три месяца полную ИТ инфраструктуру офиса используя свои текущие знания, при этом практически с нуля изучая Cisco (недельные курсы icnd по маршрутизации в 2007 кажется, не считаются, забыл нафиг), и iSCSI NAS, с виртуализацией, новым доменом, новым почтовым сервером, IP телефонией, разнесением разного трафика по VLAN'ам, подсетям и настройками доступа.
Причем это всё было достаточно детально описано — где-то полторы недели тупо писал документацию по этому всему зоопарку и то, далеко не всё охватил.
— Скилл написания — В условиях СНГ, а как показывает мои знакомые — и не только в СНГ — лично полученные грабли — заболел админ и всё нафиг умерло — резервируем админа.
Провайдеру перебили оптику — покупаем у второго провайдера второй канал.
Перебили оба канала потому что они оба лежат в одном колодце — привет СНГ — проверяем чтобы оба канала интернета шли разными путями.
Местные энергетики передали привет от сгоревшей подстанции — покупаем второй ввод 220, если и там проблемы — тратимся на генератор.
Сгорел сервер/коммутатор/маршрутизатор/компьютер/ноутбук/модем/мультиплексор/конвертер — имеем 1 (2/3/пачку) в запасе.
Имеем 8 головый ксеон/16 гиг памяти, который занимается тупой раздачей файлов, а рядом стоят еще три старых ксеона — заводим виртуализацию, три железки ставятся под менее ресурсоемкие задачи/тестинг либо вообще отдаются в резерв, чтобы в случае выхода большого ксеона — быстро поднять эти виртуалки на них.
Освобождаем файловый сервер от много винтов — покупая большой и толстый NAS/SAN, куда складывается почтовые, файловые шары, базы данных.
Юзер лазит по социалкам в рабочее время — ставим ограничение на прокси — которая вместе с почтовым сервером прекрасно живут по небольшим виртуалкам.
Юзер ставит лишнее и не нужное п/о — применяем пистоны и групповые политики запрета запуска неподписанного п/о
и так далее.
—
А если по правильному и по умному —
Есть общие рекомендации по управлению бизнесом, ИТ и так далее — ключевое слово — «ITIL», по уровням надёжности ЦОД — «TIER», навскидку.
Есть рекомендации по построению инфраструктуры — те же доки от вендоров — Microsoft, Cisco, IBM, HP, Oracle, VmWare и других о том, как правильно строить соответствующую инфраструктуру виртуализации, систем резервного копирования, защиты периметра и внутренней сети, коммутаторов, каналов, систем хранения, кластеров, ЦОДов, облаков, конкретных систем, сервисов и услуг — собственно этому учат на курсах соответствующих направлений конкретных вендоров.
Это по хорошему и правильному —
Нравится Linux/Unix — изучаешь курсы и документацию LPI, Oracle, RedHat xBSD и соответствующую документацию
Нравится MIcrosoft — изучаешь Программирование на .Net/Active Directory/SQL/Sharepoint/Office/Azure и т.п. по идеологии данного вендора.
Нравятся базы данных — Mysq/Postgres/MS Sql/Oracle к Вашим услугам + хотя бы немного изучаешь ту ОС, под которой оно живет, т.к. это надо понимать как целостную платформу.
Нравятся сети — Cisco, Huawei, Nortel, D-Link, Linksys, VPN, маршрутизация — насколько я понимаю на данный момент — лучшие курсы по сетям де факто от Cisco — некоторые остальные вендоры сейчас по управлению своими железками стараются внедрить интерфейс управления в консоли, похожий на Cisco CLI.
— Соответственно в идеале и по правильному — это очень узкая специализация, на практике у нас пытаются экономить и хотят знаний побольше от одного, и чтобы платить поменьше. и это печально.
— развлекаться с компьютерами я начал еще с 7 лет.
и начинал с MS-DOS. сначала игры, потом в школе обьединил Lantastic (6х286 пк) с стоящей «на сервере» (1х486) Win3.11 for WG в одну сеть.
Потом вся линейка 9x, и рабочие станции NT с 2000й. потом в 2005 добавилась фря и линукса. Соответственно граблей было много от идиотских и разных до феерических и сложных, что приходилось дергать сертифицированных по данной технологии знакомых.
С доменом фактически столкнулся уже в прошлом году, пришлось много чего в компании переделывать в ИТ инфраструктуре, т.к. она фактически была заброшена и меня брали как раз на администратора- инженера, который будет тестить и внедрять новый функционал, т.к. до меня домен был только общей системой авторизации на рабочих станциях. Соответственно писалась документация по всему, что, где и как я настраивал, какие групповые политики, какие сервисы — буквально со скриншотами каждого шага настройки с описанием что, где, зачем и почему. Потом высчитывались временные интервалы SLA и зависимости — если упадет такой то сервис — время поднятия, если упадет такой-то сервер — какие сервисы это затронет и сколько будет заниматься восстановление из бекапа либо же развертыванияе с нуля/либо же перенос виртуалки. Причем оно реально выполнялось — т.е. мы знали, например, что полный бекап файлопомойки если её не разбить на части — выполняется больше 2х суток.
На последнем месте работы вообще полностью с нуля развернул за три месяца полную ИТ инфраструктуру офиса используя свои текущие знания, при этом практически с нуля изучая Cisco (недельные курсы icnd по маршрутизации в 2007 кажется, не считаются, забыл нафиг), и iSCSI NAS, с виртуализацией, новым доменом, новым почтовым сервером, IP телефонией, разнесением разного трафика по VLAN'ам, подсетям и настройками доступа.
Причем это всё было достаточно детально описано — где-то полторы недели тупо писал документацию по этому всему зоопарку и то, далеко не всё охватил.
— Скилл написания — В условиях СНГ, а как показывает мои знакомые — и не только в СНГ — лично полученные грабли — заболел админ и всё нафиг умерло — резервируем админа.
Провайдеру перебили оптику — покупаем у второго провайдера второй канал.
Перебили оба канала потому что они оба лежат в одном колодце — привет СНГ — проверяем чтобы оба канала интернета шли разными путями.
Местные энергетики передали привет от сгоревшей подстанции — покупаем второй ввод 220, если и там проблемы — тратимся на генератор.
Сгорел сервер/коммутатор/маршрутизатор/компьютер/ноутбук/модем/мультиплексор/конвертер — имеем 1 (2/3/пачку) в запасе.
Имеем 8 головый ксеон/16 гиг памяти, который занимается тупой раздачей файлов, а рядом стоят еще три старых ксеона — заводим виртуализацию, три железки ставятся под менее ресурсоемкие задачи/тестинг либо вообще отдаются в резерв, чтобы в случае выхода большого ксеона — быстро поднять эти виртуалки на них.
Освобождаем файловый сервер от много винтов — покупая большой и толстый NAS/SAN, куда складывается почтовые, файловые шары, базы данных.
Юзер лазит по социалкам в рабочее время — ставим ограничение на прокси — которая вместе с почтовым сервером прекрасно живут по небольшим виртуалкам.
Юзер ставит лишнее и не нужное п/о — применяем пистоны и групповые политики запрета запуска неподписанного п/о
и так далее.
—
А если по правильному и по умному —
Есть общие рекомендации по управлению бизнесом, ИТ и так далее — ключевое слово — «ITIL», по уровням надёжности ЦОД — «TIER», навскидку.
Есть рекомендации по построению инфраструктуры — те же доки от вендоров — Microsoft, Cisco, IBM, HP, Oracle, VmWare и других о том, как правильно строить соответствующую инфраструктуру виртуализации, систем резервного копирования, защиты периметра и внутренней сети, коммутаторов, каналов, систем хранения, кластеров, ЦОДов, облаков, конкретных систем, сервисов и услуг — собственно этому учат на курсах соответствующих направлений конкретных вендоров.
Это по хорошему и правильному —
Нравится Linux/Unix — изучаешь курсы и документацию LPI, Oracle, RedHat xBSD и соответствующую документацию
Нравится MIcrosoft — изучаешь Программирование на .Net/Active Directory/SQL/Sharepoint/Office/Azure и т.п. по идеологии данного вендора.
Нравятся базы данных — Mysq/Postgres/MS Sql/Oracle к Вашим услугам + хотя бы немного изучаешь ту ОС, под которой оно живет, т.к. это надо понимать как целостную платформу.
Нравятся сети — Cisco, Huawei, Nortel, D-Link, Linksys, VPN, маршрутизация — насколько я понимаю на данный момент — лучшие курсы по сетям де факто от Cisco — некоторые остальные вендоры сейчас по управлению своими железками стараются внедрить интерфейс управления в консоли, похожий на Cisco CLI.
— Соответственно в идеале и по правильному — это очень узкая специализация, на практике у нас пытаются экономить и хотят знаний побольше от одного, и чтобы платить поменьше. и это печально.
Да я сам CCNP/CCDP, так что как строится, скажем, сеть — примерно представляю. Техническая сторона вопросов особо не вызывает.
А вот политики компании, IT-отдела, регламенты и т.д… Такого обучения не встречал.
Буду копать в направлении ITIL.
Спасибо за ответ!
А вот политики компании, IT-отдела, регламенты и т.д… Такого обучения не встречал.
Буду копать в направлении ITIL.
Спасибо за ответ!
Да не было никакого обучения по написанию документации. Берешь и пишешь, формате мануала + приказа по компании. ЧТо если юзер оставляет документы не на сетевом диске а на локальной машине, винт умирает и документы профуканы — виноват юзер. дальше уже докладная руководству, что Вася пупкин приказ не выполнил и пролюбил контракт на миллион вместе с ноутом в поезде и блабла…
Чертовски приятно ощущать победу над хаосом. У меня альтернативная история, когда добавляется ещё один элемент, начальство с не очень логичными идеями. Когда стало понятно, что бессмысленно бороться с глупостью, была создана параллельная ситема, работающая система. Все были счастливы, у нас всё работало, а начальник думал что его методы приносят результат, ну и уволил нашего ведущего инженера. Не замедлительно «была нажата кнопка power», и опять все погрузилось в хаос.
У вас есть отличный опыт построения сети интернет-провадера, в т.ч. опыт решения многих подводных камней этой области. Не думали ли вы организовать свой бизнес? Найти местность, куда не добрались еще крупные игроки рынка, оценить возможные доходы, оценить расходы на развертывание сети и подключение абонентов, собрать команду инженеров-единомышленников (возможно из места текущей работы) и стать игроком телеком-рынка.
Мне Ваша работа нравится. Можете ли Вы сообщить регион и уровень оплаты (можно в личные сообщения)?
Я так понял у Вас используется PPPoE? Но если есть привязка к порту может тогда обойтись DHCP — тогда подключение абонента ещё более ускорится.
Я так понял у Вас используется PPPoE? Но если есть привязка к порту может тогда обойтись DHCP — тогда подключение абонента ещё более ускорится.
зачем pppoe когда на каждого абонента свой vlan
Просто по мак адресу назначается ip через dhcp и всё.
В России такой способ подключения назвали IPoE
Просто по мак адресу назначается ip через dhcp и всё.
В России такой способ подключения назвали IPoE
Ну да, это я и имел в виду. А что если у клиента несколько компьютеров (вот я во что только кабель провайдера (PPPOE) не пихаю — настраиваю разные компы. Каждый раз звонить провайдеру и просить поменять настройки на новый МАС?
решается установкой роутера ;)
А доблестная компания Комстар (ныне МТС) использует PPPoE, но при этом еще и привязку по MAC-адресу. Так что там двойной трындец. Уже 4-й роутер меняется. Просто перепрописываем MAC-и с первой железки уже несколько лет.
Но недавно пришлось купить (прости Господи) АПКШ-Континент, а у него, вот черт его так, нельзя перепрописать MAC на портах. Так вот смена привязки MAC-а к порту для юриков — тот еще писец…
Согласен что привязка к MAC-у — зло.
Но недавно пришлось купить (прости Господи) АПКШ-Континент, а у него, вот черт его так, нельзя перепрописать MAC на портах. Так вот смена привязки MAC-а к порту для юриков — тот еще писец…
Согласен что привязка к MAC-у — зло.
Т. е. притащил домой ноут с работы — воткнул, не работает? Надо звонить, объясняться, привязывать новый мак? А если это случилось ночью? Сколько времени я должен потратить, что бы оно заработало?
Говорите, кол-во обращений в техподдержку уменьшилось? Первый бы от вас сбежал как клиент. Нормальная схема только одна — пользователь подключил шнурок — все заработало. Порт девайса = то, что авторизует пользователя и только он.
Нормальный подход тут был бы с 82 опцией дхцп. Пользователь получил ип — знаем с какого порта, какой-бы ип не был получен, трафик посчитаем нужному абоненту. Пользователь не получил ип авторматом? Выставил вручную, еще что-то? Сеть у него не заработала.
Говорите, кол-во обращений в техподдержку уменьшилось? Первый бы от вас сбежал как клиент. Нормальная схема только одна — пользователь подключил шнурок — все заработало. Порт девайса = то, что авторизует пользователя и только он.
Нормальный подход тут был бы с 82 опцией дхцп. Пользователь получил ип — знаем с какого порта, какой-бы ип не был получен, трафик посчитаем нужному абоненту. Пользователь не получил ип авторматом? Выставил вручную, еще что-то? Сеть у него не заработала.
Когда врежутся в подъезде к вашему шлангу — посмотрим как запоёте.
И чо будет в схеме автора? Что мешает врезавшемуся мак юзера использовать?
ничего. просто говорю что порт девайсе != авторизации.
к тому же, есть вероятность получить один мак на разных портах (пришел к соседу через стенку) = геморрой.
к тому же, есть вероятность получить один мак на разных портах (пришел к соседу через стенку) = геморрой.
Это замена авторизации, замена отжившим или уже изживающим себя пптп и пппое. Так большинство нормальных провайдеров сегодня работает. Часто вообще влан на пользователя + белый ип. «А мужики-то и не знают» ©
Если влан на юзера — никакой проблемы с одинаковыми маками для нормального железа (IVL, а не SVL реализация).
Да, и к слову. Если с моего шланга пентагон ломать не будут или едро в блогах поливать, что мне в итоге? Я больше заплачу? Неприятно, согласен. И? У вас помегабайтный тариф?
я так понял про эту опцию — коммутатор передаёт (dhcp-relay) DHCP-серверу запрос от клиента, добавив в него(запрос) параметры для опции 82?
xgu.ru/wiki/%D0%9E%D0%BF%D1%86%D0%B8%D1%8F_82_DHCP
опция протокола DHCP, использующаяся для того чтобы проинформировать DHCP-сервер о том, от какого DHCP-ретранслятора и через какой его порт был получен запрос. Применяется при решении задачи привязки IP-адреса к порту коммутатора
опция протокола DHCP, использующаяся для того чтобы проинформировать DHCP-сервер о том, от какого DHCP-ретранслятора и через какой его порт был получен запрос. Применяется при решении задачи привязки IP-адреса к порту коммутатора
В нашей сети используется «несуществующая» технология IPoE (ниже объясню)
Кстати, на Хабре были статьи, затрагивающие, в том числе, IPoE и DHCP Option 82, в частности, вот:
habrahabr.ru/post/108453/
Так вот, при подключении ранее незарегистрированного оборудования (мак не совпадает), клиент получает «левые» настройки и, при выходе в интернет, видит страничку с сообщением что оборудование незарегистрировано, код регистрации, наш телефон и краткую инструкцию, дополнительно выводятся текущие IP и MAC-адреса. Достаточно, например, позвонить и оставить заявку на перепривязку оборудования, назвав номер договора, фамилию и код регистрации. Естественно, если настройки прописаны вручную, то клиент странички не увидит.
Часто спасает если кто-то переехал в квартиру где уже есть наш кабель или кому-то просто нужно подключить новый/роутер.
Естественно, сеть поделена на сегменты, выдающиеся настройки разные, коды регистрации тоже. Так, переехав с одного сегмента в другой, старый клиент тоже будет получать страничку о необходимости регистрации и потребуется перепривязать мак в другой сегмент.
В принципе, перепривязку оборудования тоже можно автоматизировать.
Кстати, на Хабре были статьи, затрагивающие, в том числе, IPoE и DHCP Option 82, в частности, вот:
habrahabr.ru/post/108453/
Так вот, при подключении ранее незарегистрированного оборудования (мак не совпадает), клиент получает «левые» настройки и, при выходе в интернет, видит страничку с сообщением что оборудование незарегистрировано, код регистрации, наш телефон и краткую инструкцию, дополнительно выводятся текущие IP и MAC-адреса. Достаточно, например, позвонить и оставить заявку на перепривязку оборудования, назвав номер договора, фамилию и код регистрации. Естественно, если настройки прописаны вручную, то клиент странички не увидит.
Часто спасает если кто-то переехал в квартиру где уже есть наш кабель или кому-то просто нужно подключить новый/роутер.
Естественно, сеть поделена на сегменты, выдающиеся настройки разные, коды регистрации тоже. Так, переехав с одного сегмента в другой, старый клиент тоже будет получать страничку о необходимости регистрации и потребуется перепривязать мак в другой сегмент.
В принципе, перепривязку оборудования тоже можно автоматизировать.
В таких ситуациях нормальные люди покупают роутеры и подключают мобильные устройства через них…
Чем валить в кучу разрозненную инфу про поля биллинговой базы и прекрасное оборудование длинк можно было б сделать хотя б элементарный обзор, как без впн можно авторизовать, какие дизайны существуют и почему выбран именно тот, который описан (один из самых дурацких).
Good job
У нас была в университете точно такая же история 4 года назад, когда пришлось фактически заново создавать сеть студенческого городка. Теперь все четко и красиво.
Единственное, не ясно как и кому продать сеть. Я бы продал небольшую в Одессе.
Автор молодец — проект интересный и достаточно обширный по кругу решения задач.
Комплекс п/о для таких вещей тоже должен неплохим получиться.
Комплекс п/о для таких вещей тоже должен неплохим получиться.
Было бы неплохо дополнить пост основными количественными показателями: сколько абонентов, сколько и каких девайсов и т.п.
Работаю администратором небольшого провайдера. У нас клиенты также подключаются по VPN (pptp). С коллегами не так давно обсуждали уход от pptp в сторону выдачи статического ip-адреса и привязки его к порту коммутатора. Нашли два приемлемых варианта: коммутаторы DLink c их ip-mac-port binding и HP V1910G c Arp-management (та же возможность привязки ip-mac-port). И по ценам очень приятно оказалось.
Простите, а чем IPoE на основе dhcp relay с Option 82 + address binding не подошел? Привязывать маки какой смысл? Сегодня абонент воткнул в порт стационарник, завтра сгорела сетевая — поменял, послезавтра ноутбук, потом роутер или еще чего и каждый раз ему придется звонить вам, тратить свое и ваше время для изменения настроек (Это не говоря про некоторые чудо-роутеры, которые при каждом ребуте генерят себе новый мак). А так изолируем порты, поднимаем 82 опцию и все, абонент привязан к айпишке и пусть в порт втыкает что хочет, с другой айпишкой порт работать не будет, на другом порту эта айпишка работать не будет, никаких гемороев с привязками, воткнулся в порт и все заработало.
В нашем случае (десяток студенческих общежитий) такой фокус не пройдет — начнется содом и гоморра. В складчину половина этажа через подключение одного это самое нормальное что мы видели, когда оборудование было частично «тупым».
Простите, а кто им виноват, что студенты хотят шары.
И чем привязка по маку помешает? Ставим роутер и продолжаем раздавать интернет на пол общаги, заметьте с одного мака. При этом вы создадите себе не слабый геморрой с учетом всех маков, а банальная смена сгоревшего коммутатора будет требовать не тривиальных действий, при этом сменить мак для понимающего человека — дело 30 секунд, хотя может я чего не понимаю. Если не секрет какое ориентировочно количество абонентов в вашей сети?
В случае без привязки Вы даже не заметите, что на том конце провода сменился клиент.
Какой геморрой может быть, если биллинг строился с моделью жесткой связки клиент-порт-mac-ip?
Увы секрет =)
Какой геморрой может быть, если биллинг строился с моделью жесткой связки клиент-порт-mac-ip?
Увы секрет =)
Смена коммутатора — наипростейшая задача. Чтобы заменить коммутатор — еще нужны основания. Это раз. У 45% оборудования уже сейчас установлено бесперебойное питание, случаи с заменами крайне редки — на 100 коммутаторов 1 меняем не чаще чем раз в полгода. Это два. Монтажник едет с распечаткой — кто в каком порту, поэтому переброс с одного коммутатора на другой проходит без проблем. Это три. Геморрой — это вам так кажется. На самом деле все прекрасно, главное правильно к вопросу подойти.
видимо Вы промахнулись веткой
В датацентре и в идеальных условиях именно так. И даже в описаном вами случаи идеальных условий 100 комутаторов 1 раз в пол года, 10 000 коммутаторов — это 100 в пол года или 16 в месяц, или же через день. Опять же на 100 коммутаторов ставить 45 упс, не проблема, на 10К уже вопрос, везде ли по городу его получится поставить и не придется извращаться с PoE. Монтаж едет с распечаткой это понятно, но при смене коммутатора меняется его мак, что тянет за собой перепривязку в биллинге минимум 20 абонентов, в случае vlan per user виланы последней мили тоже надо указать ручками (хоть до коммутатора они по gvrp дошли), вписать в нужные кольца STP и т.д. Когда мне кажется, я гуглю, а тут у меня более 50К юзеров (не столица и многоэтажки) и разрозненные сети из кучи вендоров и технологий авторизации и я знаю что говорю. Даже внедрение ERP систем не спасает от проблем, когда сгорает свич, например, в выкупленом сегменте сети, где просто нет данных кто в каком порту и монтажник вместо распечатки пол дня по проводам лазит и забивает базу, когда гроза выбивает целый квартал с железом, запитанным по PoE и протянутым по воздушке, про оставшиеся «медные» районы я не говорю. Очень завидую Вам, что все так просто и на автомате, но не у всех и не всегда именно так.
И даже в описаном вами случаи идеальных условий 100 комутаторов 1 раз в пол года, 10 000 коммутаторов — это 100 в пол года или 16 в месяц, или же через день. Опять же на 100 коммутаторов ставить 45 упс, не проблема, на 10К уже вопрос, везде ли по городу его получится поставить и не придется извращаться с PoE. Монтаж едет с распечаткой это понятно, но при смене коммутатора меняется его мак, что тянет за собой перепривязку в биллинге минимум 20 абонентов
1. В-основном меняются DES 3200-10 на что-то 24-х портовое, а не по факту выгораний.
2. Вы что-то путаете. Смена коммутатора — это смена коммутатора, и только. Кстати производится под абсолютно полным контролем — поле mac адрес в БД, где хранятся устройства — с атрибутом unique, и zabbix эту информацию проверяет. Есть система контроля оборудования — начиная от самописной веб-морды, с помощью которой производятся нужные операции и заканчивая триггерами в самой бд. Каждый чих пишется в лог:
дата время: Такой-то сотрудник пометил порт у такого-то устройства (mac устройства), как сгоревший;
дата время: Такой-то коммутатор отправлен со склада туда-то. Причина такая-то. Провел такой-то;
дата время: такой-то коммутатор заменен на такой-то коммутатор. Причина такая-то. Провел такой-то;
Зачем делать перепривязку 20 абонентов в биллинге?
1. У нас по факту выгоряний или сбоев в работе.
2. Не путайте инвентаризацию с биллингом, у вас zabbix тарифные планы абонентам назначает, если да то скажите как? Предположим использована схема авторизации по IPoE как биллинг в вашем случае узнает что Иванов Иван Иванович теперь подключен к свичу в маком 00:00:00:00:00:07 а не 00:00:00:00:00:05? Заббикс вам только напишет что у коммутатора xxx.xxx.xxx.xxx сменился мак и занесет его в свою базу, автоматизировать перепривязку абонентов на основе мониторинга — пробовали, любая ошибка оператора в настройке IP свича становится плачевной, если у вас операторы не ошибаются, продайте нам пару этих роботов. Такой-то коммутатор отправлен со склада туда-то, ага именно так в идеальном мире с розовыми единорогами, а по практике выбило район приехала машина забрала 20 коммутаторов и уехала менять, а вот какой куда конкретно попадет загадка для всех. Ладно мы от темы поста отошли очень, предлагаю завершить офтоп.
2. Не путайте инвентаризацию с биллингом, у вас zabbix тарифные планы абонентам назначает, если да то скажите как? Предположим использована схема авторизации по IPoE как биллинг в вашем случае узнает что Иванов Иван Иванович теперь подключен к свичу в маком 00:00:00:00:00:07 а не 00:00:00:00:00:05? Заббикс вам только напишет что у коммутатора xxx.xxx.xxx.xxx сменился мак и занесет его в свою базу, автоматизировать перепривязку абонентов на основе мониторинга — пробовали, любая ошибка оператора в настройке IP свича становится плачевной, если у вас операторы не ошибаются, продайте нам пару этих роботов. Такой-то коммутатор отправлен со склада туда-то, ага именно так в идеальном мире с розовыми единорогами, а по практике выбило район приехала машина забрала 20 коммутаторов и уехала менять, а вот какой куда конкретно попадет загадка для всех. Ладно мы от темы поста отошли очень, предлагаю завершить офтоп.
Все же отвечу. Но продолжать действительно не будем. «Роботы» не ошибаются, как писал foxmuldercp, регламент, регламент и еще раз регламент. Проблемы с грозами — что-то ужасное. Хорошо, что пережили. Нет, действительно. Когда выдернули родное питание и заменили на альтернативное с аккумами проблемы с грозами исчезли. Есть же статистика. Заббикс вообще в этой ситуации не причем. Он только даст нам знать, что какой-то засранец выставил коммутатор без документирования. В биллинге есть ip коммутатора, порт абонента, mac абонента, ip абонента. Конфиги на коммутаторы улетают автоматом. И если будет нарушен цикл подготовки коммутатора — то конфиг он не получит. И работать никто не будет. Предварительный конфиг заливается еще в офисе, генерируем тоже скриптом, для единства конфигурации. Окончательный конфиг заливается автоматом, когда коммутатор появляется в сети. Привязки абонентов обновляются при перебросе абонента с порта на порт, при изменении mac-адреса абонента, при изменении ip-адреса абонента, при указании порта сгоревшим.
Все аналогично, и конфиг базовый залетает автоматом в момент первого включения на техплощадке и на месте почти все (кроме сложных структур STP) автоматизированно, только маки мы не контролируем, отдаем абоненту порт а что он туда втыкает — его личное дело. Вот интересно чисто для себя, зачем вам маки абонентов? Да и какой биллинг используете, я сейчас хочу уходить от UTM5 (сложно дорабатывать) и nodeny (нельзя выдавать динамический адрес) в своих сетях, вот подбираю решение, чтоб подошло для разных структур, если не затруднит — в личку, чтоб не захламлять тему.
Да и с привязкой, если человеку нужно — вы ничего не заметите, большинство роутеров прекрасно прошивается альтернативными прошивками, в базовом функционале которых есть смена мака на wan порту. Но тут кому что нравится. У меня в сетях были следующие этапы: авторизатор, привязка только мак, PPPoE (на нем 2 сети, обслуживающие много частного сектора до сих пор), IPoE (как Vlan per user так и Opt82+address binding) что выбрать очень зависит от структуры сети, железа в наличии и еще кучи факторов. Когда вся сеть строится исключительно по многоэтажкам, где есть техэтажи, есть возможность нормально поставить ящик со свичем и ups — это 1 вариант, когда это частный сектор, сеть чисто воздушка и низкие столбы, на которых даже ящик не повесить нормальный, не то что UPS поставить — это совсем другой вариант (питание по PoE, куча меди и гроза выжигает целые районы). У вашей схемы всего 1 минус, техподдержка задолбется при количестве абонентов более 2К.
pon решает проблемы частного сектора раз и навсегда. И что мешает дать служебный тарифный план абоненту в частном секторе и разместить ящик с коммутатором у него? Тут либо портянка медиаконвертеров в комплекте либо коммутатор с sfp-портами. Если вы пишите про мою схему, то у несколько десятков тысяч абонентов, проблемы у тех.поддержки исчезли, как только эту схему разработали, допилили и внедрили. Надо сказать, что пришлось не просто попотеть — в свое время отказался от всех шабашек и ушел с головой в работу.
Сейчас внедряем pon на последнюю милю, очень со скрипом идет, хорошо если за пару лет закончим. Ящик с коммутатором у абонента решение, но мы теряем доступ к нему 24х7, вот из практики: ящик на чердаке абонента, у абонента халявный интернет все счастливы и довольны, абонент как любой нормальный человек летом берет отпуск и укатывает на 2 недели отдыхать (телефон вне доступа), по закону Мерфи на второй день после отъезда что-то случается с коммутатором(не помню уже что), доступ к дому есть у бабушки-цербера, которая приходит кормить псину и про интернет знает, что это творение дьявола и крестится при любом упоминании, оставить сотню близлежащих абонентов на 2 недели вез сети (резервирование на этот сегмент еще не завели)? Экстренно на столбах делается какое-то подобие ящика, варится и ведется новая оптика и т.д. за срочность выходят затраты как заново перетянуть район — в этой сети этот ящик был последний, стоящий у абонента. У меня ни одна сеть, а несколько, с разным руководством и разными взглядами на развитие, где готовы развиваться и менять структуру, там тоже все гуд, а вот где руководствуются принципом, зачем вкладывать деньги если и так пока все работает, там печально. О чем мы спорим, тут разные ситуации, я просто говорю что не везде и не всегда все идеально, есть автоматизация и передовые решения, как говорится случаи разные бывают, за вашу сеть только рад, если у вас все хорошо и нет проблем.
Чем это её задолбают? Абонентов уже больше 2к и ничего 1.5 человека справляется
Заведите себе книгу жалоб и предложений онлайн без права модерирования ТП, узнаете много нового от абонентов которым нужно было срочно поменять железку у себя. Сам попал в ситуацию, когда пошел помочь знакомым с новым компьютером, а они подключены к сети, админа которой и руководство я не знаю. После 20 минут слушания музыки на номере СТП, а потом объяснения еще 15 минут что я хочу, зачем мне менять мак, называния всех реквизитов, контрольных слов и прочего автоматически записал всю компанию, ее руководство, админа и ТП к сексуальным меньшинствам и на все дальнейшие вопросы любых знакомых или знакомых-знакомых к какой сети подключиться в том районе, говорил к любой, кроме %company_name%
Все зависит от того, как организовать этот процесс. Уверяю Вас это можно сделать нормально.
Ок у вас полтора человека, вам позвонило 3 абонента, первые 2 попали к операторам 1 висит в очереди, при этом первые 2 абонента совсем «не в теме» и решение проблемы по телефону затягивается, третий которому срочно надо поменять mac (вот прямо сейчас) слушает музыку и матюкает вас и вашу ТП. И тут не проблема операторов, они могут быть профессионалы и лучшие люди в городе, не проблема первых 2х абонентов, они дозвонились и их проблему сейчас решают, а вот третий, который в теме, точно знает что ему надо, но вынужден висеть на линии, смотреть на часы и желать вам всевозможных кар, вопрос зачем, если этого можно избежать. Вот зачем вам мак абонента?
Как клиент я хочу сказать большое «фи» всем, кто привязывает абонента по MAC'у. А если я железки разные в сеть тыкаю? Дали порт, разрешили/дали IP, усё.
Пока что не встречал абонентов, у которых есть множество различных железок, и нет денег на роутер. И дело даже не в привязке к mac-адресу — это как надо себя не любить, чтобы не лениться лазить под стол, и кабель то в один компьютер тыкать, то хватать этот кабель и тащить его к другому компьютеру. А как же быть с планшетами и трубками? Сплошной геморрой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сказ о том, как мы абонентов к портам привязывали