The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Изначальное сообщение [ Отслеживать ]

"Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от off (ok) on 09-Фев-15, 20:58 
Есть два FastEthernet-канала (именно канала). Нужно сделать 200. Но подождите отвечать ECMP/L3 или LAG/L2. Я бы сюда не писал, если бы всё было так просто.

1. Мы не контролируем проходящие пакеты. Они могут быть L2 (CDP/LLDP/VTP/STP/dotQ/QinQ/FCoE/...), L3 (IP), MPLS, что угодно, Jumbo/не-Jumbo. Т. е. даже "port-channel load-balance vlan-src-dst-mixed-ip-port" и близко не делает более-менее равное распределение: подавляющая часть трафика идёт от одного MAC с одной стороны к другому MAC с другой стороны (т. к. это MPLS между соседями), соответственно, получается 110-120, никак не 200. Ну и один поток, понятно, максимум 100.

2. На эту тему у Juniper есть "Per-Packet Random Spray Load Balancing": [edit interfaces aex aggregated-ether-options load-balance] per-packet. НО! Вспоминаем, что эти две сотни - каналы. Весьма близкие по характеристикам, но, к сожалению, не идентичные, а плюс-минус 2-5 ms друг относительно друга. Таким образом, сразу натыкаемся на out-of-order пакетов (об этом и Juniper предупреждает). А для нас это критично. Т. е. между разными flow - плевать, но в пределах одного flow должно быть строго in order. А что есть flow - наше оборудование не знает, т. к. см. п. 1.

Уже всю голову сломал. Фактически, нужно что-то, что с одной стороны будет инкапсулировать L2, нумеровать пакеты и запихивать их в каналы либо поочерёдно, либо по какому-то принципу (пытаться определить, какие flow есть в потоке?), а с другой стороны иметь sequencing buffer на несколько пакетов/миллисекунд и собирать пакеты по порядку (или нет, если flow найдены и разбросаны по каналам?). Замечательный вариант - MLPPP, он это умеет ("ppp multilink slippage"), но MLPPP в принципе не бывает на PPPoE. А у нас пара Ethernet'ов, а не Serial'ов.

Что бы это могло быть? Может ли это быть Cisco не самых дорогих семейств (кроме CRS/ASR/Nexus :) Или какое-то другое не запредельно дорогое железо?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от eek (ok) on 09-Фев-15, 21:52 
> Есть два FastEthernet-канала (именно канала). Нужно сделать 200. Но подождите отвечать
> ECMP/L3 или LAG/L2. Я бы сюда не писал, если бы всё
> было так просто.
> 2. На эту тему у Juniper есть "Per-Packet Random Spray Load Balancing":
> [edit interfaces aex aggregated-ether-options load-balance] per-packet. НО! Вспоминаем,
> что эти две сотни - каналы. Весьма близкие по характеристикам, но,
> к сожалению, не идентичные, а плюс-минус 2-5 ms друг относительно друга.
> Таким образом, сразу натыкаемся на out-of-order пакетов (об этом и Juniper
> предупреждает).

Такое умеет только brocade когда оба порта сидят на одном asic.

Они фактически делают контролируемый delay и тем самым соблюдают порядок пакетов. Запрашивайте кейс, пусть делают предложение, если для вашей задачи в этом есть смысл. Сюда к стати отпишите потом сколько получилась цена вопросам.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от off (ok) on 09-Фев-15, 22:01 
> Такое умеет только brocade когда оба порта сидят на одном asic.
> Они фактически делают контролируемый delay и тем самым соблюдают порядок пакетов. Запрашивайте
> кейс, пусть делают предложение, если для вашей задачи в этом есть
> смысл. Сюда к стати отпишите потом сколько получилась цена вопросам.

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от eek (ok) on 09-Фев-15, 22:17 
> так цифры задержки у каналов не фиксированы, плавают. бывает, один чуть быстрее
> - а через полминуты наоборот, чуть медленнее. брокейды пакеты метят таймкодом,
> что ли?

Коллега, эта часть технологии нигде в документации подробно не описана (патенты жеж), показывали они эту мульку как часть презентации их новой фабрики. Преподносилось это под соусом, "мы так умеем, а больше никто не умеет". Что от части правда, но так же и правда что такое за дорого нафиг некому не надо. А за дешево им самим не интересно.

Ценник за их фабрику тогда объявить не захотели, но в кулуарах намекали что примерно как nexus + fabric path, по этой причине для меня интереса не представил. Что знал по теме я сказал, дальше лучше вопросы задавать brocade на прямую.  BTW никто из тех с кем общаюсь фабрику у брокейда так и не купил. (fabric path - встречается)

