sexst
Забавный факт, кстати. Тупой roundrobin в железе геморройнее реализовать чем консистентный порт на основе хеша посчитать.
Stanislav
ну и на хуа например можно глянуть как бакеты маппятся в порты
Stanislav
в хуа кстати есть раунд робин )
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
--------------------------------------------------
sexst
Stanislav
это типа бакеты
Stanislav
в 1 массив залезть и посмотерть выходной интерфейс тока и усё )
Stanislav
vitex
vitex
sexst
Проблема в повешенном на меня тикете по дебильному триггеру на "Разбалансировку утилизации линков в LAG". Там толстый монопоток от одного клиента сворачивается, естессно, в один хеш и грузит один порт лишним гигабитом. А так как там утилизации всего нифига, то получается один порт работает сильно больше других. Хотя до потолка ему как до Луны. Объяснять что триггер сам по себе бредовый мне за год надоело, вяло ищу способы его разрешить не меняя ничего в линках.
sexst
sexst
Это в обычный fib не запихать при всем желании
vitex
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
Ilya
Tema
опять же давно тут уже всё это обсуждали ))
Tema
и признали УГ
Tema
может сейчас мнение поменялось
Ilya
sexst
sexst
Ага и DF бит еще того заодно...
Я уже посмотрел доклад, не поможет оно мне конкретно с этим
Stanislav
тысяча гигабитных линков это что за лаг на терабит )
sexst
Если речь про 1к линков в LAG, то нет - до 64. Там 31 бит считается, но хеш еще и в других местах нужен.
Если про 1G - тоже нет)
sexst
А я только досмотрел :-P
И вообще тематические дискуссии- полезно
vitex
Драм вполне себе справляется
Зачем?
На нексусах есть сочетание драм+ткам но там это для решения коллизий хеша
А на том же qfx10k все в драме
vitex
У нексуса из за возможных коллизий хеша в драме
Часть префиксов помещается в ткам
Я с этим сталкивался когда фулл заливал в n93180
sexst
Линк толстый. Утилизация микроскопическая. Один периодический поток больше чем все остальное в сумме по полосе. И тут как ни балансируй, линк, получивший этот поток будет загружен больше остальных. Я надеялся на анализ чего-то глубже L4, но не взлетело)
Ilya
да, мне понравилось
Ilya
sexst
Тупо udp в один поток. Похоже на какой-то извращенский способ быстро бекапы или апдейты лить, обходя проблемы TCP со скоростью при больших RTT. Проприетарщина таким страдать любит. Велосипедами с гарантированной доставкой поверх UDP в смысле.
Tema
Tema
ага
sexst
Да ну, учитывая что кроме меня ниркто не страдает, нунах просто и все=)
vitex
vitex
Да можно хоть тупо первые n байт хэшировать только вот воздействие на аппликейшн будет такое же как и при перпакете
sexst
vitex
В смысле двойной?
vitex
Tema
а у меня был кейс когда попался pr и нихера не Работало)))
sexst
DPI нужен скорее чтобы у всяких менеджеров
sexst
Tema
я просто работал только с такими проблемами))
sexst
Есть разные варианты у разных вендоров опять же. Может хеш еще раз берут. Может первый хэш на начало списка указывает.
vitex
Возможно
Имхо сначала делается Лукас в ткаме, потом в драм
А может и одновременно
Так далеко я уже не разбирался
vitex
Лукап
vitex
Лукас блин :)
vitex
Ну так хэш в драме там явно слабее
Ilya
sexst
Ilya
там ограничения есть или ты просто ради интереса?
sexst
Те же джуны считают два сразу. Оно аппаратно сделано и не стоит ничего вообще
Ilya
vitex
ntwrk_bot
Добро пожаловать! Ознакомиться с правилами группы можно по ссылке.
Evgeniy
Может кто подскажет.
Есть linux и windows устройства. Подключены друг к другу через свитч. IP выставлены, маски подсетей тоже, но не пингуются почему-то
Но если к этому делу подрубить windows server, то все начинает работать
не пойму почему так происходит
Arthur
посмотреть arp -a на windows
и arp на linux
Vitaly
Anonymous
тишут))) 1- коммутатор управляемы
2 - арпы
3- какая адресация прописана
вариаций много из указанного вопроса вытекает. Начиная от не верно указанной адресации, вланов и ит.д.
Andrey