[-Ars-]

nuclearcat, ок, есть еще один контраргумент:

Чем сложнее система, тем больше шансов на неисправность, так? Что дешевле: держать еще одну бэкапом, или всё-таки продолжать работать "по-старинке"?

Я понимаю (кажется ;) ) все ваши технические аргументы, но деньги решают всё.

Вопрос номер раз: сколько может стоить переход на такой сервис и оправдает ли он себя в сравнении со всеми текущими описанными выше проблемами? Вы делали прикидки? Хотя бы исходя из своих локальных условий?

Вопрос номер два: сколько провайдеров скажут: ааа, да, мы тут занимались фигнёй, у нас до сих пор несколько миллионов вложено в разработки кастомизированных СРЕ, давайте, мы плюнем на эти деньги и разработку, и вложим еще несколько десятков миллионов в новое оборудование, которое нам упростит жизнь в будушем.

И, учитывая рост современных скоростей, сколько это оборудование протянет до замены? И успеет ли оно окупиться к тому времени?

 

Если уж хочется поддерживать клиента именно так :-)

А вот нинада тут этого вот ;)

Изменено 19 июля, 2011 пользователем -Ars-

[sirmax]

nuclearcat

Можно чуть подробнее про реализацию?

[nuclearcat]

В моем случае это невозможно, в Ливане полнейший колхоз из горы неуправляемых свитчей, и даже PPPoE тут с трудом справляется. Жаль, что в спецификации не думали про безопасность и неуправляемые сети. Вменяемость у шефов и "агрегаторов" в техническом плане крайне низка, потому выбор у меня невелик.

В Саудовской Аравии - там попроще, и именно там возможно и буду заниматься внедрением такого. Но там это не очень актуально, в основном корпораты.

 

Именно процесс перехода полностью прозрачен, при включении этой системы - CPE продолжает работать по прежнему, можно лишь постепенно включать сначала кастомный NAT, потом постепенно убирать у клиентов CPE и т.п. Хотя сегментированный ввод системы не очень удобен в плане техподдержки, но все можно спланировать. И благодаря этому систему легко тестировать даже на части клиентов.

Конечно держать две системы сложно, и это разумно только в переходной период.

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

 

А по поводу кастомизированных CPE, им(провайдерам) рано или поздно прийдется внедрять новые сервисы. Систему можно развивать без особых затрат и жертв так, чтоб можно было откатиться, а кастомизированные CPE с телефонами и видео могли работать и с натом на коробочке у клиента, только прийдется уже ставить две коробки, т.к. в моей концепции этот CPE предоставляет дополнительные сервисы, а в существующей на сегодня - CPE это необходимое средство для предоставления основного сервиса, инета.

 

Кстати еще одна фича - выдача реальника только на один из компов клиента. Т.е. сейчас многие провайдеры конечно выдают реальники, но с существующими CPE и необходимостью их применения это почти бесполезно, костыли в виде uPNP и DMZ - не панацея. А вот даже для приставок, наличие честного IP, без лишних телодвижений - серьезное подспорье.

[x86]

Поддерживаю уважаемого nuclearcat.

У нас нечто подобное изначально реализовано на доступе.

Без проблем выдаем подсетки на порт и берем за это дополнительные деньги :)

Пользователь получает чистку трафика и QoS, а также простоту настройки его оборудования - достаточно обычного свитча.

Для тех, кто опасается проблем со стороны других абонентов, есть волшебная кнопка на домашней страничке - Отключить доступ в локальную сеть.

Также хочу отметить потенциальную гибкость подобного решения - ибо любые хотелки реализуются просто написанием нужного софта.

[nuclearcat]

nuclearcat

Можно чуть подробнее про реализацию?

Пока только концепт.

Опубликую скрипт, который я сделал для своей домашней сетки, т.к. меня здорово достали глюки разнообразных мыльниц и микротиков:

#!/bin/sh                                                                                                                                                                                                 
killall meoip                                                                                                                                                                                             
killall udhcpd                                                                                                                                                                                            
kill `cat /var/run/dropbear2.pid`                                                                                                                                                                         
ip link del dev vupnuc0                                                                                                                                                                                   
ip netns delete nuc                                                                                                                                                                                       
ip link add name vnuc0 type veth peer name vupnuc0                                                                                                                                                        
ip link set vnuc0 up                                                                                                                                                                                      
ip link set vupnuc0 up                                                                                                                                                                                    
brctl addif br0 vupnuc0                                                                                                                                                                                   
ip netns add nuc                                                                                                                                                                                          
ip link set vnuc0 netns nuc                                                                                                                                                                               
ip netns exec nuc ip addr add dev vnuc0 192.168.20.21/24                                                                                                                                                  
ip netns exec nuc ip link set dev vnuc0 up                                                                                                                                                                
ip netns exec nuc ip route add default via 192.168.20.8                                                                                                                                                   
ip netns exec nuc ip link set dev lo up                                                                                                                                                                   
ip netns exec nuc ip addr add dev lo 127.0.0.1/8                                                                                                                                                          
ip netns exec nuc ip addr add dev vnuc0 80.83.x.x/32                                                                                                                                                     

ip netns exec nuc meoip /config/meoip.cfg
ip netns exec nuc brctl addbr brnuc                                                                                                                                                                       
ip netns exec nuc brctl addif brnuc eoip0                                                                                                                                                                 
ip netns exec nuc brctl addif brnuc eoip1                                                                                                                                                                 
ip netns exec nuc ip addr add dev brnuc 192.168.2.1/24                                                                                                                                                    
ip netns exec nuc sh /config/firewall-virtual-nuc.cfg                                                                                                                                                     
ip netns exec nuc /usr/sbin/sshd -P /var/run/dropbear2.pid                                                                                                                                                
ip netns exec nuc udhcpd -S /config/vnuc/vnuc-udhcpd.conf                                                                                                                                                 
ip netns exec nuc brctl stp brnuc off                                                                                                                                                                     
ip netns exec nuc ip link set dev brnuc up    

firewall

#!/bin/sh                                                                                                                                                                                                 
iptables -F                                                                                                                                                                                               
iptables -t nat -F                                                                                                                                                                                        

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -j SNAT --to-source 80.83.22.2  

 

Естественно для массового применения идею надо тщательно допиливать и переделывать, возможно даже namespaces здесь не решение.

Кроме того я использую два eoip туннеля, т.к. сплитнул свою сетку с другой сеткой имеющей ко мне отношение.

[nuclearcat]

-Ars- я не могу вот так вот взять и навскидку сказать, это было бы балабольством. Среднего размера компания никак не говорит о pps и мегабитах.

Более того, я еще не проводил даже тесты зависимости нагрузки на железо при нескольких namespaces, хотя если там и есть проблемы, уверен, они решаются. Хотя... тесты проводили другие люди, но для немного других задач, и там все было замечательно.

 

STB? Вы давно прокидывали большие обьемы мультикаста через CPE с wifi? Особенно если этот мультикаст по какой-то причине уехал в wifi, и хотя коробка 802.11n, она из-за старого девайса сделала fallback на 802.11g, или не дай бог даже 802.11b.

Или гонять IPTV/войс через CPE с ограниченными ресурсами?

STB имхо нужнее прямой вход в сеть оператора, без сомнительных "посредников" в виде CPE. Кастомизированный CPE может ограничивать в выборе, т.к. кого-то могут не устроить ограничения в нем, а вам врядли захочется разрабатывать линейку продуктов под все хотелки.

 

В небольших масштабах я это буду делать всенепременно, но чистый IPoE только у корпоративов, у остальных в лучшем случае wireless CPE на которые я могу прокинуть туннели.

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

[-Ars-]

STB? Вы давно прокидывали большие обьемы мультикаста через CPE с wifi?

Нам заказчики говорят конкретно: никакого мультикаста через wifi :-)

[nuclearcat]

Ну это вынужденный костыль, сами понимаете :-)

Я могу еще повспоминать море граблей, через которые прийдется пройти производителю CPE, т.е. вам :-)

Ненужных граблей.

[ingress]

Пока только концепт.

 

upnpd в обязательном порядке.

[-Ars-]

Я могу еще повспоминать море граблей, через которые прийдется пройти производителю CPE, т.е. вам :-)

Тут уже идет речь про наши грабли (в большинстве своём уже пройденные) vs грабли производителя соответствующего оборудования провайдерского класса + грабли собственно провайдера, которому надо будет всё это отлаживать и поддерживать.

 

