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

Как же строить сеть. Новый топик для обсуждений

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

 

Что делается:

На дома L2 DLINK DES3200-28 (кое где поставлены DES3028)

На агрегацию микрорайона (группа до 20 домов) L3 DLINK DGS3627G (vlan на дом)

На агрегацию района (группа до 16 микрорайонов) L3 DLINK DGS3627G (пока так, потом мб будет заменено на что-то вразумительное)

Ядро пока на PC-Router (функции ядра pptp-server, border router), ядро будет заменено в будущем на Juniper MX80 или ASR1004

IP адресация серая (на pptp тунель выдается белый адрес)

 

Вроде бы все хорошо, vlan доступа терминируются на L3 микрорайона, агрегируются в более крупные подсети и передаются на агрегацию района.

связаность с соседями агрегаторами есть как между микрорайонами так и между районами.

 

Как бы все хорошо. Но что хочется:

 

Уйти от тунелей (pptp, l2tp, pppoe) т.е. придти к схеме чистого IPoE.

Есть достаточно большой пул белых адресов /18 что перекрывает потребоность при онлайн абонентов в ЧНН, поэтому хочется абоненту выдать по DHCP сразу белый адрес на интерфейс, тем самым избежать NAT, даже в варианте One-to-One NAT.

 

Управлять сервисами абонента в одном месте (BSR).

В этом случае тянуть vlan-per-customer до BSR через QinQ, но проблема что на DLINK не совсем понятно как работает QinQ (по всей видимости с очень ограниченым функционалом) и проблема роста трафика если абонентам предоставлять подписку на IPTV.

 

Хочу обратиться за советом-подсказками к опыту старших товарищей по счастью/несчастью в решении этих задач.

Жду ваших советов :)

Share this post


Link to post
Share on other sites
На агрегацию микрорайона (группа до 20 домов) L3 DLINK DGS3627G (vlan на дом)

Явный overkill. У вас двухуровневая L3 агрегация получается, какова цель ? L3 достаточно в ядре, а все требования к агрегации - гнать vlan'ы и STP.

 

Есть достаточно большой пул белых адресов /18 что перекрывает потребоность при онлайн абонентов в ЧНН, поэтому хочется абоненту выдать по DHCP сразу белый адрес на интерфейс, тем самым избежать NAT, даже в варианте One-to-One NAT.

Резко вырастет траффик на аплинках по сравнению с NAT.

Share this post


Link to post
Share on other sites

1) Где сразу не куда было, не терминировать же порядка 1,5к вланов (по 1 на дом) на PCюках

2) Когда будет куда (с покупкой серьезного ядра), не хочется гнать стандартными vlan и иметь ограничение по маштабируемости не более 4к домов/vlan, да и делать в таком случае лучше схему vlan-per-user только вот Dlink qinq странно поддерживают (теряют vlan управления при этом)

3) Издержки на NAT могут быть слишком высокими :( Т.е. NAT будет самым узким местом в ядре со всеми вытекающими хлопатами в виде вечного апгрейда.

Edited by shicoy

Share this post


Link to post
Share on other sites
1) Где сразу не куда было, не терминировать же порядка 1,5к вланов (по 1 на дом) на PCюках

В чем проблема ? Я терминирую.

 

2) Когда будет куда (с покупкой серьезного ядра), не хочется гнать стандартными vlan и иметь ограничение по маштабируемости не более 4к домов/vlan, да и делать в таком случае лучше схему vlan-per-user только вот Dlink qinq странно поддерживают (теряют vlan управления при этом)