Мое сугубое мнение когда встают вопросы про магические технологии:
1) Перестать жрать кактус
2) Сделать qos + расширить каналы

Но вам думаю про ваши проблемы понятно значительно больше чем мне. Собственно и решать вам.

P.S. Попытайте еще вендоров которые делают wan оптимизаторы. Они как раз умеют и каналы мультиплексировать с плавающими задержками, только там счет вроде идет на десятки-сотни ms, как насчет едениц сказать сложно.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от off (ok) on 09-Фев-15, 22:21 
> 2) Сделать qos + расширить каналы
> Но вам думаю про ваши проблемы понятно значительно больше чем мне. Собственно
> и решать вам.

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от eek (ok) on 09-Фев-15, 22:22 
>> 2) Сделать qos + расширить каналы
>> Но вам думаю про ваши проблемы понятно значительно больше чем мне. Собственно
>> и решать вам.
> расширить каналы невозможно в принципе, иначе вопроса бы не было. это спутник.

Продублирую.

P.S. Попытайте еще вендоров которые делают wan оптимизаторы. Они как раз умеют и каналы мультиплексировать с плавающими задержками, только там счет вроде идет на десятки-сотни ms, как насчет едениц сказать сложно.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от off (ok) on 09-Фев-15, 22:29 
> P.S. Попытайте еще вендоров которые делают wan оптимизаторы. Они как раз умеют
> и каналы мультиплексировать с плавающими задержками, только там счет вроде идет
> на десятки-сотни ms, как насчет едениц сказать сложно.

это-то понятно... было бы, если бы был чистый ip-трафик. а он там почти весь mpls. т. е., конечно, с учётом php небольшая часть таки ip, но очень небольшая. wan-оптимизатор, который умеет сковырнуть метки, проанализировать получившийся трафик, а потом снова метки навесить, честно говоря, я даже представить не могу.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от eek (ok) on 09-Фев-15, 22:30 
> получившийся трафик, а потом снова метки навесить, честно говоря, я даже
> представить не могу.

Про TE + RSVP думали?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от off (ok) on 09-Фев-15, 22:43 
>> получившийся трафик, а потом снова метки навесить, честно говоря, я даже
>> представить не могу.
> Про TE + RSVP думали?

думали. очень сильно думали. но как и по какому принципу распихать в разные туннели разные пакеты, если для нас они почти все одинMAC-другойMAC-ethertype8847? т. е. наверное, можно попросить клиента разный трафик маркировать разным ip precedence, потом перенести это в их mpls exp, а нам использовать. но это же нельзя сделать динамически, и если вдруг распределение трафика сильно изменится по сравнению с тем моментом, когда будут выбраны критерии маркировки, опять получим ассимметрию и необходимость крутить руками.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от eek (ok) on 09-Фев-15, 23:11 
Не зацикливайтесь на пакетах, разрисуйте схему целиком (прямо с сервисами клиента) и посчитайте как протащить нужные сервисы через эти каналы, так, чтобы загрузка каждого отдельного линка была максимальной. (В конечном итоге вы же этого добиваетесь).

И потому уже считайте достаточно ли будет вам улучшить показатель со 120 мегабит до скажем 150-160 мегабит, ну и расчитывать на загрузку более 80% вряд-ли стоит.

Раз у вас большая часть MPLS - думайте в сторону TE+RSVP.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от off (ok) on 09-Фев-15, 23:17 
> Не зацикливайтесь на пакетах, разрисуйте схему целиком (прямо с сервисами клиента) и
> посчитайте как протащить нужные сервисы через эти каналы, так, чтобы загрузка
> каждого отдельного линка была максимальной. (В конечном итоге вы же этого
> добиваетесь).

а так хотелось не привлекать клиента к этому процессу... :( это ж хорошо, если они будут мониторить свой трафик и его распределение, да ещё и откликаться на наши призывы поменять что-то в своей консерватории. а если нет? обычный-то клиент своего провайдера в глубоком виду имеет. "я за сервис заплатил - давайте сервис, остальное меня не еб*т, SLA - в договоре".

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

12. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от eek (ok) on 10-Фев-15, 03:41 
> SLA - в договоре".

Ну в таком разе N+1 резервирование и никаких проблем :) И пункт в договоре, можем дать любую скорость, но в одну дудку не более 100мбит и на этом все.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

11. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от mr_gfd on 10-Фев-15, 01:08 
Если MLPPP взлетит - то это точно работает на нервном тике (microtik) и фряхе (mpd5 к Вашим услугам). естественно, никакого mppe+mppc и обязательно scrub для интерфейсов
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от off (ok) on 10-Фев-15, 15:18 
> Если MLPPP взлетит - то это точно работает на нервном тике (microtik)
> и фряхе (mpd5 к Вашим услугам). естественно, никакого mppe+mppc и обязательно
> scrub для интерфейсов

а как оно взлетит-то, если mlppp не бывает для pppoe?

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от mr_gfd on 10-Фев-15, 16:35 
>> Если MLPPP взлетит - то это точно работает на нервном тике (microtik)
>> и фряхе (mpd5 к Вашим услугам). естественно, никакого mppe+mppc и обязательно
>> scrub для интерфейсов
> а как оно взлетит-то, если mlppp не бывает для pppoe?

а доку по вышеприведенным продуктам почитать не судьба? или
pppoe_server:
        set link enable multilink
        set pppoe acname "bras13"
        set pppoe iface lagg1
        set pppoe service "*"

вот кусок рабочего конфига mpd.conf

у всех вдруг перестал работать?

и для микротика мануал

http://wiki.mikrotik.com/wiki/Manual:MLPPP_over_single_and_m...

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от off (ok) on 10-Фев-15, 19:48 
> вот кусок рабочего конфига mpd.conf
> у всех вдруг перестал работать?
> и для микротика мануал
> http://wiki.mikrotik.com/wiki/Manual:MLPPP_over_single_and_m...

ну, нет такого в стандарте, rfc 2516, 4938, 5578. ок, спасибо, попробую микротики с обеих сторон.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

19. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от mr_gfd on 10-Фев-15, 21:41 
>> вот кусок рабочего конфига mpd.conf
>> у всех вдруг перестал работать?
>> и для микротика мануал
>> http://wiki.mikrotik.com/wiki/Manual:MLPPP_over_single_and_m...
> ну, нет такого в стандарте, rfc 2516, 4938, 5578. ок, спасибо, попробую
> микротики с обеих сторон.

в https://tools.ietf.org/html/rfc2516
6. PPP Session Stage

   Once the PPPoE session begins, PPP data is sent as in any other PPP
   encapsulation.

и по https://tools.ietf.org/html/rfc1990 никаких link-layer specific особенностей нет, ктоме того, что пппое сервер и клиент должны использовать LCP negotiation, который по 2516 - RECOMMENDED

Multilink is based on an LCP option negotiation that permits a system
   to indicate to its peer that it is capable of combining multiple
   physical links into a "bundle".


Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

16. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от off (ok) on 10-Фев-15, 20:24 
> а доку по вышеприведенным продуктам почитать не судьба? или
> pppoe_server:
>         set link enable multilink
>         set pppoe acname "bras13"
>         set pppoe iface lagg1
>         set pppoe service "*"

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от mr_gfd on 10-Фев-15, 21:27 
>> а доку по вышеприведенным продуктам почитать не судьба? или
>> pppoe_server:
>>         set link enable multilink
>>         set pppoe acname "bras13"
>>         set pppoe iface lagg1
>>         set pppoe service "*"
> несколько ethernet указать невозможно, через запятую не принимает. PPPoE поверх аггрегированного
> интерфейса дает поляризацию в один из интерфейсов (MAC-адреса клиента и сервера
> постоянны)

это кусок конфига сервера для мультилинка на одном интерфейсе - получить полные 1500 байт mtu. для мультилинка в Вашем случае нужно поступать по иному - примерно так

set bundle disable round-robin
set bundle disable bw-manage
set bundle links L1 L2
set iface enable tcpmssfix
create link static L1 pppoe
set auth authname xxx
set auth password xxx
set pppoe iface if1
set pppoe service "bla-bla"
set link enable multilink
set link enable shortseq
set link disable protocomp
set link mrru 1500
set link mtu 1492
set link action bundle B1
open

create link static L2 pppoe
set auth authname xxx
set auth password xxx
set link max-redial 0
set link keep-alive 10 60
set pppoe iface if2
set pppoe service "bla-bla"
set link enable multilink
set link enable shortseq
set link disable protocomp
set link mrru 1500
set link mtu 1492
set link action bundle B1
open

http://mpd.sourceforge.net/doc5/mpd20.html#20

как сервер настраивать - в доке тоже есть.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Получить 200 Mb/s из двух 100 Mb/s (маршрутизация, коммутация)"  +/
Сообщение от mr_gfd on 10-Фев-15, 21:28 
ну и не забыть
set link bandwidth для бандлов свой
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру