Перейти к содержимому
Калькуляторы

взлетит или не взлетит? уход с pppoe на ipoe

Доброго времени суток. Покритикуйте схему.

 

Хотим уйти от pppoe-тоннелей на юриков и недо-ipoe с привязкой по маку и терминацией на софтроутере для физиков в сторону ipoe с привязкой по маку.

Схема примерно такова.

1. Ввиду достаточно кривой реализации dhcp+radius уходим от привязки абонентов по макам. И просто при создании абонента забиваем его в конфиг dhcpd скриптом из биллинга с привязкой по option 82. Т.е. абонент у нас имеет заранее назначеный статический белый или серый адрес независимо от того, во что он воткнет кабель.

2. На достуе включаем dhcp snooping, access-порты делаем недоверенными, аплинки к акрегации - доверенными. И там же вставляетм опцию 82.

3. На агрегации ставим l3-свитч и терминируем не нем по l3 vlan на несколько домов. На этом свитче включаем dhcp snooping и делаем порты в сторону доступа недоверенными, а в сторону ядра - доверенными. Там же релеим dhcp на dhcpd. Чтобы абонент смог работать только с выданным по dhcp адресом включаем dynamic arp inspection для l3-интерфейсов. 3550-12g справиться с роутингом до 200-300 мбит трафика таким образом? Или стоит проапгрейдиться сразу до 3750/4506?

4. Загоняем трафик в ядро, где стоит 6509 + sup720-3bxl + WS-X6748-SFP. Там заворачиваем трафик или в локалку или на брас.

5. В качестве браса на первое время планируем использовать 7206+ npe-g1. На нем поднимаем isg и по радиусу прикручиваем к биллингу. Т.к. адрес у нас верифицирован на доступе, то в качестве инициатора сессий выступает ip. Соответственно по нему мы о определяем пользоватеся. На брасе полисим трафик и если адрес серый, то заворачиваем его на тазик с линуксом для nat. Если адрес белый, то заворачиваем его на бордер. Если npe-g1 станет мало (к стати сколько он сможет через себя прокачать?), то апгрейдим его до npe-g2 или сразу до ASR1002. К стати интересно, а у кого-нибудь получилось нормально зарезервировать и обеспечить балансировку брасов по glbp?

 

В общем, вот такая схема. Здоровую критику принимаю.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. Да согласен.

2,3 - не вижу особого смысла релеить на агрегации, когда можно сразу на доступе можно и релеить и опцию 82 вставлять. Все железки которые умеют снупинг умеют и релей. dynamic arp inspection на тех же длинках вполне работает.

Да и вообще не вижу смысла агрегации. Не проще тащить вланами в ядро, а в ядре делать что угодно.

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

Да и если нет заморочек с ARP-Inspection и всякими аналогами и фильтрацией на доступе - то теоретически абонент сможет подгадить соседу.

5. От тазиков с НАТ-ом есть смысл отказаться в сторону железок. по крайней мере есть над чем подумать.

 

Вообще тема интересная. Мы сами в процессе ухода от PPPoE, но у нас ситуация немного другая.

Изменено пользователем Negator

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 - в принципе согласен, но тогда DAI не получится использовать т.к. dhcp будет лететь в отличном от абонентского влане. Проблема в том, что на доступе стоят в основном циски 2950g и DAI они не умеют. А привязать пользователся к порту как то надо. Тем более хочется сделать это какими-то более-менее стандартными средствами чем колдовать с динамическим редактированием acl... А по поводу нагадить соседу - можно сделать радикальные меры и порты с абонентами сделать protected и тогда они не будут видеть друг друга. Да и к тому же гадь - не гадь, а привязка все равно к порту, так что соседу можно разве что витую пару отрезать:).

 

К стати, чем плохи софтовые тазики с натом? Мегабит 500-600 на каком-нибудь Xeon E5630 плюс интеловские сетевушки нельзя что ли выжать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да и к тому же гадь - не гадь, а привязка все равно к порту, так что соседу можно разве что витую пару отрезать:).

2950 не пойдут для обеспечения защиты от подмены IP/мака. Банально юзер ставит у себя IP+мак соседа (статикой), закрывается наглухо файрволом, и прекрасно делит с соседом его интернет. Т.е. защита для честных людей сродни замкам с универсальными ключами.

 

