Есть два 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 :) Или какое-то другое не запредельно дорогое железо?
> Есть два 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 и тем самым соблюдают порядок пакетов. Запрашивайте кейс, пусть делают предложение, если для вашей задачи в этом есть смысл. Сюда к стати отпишите потом сколько получилась цена вопросам.
> Такое умеет только brocade когда оба порта сидят на одном asic.
> Они фактически делают контролируемый delay и тем самым соблюдают порядок пакетов. Запрашивайте
> кейс, пусть делают предложение, если для вашей задачи в этом есть
> смысл. Сюда к стати отпишите потом сколько получилась цена вопросам.так цифры задержки у каналов не фиксированы, плавают. бывает, один чуть быстрее - а через полминуты наоборот, чуть медленнее. брокейды пакеты метят таймкодом, что ли?
> так цифры задержки у каналов не фиксированы, плавают. бывает, один чуть быстрее
> - а через полминуты наоборот, чуть медленнее. брокейды пакеты метят таймкодом,
> что ли?Коллега, эта часть технологии нигде в документации подробно не описана (патенты жеж), показывали они эту мульку как часть презентации их новой фабрики. Преподносилось это под соусом, "мы так умеем, а больше никто не умеет". Что от части правда, но так же и правда что такое за дорого нафиг некому не надо. А за дешево им самим не интересно.
Ценник за их фабрику тогда объявить не захотели, но в кулуарах намекали что примерно как nexus + fabric path, по этой причине для меня интереса не представил. Что знал по теме я сказал, дальше лучше вопросы задавать brocade на прямую. BTW никто из тех с кем общаюсь фабрику у брокейда так и не купил. (fabric path - встречается)
Мое сугубое мнение когда встают вопросы про магические технологии:
1) Перестать жрать кактус
2) Сделать qos + расширить каналыНо вам думаю про ваши проблемы понятно значительно больше чем мне. Собственно и решать вам.
P.S. Попытайте еще вендоров которые делают wan оптимизаторы. Они как раз умеют и каналы мультиплексировать с плавающими задержками, только там счет вроде идет на десятки-сотни ms, как насчет едениц сказать сложно.
> 2) Сделать qos + расширить каналы
> Но вам думаю про ваши проблемы понятно значительно больше чем мне. Собственно
> и решать вам.расширить каналы невозможно в принципе, иначе вопроса бы не было. это спутник.
>> 2) Сделать qos + расширить каналы
>> Но вам думаю про ваши проблемы понятно значительно больше чем мне. Собственно
>> и решать вам.
> расширить каналы невозможно в принципе, иначе вопроса бы не было. это спутник.Продублирую.
P.S. Попытайте еще вендоров которые делают wan оптимизаторы. Они как раз умеют и каналы мультиплексировать с плавающими задержками, только там счет вроде идет на десятки-сотни ms, как насчет едениц сказать сложно.
> P.S. Попытайте еще вендоров которые делают wan оптимизаторы. Они как раз умеют
> и каналы мультиплексировать с плавающими задержками, только там счет вроде идет
> на десятки-сотни ms, как насчет едениц сказать сложно.это-то понятно... было бы, если бы был чистый ip-трафик. а он там почти весь mpls. т. е., конечно, с учётом php небольшая часть таки ip, но очень небольшая. wan-оптимизатор, который умеет сковырнуть метки, проанализировать получившийся трафик, а потом снова метки навесить, честно говоря, я даже представить не могу.
> получившийся трафик, а потом снова метки навесить, честно говоря, я даже
> представить не могу.Про TE + RSVP думали?
>> получившийся трафик, а потом снова метки навесить, честно говоря, я даже
>> представить не могу.
> Про TE + RSVP думали?думали. очень сильно думали. но как и по какому принципу распихать в разные туннели разные пакеты, если для нас они почти все одинMAC-другойMAC-ethertype8847? т. е. наверное, можно попросить клиента разный трафик маркировать разным ip precedence, потом перенести это в их mpls exp, а нам использовать. но это же нельзя сделать динамически, и если вдруг распределение трафика сильно изменится по сравнению с тем моментом, когда будут выбраны критерии маркировки, опять получим ассимметрию и необходимость крутить руками.
Не зацикливайтесь на пакетах, разрисуйте схему целиком (прямо с сервисами клиента) и посчитайте как протащить нужные сервисы через эти каналы, так, чтобы загрузка каждого отдельного линка была максимальной. (В конечном итоге вы же этого добиваетесь).И потому уже считайте достаточно ли будет вам улучшить показатель со 120 мегабит до скажем 150-160 мегабит, ну и расчитывать на загрузку более 80% вряд-ли стоит.
Раз у вас большая часть MPLS - думайте в сторону TE+RSVP.
> Не зацикливайтесь на пакетах, разрисуйте схему целиком (прямо с сервисами клиента) и
> посчитайте как протащить нужные сервисы через эти каналы, так, чтобы загрузка
> каждого отдельного линка была максимальной. (В конечном итоге вы же этого
> добиваетесь).а так хотелось не привлекать клиента к этому процессу... :( это ж хорошо, если они будут мониторить свой трафик и его распределение, да ещё и откликаться на наши призывы поменять что-то в своей консерватории. а если нет? обычный-то клиент своего провайдера в глубоком виду имеет. "я за сервис заплатил - давайте сервис, остальное меня не еб*т, SLA - в договоре".
> SLA - в договоре".Ну в таком разе N+1 резервирование и никаких проблем :) И пункт в договоре, можем дать любую скорость, но в одну дудку не более 100мбит и на этом все.
Если MLPPP взлетит - то это точно работает на нервном тике (microtik) и фряхе (mpd5 к Вашим услугам). естественно, никакого mppe+mppc и обязательно scrub для интерфейсов
> Если MLPPP взлетит - то это точно работает на нервном тике (microtik)
> и фряхе (mpd5 к Вашим услугам). естественно, никакого mppe+mppc и обязательно
> scrub для интерфейсова как оно взлетит-то, если mlppp не бывает для pppoe?
>> Если 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...
> вот кусок рабочего конфига mpd.conf
> у всех вдруг перестал работать?
> и для микротика мануал
> http://wiki.mikrotik.com/wiki/Manual:MLPPP_over_single_and_m...ну, нет такого в стандарте, rfc 2516, 4938, 5578. ок, спасибо, попробую микротики с обеих сторон.
>> вот кусок рабочего конфига 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 StageOnce 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".
> а доку по вышеприведенным продуктам почитать не судьба? или
> pppoe_server:
> set link enable multilink
> set pppoe acname "bras13"
> set pppoe iface lagg1
> set pppoe service "*"несколько ethernet указать невозможно, через запятую не принимает. PPPoE поверх аггрегированного интерфейса дает поляризацию в один из интерфейсов (MAC-адреса клиента и сервера постоянны)
>> а доку по вышеприведенным продуктам почитать не судьба? или
>> 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
opencreate 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
openhttp://mpd.sourceforge.net/doc5/mpd20.html#20
как сервер настраивать - в доке тоже есть.
ну и не забыть
set link bandwidth для бандлов свой