Внедрение ipv6 в маленькую сеть!

[Dimkers 1 600]

@KaYot
 А есть возможность сделать замер, запустив что-то, грузящее проц? В идеале пустить через него трафик и сказать к примеру - жрет при 5Г 80Вт.

[Baneff 149]

40 минут назад, Dimkers сказал:

@KaYot
 А есть возможность сделать замер, запустив что-то, грузящее проц? В идеале пустить через него трафик и сказать к примеру - жрет при 5Г 80Вт.

Ну вот, к примеру. Реальный двухголовый сервак, сильно нагруженный днём и слабо нагруженный ночью. Это не форвардер. Это сервак "всё в одном" мелкого провайдера, там много кое чего крутится, потому нагруженный. Ну и вот. Одноголовый форвардер онли будет конечно жрать меньше, но не 60Вт. Кто-то может возразить реальными замерами на реальном оборудовании?

[Dimkers 1 600]

У меня на брасе стоял ксенон e2-1275 v3. Около 90Вт на 2.5Г было.

[KaYot 3 708]

Мой последний пост в отношении серверов и потребления, не вижу смысла объяснять примитивные вещи.

График с моего БРАСа HP DL380 G6 - 12 ядер, 16GB, 2xHDD 7200 SAS, рейд с кешем и батареей - топовый когда-то сервер расчитанный больше на файлопомойку чем на роутеры.

186Вт в пике.

Dell замерить сложнее, в IPMI питание не мониторится. Чисто глазуально - выхлоп у него на порядок холоднее и слабее чем у рядом стоящего HP G6.

А трафик молотят одинаково.

 

300+Вт может жрать очень старое кривое говно, какой-то opteron поколения athlon64 или xeon на пентиум-4.

О чем и начался разговор на прошлой странице. Не используйте такое железо в провайдинге, это жлобство.

 

 

P.S. зашел и на соседний БРАС, такой же сервер только без ненужных рейдов и с 1 CPU

Трафика оба пропускают одинаково, до 3Гбит(полное резервирование), в момент падения соседа тоже никакого окукливания нет.

Походу пойду сниму лишнюю голову, толку от нее в роутинге никакого.

Изменено 2019-10-15 15:21:26 пользователем KaYot

[Dimkers 1 600]

53 минуты назад, KaYot сказал:

Мой последний пост в отношении серверов и потребления, не вижу смысла объяснять примитивные вещи.

Все круто и классно, но есть нюанс! Ты сам сказал что жрет оно 80Вт. Ну вот и хотелось бы глянуть в реале так сказать. Для объективной картины.

53 минуты назад, KaYot сказал:

График с моего БРАСа HP DL380 G6 - 12 ядер, 16GB, 2xHDD 7200 SAS, рейд с кешем и батареей - топовый когда-то сервер расчитанный больше на файлопомойку чем на роутеры.

186Вт в пике.

Да, де то так и выходит брасом и у меня, но разговор о твоем R210.

53 минуты назад, KaYot сказал:

Чисто глазуально - выхлоп у него на порядок холоднее и слабее чем у рядом стоящего HP G6.

А трафик молотят одинаково.

Ну всеж хотелось бы таки данные по точнее, а не пальцем по ветру.

53 минуты назад, KaYot сказал:

Трафика оба пропускают одинаково, до 3Гбит(полное резервирование), в момент падения соседа тоже никакого окукливания нет.

Походу пойду сниму лишнюю голову, толку от нее в роутинге никакого.

Это все да, но. Что меня не прельщает в R210 - один БП. Ну например когда стойка с гарантированным 48В и приходится костылить преобразователь 48->220. А инвертора, сука, имеют свойство дохнуть. При чем в самый важный момент. А так себе 1 БП кинул через преобразователь-упс, другой БП - в грязную розетку. Благо HP умеют балансить. Отсох БП - алярм. Поехал и посмотрел шо к чему.

Ну и напарить на файлопомойку НР можно, виндузятникам под ВИН_серв. А 210-й кому нах нада? Ни помойки с рейдами не сколотить нормальной, нифика кароче, чисто под какоую-нить вмсферу\майнинг\ресурсные вычисления. Что в нынешнем свете - такое себе.

ИМХО.

Изменено 2019-10-15 15:37:07 пользователем Dimkers

[NiTr0 584]

7 часов назад, KaYot сказал:

КПД современных БП работающих с небольшой нагрузкой(порядка 50% от максимальной) очень высок, процентов 90. Да и маршрутизатор свой TDP скушать с веростяностью 100% никак не сможет, математики там мизер, и она вся целочисленная. Итого сервер в сборе вполне может кушать 60Вт.

dell r210 первого поколения кушали 120 Вт что ли под нагрузкой, или даже 150... в простое - ватт 60. это с парой винтов, при том что там тоже ничего особо греющегося не было.

тут конечно поменьше кушать будет, но не думаю что 60Вт (разве что в простое). ну и явно не 200-300 (это 2-головые лга1366 столько кушают).

[pashaumka 33]

В 13.10.2019 в 11:38, Baneff сказал:

А в чём проблема с IPoE на FreeBSD? Accel-а нету, да. Был бы - было бы проще. Но менять ради этого ось на системе, которая более двадцати лет работает как-то лень. Какая ось лучше - спорить не будем, есть то что есть. Телефон поддержки тоже беспокоит крайне редко. Но это всё касаемо ipv4. А вот какие грабли вылезут при внедрении ipv6 пока непонятно. Но будем пробовать потихоньку.

так просто расскажите, на чем это реализовать..  Тазик свободные есть - попробую

[vop 370]

7 hours ago, pashaumka said:

так просто расскажите, на чем это реализовать..  Тазик свободные есть - попробую

 

Под freebsd есть rtadvd и dhcp. Я не пробовал их. Попробуйте, расскажите - будет интересно людям.

 

PS Или времена, когда  народ делился опытом ушли в старину, и теперь не принято?

[Baneff 149]

2 часа назад, vop сказал:

 

Под freebsd есть rtadvd и dhcp. Я не пробовал их. Попробуйте, расскажите - будет интересно людям.

 

PS Или времена, когда  народ делился опытом ушли в старину, и теперь не принято?

Ну почему не принято, просто тут фришников и не осталось уже почти, не с кем делиться. Я, например, как только прикуплю ipv6 адресов, так сразу и начну делиться

Насчёт rtadvd и dhcp врядли там что-то не будет работать. Больше интересует впишется ли оно нормально в vlan per user и unnumbered ip и будет ли работать arp proxy под ipv6 ? Возможно там вообще всё по другому.

[melvin 66]

1 час назад, Baneff сказал:

просто тут фришников и не осталось уже почти

Остались. Староверов и любителей стабильности хватает.

Мне, лично, будет очень интересно.

[vop 370]

1 hour ago, Baneff said:

Ну почему не принято, просто тут фришников и не осталось уже почти, не с кем делиться. Я, например, как только прикуплю ipv6 адресов, так сразу и начну делиться

 

Я когда-то пытался делиться идеями и наработками с авторами биллингов. Но почему-то они воспринимали меня конкурентом, и подозревали подвох. Хотя, в чем он, понять не могли... На общение не шли, и "крутили фиги в кармане".

 

Quote

Насчёт rtadvd и dhcp врядли там что-то не будет работать. Больше интересует впишется ли оно нормально в vlan per user и unnumbered ip и будет ли работать arp proxy под ipv6 ? Возможно там вообще всё по другому.

 

Ну как сказать? Ну, немного по другому.

1. В ipv6 нет броадкаста. Поэтому раскидывать адреса можно как угодно по одной штуке.

2. В ipv6 unnumbered как бы генетически заложено. Адреса еще биндятся к интерфейсам, но все они в одной куче с lo. Кстати, кто лет 25 назад настраивал на одном сервере slip/ppp и ether, не догадывались, что это называется unnumbered

3. На сабскрайберский линк внешние адреса можно вообще не давать. Да и не нужно. link-local достаточно.  Если это vlan per user - то там вообще с клиентской стороны ставится дефолтный роутинг на fe80::1, а все остальное самонастроится.

 

И последнее, опять же option 82. Готовьте ее правильно.

Изменено 2019-10-16 18:32:09 пользователем vop

[vop 370]

И да, там нет arp, ибо нет broadcast. Соответственно, нет arp proxy, бо не надо.  Есть ndp. Иногда он весьма забавные вещи дискаверит.

[Baneff 149]

9 минут назад, vop сказал:

И последнее, опять же option 82. Готовьте ее правильно. 

Кака-така любовь? (С)

В смысле какая такая option 82 ? Мы люди бедные, о таком только слышали краем уха. Да и зачем при вилан пер юзер оно надо? Только деньги на ветер.

[vop 370]

2 minutes ago, Baneff said:

Кака-така любовь? (С)

В смысле какая такая option 82 ? Мы люди бедные, о таком только слышали краем уха. Да и зачем при вилан пер юзер оно надо? Только деньги на ветер.

 

