Концепт. Выносим роутер на сторону провайдера.

[nuclearcat]

В процессе экспериментов получил интересную функциональность на софтроутере - я могу создать много overlapping networks и "несмешанных" NAT на одном роутере.

Т.е. проще говоря я могу создать штук *надцать 802.1q vlan (может и больше), назначить каждому 192.168.0.0/24 сетку (т.е. на каждом стоит к примеру ip 192.168.0.1), причем никак не пересекающихся друг с другом. Или пересекающихся, по моему выбору.

 

До наступления полного счастья в IPv6, по идее это поможет клиентам избавиться от разнообразного зоопарка CPE, и потуг производителей реализовать полноценный NAT и кучу другого функционала на стороне клиента (DIR-300 NRU с стоковой прошивкой и его отвалами к примеру, отвалы при флуде торрентами и т.п.), т.е. клиент просто втыкает в свой vlan порт свое оборудование, и все. Как бонус - оператор имеет кое-какой доступ к управлению этим хозяйством, и к примеру может назначить IPTV коробочке в "сети" клиента определенный IP, пропинговать ip _внутри_ сети клиента и т.п., ну и конечно клиенту не надо изобретать велосипед, ему достаточно поставить wifi или свитч.

Функционал напоминает Cisco VRF, но Cisco не умеет выполнять приложения (IOS XR и ограничена ресурсами TCAM, плюс VRF там заточен под другие цели (IPVPN).

 

Определенного функционала OS конечно не хватает, но это не препятствие.

[dignity]

Мы так делаем для некоторых клиентов. То есть на своей стороне и NAT и раутинг и поддержку туннелирования, VPN. Делаем с помощью VPS на KVM.

[nuclearcat]

dignity - ну это _очень_ накладно, думаю максимум 20-50 клиентов, плюс в каждой kvm свой набор приложений.

[Картуччо]

Есть ощущение, что одним клиентам будет крайне утомительно объяснять зачем это надо, а другим клиентам объяснять не потребуется, но им это будет не надо.

И потом, есть ощущение, что большинство операторов выдают хоть и динамический, но public адрес.

[woddy]

если у абонентов серые ИПы - то проще раздавать по 16 адресов на абонента из своего пула. (остаются вопросы настройки порта коммутатора, ACL)

[nuclearcat]

А зачем клиентам что-либо обьяснять?

Как раз клиентам несколько проще, они покупают тупой свитч или wifi AP, которые не надо настраивать.

В отличии от "роутера" и его многочисленных глюков.

[Картуччо]

Ну а зачем тогда так вообще делать (если не объяснять) ? Выдавать по DHCP приватные адреса и всех делов и NATить их.

 

В случае с ADSL придётся покупать всё же маршрутизатор и использовать его в режиме бриджа.

[nuclearcat]

Картуччо - если у каждого клиента свой зоопарк - выдавать персональные приватные адреса каждой железке - накладно.

Конечно в больших городах шейпинг неактуально, но ведь не везде большие города...

 

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

[s.lobanov]

Т.е. проще говоря я могу создать штук *надцать 802.1q vlan (может и больше), назначить каждому 192.168.0.0/24 сетку (т.е. на каждом стоит к примеру ip 192.168.0.1), причем никак не пересекающихся друг с другом. Или пересекающихся, по моему выбору.

 

rt_tables на linux?

Хотя это вообщем-то не важно. Не вижу смысла делать пересекающиеся IP для массового потребителя. Если есть желание иметь 1 реальный IP на договор и при этом перетащить NAT на свою сторону, то пересекающиеся IP тут не нужны. Серых адресов не так уж мало.

 

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

 

Ну для этого есть стандартные решения, такие как pvlan("сегментация")+proxy_arp(опционально) или vlan-per-user.

[s.lobanov]

если у каждого клиента свой зоопарк - выдавать персональные приватные адреса каждой железке - накладно.

 

Как раз тут ничего накладного нет. А вот отказ от L3 CPE на стороне абонента приводит к увеличению таблицы мак-адресов на коммутаторе(что обсуждалось в теме про ipv4->ipv6). В случае цепочек/колец это может быть актуально(зависит от того насколько плохой чип у свитчей). И ещё вспоминается случай про мат.платы nvidia, на сетевухах которых был один и тот же мак. Два таких абонента в одном vlan и всё... С cpe-шками такого безобразия я не видел.

[nuclearcat]

Достигается через namespaces/контейнеры, т.е. полностью изолируются по mac/роутам/приложениям.

По поводу количества маков- возможно и актуально, в зависимости от того насколько хороший чип, то же и по поводу одинакового мака, я рассматриваю vlan per user.

 

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

[s.lobanov]

nuclearcat

Да понятно, что софт на современных CPE как правило уныл, но вопрос не в этом. Главный же вопрос остаётся, зачем то, что вы предлагаете нужно в isp? Экономить серые ip-адреса и более ничего? Да, ещё ваше решение плохо тем, что межабонентский трафик пойдёт через NAT

[jab]

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

[Картуччо]

Не стоковые прошивки тоже удивляют порой. Специально выбирал роутер под DD-WRT, так мало того, что в принципе не удалось добиться стабильного подключения к Билайну по PPTP/L2TP, то подключается, то не подключается и требуется полчаса передёргиваний по питанию и молитв. Так еще и не тянет даже 10 Mbps на роутере с гигабитными портами, Nным вайфаем и не самым слабым процессором. С фирменной прошивкой никаких проблем в принципе и подключается всегда и тянет.

[Ivan_83]

Тоже самое можно нетграфом нагородить во фряхе:

 

ng_ether - ng_vlan -- ng_viface (L2-L3) - ng_nat -...

 

 

 

 

Только проще отдавать клиенту серую /24 на влан: к ним проще получать доступ для диагностики и проще по дхцп адреса выдавать с настройками...

 

 

[s.lobanov]

Я думаю, что единственным применением такой штуковины могут быть юр. лица с несколькими офисами, при условии что все вланы одного такого клиента можно затерминировать в одном месте, т.е. просто vrf lite + nat, чтоб не покупать роутер с поддержкой vrf и что-то для nat'а. Правда, перенося NAT к себе, придётся ещё делать конфигуратор port-forwarding'а в личном кабиненте.

Других применений придумать не получается.

[nuclearcat]

nuclearcat

Да понятно, что софт на современных CPE как правило уныл, но вопрос не в этом. Главный же вопрос остаётся, зачем то, что вы предлагаете нужно в isp? Экономить серые ip-адреса и более ничего? Да, ещё ваше решение плохо тем, что межабонентский трафик пойдёт через NAT

Это как бы начало, решает проблемы CPE.

Кроме того позволяет решить несколько проблем хомячков, к примеру если клиент шейпится на 1Мбит, у клиента два компа, один для детей, и он тянет торренты. Седовласый отец семейства идет вечером пообщаться с кем-то в скайпе и курит бамбук, и странички у него медленно открываются, и скайпу каюк. А тут - бац, и провайдер делает QoS, который равномерно раздаст траффик на каждый ip, и визуально для хомячка все хорошо. А в технические детали ему вдаваться совсем не хочется...

Попытки прошейпить и решить такую проблему на CPE клиента - почти бесполезны, т.к. бутылочное горлышко до него, и CPE остается только "шейпить" с запасом, и надеяться что какой-нить дурной uTP не забьет канал, игнорируя попытки CPE намекнуть на уменьшение скорости дропами.

 

Опять же multicast, и куча костылей для его пропуска через зоопарк CPE. IPv6 и та же самая проблема.

 

Второй шаг - дополнительные услуги, за некоторые вполне можно содрать денежку.

Firewall, DMZ, 1:1 NAT, parental control, доступ по времени для отдельных компьютеров в сети, возможность юзерам сплитовать сети "на поиграть" или бизнес-юзерам "на поработать", причем сплитовать лишь для отдельных устройств, приоритеты по полосе для компов, логирование доступа.

Опять же, вы видите MAC устройства и его паттерны работы, и можете соответственно раскрасить траффик для него, к примеру если это PS3, или Iphone и т.п. Диагностика сложных проблем также немного упрощается, к примеру вы можете напрямую "пропинговать" проблемную железку и "посмотреть" траффик на нее.

 

Вопрос "шарильщиков" тоже отпадает, хотя не уверен, что это еще актуально.

 

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

 

Плюс это можно автоматизировать, а не делать "ручками" и с ограничениями как VRF в циске.

[darkagent]

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

[Milon]

востребовано. мелким клиентам привычно работать в сети 192.168.0.х + все экономят на роутерах. мелочь - а приятно.

 

реализуем с использованием VRF на циске.

 

 

 

 

 

[dignity]

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

KVM VPS с 1CPU (shared)/256RAM стоит (по нашим затратам) порядка 300 р/мес.

[ingress]

Всё хорошо, одно но.

CPE находится в зоне ответственности клиента, а ваш edge router/BRAS в вашей зоне.

Проверив связность и оценив качество(командой ping :) ) до CPE вы можете сказать: "с нашей стороны проблем нет",

