[dignity]

День добрый.

 

Возник вопрос. Мы VPN-провайдер (ибо у нас в городе есть всеобъемлющая LAN нескольких провайдеров).

Сейчас мы решаем выйти на клиентов с непосредственным подключением в домах по Ethernet. Соответственно вопрос:

 

Если делать авторизацию пользователей по PPPoE, то это очень удобно для нас с точки зрения учета сессий и т.п.

Отбрить клиента легко при отрицательном балансе. В общем, те же плюсы, что и при PPTP.

 

Реалии таковы, что большинство клиентов ожидают доступ к городской сети на скорости порта 100Mbit, соответственно, если

делать это по PPPoE, ни один BRAS за разумные деньги не выдержит (к тому же у нас торренты в городе в большом фаворе).

 

Хотелось бы иметь городскую сеть на свитчах без BRAS (возможно с VLAN-per-User) чтобы весь внутренний и городской трафик

разливать в ядре сети. Клиентов привязывать по MAC. Адреса белые.

 

А внешний трафик через рутер пускать в ТТК, РТК через 7206VXR.

 

Сеть будет полностью на управляемом оборудовании.

 

Вот, сейчас мне видится схема таким образом:

 

L3-свич ядра (смотрю на BigIron JetCore) (BGP с пирами в городе) + default на Shape-Vyatta/Linux, дальше на 7206VXR (РТК, ТТК). Без использования PPPoE и других механизмов контроля сессий. Если отрубаем внешний траф, то Deny на Shape-Vyatta.

 

Если отрубаем город, то выключаем VLAN на L3 в ядре (ну или на свичах доступа) в зависимости от реализации. Свичи доступа Extreme Alpine3808 (там можно набивку в 160 FastEthernet портов делать, да и цена за БУ полного фарша < 1000USD). Магистрали сети на оптике - 1Gbit звезда и кольца.

 

Покритикуйте. Если есть лучше схемы, прошу поделиться.

 

PS. Время от времени встречаю информацию по IPoE/ISG, если есть вменяемый мануал прошу ссылку дать, что-то Google мне ничего внятного не говорит.

Изменено 19 апреля, 2010 пользователем dignity

[Ivan Rostovikov]

Это опять холивар про pppoe vs ipoe

[Giga-Byte]

Реалии таковы, что большинство клиентов ожидают доступ к городской сети на скорости порта 100Mbit, соответственно, если

делать это по PPPoE, ни один BRAS за разумные деньги не выдержит (к тому же у нас торренты в городе в большом фаворе).

ну конечно... абонентов то сколько в он-лайне?

я бы сказал с нарезкой полос не выдержит, а тупо концентрировать PPPoE сессии и роутить гигабитные скорости сможет.

 

Хотелось бы иметь городскую сеть на свитчах без BRAS (возможно с VLAN-per-User) чтобы весь внутренний и городской трафик

разливать в ядре сети. Клиентов привязывать по MAC. Адреса белые.

да без проблем, только учитывайте требования СОРМ-2

 

 

 

а клиента надо не к МАС-у привязывать а к порту коммутатора.

 

[Ilya Evseev]

Когда мы использовали VPN/PPPoE, клиентам при подключении настраивались локальные маршруты, чтобы трафик к 192.168.*, 10.* и 172.16.* шёл не в туннель, а на LAN-шлюз.

 

На VPN-сервере трафик к локальным получателям запрещался файрволлом,

исключение было только для доступа на официальный сайт и личный кабинет.

 

Такая же схема, насколько я знаю, использовалась в Корбине.

[mschedrin]

Когда мы использовали VPN/PPPoE, клиентам при подключении настраивались локальные маршруты, чтобы трафик к 192.168.*, 10.* и 172.16.* шёл не в туннель, а на LAN-шлюз.

 

На VPN-сервере трафик к локальным получателям запрещался файрволлом,

исключение было только для доступа на официальный сайт и личный кабинет.

 

Такая же схема, насколько я знаю, использовалась в Корбине.

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

[Ilya Evseev]

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

Привет Скайнету ;-)

Решением стал плавный отказ от VPN и PPPoE с переходом на привязку IP-MAC-Port.

[Abram]

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

Привет Скайнету ;-)