Вобщем, даже если эта идея и воплотится в жизнь, это не сразу будет глобально, да и произойдёт не сегодня, не завтра и даже не через год. Пойду спокойно спать ;)

[darkagent]

Без проблем выдаем подсетки на порт и берем за это дополнительные деньги :)

Пользователь получает чистку трафика и QoS, а также простоту настройки его оборудования - достаточно обычного свитча.

а провайдеру достается целый зоопарк из абонентских мак-адресов, которых он может привести с прилично (например за спиной пионернет подтянуть). у вас от ядра до конечного коммутатора доступа выделенное волокно?

уж чего чего, а с маками головняк пожалуй у большинства здесь присутствующих. пока оператор мал и не вырос из первого десятка тысяч - он даже и не заметит что "много маков - это плохо"..

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

[Deac]

Даже если абстрагироваться от организационных вопросов.

Фактически, придётся, как минимум, ещё дважды переписывать.

Один раз на время IPv4 + IPv6, а потом ещё раз, для чистого IPv6(этот вариант вообще противоречит предлагаемой идеологии).

[nuclearcat]

Даже если абстрагироваться от организационных вопросов.

Фактически, придётся, как минимум, ещё дважды переписывать.

Один раз на время IPv4 + IPv6, а потом ещё раз, для чистого IPv6(этот вариант вообще противоречит предлагаемой идеологии).

Как раз наоборот.

В случае IPv6 вам CPE не нужен, но нужно выдавать сетку клиенту.

Создается сложность, либо нужен гибридный IPv6 CPE, который будет v4 натить, а v6 рутить, либо все таки переходить к идеологии выдачи адресов клиенту напрямую.

 

В случае моей идеологии оператор уже готов к этому, просто отключается nat. В namespaces все ipv6 ready, но сохраняется возможность персонализированного firewall и т.п. фич.

P.S. ipv4 думаю еще будет долго нужен, лет 5 как минимум, т.к. много старых устройств, особенно embedded, потому отключать его нужно будет нескоро.

[Deac]

переходить к идеологии выдачи адресов клиенту напрямую.

 

По райп-у - другого пути нет.

 

P.S. ipv4 думаю еще будет долго нужен, лет 5 как минимум, т.к. много старых устройств, особенно embedded, потому отключать его нужно будет нескоро.

 

Переход может состояться и в приказном порядке, а для всего не поддерживающего IPv6 - добавлять прослойку 4to6.

Изменено 19 июля, 2011 пользователем Deac

[s.lobanov]

-Ars-

Куда интереснее рассматривать этот вопрос(ненужности CPE) в контексте IPv6, а именно - L2- vs L3-коробочки дома у абонента. Ведь фактически тогда необхоимость иметь CPE только в случае pppoe(не считая xdsl/xpon где она выступает в первую очередь медиаконвертером)

[nuclearcat]

Переход может состояться и в приказном порядке, а для всего не поддерживающего IPv6 - добавлять прослойку 4to6.

На стороне провайдера 4to6 :-)

Интернет не терпит приказных порядков.

[Deac]

На стороне провайдера 4to6 :-)

 

Если у провайдера есть embedded, не поддерживающий IPv6 - да на стороне провайдера, непосредственно между embedded и остальной сетью.

 

Интернет не терпит приказных порядков.

 

После УЗАКОНЕННОГО блокирования DNS - возможны любые варианты.

[x86]

а провайдеру достается целый зоопарк из абонентских мак-адресов, которых он может привести с прилично (например за спиной пионернет подтянуть). у вас от ядра до конечного коммутатора доступа выделенное волокно?

уж чего чего, а с маками головняк пожалуй у большинства здесь присутствующих. пока оператор мал и не вырос из первого десятка тысяч - он даже и не заметит что "много маков - это плохо"..

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

Открою страшный секрет - я не знаю, что такое MAC.

И, о ужас, абоненты тоже не подозревают о его существовании :)

Мы выдаем подсетку на порт ( /32 это ее частный случай ) и имеем дело только с IP, т.е. у нас построена L3-сеть.