3) Издержки на NAT могут быть слишком высокими :( Т.е. NAT будет самым узким местом в ядре со всеми вытекающими хлопатами в виде вечного апгрейда.

Сколько гигабит аплинков ?

 

 

Для меня возможность сэкономить 20% аплинка в час пик оправдывает экономически практически любые танцы с NAT'ом.

Share this post


Link to post
Share on other sites

2Г, по прогнозам через год будет 4Г и т.д. т.е. рост есть и достаточно интенсивный :(

 

В чем проблема ? Я терминирую.

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

 

Сколько гигабит аплинков ?

Для меня возможность сэкономить 20% аплинка в час пик оправдывает экономически практически любые танцы с NAT'ом.

Как уже написать расчитывать нужно на 4Гб аплинка в некой перспективе, да и не каждый NAT справится с таким объемом (опять же цена вопроса растет). К тому же абоненты привыкли получить белые IP на тунель pptp, т.е. 1 сессия абонента = 1 внешний IP

 

Share this post


Link to post
Share on other sites
2Г, по прогнозам через год будет 4Г и т.д. т.е. рост есть и достаточно интенсивный :(

4Г писюки прожуют и обсчитают без проблем уже сейчас. А через год вообще за копейки. Брать ASR1004 на 4G - это из пушки по воробьям.

Share this post


Link to post
Share on other sites

задам вопрос в тему. кто подскажет каково оптимальное количество узлов на узел агрегации? первый вариант думается в районе 20ти с установкой что-то типа 3200-28F. Слышал такую мысль что лучше это количество увеличивать до 50 и что ставить тогда? Нужно ли в таком случае только L2 на таком узле или уже недостаточно?

Share this post


Link to post
Share on other sites
2Г, по прогнозам через год будет 4Г и т.д. т.е. рост есть и достаточно интенсивный :(

4Г писюки прожуют и обсчитают без проблем уже сейчас. А через год вообще за копейки. Брать ASR1004 на 4G - это из пушки по воробьям.

в ядро все равно будет устанавливаться что то типа Juniper MX80 или ASR, для целей управления услугами абонентов (шейпер, qos и т.д.), понятно что все это могут и PC, но не так удобно как нормальных BSR

 

задам вопрос в тему. кто подскажет каково оптимальное количество узлов на узел агрегации? первый вариант думается в районе 20ти с установкой что-то типа 3200-28F. Слышал такую мысль что лучше это количество увеличивать до 50 и что ставить тогда? Нужно ли в таком случае только L2 на таком узле или уже недостаточно?
Смотря чем агрегировать и для каких целей. Если DLINK то больше 20-22ти наверное не нужно.

 

Меня пока больше волнует какой вариант выбрать:

1) Большие плоские сегменты на 4к абонентов в каждом с включением Private Vlan (Traffic Segmentation) и выдачей реальных IP

2) Схема vlan-per-user с терминированием клиентских вланов на BSR и доп. затратами на магистральные каналы до узлов агрегации

3) Либо оставить как есть, а способом отказа от тунелей будет создание One-to-One NAT (IP real = IP local) в момент события IP detection или DHCPreq.

Share this post


Link to post
Share on other sites

jab, откуда сейчас отдаёшь мультикаст?

 

видел у некоторых провайдеров с пппое стоят прокси которые превращают мультик в юникаст по http.

костыль бесподобный.

Share this post


Link to post
Share on other sites
jab, откуда сейчас отдаёшь мультикаст?

видел у некоторых провайдеров с пппое стоят прокси которые превращают мультик в юникаст по http.

костыль бесподобный.

У меня сейчас unicast. На IPoE Малтикаст буду гнать со стримера прям в ядро в ISM VLAN бриджом сквозь рутера и агрегацию до access. Никакого multicast routing и прочих PIM-SM/PIM-DM, голый L2 + IGMP Snooping.

Share this post


Link to post
Share on other sites
Для меня возможность сэкономить 20% аплинка в час пик оправдывает экономически практически любые танцы с NAT'ом.
NAT -- это костыль и потенциальный источник проблем с масштабированием и возможной заменой пц-шлюза на какое-то брендовое решение. Во фре, например, один нат недостаточно фичастый и не дружит с task offloading (libalias), другой не масштабируется на SMP (pf), у третьего течет память (ipnat). Про natd я вообще не говорю. В Линуксе ситуация с натом менее безблагодатная, но у iptables тоже не все в порядке с блокировками. Если нужно экономить трафик, то проще большинству пользователей закрыть файрволом входящие соединения на порты <1024. Открывать по заявлению, может быть даже и за дополнительную плату. Эффект примерно тот же, что и от NATа.
4Г писюки прожуют и обсчитают без проблем уже сейчас.
С натом или без? Без ната верю, что обсчитают, но это еще смотря каким размером пакетов. Важен пакетрейт, а не гигабиты.
Edited by photon

Share this post


Link to post
Share on other sites

в ядро все равно будет устанавливаться что то типа Juniper MX80 или ASR, для целей управления услугами абонентов (шейпер, qos и т.д.), понятно что все это могут и PC, но не так удобно как нормальных BSR

а в чём удобство?

Share this post


Link to post
Share on other sites
jab, откуда сейчас отдаёшь мультикаст?

видел у некоторых провайдеров с пппое стоят прокси которые превращают мультик в юникаст по http.

костыль бесподобный.

У меня сейчас unicast. На IPoE Малтикаст буду гнать со стримера прям в ядро в ISM VLAN бриджом сквозь рутера и агрегацию до access. Никакого multicast routing и прочих PIM-SM/PIM-DM, голый L2 + IGMP Snooping.

квариером кто то должен быть, кто?

Share this post


Link to post
Share on other sites
в ядро все равно будет устанавливаться что то типа Juniper MX80 или ASR, для целей управления услугами абонентов (шейпер, qos и т.д.), понятно что все это могут и PC, но не так удобно как нормальных BSR
а в чём удобство?

MX80 обещают в районе 60-65к баксов, это за 4 десятки и 80гбит на Trio чипсете(с аппаратным натом, 64к очередей) c 2U

если пересчитать на писюки(концепция jab - "много мелких и дешёвых") за 2к бакса, предположим каждый из которых сделает гигабит с сервисами(нат,шейп,етц) то это получается 33 юнита и 33 гигабита :)

 

