sexst
Забавный факт, кстати. Тупой roundrobin в железе геморройнее реализовать чем консистентный порт на основе хеша посчитать.
Stanislav
ну и на хуа например можно глянуть как бакеты маппятся в порты
Stanislav
в хуа кстати есть раунд робин )
sexst
ток сначала от хэша маппинг в бакеты, а бакеты в порты ) сразу в порты не получится, если портов нечетное количество например.
hash value MOD ports count = LAG port index. Это Для работы в железе вообще операцией не считается. А вот если нет прямого соответствия, а оно постоянно перерапределяется, то там лукап по какой-то таблице делать нужно. То есть если хеш со значением 0x01 был в первом порту LAG'А, а потом его перенесли в седьмой, то это уже не посчитаешь
sexst
в хуа кстати есть раунд робин )
Это для случаев когда все охуительно работает, а тебе боли хочется немного=) Не ну really. Там же даже разная протяженность оптики между членами LAG гадить потенциально начинает=)
sexst
Иииии? А как хеш потом на другой порт прибивается и где это соответствие хранится? Какой размер хеша вообще?
sexst
А как тогда пакетики с хешем, скажем, 0x01 порт то меняют?
Stanislav
А как тогда пакетики с хешем, скажем, 0x01 порт то меняют?
ну у тебя допустим 3 порта мапятся в 64 бакета. типа по умолчанию 1, 2, 3, 1, 2, 3, 1, 2, 3 и тд 64 раза. 1 линк перегружен, тогда допустим можно сделать чтобы в этих 64 бакетах 1 линк реже встречался, например не 21 раз, а 15. 2 и 3 чаще встречаться будут. хэш должен быть длиннее бакета конеш.
sexst
Пришел пакет. Мы берем и считает хеш из заголовков. Считаем всегда по одному алгоритму. Например, XORим байты оттуда по одному и получаем в итоге однобайтный хэш. Один байт может иметь 256 разных значений. Эти значения распределяются по портам LAG. То есть в простом случае мы считаем что если у нас восемь портов, а хеш равен 0,9,17,25..., то кидаем в первый порт в LAG, если 1,8,19,26... во второй итд. Это часто тупо остатком от деления одного на второе делается. Но если мы перераспределяем хеши между портами периодически, то делить не покатит. Нужно где-то смотреть в какой порт выплевывать пакет при полученном для него значении хеша. То есть это соответствие где-то хранится и периодически обновляется. То есть для каждого пакета мы в память лишний раз лезем. Вот подробности мне и интересны в разрезе моей проблемки одной.
Stanislav
Пришел пакет. Мы берем и считает хеш из заголовков. Считаем всегда по одному алгоритму. Например, XORим байты оттуда по одному и получаем в итоге однобайтный хэш. Один байт может иметь 256 разных значений. Эти значения распределяются по портам LAG. То есть в простом случае мы считаем что если у нас восемь портов, а хеш равен 0,9,17,25..., то кидаем в первый порт в LAG, если 1,8,19,26... во второй итд. Это часто тупо остатком от деления одного на второе делается. Но если мы перераспределяем хеши между портами периодически, то делить не покатит. Нужно где-то смотреть в какой порт выплевывать пакет при полученном для него значении хеша. То есть это соответствие где-то хранится и периодически обновляется. То есть для каждого пакета мы в память лишний раз лезем. Вот подробности мне и интересны в разрезе моей проблемки одной.
да сразу порт не определают, сначала бакет, я вот прям с хуа щас копирну
Stanislav
<hmir1>display trunkfwdtbl e 1 Eth-Trunk1's forwarding table is: XGigabitEthernet0/0/1 XGigabitEthernet0/0/2 XGigabitEthernet0/0/3 XGigabitEthernet0/0/4 XGigabitEthernet0/0/1 XGigabitEthernet0/0/2 XGigabitEthernet0/0/3 и тд
Stanislav
<hmir1>display trunk conf -------------------------------------------------- Item Default Current Configured -------------------------------------------------- trunk-group 128 32 32 trunk-member 8 64 64 --------------------------------------------------
Stanislav
это типа бакеты
sexst
Bucket это понятно опять же, я упрощаю
Но там все равно целый слой дополнительных операций потенциально рисуется
Stanislav
в 1 массив залезть и посмотерть выходной интерфейс тока и усё )
sexst
в 1 массив залезть и посмотерть выходной интерфейс тока и усё )
А если его переписывают, то, возможно, подождать пока лок не снимут. А еще это долго по меркам железа в память лишний раз тащиться ради каждого пакета. А еще это не решает моей конкретной проблемы=) Ну и любопытство, мать его, тупо любопытство
vitex
sexst
Проблема в повешенном на меня тикете по дебильному триггеру на "Разбалансировку утилизации линков в LAG". Там толстый монопоток от одного клиента сворачивается, естессно, в один хеш и грузит один порт лишним гигабитом. А так как там утилизации всего нифига, то получается один порт работает сильно больше других. Хотя до потолка ему как до Луны. Объяснять что триггер сам по себе бредовый мне за год надоело, вяло ищу способы его разрешить не меняя ничего в линках.
sexst
можно пояснить за термин "дополнительных лукапов выходного порта"? это что за зверь такой?
Ну дополнительно лазить к какую-то табличку где записано соответствие хэш-порт
sexst
Это в обычный fib не запихать при всем желании
sexst
256 бакетов насколько помню джуна
Чет пока ощущение что они у openvswitch всю идею одолжили. Если судить по времени внедрения=)
vitex
чем необычный отличается от обычного?
sexst
а что есть обычный фиб?
fib у каждого крупного вендора может и отличаться по реализации. "Обычный", согласен, зря это слово написал. Просто fib
Andrey
Andrey Ustinovich, [28.06.18 14:21] https://rospravosudie.com/court-kurchatovskij-rajonnyj-sud-g-chelyabinska-chelyabinskaya-oblast-s/act-106708020/ Andrey Ustinovich, [28.06.18 14:21] об обязании демонтажа оптико - волокнистых линий Andrey Ustinovich, [28.06.18 14:21] ВОЛОКНИСТЫХ БЛЯТЬ
Ilya
flex-e ? :)
Ilya
@orlik че там, 1к в лаге щас можно в МХ сделать?
Tema
flex-e ? :)
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/link-aggregation-mixed.html
Tema
Starting with Junos OS Release 14.1R1 and 14.2, support for mixed rates on aggregated Ethernet bundles is extended to MX240, MX480, MX960, MX2010, and MX2020 routers. You can now configure the member links with any combination of rates—10-Gigabit Ethernet, 40-Gigabit Ethernet, and 100-Gigabit Ethernet—on an aggregated Ethernet bundle.
Ilya
link members
Tema
опять же давно тут уже всё это обсуждали ))
Tema
и признали УГ
Tema
может сейчас мнение поменялось
Ilya
sexst
Ага и DF бит еще того заодно... Я уже посмотрел доклад, не поможет оно мне конкретно с этим
Stanislav
тысяча гигабитных линков это что за лаг на терабит )
sexst
Если речь про 1к линков в LAG, то нет - до 64. Там 31 бит считается, но хеш еще и в других местах нужен. Если про 1G - тоже нет)
sexst
А я только досмотрел :-P И вообще тематические дискуссии- полезно
vitex
Драм вполне себе справляется Зачем? На нексусах есть сочетание драм+ткам но там это для решения коллизий хеша А на том же qfx10k все в драме
vitex
У нексуса из за возможных коллизий хеша в драме Часть префиксов помещается в ткам Я с этим сталкивался когда фулл заливал в n93180
sexst
Линк толстый. Утилизация микроскопическая. Один периодический поток больше чем все остальное в сумме по полосе. И тут как ни балансируй, линк, получивший этот поток будет загружен больше остальных. Я надеялся на анализ чего-то глубже L4, но не взлетело)
Ilya
да, мне понравилось
sexst
Тупо udp в один поток. Похоже на какой-то извращенский способ быстро бекапы или апдейты лить, обходя проблемы TCP со скоростью при больших RTT. Проприетарщина таким страдать любит. Велосипедами с гарантированной доставкой поверх UDP в смысле.
Stanislav
а если 1к 100г линков?)
ну таких плотных соточных карт ещё нет )
Tema
ага
sexst
Да ну, учитывая что кроме меня ниркто не страдает, нунах просто и все=)
vitex
Да можно хоть тупо первые n байт хэшировать только вот воздействие на аппликейшн будет такое же как и при перпакете
sexst
Глубже л4 это как? Там глубже уже некуда
Только что GTP упомянули тут
vitex
В смысле двойной?
vitex
Только что GTP упомянули тут
Это ещё одна инкапсуляция
Tema
а у меня был кейс когда попался pr и нихера не Работало)))
sexst
DPI нужен скорее чтобы у всяких менеджеров
sexst
Tema
я просто работал только с такими проблемами))
Vladimir
а если 1к 100г линков?)
звучит как бюджет нескольких стран
sexst
Есть разные варианты у разных вендоров опять же. Может хеш еще раз берут. Может первый хэш на начало списка указывает.
vitex
Возможно Имхо сначала делается Лукас в ткаме, потом в драм А может и одновременно Так далеко я уже не разбирался
vitex
Лукап
vitex
Лукас блин :)
vitex
Ну так хэш в драме там явно слабее
Ilya
там ограничения есть или ты просто ради интереса?
sexst
Те же джуны считают два сразу. Оно аппаратно сделано и не стоит ничего вообще
ntwrk_bot
Добро пожаловать! Ознакомиться с правилами группы можно по ссылке.
Evgeniy
Может кто подскажет. Есть linux и windows устройства. Подключены друг к другу через свитч. IP выставлены, маски подсетей тоже, но не пингуются почему-то Но если к этому делу подрубить windows server, то все начинает работать не пойму почему так происходит
Arthur
посмотреть arp -a на windows и arp на linux
Anonymous
тишут))) 1- коммутатор управляемы 2 - арпы 3- какая адресация прописана вариаций много из указанного вопроса вытекает. Начиная от не верно указанной адресации, вланов и ит.д.