L2 работает только между шлюзом на роутере и портом на свитче, и таким образом всевозможные проблемы со спуфингом невозможны в принципе + роутер имеет защиту от перегрузки по pps. Грубо по архитектуре - волокно выведено на узел доступа, который терминирует несколько коммутаторов доступа( кое-где встречаются и колбаски ). Мыльниц на доступе, естественно, нет, но и супер-возможностей от свитчей тоже не требуется - 802.1q и rate-shaping( хотя на самом деле это полисинг ) вполне достаточно.

[darkagent]

причем тут мак и спуфинги? не о них речь. у вас узел доступа L3 или все же L2 ? сколько маков у вас в среднем на одном узле сходится?

[x86]

причем тут мак и спуфинги? не о них речь. у вас узел доступа L3 или все же L2 ? сколько маков у вас в среднем на одном узле сходится?

Узел доступа у нас - L3. Сколько маков сходиться - бес понятия, ибо каждый абонентский порт находится в отдельном VLAN. Если абонент загадит большим количеством маков свой порт - это его проблемы, которые я могу не безвозмездно помочь решить. Еще раз - всю остальную сеть( да и мир тоже ) абонент видит только через шлюз и общаться с ними сможет только через его мак-адрес.

[inkelyad]

В пропагандируемом мной подходе микро-CPE-розетка совсем-совсем глупое. Никаких firewall-ов, NAT-а вытаскивания голоса. Ему только и нужно уметь, что маршрутизировать приходящие на него пакеты на вышестоящий маршрутизатор. Это лишь чуть умнее, чем тупая замена src и dst MAC-ов в проходящих кадрах. С точки зрения логики работы это будет даже не

совсем маршрутизатор. Скорее хитрая форма ProxyARP "моста".

 

Такое вполне возможно дешево делать на любой нужной wirespeed. И прошивку после этого менять потребуется разве что при переходе IP4->IP6. Да и выглядить такое "cpe" должно именно как розетка, а не как дополнительный кирпичик-маршрутизатор.

 

Еще раз - всю остальную сеть( да и мир тоже ) абонент видит только через шлюз и общаться с ними сможет только через его мак-адрес.

Во, осталось сделать так, что этот самый MAC находился в чипе на абонентском конце кабеля. А с той стороны чипа, что в операторскую сеть смотрит, можно, скажем, дальнобойный Ethernet поставить. Или совсем не Ethernet.

[nuclearcat]

В пропагандируемом мной подходе микро-CPE-розетка совсем-совсем глупое. Никаких firewall-ов, NAT-а вытаскивания голоса. Ему только и нужно уметь, что маршрутизировать приходящие на него пакеты на вышестоящий маршрутизатор. Это лишь чуть умнее, чем тупая замена src и dst MAC-ов в проходящих кадрах. С точки зрения логики работы это будет даже не

совсем маршрутизатор. Скорее хитрая форма ProxyARP "моста".

Это получается просто костыль для борьбы с большим количеством маков.

 

Такое вполне возможно дешево делать на любой нужной wirespeed. И прошивку после этого менять потребуется разве что при переходе IP4->IP6. Да и выглядить такое "cpe" должно именно как розетка, а не как дополнительный кирпичик-маршрутизатор.

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

И перемолоть 100 Мбит с пакетной обработкой... начнем с того, что там нужен PHY, MAC, причем с обеих сторон... даже если это FPGA - это уже не будет дешево. Если разрабатывать ASIC - это миллионы долларов и нужен массовый спрос. Ради костыля?

Изначально нереальное решение.

[inkelyad]

Это получается просто костыль для борьбы с большим количеством маков.

Не только. Еще будет

a) контроль линии до самой квартиры абонента

б) почти постоянную привязку MAC<->абонент.

в) полную развязку абонентов по канальному уровню. vlan-на-пользователя, в общем, ради этого и используется.

 

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

И перемолоть 100 Мбит с пакетной обработкой... начнем с того, что там нужен PHY, MAC, причем с обеих сторон... даже если это FPGA - это уже не будет дешево.

Я как-то наивно думаю, что из пачек "сетевых процесоров" хоть один подходящий найдется.

 

Изначально нереальное решение.

Выше по теме народ посчитал реальным решением ставить абоненту CPE потолще. Почему-то на их разработку деньги у производителей нашлись.

[vIv]

http://forum.nag.ru/forum/index.php?showtopic=54015 - прямо само просится!

[woddy]

ага, и ценник порядка 30 баксов...