О! Вот оно. Именно при vlan-per-user оно очень полезно. Ежели, конечно, линейное оборудование умеет рассказывать про option 82.

[Baneff 149]

10 минут назад, vop сказал:

 

О! Вот оно. Именно при vlan-per-user оно очень полезно. Ежели, конечно, линейное оборудование умеет рассказывать про option 82.

В чём польза? Оборудование не умеет, но не важно. Правда не понятно, как можно опшн 82 с пользой прилепить к вилан пер юзер?

[vop 370]

11 minutes ago, Baneff said:

В чём польза? Оборудование не умеет, но не важно. Правда не понятно, как можно опшн 82 с пользой прилепить к вилан пер юзер?

 

Ну если не поддерживается, то и ладно, можно без него.

 

Я в свое время взялся писать софт под провайдера, с академической целью убрать максимально человеческий труд, там где он не нужен. Давно придумал схему, в которой офис для клиента совсем не нужен, реализовал. Но, похоже, никому "оно не надо". Или просто я плохо доношу свою мысль до коллег.

 

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.

 

Написал, наверно, длинно и бестолково.

 

Если добавить сюда самостоятельную регистрацию клиента в биллинге, то надобность в офисе как бы и отпадает.

 

[Baneff 149]

27 минут назад, vop сказал:

 

Ну если не поддерживается, то и ладно, можно без него.

 

Я в свое время взялся писать софт под провайдера, с академической целью убрать максимально человеческий труд, там где он не нужен. Давно придумал схему, в которой офис для клиента совсем не нужен, реализовал. Но, похоже, никому "оно не надо". Или просто я плохо доношу свою мысль до коллег.

 

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.

 

Написал, наверно, длинно и бестолково.

 

Если добавить сюда самостоятельную регистрацию клиента в биллинге, то надобность в офисе как бы и отпадает.

 

Так это реализовано у Киевстара. Если свичи поддерживают опшн 82, то зачем тогда вилан пер юзер? Зачем нужно и одно и другое одновременно? DHCP сервер выдаёт лизы в соответствии с номером вилана откуда пришёл запрос. Каждому порту приписывается свой вилан. Один юзер - один порт - один вилан - одна лиза. Зачем здесь опшн 82? Просто шоб было? Так оно денег стоит немалых. Одно дело свич от которого требуется только поддержка виланов и совсем другое - свич поддерживающий опшн 82 на портах. Моя твоя не понимай!

[vop 370]

16 minutes ago, Baneff said:

Так это реализовано у Киевстара. Если свичи поддерживают опшн 82, то зачем тогда вилан пер юзер? Зачем нужно и одно и другое одновременно? DHCP сервер выдаёт лизы в соответствии с номером вилана откуда пришёл запрос. Каждому порту приписывается свой вилан. Один юзер - один порт - один вилан - одна лиза. Зачем здесь опшн 82? Просто шоб было? Так оно денег стоит немалых. Одно дело свич от которого требуется только поддержка виланов и совсем другое - свич поддерживающий опшн 82 на портах. Моя твоя не понимай!

 

Наверно я плохо описал, зачем. Для идентификации подключения клиента. optiоn 82 замечательно идентифицирует как порт подключения, так и vlan.

 

В природе есть два способа идентификации физического подключения:

1. Монтажник записал на сигаретной пачке.

2. Клиент ввел свои id/secret.

 

Других, как бы не существует. В первом случае 82-ю опцию часто используют для определения политики выбора пула в dhcp. Как и vlan. Тут действительно или vlan или opt82. Одновременно они не нужны. Нужно только заранее знать, кому принадлежит порт, или vlan. Но это "ручная бумажная технология". Во втором случае можно и vlan с opt82. А можно вообще без того и без другого. Ибо и то, и другое - надстройка над dhcp сервером, который ВСЕГДА выдает лизы по duid. У меня в маленькой тестовой сети клиенты напрямую регистрируются по duid'у, а dhcp тупо выдает ip без всякой классификации политик.

 

PS Я там писал, что знаю 2 (или 3) провайдера, где реализована идентификация клиента. И Киевстар - один из них.

Изменено 2019-10-16 20:42:39 пользователем vop

[Baneff 149]

В КС второй вариант. Когда первый раз подключаешься с новым МАС-ом, то нужно вводить номер договра и пароль. Далее система уже запоминает откуда пришёл запрос. Правда непонятно, зачем тут ещё и привязка к МАС-у, если уже и так понятно на каком порту сидит юзер и свич исправно рапортует о запросах с этого порта с помощью опшн 82. Но им виднее зачем, факт налицо - каждый раз при подключении нового устройства требует регистрации.