Мегабит 500-600 на каком-нибудь Xeon E5630 плюс интеловские сетевушки нельзя что ли выжать?

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

 

Сами планируем на IPoE постепенно сваливать. Остановились на схеме vlan per user + QinQ, и тащить все в ядро, где на писюках терминировать с каким-то вариантом ip unnumbered. Сначала думали опцию 82 пользовать, но передумали, дешевле vlan per user

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

От 2950 в данном случае требуется только нормальный снупинг ну и модет порт-секурити со стики-адресами. Прикол в том, что привязка идет не к маку клиента, а к маку свитча + номер порта клиента (это как раз и есть опция 82). Т.е. какой бы мак абонент не поставил, все равно получит один и тот же ip, по которому его биллинг и определяет. В этом весь и прикол. Ну максимум что произойдет - интернет у соседа, чей мак соспуфили, работать перестанет. Опять же если порты protected, то абоненты друг друга не видят. Для того чтобы увидели надо на агрегации включить arp proxy.

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

 

Короче, механизм как в аналоговой телефонии - что бы ты не втыкал в линию, номер у тебя будет тот же. Вот.

 

Vlan per user к стати рассматривался. Но он очень неудобен в управлении, т.е. нет относительно стандартных способов по пропуску влана до нужного порта. VTP и GVRP по моему опыту работали как то через раз. Да и к тому же 2950 нормально qinq не умеют.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3. На агрегации ставим l3-свитч и терминируем не нем по l3 vlan на несколько домов. На этом свитче включаем dhcp snooping и делаем порты в сторону доступа недоверенными, а в сторону ядра - доверенными. Там же релеим dhcp на dhcpd. Чтобы абонент смог работать только с выданным по dhcp адресом включаем dynamic arp inspection для l3-интерфейсов. 3550-12g справиться с роутингом до 200-300 мбит трафика таким образом? Или стоит проапгрейдиться сразу до 3750/4506?

 

Пробовали для одного трафика сделать и snooping и relay? Есть опасение, что работать будет что-то одно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

От 2950 в данном случае требуется только нормальный снупинг ну и модет порт-секурити со стики-адресами. Прикол в том, что привязка идет не к маку клиента, а к маку свитча + номер порта клиента (это как раз и есть опция 82). Т.е. какой бы мак абонент не поставил, все равно получит один и тот же ip, по которому его биллинг и определяет. В этом весь и прикол. Ну максимум что произойдет - интернет у соседа, чей мак соспуфили, работать перестанет. Опять же если порты protected, то абоненты друг друга не видят. Для того чтобы увидели надо на агрегации включить arp proxy.

Единственный способ попользоваться интернетами нахаляву - врезаться в соседвкую витуху.

Снупинг с опцией 82 - не "привязка". Он никак не помешает статикой прописать соседские мак и айпи. И protected тоже не помешает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К стати, чем плохи софтовые тазики с натом? Мегабит 500-600 на каком-нибудь Xeon E5630 плюс интеловские сетевушки нельзя что ли выжать?

Xeon здесь не нужен.

Обычный Core i5-750 с 4 картами по $40 справится с nat+filter+netflow до 1,5-2gbps.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

1) Коммутаторам доступа сразу выделяется по 25 или 50 vlan'ов.

2) На транзитные и родительские порты сразу назначается полный диапазон клиентских vlan'ов 2050-4000.

3) При подключении клиента на access-порт N назначается vlan Base+N.

4) В ядре Циска использует double vlan tagging.

 

На доступе и агрегации используются Qtech'и.

С Длинками п.2 не пройдёт и проталкивать vlan'ы от ядра до клиента придётся поштучно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С Длинками п.2 не пройдёт и проталкивать vlan'ы от ядра до клиента придётся поштучно.

не понял, почему....3120 в конфигурации "4К вланов во всех портах, все порты транком" - чем не подходит для агрегации?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2,3 - не вижу особого смысла релеить на агрегации, когда можно сразу на доступе можно и релеить и опцию 82 вставлять. Все железки которые умеют снупинг умеют и релей. dynamic arp inspection на тех же длинках вполне работает.

Да и вообще не вижу смысла агрегации. Не проще тащить вланами в ядро, а в ядре делать что угодно.

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

Да и если нет заморочек с ARP-Inspection и всякими аналогами и фильтрацией на доступе - то теоретически абонент сможет подгадить соседу.