если CPE интегрирован в ваш edge, то вам придётся нести ответственность за всё что внутри у клиента, т.к. зоны ответственности плавно растворяются.

оно вам надо?

[nuclearcat]

Всё хорошо, одно но.

CPE находится в зоне ответственности клиента, а ваш edge router/BRAS в вашей зоне.

Проверив связность и оценив качество(командой ping :) ) до CPE вы можете сказать: "с нашей стороны проблем нет",

если CPE интегрирован в ваш edge, то вам придётся нести ответственность за всё что внутри у клиента, т.к. зоны ответственности плавно растворяются.

оно вам надо?

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

 

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

[ingress]

я не хочу брать на себя ответственность за чужую(в данном случае домашнюю) сеть абонента.

в случае отсутствия CPE все криворучки с проблемами "не получаю адрес, не пробрасывается порт, не пингую шлюз" будут сваливаться на меня :(

[s.lobanov]

 

Кроме того позволяет решить несколько проблем хомячков, к примеру если клиент шейпится на 1Мбит, у клиента два компа, один для детей, и он тянет торренты. Седовласый отец семейства идет вечером пообщаться с кем-то в скайпе и курит бамбук, и странички у него медленно открываются, и скайпу каюк. А тут - бац, и провайдер делает QoS, который равномерно раздаст траффик на каждый ip, и визуально для хомячка все хорошо. А в технические детали ему вдаваться совсем не хочется...

Попытки прошейпить и решить такую проблему на CPE клиента - почти бесполезны, т.к. бутылочное горлышко до него, и CPE остается только "шейпить" с запасом, и надеяться что какой-нить дурной uTP не забьет канал, игнорируя попытки CPE намекнуть на уменьшение скорости дропами.

 

Опять же multicast, и куча костылей для его пропуска через зоопарк CPE. IPv6 и та же самая проблема.

 

Второй шаг - дополнительные услуги, за некоторые вполне можно содрать денежку.

Firewall, DMZ, 1:1 NAT, parental control, доступ по времени для отдельных компьютеров в сети, возможность юзерам сплитовать сети "на поиграть" или бизнес-юзерам "на поработать", причем сплитовать лишь для отдельных устройств, приоритеты по полосе для компов, логирование доступа.

Опять же, вы видите MAC устройства и его паттерны работы, и можете соответственно раскрасить траффик для него, к примеру если это PS3, или Iphone и т.п. Диагностика сложных проблем также немного упрощается, к примеру вы можете напрямую "пропинговать" проблемную железку и "посмотреть" траффик на нее.

 

 

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

[nuclearcat]

s.lobanov - не совсем. firewall прийдется городить, морочится с ipset и огромными цепочками правил, и т.п.

Если так делать, то линукс тут вообще не нужен, можно вполне обойтись Cisco и т.п.