Решением стал плавный отказ от VPN и PPPoE с переходом на привязку IP-MAC-Port.

А таки эта схема работает?

А то я уже и DHCP-сервер под это дело ваяю, и управление веб-смартами... Стоит ли?

[Ilya Evseev]

Решением стал плавный отказ от VPN и PPPoE с переходом на привязку IP-MAC-Port.

А таки эта схема работает?

А то я уже и DHCP-сервер под это дело ваяю, и управление веб-смартами... Стоит ли?

Главный критерий - количество заявок в техподдержку.

После отказа от VPN/PPPoE оно уменьшилось _примерно_ раза в два.

[Abram]

Решением стал плавный отказ от VPN и PPPoE с переходом на привязку IP-MAC-Port.

А таки эта схема работает?

А то я уже и DHCP-сервер под это дело ваяю, и управление веб-смартами... Стоит ли?

Главный критерий - количество заявок в техподдержку.

После отказа от VPN/PPPoE оно уменьшилось _примерно_ раза в два.

Что и требовалось доказать ;).

Не подскажете - какой используете биллинг? Или своё? Слабо представляю, как прикрутить то, что у меня получается, к какому-либо биллингу.

Как выдаете клиентам внешние айпи? Натите на пачку адресов? Я вот думаю по получению айпи клиентом (внутреннего) делать stateless nat (т.е тупо менять source/destination) по принципу один внутренний айпи = один внешний.

[Ilya Evseev]

Не подскажете - какой используете биллинг? Или своё?

Слабо представляю, как прикрутить то, что у меня получается, к какому-либо биллингу.

 

Как выдаете клиентам внешние айпи? Натите на пачку адресов?

Я вот думаю по получению айпи клиентом (внутреннего) делать stateless nat

(т.е тупо менять source/destination) по принципу один внутренний айпи = один внешний.

Используем несколько разных биллингов плюс кучу собственных костылей.

Для управления коммутаторами написано собственное ПО:

http://forum.nag.ru/forum/index.php?showtopic=54023

Сейчас обслуживает 4 биллинга и ~2.5k устройств разных типов.

 

Адреса выдаём статически, так сложилось много лет назад,

тестовое внедрение DHCP показало, что выигрыш минимальный (в нашем случае).

 

Для публичных адресов есть статическая подсеть в отдельном VLAN,

плюс BiNAT на шлюзе для тех клиентов, до которых этот VLAN не прокинуть.

Правила BiNAT для PF и iptables+ipset строятся из биллинга автоматически.

[mschedrin]

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

Привет Скайнету ;-)

Решением стал плавный отказ от VPN и PPPoE с переходом на привязку IP-MAC-Port.

На мой взгляд - идеальным вариантом является привязка исключительно к порту коммутатора, без использования мак адреса пользователя. Это приемлимо для провайдера, и максимально удобно для пользователя.

[dignity]

Клиентов можно привязывать и по порту/VLAN.

 

Вообще, идеальная картина мира для нас такая: Клиент заехал в дом, видит стоит розетка (и бумажка "воткнись - будет тебе счастье) - воткнулся - страница сайта где написано куда звонить/идти/платить.

 

[Abram]

Для управления коммутаторами написано собственное ПО:

http://forum.nag.ru/forum/index.php?showtopic=54023

Сейчас обслуживает 4 биллинга и ~2.5k устройств разных типов.

О, то что надо! =) И даже на перле.

Я понимаю, что документации нет, но может где завалялись комментарии, какая ф-ция в модулях управления коммутаторами что делает? Какие из них обязательны? А то у меня под мои TP-Link-и уже кое-чего написано, так что просто возьму и перетащу.

[Ilya Evseev]

Для управления коммутаторами написано собственное ПО:

http://forum.nag.ru/forum/index.php?showtopic=54023

Сейчас обслуживает 4 биллинга и ~2.5k устройств разных типов.

О, то что надо! =) И даже на перле.

Я понимаю, что документации нет, но может где завалялись комментарии, какая ф-ция в модулях управления коммутаторами что делает? Какие из них обязательны? А то у меня под мои TP-Link-и уже кое-чего написано, так что просто возьму и перетащу.

Все вопросы по routers_mgmt задавайте в соответствующей теме:

http://forum.nag.ru/forum/index.php?showtopic=54023