И, кстати, не вижу ничего плохого во втором варианте, юзер должен знать свой номер договора и один раз при включении вполне себе может зарегистрироваться. Или монтажник за него зарегистрируется и не понадобиться записи делать на пачке сигарет. Дальше уже юзер может подключать что угодно - порт известен и вилан известен, какую лизу выдавать понятно, привязка к МАС-у не нужна. Проблема, правда, если свич приходится менять или порт включения юзера. Грозы, знаете ли, никого не щадят

А duid - это наверное прекрасно, но это же фишка ipv6 только, нет?

[vop 370]

50 minutes ago, Baneff said:

В КС второй вариант. Когда первый раз подключаешься с новым МАС-ом, то нужно вводить номер договра и пароль. Далее система уже запоминает откуда пришёл запрос. Правда непонятно, зачем тут ещё и привязка к МАС-у, если уже и так понятно на каком порту сидит юзер и свич исправно рапортует о запросах с этого порта с помощью опшн 82. Но им виднее зачем, факт налицо - каждый раз при подключении нового устройства требует регистрации.

 

Немного странно. У меня такая процедура потребовалась в Киевстаре только один раз, когдау них "паламался" свич, и они меня переткнули в другой.

 

MAC (DUID) нужен всегда, так-как это основной id, на котором работает dhcp. Если порт висит в воздухе, то при подключении устройства DHCP выдает неизвестному MAC'у  свободный адрес из пула (зачем его потом менять - неизвестно). Потом смотрит, на каом порту висит этот мак по opt82. И только после того, как клиент ввел свои кредиты, порт "закрепляется" за клиентом, и в дальнейшем все другие маки, пришедшие с этого порта, будут числиться за этим клиентом. Но изначальный ip выдан изначальному маку по лизе.

 

Quote

И, кстати, не вижу ничего плохого во втором варианте, юзер должен знать свой номер договора и один раз при включении вполне себе может зарегистрироваться. Или монтажник за него зарегистрируется и не понадобиться записи делать на пачке сигарет. Дальше уже юзер может подключать что угодно - порт известен и вилан известен, какую лизу выдавать понятно, привязка к МАС-у не нужна. Проблема, правда, если свич приходится менять или порт включения юзера. Грозы, знаете ли, никого не щадят

А duid - это наверное прекрасно, но это же фишка ipv6 только, нет?

 

Если лиза выдана, то она выдана уже МАКу. Какой бы влан не приехал, какой бы порт ни прискакал - это уже не имеет значения, так-как уже и политика выбора пула давно отработана, и лиза давно выдана, только продлевается. В этом костыль всех этих "неприродных" способов изначальной привязки политик и заключается. Поменялся порт, крендель зашел к соседу со своим ноутом, и т.д. Все опять начинается с мятой пачки от сигарет.:)

 

duid - это в ipv6. Можно, по большому счету, это назвать mac unnumbered. Ну, в ipv6 решили не привязываться к маку, а придумали замену ему. Но сути это дело не меняет. Хотя, на практике, можно свой мак менять, лиза уже выдана на этот duid, который "в мирное время" всегда остается тем же.

Изменено 2019-10-16 21:54:59 пользователем vop

[sanyadnepr 305]

9 часов назад, Baneff сказал:

свич поддерживающий опшн 82 на портах. Моя твоя не понимай!

Если Вы не в курсе, то dhcp запросы/ответы "перехватывает" и передает коммутатор, во влане управления, dhcp сервера в абонентском влане просто нет.

 

10 часов назад, vop сказал:

В схеме, которую я реализовывал, монтажник тупо подключает розетку клиента к сети... и все. Уходит дальше работать.

 не совсем у Вас диджитализация...кто вводит Адрес, ФИО и т.д., офис ? Есть мнение, для полной автоматизации, эти данные вводит монтажник подключив клиента, после ввода "идентификатора и пароля", они автоматом заносятся в биллинг, а дальше, при смене оборудования, только "идентификатор и пароль".

В целом Ваша схема хороша, но не нова.

Изменено 2019-10-17 05:56:10 пользователем sanyadnepr

[Baneff 149]

2 минуты назад, sanyadnepr сказал:

Если Вы не в курсе, то dhcp запросы/ответы "перехватывает" и передает коммутатор, во влане управления, dhcp сервера в абонентском влане просто нет.

Я не в курсе и не буду в курсе, поскольку, как я уже сказал, оборудование с опшн 82 не используем ввиду его избыточности и цены. Там свичи по 24 порта, а у нас старый город - по 5-8 и очень редко больше юзеров на дом. Зачем в этих условиях ставить 24-ки - не понятно. Разве что чтобы больше кайфа при грозе словить.