чур-чур, опять вредные советы от длинководов... не надо релеить на доступе.

 

2топик-стартер: схема нормальная стандартная, аналогичная работает, только коробки другие. На доступе SNRы с dhcp snooping user bind, агрегация 2*х460, ядро х670, брас/бордер - шестисотый. вилан на коммутатор, виланы терминируются на 460м.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сначала думали опцию 82 пользовать, но передумали, дешевле vlan per user

одно другому не мешает....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3120 в конфигурации "4К вланов во всех портах, все порты транком" - чем не подходит для агрегации?

Редко получается поставить 3120 прямым родителем для всех устройств доступа.

Окажется где-нибудь транзитный des-3200, и как Вы на него будете прописывать 2k vlan'ов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3120 в конфигурации "4К вланов во всех портах, все порты транком" - чем не подходит для агрегации?

Редко получается поставить 3120 прямым родителем для всех устройств доступа.

Окажется где-нибудь транзитный des-3200, и как Вы на него будете прописывать 2k vlan'ов?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2топик-стартер: схема нормальная стандартная, аналогичная работает, только коробки другие. На доступе SNRы с dhcp snooping user bind, агрегация 2*х460, ядро х670, брас/бордер - шестисотый. вилан на коммутатор, виланы терминируются на 460м.

Как к стати себя ведут СНРы на доступе? Опция 82 нормально работает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

все равно получит один и тот же ip

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

 

Ну максимум что произойдет - интернет у соседа, чей мак соспуфили, работать перестанет

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

 

Обычный Core i5-750 с 4 картами по $40 справится с nat+filter+netflow до 1,5-2gbps.

Накой 4 карты по $40 если за эти деньги 2-головую i82576 можно взять?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Связка vlan per user и ip innumbered - хороша тем что имеет свойство фильтровать весь левый трафик благодаря своей структуре - роутить определеный ip адрес в нужный vlan. Весь левый трафик(например сетевой вирус) неизвестно куда исчезают.

Перевели где-то 80% пользователей. В центре стоит 6509 + sup720-3b, на доступе делинки, на них отключили все функции кроме vlan.

DHCP релеит цыска, вставляет свою особую опцию, на ответ DHCP-сервера подымает до клиента роут, здесь насколько фантазии хватит можно играться с раздачей ip адресов в зависимости от состояния счета клиента. DHCP с прямым подключением к mysql.vlanы до клиента пробрасывает скрипт. Вот и все - просто и железнобетонно. Техподержка зажила нормальной жизню! Все сделано по рекомендациям этого форума.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

а вот если IP подставить соседский - то проблемы будут у обоих.

И даже если инета он не получит - то соседу поднасрать сможет.

Изменено пользователем Negator

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

T_Igor

Сколько пользователей? Какая нагрузка на 6509, с чем связан выбор 3b ?

Пожалуйста, если не сложно

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

T_Igor

Сколько пользователей? Какая нагрузка на 6509, с чем связан выбор 3b ?

Пожалуйста, если не сложно

Пользователей более 3-х тысяч, загрузка не превышает 10%, единственное что не любит эта цыска так экспорт списков acl, в этот момент загрузка CPU 99%, поэтому доступом клиентов рулим через DHCP.

3bxl - слишком дорогой(но можно использовать как бордер BGP), 2 СУП менее функцианален.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Накой 4 карты по $40 если за эти деньги 2-головую i82576 можно взять?

Пруф?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

хм ... столько телодвижений чтоб только уйти от pppoE, стоит ли?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

хм ... столько телодвижений чтоб только уйти от pppoE, стоит ли?

Мода всегда требовала жертв :) . Хочешь быть в тренде - выкладывай бабки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

хм ... столько телодвижений чтоб только уйти от pppoE, стоит ли?

После перехода от PPPoE и PPTP на IPoE количество заявок в ТП уменьшилось примерно вдвое.

Вывод - оно того стоило.

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

T_Igor

Сколько пользователей? Какая нагрузка на 6509, с чем связан выбор 3b ?

Пожалуйста, если не сложно

Пользователей более 3-х тысяч, загрузка не превышает 10%, единственное что не любит эта цыска так экспорт списков acl, в этот момент загрузка CPU 99%, поэтому доступом клиентов рулим через DHCP.

3bxl - слишком дорогой(но можно использовать как бордер BGP), 2 СУП менее функцианален.

достаточно было сап32

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.