Таблиця лідерів

На віджатому обладнанні й повинно погано процювати. Стрибайте та підтримайте краще місцевого провайдера, який процював до 2014 року на ринку.

SFP сдох.

Sh int bri Sh ep op int epo 0/5 Conf Int epo 0/5 Shu No shu Повторно sh команды

D njxre/ Переведете сами с английской раскладки.... все эти тендеры все гавно на палочке, сцука делаем инет в одном селе, так сказать. Его скорее всего лет через 20ть не будет на карте, но сцука деньи из бюджета выделены на инет, делаем норм, 30мбти задача. Подали более по радиомосту, не на камбЕ. В селе, чтоб вы понимали, школа самое модное заведение, вокруг 30ть хат на хуторе. Какой там нах камбиум и т.д. там этого камбиума хватит чтоб все село покрыть (в убыток), и даже тупо омнитика хватит. А деньги то уже выделены, можно построить дешевле,но сцука выделены, нужно потратить, ибо сцука осень, нужно отчитаться. Короч гавно, попробовал раз, больше не окунусь в эти тендеры ни коркой..... п.с. ИМХО камбиум для попила бабла нормальная тема, Хто хочет участвовать... пожалуйста... . Не представляю себе школу, где сцуко нужен бесшовный роуминг для 500-т человек.. это сюрр. Нах вобще детям вайфай в школе. Пускай учат матчасть, Вон в Англии недавно признали Совдеп систему образовния лучшей и переходят на нее, сцылко нету, но вроде как факт, нах вайфай, пускай локти грызут. В Европе даже такого не замечал, чтоб халявный вайфай в бесшовном роуминге... лучше б в аэропортах сделали, и то не особо нужно................ Вообще ваш бесшовный роуминг никому нах не впался.... или вы как троль какой-то постоянно в трансляции весите. СТРИМИТЕ с утра до ночи. ...в типа por*hub.com п.п.с. Я б вообще тендеры для нашей страны отменил, потому-что народ очень быстро оптимизировался на "освоение" этих тендерв.

Ну если не поддерживается, то и ладно, можно без него. Я в свое время взялся писать софт под провайдера, с академической целью убрать максимально человеческий труд, там где он не нужен. Давно придумал схему, в которой офис для клиента совсем не нужен, реализовал. Но, похоже, никому "оно не надо". Или просто я плохо доношу свою мысль до коллег. Option 82 была придумана вообще, как механизм защиты от атак на DHCP из untrusted segments. Ну, поскольку она стала удобной для работы в крупных сетях, в том числе и провайдерской, то почему бы ее не использовать. Есть несколько схем ее использования. Та схема, которую многие считают единственной, выглядит примерно так: Монтажник, подключив розетку клиента, записал на кусочке мятой сигаретной пачки (условно) физический адрес, куда он его подключил. После этого он приходит в офис (условно) и сообщает оператору, куда подключен клиент. Оператор, заключив с клиентом договор, заносит параметры подключения в виде той самой опции 82, в профайл клиента, которые реализуются в виде настроек dhcp сервера. Возникает вопрос - вам больше нечем заняться, что бы таскаться туда-сюда с ручной работой. Компьютеризация (или, как модно говорить, диджиитализация) заключается не в наличие компьютеров и серверов, а в отсутствии "бумажной" работы. Если раньше человек что-то записывал в журнал, карточку, тетрадку, а потом поставили компьютер, он начал набивать туда - то это не "электронный документооборот", это та же бумажная технология. А вот если человеку поставили компьютер, и его услуги стали не нужны - это уже оно - диджитализация. В схеме, которую я реализовывал, монтажник тупо подключает розетку клиента к сети... и все. Уходит дальше работать. В этой схеме option 82 применяется только для одной функции - идентификации порта, к которому подключен клиент. Клиент заходит на портал со своими кредитами, система регистрирует ресурс клиента за его профайлом. DHCP сервер выдает лизы по mac/duid, хранит эти лизы по mac/duid. Лепить политику выделения пула по option 82 - дурацкая идея. Вместо этого ставится парсер dhcp пакетов (в любом варианте - dhcp-cap, dhcp-log). Парсер регистрирует автоматически выданные ip адреса за физическим адресом подключения, и заносит это дело в реестр биллинга. Все "ручные" (или "бумажные") технологии базируются на том, что монтажник/оператор/администратор изначально "где-та бирут" данные о физическом подключении клиента. Вот это "где-та бирут" - совершенно не нужные затраты и средств и добавление ненадежности в виде человеческого фактора. В "типичной" схеме с option 82 точно так же надо "где-то брать". Тут у меня подопечный провайдер месяц назад подключал пон сеть, принес в базу биллинга список из нескольких тысяч MАC адресов онушек. Спрашиваю - как будете узнавать, у кого какая онушка стоит? Говорит - у нас записано... В схеме vlan-per-user та же система. Монтажник впихнул клиента, "куда попало", и пошел домой. Клиент подключился, залогинился в портале, портал "посмотрел" по option 82, откуда клиент пришел, зафиксировал vlan за клиентом, и никому ничего не надо заранее на сигаретной пачке записывать. Хотя, эту схему можно и без option 82 реализовать, если есть преконфигурация vlan/ip-pool. Написал, наверно, длинно и бестолково. Если добавить сюда самостоятельную регистрацию клиента в биллинге, то надобность в офисе как бы и отпадает.