А DHCP сервер прекрасно ловит запросы от клиентов на их виланах и выдаёт им их лизы и без этих несомненно крайне полезных опций.

9 минут назад, sanyadnepr сказал:

 не совсем у Вас диджитализация...кто вводит Адрес, ФИО и т.д., офис ? Есть мнение, для полной автоматизации, эти данные вводит монтажник подключив клиента, после ввода "идентификатора и пароля", они автоматом заносятся в биллинг, а дальше, при смене оборудования, только "идентификатор и пароль".

Да, именно так и есть. Монтажник берёт у юзера его данные и далее либо записывает их на вышеупомянутой пачке сигарет и потом эту пачку передаёт в офис либо сам в онлайн режиме сразу заносит всё в базу. Это уж у кого как и об этом @vop выше писал уже.

[NiTr0 584]

11 часов назад, Baneff сказал:

Правда непонятно, зачем тут ещё и привязка к МАС-у, если уже и так понятно на каком порту сидит юзер и свич исправно рапортует о запросах с этого порта с помощью опшн 82.

защита от рукожопов, тыкающих при ремонте абонкабели в первый попавшийся порт.

 

2 часа назад, sanyadnepr сказал:

Если Вы не в курсе, то dhcp запросы/ответы "перехватывает" и передает коммутатор, во влане управления

нет, это разве что отдельные альтернативно одаренные типа длинка таким занимаются... втех же хуавеях опция82 вставляется абсолютно прозрачно.

[Baneff 149]

2 минуты назад, NiTr0 сказал:

защита от рукожопов, тыкающих при ремонте абонкабели в первый попавшийся порт.

Ну если там есть option 82 , то и DHCP snooping должон быть, не?

А если вилан пер юзер, то тогда вообще без разницы кто и что и куда там втыкает.

[vop 370]

7 hours ago, sanyadnepr said:

 не совсем у Вас диджитализация...кто вводит Адрес, ФИО и т.д., офис ? Есть мнение, для полной автоматизации, эти данные вводит монтажник подключив клиента, после ввода "идентификатора и пароля", они автоматом заносятся в биллинг, а дальше, при смене оборудования, только "идентификатор и пароль".

В целом Ваша схема хороша, но не нова.

 

(Анекдот) У логопеда:

- Доктор, я плохо выговариваю букву Ч?

- Ну как же, дружище! Совсем даже не плохо выговариваете!

- Ну не чавчем.:)

 

И так, схема такая. В одном месте оказываются человек и розетка (та, которую когда-то поставил монтажник). Просто не забываем, что в цивилизованном случае в квартире у человека электрические и ethernet розетки изначально давно установлены и куда надо подключены. Человек втыкает что-то интернет-кушающее в розетку.

1. Этот этап пропускам в описании, так-как для Украины не актуально (интеграторы последней мили в стране не прижились).

2. "Если вы у нас первый раз - зарегистрируйтесь, если вы наш клиент - залогиньтесь". Человек (в мире диджитализации) прикладывает свою id-card, (а в отсталом мире) вводит свое имя, телефон, адрес. Монтажник тут не при чем, ибо он был тут последний раз 3 года назад, когда строили район.:)

3. Если человек уже клиент, просто логинится, прикладывая какое-нибудь диджитализирующее устровйтсво к диждитализирующему идентификатору... Ну, например, сканирует qr-code. И это только в случае замены оборудования или других проблем. Иначе клиент никуда не заходит и ничего не вводит.

3. Если клиент новый - он заходит в свой профайл, выбирает услугу(-и), произовдит оплату в "ван клик" одним из 1072 доступных способов, и забывает об остальных отношениях своих с провайдером. Факт оплаты в цивилизованной стране является фактом подписывания договора.

 

Вопрос адреса. Если дядя покупает в интернет магазине энциклопедию (или надувную тётку), он вводит там свой адрес для доставки товара. Тут то же самое - введите свой адрес, без которого мы не сможет пофиксить неисправности, если таковые возникнут. Не введет клиент свой адрес, работает все, платит - ну и слава богу, деньги поступают, мороки нет.

 

Вот такая простенькая схема. И да, такая схема не нова. Она была запущена (сейчас посмотрю...) в мае 2005 года.

 

С тех пор я слышал огромное количество "аргументов" со стороны украинских провайдеров, почему они это делать не хотят, им это не выгодно, это не правильно... Ну то дело такое.

Изменено 2019-10-17 13:34:43 пользователем vop