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

Снова IPoE - дизайн сети прошу покритиковать

Добрый день.

Сеть средних размеров (более 50к абонентов)

L2, все стекается до BRAS, который терминирует pppoe.

IPTV сеть маршрутизируется с помощью L3 коммутаторов.

Доступ управляемый, все на D-Link. В среднем к каждому DGS-3620/3627 подключено 2000-3000 хостов.

В пользовательском VLAN работает DHCP сервер для IPTV приставок.

 

Что не устраивает в текущей схеме сети:

1. Приходится гнать все абонентские VLAN до BRAS, а это несколько городов.

2. Карты на BRAS очень дорогие.

 

Решено рассмотреть вариант модернизации сети в сторону перехода на IPoE. Рассматривается так же вариант с терминированием абонентов не в ядре сети, а в городах, что бы потом уже оттуда по L3 маршрутизировать только до BGP роутера.

 

Видимое решение и проблемы:

1. Авторизовывать абонентов по Opt82. FreeRadius as a DHCP сервер.

- Как в данном случае быть с iptv? Сейчас абоненту либо ставят неуправляемый 5п свитч, 1 порт на роутер, 2 порт на приставку. Либо если роутер поддерживает бриджевание, то приставку сразу в роутер. Сейчас приставки получают IP просто из пула, видимо придется их привязывать к MAC адресу.

- Есть редкие случаи, когда в управляемом порту может быть 2-5 интернет клиентов. Решение - подключать как положено или авторизовывать их по MAC-адресу+Opt82.

- Как выдавать реальные IP адреса? Пробрасывать отдельно VLAN для таких клиентов человекозатратно, учитывая что физики могут каждый месяц ставить/убирать себе реальный IP-адрес, предлагать им данную услугу только через pppoe? схема становится не типовой. Как быть с юриками, которым нужно подключение без VPN? Тянуть VLAN?

2. Далее терминировать абонентов на BRAS, для этого у них должен быть маршрут по умолчанию до него или до коммутатора Ядра. Как дать такой маршрут, использовать default gateway на всех L3 до коммутатора Ядра? Для BRAS требования NAT и SHAPING. Кто что посоветует? Redback и Mikrotik не предлагать :). Рассматриваем все варианты, от софтверного до аппаратного решения.

3. Осуществление плавного перехода для абонентов, PPPoE и IPoE должны работать одновременно.

- Тут как я понимаю проблем быть не должно, абонент перенастраивает своё подключение на DHCP и всё.

4. Рассмотрение варианта децентрализации терминирования абонентов в ядре сети. Но что-то мне подсказывает что осуществлять NAT и SHAPING в одном месте дешевле, чем в нескольких (Стоимость BRAS). Учитывая что переход абонентов займёт продолжительное время, а узел оборудовать необходимо сразу, то решение будет дорогим. Либо переводить города поочереди.

 

Резюмируя:

Ваше мнение на все это безумие? Может кто-то предложит что-то интереснее.

В аттаче схема с подходом к реализации.

Снимок.PNG

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


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

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

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


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

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

Решение изложено выше, в котором описаны изъяны реализации (в связи с частностью исполнения схемы сети) и просто мысли вслух :)

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


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

Как выдавать реальные IP адреса?

unnumbered. там пофиг - реальные или нет. и лучше влан на юзера тянуть.

 

. Кто что посоветует? Redback и Mikrotik не предлагать :). Рассматриваем все варианты, от софтверного до аппаратного решения.

accel-ppp на linux, можно в связке с радиусом (минимум модификаций биллинга). для надежности - можно 2 браса параллельно юзать на каждой техплощадке. ну и динамическая маршрутизация (ibgp/ospf/rip/что там еще) ессно.

либо как вариант - терминация на какой-нить циске 3550, а дальше шейпинг на accel-ppp в L3 режиме, кому надо белые ип - нат 1:1 (но как по мне это костыль).

микротик тут 100% не подойдет - он ни опцию 82 не умеет, ни unnumbered нормально (вариант "нагенерить скриптами статик роутов и дхцп серверов" ессно не рассматривается).

 

Осуществление плавного перехода для абонентов, PPPoE и IPoE должны работать одновременно.