p.s. я так грубо прикинул, ну вы понели ;)

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

но вообщем то 2U против 33U очень даже сравнивается. с ISG(Subscriber Management) не в альфа стадии(модулем к iptables+ пара перловых скриптов ;)

Share this post


Link to post
Share on other sites
в ядро все равно будет устанавливаться что то типа Juniper MX80 или ASR, для целей управления услугами абонентов (шейпер, qos и т.д.), понятно что все это могут и PC, но не так удобно как нормальных BSR
а в чём удобство?

MX80 обещают в районе 60-65к баксов, это за 4 десятки и 80гбит на Trio чипсете(с аппаратным натом, 64к очередей) c 2U

если пересчитать на писюки(концепция jab - "много мелких и дешёвых") за 2к бакса, предположим каждый из которых сделает гигабит с сервисами(нат,шейп,етц) то это получается полностью забитая стойка и 42 гигабита :)

ну, думаю, jab просто не купил бы компов для 80гбит, когда по ТЗ нужно 2 с перспективой в 4.

 

к тому времени, когда сеть вырастет до 80гбит их НАТ будет стоить в разы дешевле

Share this post


Link to post
Share on other sites

здесь ещё получается запас по внутренней полосе(между пользователями), ведь весь трафик идёт через центр(брас), сколько там внешней полосы мало колебёт :)

Share this post


Link to post
Share on other sites

здесь ещё получается запас по внутренней полосе(между пользователями), ведь весь трафик идёт через центр(брас), сколько там внешней полосы мало колебёт :)

зачем гонять локалку через брас, когда она отлично может бегать между теми же 3627 по 10Гбит?

Share this post


Link to post
Share on other sites
здесь ещё получается запас по внутренней полосе(между пользователями), ведь весь трафик идёт через центр(брас), сколько там внешней полосы мало колебёт :)
зачем гонять локалку через брас, когда она отлично может бегать между теми же 3627 по 10Гбит?

потому что концепция браса не предполагает "локалку"(читайте "халява"), а предполагает "услуги"(читайте "деньги")

 

хотя народ умудряется и иптв полученый от home-ix (пере)продавать, совсем нюх потеряли :)

Share this post


Link to post
Share on other sites
здесь ещё получается запас по внутренней полосе(между пользователями), ведь весь трафик идёт через центр(брас), сколько там внешней полосы мало колебёт :)
зачем гонять локалку через брас, когда она отлично может бегать между теми же 3627 по 10Гбит?

потому что концепция браса не предполагает "локалку"(читайте "халява"), а предполагает "услуги"(читайте "деньги")

 

хотя народ умудряется и иптв полученый от home-ix (пере)продавать, совсем нюх потеряли :)

думаю, что при масштабах сети, выбирающей 2Гбит аплинка стоимость браса будет долго отбиваться тарифами на локалку. проще сразу сделать халявную локалку своим конкурентным преимуществом

Share this post


Link to post
Share on other sites

за неё ап можно смело брать, что нить в районе 50-100 рублей

