[iValera]

Добрый день.

Сеть средних размеров (более 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). Учитывая что переход абонентов займёт продолжительное время, а узел оборудовать необходимо сразу, то решение будет дорогим. Либо переводить города поочереди.

 

Резюмируя:

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

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

[s.lobanov]

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

[iValera]

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

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

[NiTr0]

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

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

 

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

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

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

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

 

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

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

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

[orlik]

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

[Saab95]

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

 

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

[iValera]

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

[uk2558]

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

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

[NiTr0]

Зачем 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 надежнее все же, случаи разные бывают) на каждый город.

[rdc]

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

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

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

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

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

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

[vlad11]

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

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

[myst]

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

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

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

[ShyLion]

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

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

 

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

[[anp/hsw]]

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

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

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

[ShyLion]

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

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

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

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

 

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

[[anp/hsw]]

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

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

[xcme]

' timestamp='1453872882' post=1233538]

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

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

 

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

 

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

[ShyLion]

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

 

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

Edited January 27, 2016 by ShyLion

[AlexTN]

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

 

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

[kayot]

AlexTN

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

[zstas]

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

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

[xcme]

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

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

 

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

[s.lobanov]

xcme

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

[Saab95]

xcme

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

 

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

[iValera]

xcme

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

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