- Тут как я понимаю проблем быть не должно, абонент перенастраивает своё подключение на DHCP и всё.

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

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


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

1) Выдавать реальные адреса так-же как и остальные , просто отдавайте framed-ip-address или framed-ip-pool и держите для этого отдельные пулы.

2) Не совсем понятно , вы рисуете L3 core switch , между доступом и BRAS но если в случае ipoe бывает l3-connected то как быть с pppoe ? Или вы всетаки планируете vlan дотяггивать до BRAS ? В принципе , вас устроит любой вариант cisco asr , juniper MX (нужен нат смотрите в сторону MS-DPC или MS-MPC (MS-MIC для MX80))

3) да , должно работать

4) зачем шейпинг , неужели полисинга не достаточно ? Шейпинг - это сразу более дорогие линейные карты, а профита для ШПД никакого.

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


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

Вам просто надо передавать все абонентские вланы=порты через MPLS на BRAS, а там уже с ними делать что угодно - хотите PPPoE, хотите телевидение и т.п. От коммутаторов нужна поддержка EoMPLS. То ест на каждом свиче доступа заворачиваете каждого абонента во влан, далее эти вланы идут на L3 коммутатор, который запаковывает их в MPLS и передает в центр. В центре уже разбираете как вам удобно. Остается вопрос с телевидением мультикастом, но его можно передавать отдельно и подмешивать уже на оконечных L3 коммутаторах. Либо использовать юникаст, что более прогрессивно.

 

И это, опция 82 уже морально устарела.

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


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

unnumbered. там пофиг - реальные или нет. и лучше влан на юзера тянуть.

Зачем vlan per user? В чем отличие от общего vlan с сегментацией? В том что BRAS (или switch) должен теперь создать 50к+ интерфейсов с маршрутами?

 

accel-ppp на linux, можно в связке с радиусом (минимум модификаций биллинга). для надежности - можно 2 браса параллельно юзать на каждой техплощадке. ну и динамическая маршрутизация (ibgp/ospf/rip/что там еще) ессно.

либо как вариант - терминация на какой-нить циске 3550, а дальше шейпинг на accel-ppp в L3 режиме, кому надо белые ип - нат 1:1 (но как по мне это костыль).

Сколько linux с accel-ppp прокачет через себя GE? NAT+Shaping. 1-2GE?

 

1) Выдавать реальные адреса так-же как и остальные , просто отдавайте framed-ip-address или framed-ip-pool и держите для этого отдельные пулы.

И на шлюзе абонента (DGS) заводить внешнюю сеть? А если шлюзов 500?

2) Не совсем понятно , вы рисуете L3 core switch , между доступом и BRAS но если в случае ipoe бывает l3-connected то как быть с pppoe ? Или вы всетаки планируете vlan дотяггивать до BRAS ? В принципе , вас устроит любой вариант cisco asr , juniper MX (нужен нат смотрите в сторону MS-DPC или MS-MPC (MS-MIC для MX80))

Рассматриваем все варианты, но предпочтительнее vlan до BRAS

4) зачем шейпинг , неужели полисинга не достаточно ? Шейпинг - это сразу более дорогие линейные карты, а профита для ШПД никакого.

На самом деле да, имел в виду Policy

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


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

accel-ppp на linux, можно в связке с радиусом (минимум модификаций биллинга). для надежности - можно 2 браса параллельно юзать на каждой техплощадке. ну и динамическая маршрутизация (ibgp/ospf/rip/что там еще) ессно.

+1. У нас так же, vlan на коммутатор. NAT нет. IPTV через MVR.

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


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

Зачем vlan per user? В чем отличие от общего vlan с сегментацией? В том что BRAS (или switch) должен теперь создать 50к+ интерфейсов с маршрутами?

1) проще шейпить ipv6 2) абоны никак друг на друга не влияют 3) меньшие требования к свичам доступа (которые далеко не всегда умеют DHCPv6 snooping/ipv6 source guard).

тот же accel-ppp спокойно создает по необходимости клиентские сабинтерфейсы.

 

Сколько linux с accel-ppp прокачет через себя GE? NAT+Shaping. 1-2GE?

на свежих десктопных/младших серверных камнях (1155/1150) думаю каждый брас легко гигов по 5-7 прожует. интересно кстати тут будет смотреться broadwell с его eDRAM - которая работает как L4 кеш.

 

а 1 гиг легко осилит даже какой-то целерон...

 

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

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


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

Зачем vlan per user? В чем отличие от общего vlan с сегментацией?
- вы защищены от совпадения маков

- вы защищены от подмены ипов

- вы защищены от коллизий хэша

- у вас будет нормально работать ipv6 slaac - каждый абонент будет иметь свою /64

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

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


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

А где резервирование элементов?

Сдохла одна железка в голове и все лежит :)

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


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

А где резервирование элементов?

Сдохла одна железка в голове и все лежит :)

Во во, первое что бросается глаза очень много точек отказа.

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


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

Зачем vlan per user? В чем отличие от общего vlan с сегментацией?

- вы защищены от совпадения маков

 

А что, на свичах по отдельной таблице маков на каждый вилан?

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


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

А что, на свичах по отдельной таблице маков на каждый вилан?

А вы не знали? :)

На самом деле таблица-то одна, просто хэш делается от VLAN ID + MAC, так что vlan-per-user, например, однозначно помогал избавиться от коллизии хэшей на des3026/3028 и аналогичных огрызках.

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


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

' timestamp='1453872417' post='1233535']

А что, на свичах по отдельной таблице маков на каждый вилан?

А вы не знали? :)

На самом деле таблица-то одна, просто хэш делается от VLAN ID + MAC, так что vlan-per-user, например, однозначно помогал избавиться от коллизии хэшей на des3026/3028 и аналогичных огрызках.

 

Не то чтобы я не знал, но ради экономии и "оптимизации" китайцы способны на всякое.

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


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

но ради экономии и "оптимизации" китайцы способны на всякое.

Если vlan id исключить из таблицы, то функционал vlan работать перестанет, так что это вряд-ли возможно.

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


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

' timestamp='1453872882' post=1233538]

Если vlan id исключить из таблицы, то функционал vlan работать перестанет, так что это вряд-ли возможно.

Это возможно и будет называться Asymmetric VLAN. :)

 

Основное различие между базовым стандартом 802.1Q VLAN (или симметричными VLAN) и асимметричными VLAN заключается в способах отображения МАС-адресов. Симметричные VLAN используют отдельные адресные таблицы, поэтому не происходит пересечения МАС-адресов между виртуальными локальными сетями. Асимметричные VLAN используют одну общую таблицу МАС-адресов.

 

При использовании асимметричных VLAN существует следующее ограничение - не функционирует механизм IGMP Snooping.

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


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

Тут некоторые вендоры при некоторых условиях MAC в таблицу помещают, не проверив CRC кадра, так что я ничему не удивлюсь.

 

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

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

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


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

- вы защищены от коллизий хэша

 

Не зная хэш-функции - спорное утверждение.

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


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

AlexTN

При 1 порту в влане(что подразумевается формулой vlan per user) - утверждение истинно без оговорок :)

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


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

Не зная хэш-функции - спорное утверждение.

даже если будет коллизия, дальше форвардинг пойдёт unknown unicast-ом, а у вас всегда только 2 порта в этой влане - один к клиенту, другой аплинк. так что проблем 100% не будет.

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


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

так что проблем 100% не будет.

С форвардингом не будет. Но ведь коммутатор - это не только ценный мех (форвардинг), но еще и полтора, а то и два килограмма различных плюшек! У меня был большой сегмент из 3028, где проблема коллизий была купирована сегментацией трафика, отключением лернинга и auto_fdb. Форвардинг работал так будто коллизий не было, но телевидение, идущее мультикастом в отдельной vlan, работало отвратно. Видимо, из-за коллизий уже в мультикаст-влан. Если запихивать тв в абонентскую vlan - все ок. Когда гирлянды разобрали и снова сделали отдельную vlan - проблемы исчезли.

 

Лично мое мнение - коллизии надо именно устранять, а не обходить при помощи различных workaround. Vlan-per-customer хорошая штука, но она нужна не для решения проблемы коллизий. :)

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


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

xcme

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

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


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

xcme

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

 

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

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


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

xcme

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

а в чем проблема пригнать MVR/ISM на доступ?

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


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

Join the conversation

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

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

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

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

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

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

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