не хотите, вычтем из вашего тарифа, нищебродов найдётся тьма, поверьте :)

 

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

да, арпу упадёт.

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

Share this post


Link to post
Share on other sites

Извиняюсь что вклиниваюсь но тоже возник небольшой смежный вопрос..

Тут упоминалось по поводу рационального / не рационального распределения белых адресов.

Я так понимаю при схеме влан на дом нам в помощь приходит ip unnumbered так ? Отсюда также вытекает что все узлы агрегации должны быть "снабжены" цыской.

И вопрос собственно в следующем...

Как же выгоднее сделать ? Ставить небольшие узлы агрегации на которых будет L2 Dlink и по десятку таких узлов сводить к уже "серьёзному" узлу где будет стоять 65й catalyst и рулить на L3 ? И на этом "серьёзном" узле собирать до 8-10к пользователей (не активных имею ввиду а подключенных), вланы со всего района города к примеру. Или покупать на все узлы что то вроде 3550-12G ?

Что выгоднее и перспективнее - наращивать пропускную способность от "мелкой агрегации" к "крупной" или везде распихивать L3 тем самым снижая оверхед трафика ?

Edited by pchol

Share this post


Link to post
Share on other sites

Умные вендоры рекомендуют в центр ставить мощную железку от 60к до ..... куда сводить все на уровне L2.

Так например Juniper E120 который отдается в районе 200к буржуев, способен выполнять роль управления сервисами абонента и пережувать до 120Гбит/сек трафика с равноценным пакетрейтом.

Т.е. фактически запас по прочности для сети до 50к юзеров огромен.

В приципе E серия мне очень нравится как BRS, но ценик кусается, менее перспективная в плане софта из-за JunosE, в отличии от продвигаемой MX серии с JunOs.

 

Но повторюсь, главное не то как и где назначать услуги, правильно в центре, а то как их доставить абоненту. Толи делать широковещательные домены, толи vlan-per-customer, в последнем случае DLINK на агреагции нервно курит.

 

Это при том, что если у вас сеть с 0 строится, а когда еще вопрос о модернизации существующей сети идет, это вообще ппц.

 

Просто хотелось бы услышать мнение тех у кого опыт эксплуатации сети с чистым IPoE скажем более 20к абонентов.

Share this post


Link to post
Share on other sites
Что выгоднее и перспективнее - наращивать пропускную способность от "мелкой агрегации" к "крупной" или везде распихивать L3 тем самым снижая оверхед трафика ?
Мы пошли путем наставив L3 везде кроме уровня доступа. Схема хороша своей маштабируемостью и относительным резервированием L3 протоколами (OSPF,BGP), сложность схемы в том, что рулить абонентами трудно. Фактически приходится рулить на доступе (ACL), как результат более тесная привязка к одному вендору.

 

- Неудобно постоянно рулить таким кол-во коммутаторов доступа (т.е. порядка 1000 штук вместо 1 но большой в центре), даже при начлии автоматизации процесса.

- Сложность оказания пакета IPTV (т.е. когда за бабки и несколько вариантов подписки).

- Еще сложнее в этой схеме настраивать QoS, из за различий между транспортом от центра к агрегации (L3) и между агрегациями, и доступом (L2), приходится применять разные схемы классификации и управления трафиком, лишний геморрой в общем.

 

и забудте про IP unnumber если клиентские вланы терминируется не на BRS а на промежуточной агрегации, фактически никаких полезных преимуществ такая схема не имеет (холи вары о достойной защите от всякого говна в сети имеет по дефолту опустим, продвинутые мыльницы от того же DLINK например DES3028 могут не хуже защить сеть).

Share this post


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

Аппаратный BSR это не это только управление локальными или интернет сервисами, это еще и мощный QoS для различных групп тарифов и абонентов, это еще и отказ от обсчета трафика по столь любимому пионернетами netflow, а к переходу к модели через raduis accounting, это в конце концов снижение стоимости обслуживания/владения,в отличии от армии писюков в кол-ве 4-10штук.

Share this post


Link to post
Share on other sites

Немного не понял ваших высказываний про ip unnumbred.

Я имел ввиду лишь то что с его помощью можно вполне себе удобно/экономно выдавать белые адреса в сегментах имея схему vlan на дом, и сохранять связность на том уровне где терминируется vlan.

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