Jump to content
Калькуляторы

взлетит или не взлетит? уход с 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?

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

 

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

Edited by Negator

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

 

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

Edited by NiTr0

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

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

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites
Сначала думали опцию 82 пользовать, но передумали, дешевле vlan per user

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


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

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

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

Edited by Negator

Share this post


Link to post
Share on other sites

T_Igor

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

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

Share this post


Link to post
Share on other sites

T_Igor

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

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

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

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

Share this post


Link to post
Share on other sites

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

Пруф?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

T_Igor

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

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

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this