Dimkers

Кэп, пару вопросов. 1) у тех самых соседей сколько стоит инет? 2) у тех самых соседей нет ПОНа? Его там на таких конских ценах не строит никто, правда ведь? 3) беспроводные провайдеры где будут располагать БС в городской застройке, кэп скажет? Особенно после того, как бабушкам шепнуть про излучение Ну и да, продажи совсем падают, что начинается агония? Ну будет выгоден и интересен радиодоступ - будут у тебя покупать его. Не будет выгоден - не будут. Чё ты тужишься? На данном этапе развития - никому твой ШБД не вперся. Смирись ты уже. А создавать типа спрос ту

interface EPON0/1 switchport trunk vlan-allowed 1501 switchport mode trunk switchport protected 1 interface EPON0/1:5 epon onu port 1 ctc vlan mode tag 1501 priority 0 epon onu port 1 ctc loopback detect epon onu port 1 mac address-table dynamic maximum 8 epon onu port 1 storm-control mode 2 threshold 256 sh mac address-table int epoN 0/1 Mac Address Table (Total 46) ------------------------------------------ Vlan Mac Address Type Ports ---- ----------- ---- ----- 1501 f4f2.6df4.d795 DYNAMIC epon0/1:5 Все работает.

Дык так и есть Как раз коряво балансится у людей. Собсно как при ассиметрии спасет разделение по tcp портам? Вот и для меня загадка. Тут уже включаются другие механизмы, о которых я говорил ранее, но уж никак не облегчит жизнь разделение по tcp портам...

Так это же узкое место будет при разнесении по порту Ну как ты раскинешь https? Оптимальный вариант - чётный влево, нечётный вправо. Все.

Ну глупость же. Ей богу. Ну даже если полетит у тебя пакет одному адресату разными каналами. И что? Не, эта тема смотрю далеко ушла от самого православного радиобарахла... Дальше можно продолжать, но не пальцем в небо. Ты хоть бы почитал про очереди и проверку последовательности пакетов....

Чисто практически, чётный и не чётный делается простым : если 1 то влево, иначе вправо. Все. А переваривать в коммутации по паттерну - трудозатратные вещь и сравнима с case. Это уже дело не коммутаторов, а роутеров или какихнить dpi. Кстати именно поэтому в микротике, например том же rb4011 на arm(да и не только микротике) при увеличении числа правил в фаерволе(iptables) падает производительность. Потому как это, повторюсь - трудозатратная операция. И собсно зачем делать разделение трафика в радиоканалы по tcp/udp - загадка для меня, с головой достаточно делать как в lacp - по mac

Возможно лет 10 назад и было. Сейчас как то все со связностью стабильно. У нормальных аплинков префы не теряются.

Ни нервничай Порты и протоколы тут при том, что балансится у камбалы по.... Для сравнения по паттерну нужно выполнять трудозатратные действия. Т.е. брать кадр и сравнивать. Что-то с чем то. Это более затратная операция для железки, чем чётный влево, нечётный вправо. Это сродни тому, что на слабых железках тест tcp показывает меньшую скорость, чем udp. Казалось бы. Пакеты передавать в обоих случаях же. А нет... Не понял? Мне тоже пофиг Я и так тут много рассказал. Ну и собсно как сравнение по паттерну влияет на алгоритм балансировки - никто так и не ответил Вообще д

Я бы нат, шейп и терминацию делал в одном тазике, а БГП - на другом. Вдруг что, поставил для терминации/ната/шейпа ещё один серв и все. А БГП оставить под тупое перекладывание пакетиков. Он продавит в этом случае много. В идеале - 2 БГП. Для резерва.

x520 на 2 дырки - с головой.

Зачем? Сейчас со связанностью все более менее отлично. Если никому из клиентов не нужен фулл - то смысла в его приеме нет. E5649 c подрезанным контраком тянул не запинаясь около 15Г. Нахухры? там в ЧНН 5 Гиг.

Терминировать и шейпить тоже нужно?

Палкан! Это все фигня. Как коммутационная матрица, хардварный ЛАСП, load-balancing и паттерны связаны между собой?

Чтобы это работало, туда надо впихнуть... А не давай не так. Давай пруф, что в камбале алгоритм балансировки работает по твоим паттернам Ну и собсно даже вдруг если это так, то раскрой тайну, как идёт сравнение пришедшего кадра с паттерном.

ты для начала посиди на скорости 56 кбит и с потерями больше 5% Просил он.

Не пускать на него мультик свыше? Иначе я аж растерялся. Без АСL и полностью зарезать...

А как можно забалансить по IP packets source address and TCP/UDP port: Source IP & Source TCP/UDP Port; IP packets receive address and TCP/UDP port: Receive IP & Receive Port TCP/UDP Port; не заглядывая? У тебя прилетел кадр(он же фрейм), обернутый в кучку оберток. Как узнать порт? Да и зачем в принципе?

Так я подумал. Скажи ты - зачем заглядывать в пакет настолько глубоко, чтоб балансить трафик в засраном эфире? А? Чем номер порта и тип протокола в этом поможет?

Да? И какой же он уникальный??? Так это было пару дней назад. е$#ть у вас скоростя... Даж на прошлой странице твоей пук был: Это поэтому проц укатывается в полку? Т.е. пришедший кадр со свича дерибанится аж до TCP и потом разделяют? Дебилы шоль?

Самокритика это хорошо.

Ты дебил? Объясню на пальцах. порт 10G свич - (порт LACP из 2*1G<->порт LACP из 2*1G) - порт 10G свич Свич порт 1G - камбиум порт 1G <-> (камбиум 2 радиоканала WiFI) <-> камбиум порт 1G - свич порт 1G А что делают програмисты камбиум?

Дело в том, что в предмете вы поплыли. Ну собсно как вы и ваши прихвостни с юнидаты помагаете людям в решении проблем - мне думать страшно после ваших постов... разве что вы тупая прокладка между потребителем и разработчиком. Не более. Ржу Бл#. Ты хотя сам понял шо написал? У них разные рукажопы код пишут. да? В блялинке осилили, а в камбиуме - ну не шмогла....

Дык и мы договор хотим побачить,... Но нэт... Но в данном случае и посте про то, что ТС хочет чтоб за него порешали его проблемы - он прав.

А при чем тут коммутация пакетов в матрице, которая зачастую вообще проходит по номеру порта, к балансировке в LAG\LACP?

Я слушаю далее сказки венского леса.