[alibek]

28 минут назад, Умник сказал:

В IPv4 пакеты с IP options очень часто обрабатываются только на CPU. Платформа с7600 никогда не умела этого в железе, например.

Это довольно старая платформа. Нынче аппаратные ускорители даже на домашних устройствах встречаются, например на Кинетиках.

Ну и размер заголовков все же сильно разный, даже при программной обработке это будет заметную разницу давать.

[Умник]

Цитата

Нынче аппаратные ускорители даже на домашних устройствах встречаются, например на Кинетиках

Верно. Вопрос только в том, что они могут ускорять, а что отправляют на обработку в CPU. Я согласен, что c7600 довольно старая платформа, но судя по дате публикации draft-peng-v6ops-hbh-06 (2021 год), проблема эффективной обработки HBH все еще актуальна.

[Ivan_83]

Ну хватит уже стонов, вон нафигачили AV1 в кремнии, а такую мелочь как разбор заголовков и подавно сделают без проблем.

Да и софтварно на современных х86/арм это тоже не проблема.

Прожевать 100 или меньше байт - плёвое дело, это 2-4 кеш линии проца.

[sdy_moscow]

2 часа назад, Ivan_83 сказал:

3. Разбор IP options не такой уж затратный, условно можно сказать что каждая опция это примерно такой же оверхэд как одно правило в фаере.

Ну-ну.

А скажи мне Ваня, в каком месте в пакете искать тип протокола (UDP/TCP) и номер порта?

 

3 часа назад, FSA сказал:

Интересно тут цензура работает. Тебя оскорбляют, а ты в ответ не можешь.

1. Тут форум профессиональных операторов, а не пользователей любителей-гигабита.

2. Я вас не оскорблял, а лишь пояснил Вам, как операторы относятся к тем, кто много хочет, но мало платит.

3. СочуЙствую,  но цензура работает всегда. Прямые оскорбления и писать матом на форуме не надо , учитесь пропускать буквы и применять правильные формулировки

 

28 минут назад, Ivan_83 сказал:

Прожевать 100 или меньше байт - плёвое дело, это 2-4 кеш линии проца.

Особенно на паре сотен миллионов pps... ню ню...

[Ivan_83]

12 minutes ago, sdy_moscow said:

А скажи мне Ваня, в каком месте в пакете искать тип протокола (UDP/TCP) и номер порта?

Скажу так: я написал свои собственные разборщики DNS, DHCP4 и это не затратно - прыгаешь себе по оффсетами и всё.

 

13 minutes ago, sdy_moscow said:

Особенно на паре сотен миллионов pps... ню ню...

Это всегда можно отбалансировать хоть до тысячи древних длинков.

И потом, ты же даже не представляешь себе где узкие места в сетевом стёке, но пытаешь тут убедить что таким местом станет именно разбор опций.

Это не так.

Ещё раз: каждая IP опция примерно эквивалентна одному простому правилу в фаерволе, типа drop tcp port xxx.

5-10 подобных правил погоды давно не делают.

[sdy_moscow]

20 минут назад, Ivan_83 сказал:

Это всегда можно отбалансировать хоть до тысячи древних длинков.

Мне кажется ты не понял до сих пор, речь не про Линух сервера, в стеке которого ты ковыряешься, а про железо с 48 портами, которое желательно что-бы кушала ватт 20-30 и честно прогоняло с каждого порта 500 мегабит в пару 10 Гб портов, откинув отдельные "опасные" пакеты.

[Ivan_83]

1 minute ago, sdy_moscow said:

Мне кажется ты не понял до сих пор, речь не про Линух сервера, в стеке которого ты ковыряешься, а про железо с 48 портами, которое желательно что-бы кушала ватт 20-30 и честно прогоняло с каждого порта 500 мегабит в пару 10 Гб портов, откинув отдельные "опасные" пакеты.

Ты серьёзно думаешь что кремнивый бюджет для AV1 потянули а для IPv6 не потянут?

20-30 Ватт - это твоя фантазия, даже банальные свичи на 1г х48 без л3 жрут больше, а если там 10г хотя бы пара штук - то и подавно.

 

И потом, IPv4 себя исчерпал, как ни крути.

Идеи расширить его адресацию за счёт костылей - ущербны, как и всякие NAT которые откровенно задрали и противоречат идеологии сети где каждый может взаимодействовать с каждым напрямую.

IPv6 всё равно нужно внедрять а не придумывать какие то отмазки.

[sdy_moscow]

@Ivan_83 Ты соскакиваешь, речь про Л2, да и потребление около 20-30 ватт сейчас в штатном режиме работы коммутатора - реально. Просто ты привык возиться с задачами, как ты написал "другого уровня".

 

Более того, если смотреть на Джумбо фрэймз, то там вообще желательно передавать пакеты ДО их полного получения, иначе у тебя начинают расти задержки, а если ты не знаешь в каком месте будет нужная информация - может быть даже в самом конце пакета - то всё это резко начинает жрать память и вносить джитеры - и тут или цена в космос, или потери.

 

В общем - ГАВНО этот v6 для современного ИНТЕРНЕТА! Но возиться с ним придется, поскольку альтернатив пока кроме роста использования CG-NAT не так много. НУ или костылей еще понаставят и назовут V6.1.

[Ivan_83]

37 minutes ago, sdy_moscow said:

речь про Л2, да и потребление около 20-30 ватт сейчас в штатном режиме работы коммутатора - реально.

Пока портов мало и нет 2,5 или 10г.

Я же искал себе домой с пассивкой управляшку и в курсе.

 

39 minutes ago, sdy_moscow said:

Более того, если смотреть на Джумбо фрэймз, то там вообще желательно передавать пакеты ДО их полного получения, иначе у тебя начинают расти задержки, а если ты не знаешь в каком месте будет нужная информация - может быть даже в самом конце пакета - то всё это резко начинает жрать память и вносить джитеры - и тут или цена в космос, или потери.

Что, теперь коммутаторы не StoreAndForward уже?

А если ты про всякие роутеры то там нет вариантов, пакеты выгребаются пачками и так же сливаются в сетевуху пачками.

 

39 minutes ago, sdy_moscow said:

В общем - ГАВНО этот v6 для современного ИНТЕРНЕТА!

Да да, то ли дело те протоколы которые вы сами написали, вот они то всех лучшее.

 

Скажу так.

Для меня в6 в потенциале больше проблем решает чем создаёт, всё что сейчас не так относится скорее к привычкам и отсутствии компетенций у меня или не правильных ожиданиях.

Цепляться за в4 потому что он сейчас типа работает отлично и потому что я его лучше знаю - смысла не вижу, это путь в никуда.

Я за прогресс, пусть даже ценой временных неудобств, и это не только про технику.

[sdy_moscow]

1 час назад, Ivan_83 сказал:

Что, теперь коммутаторы не StoreAndForward уже?

Давно уже.

 

Просматривается заголовок и сразу фигачит в исходящий буфер нужного порта назначения, а тот отправляет его сразу еще до полного получения пакета. Иначе задержки бы были на джумбо фреймах раз в 5 больше, ну и размеры буферов при тех-же скоростях потребовались тоже в несколько раз больше.

 

Ищи  - cut through и fast-forward.

[Умник]

Цитата

Просматривается заголовок и сразу фигачит в исходящий буфер нужного порта назначения

Вы точно уверены? Гугление навскидку по разным каталистам:

1. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_58_se/configuration/guide/3750xscg/swadmin.html

2. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_53_se/configuration/guide/2960scg/swadmin.html

[sdy_moscow]

6 минут назад, Умник сказал:

Вы точно уверены? Гугление навскидку по разным каталистам:

1. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_58_se/configuration/guide/3750xscg/swadmin.html

2. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_53_se/configuration/guide/2960scg/swadmin.html

Уверен. Вы смотрите "древние" серии. Посмотрите в сторону Nexus'ов 6ххх и 9ххх, ну и более современное железо других вендоров, где уже много 10Гб портов, ну и там где есть 40 и 100Гб..

Еще раз - ищите  cut-through и fast-forward.

[rm_]

Quote

Но возиться с ним придется, поскольку альтернатив пока кроме роста использования CG-NAT не так много

Т.е. признавать что v6 нужен и ничего другого не будет,

Но при этом обязательно ныть, саботировать, цепляться за все столбы и углы и ждать пока в v6-будущее вас приволокут за ногу.

Это точно наиболее продуктивный способ работы?

[sdy_moscow]

13 минут назад, rm_ сказал:

Т.е. признавать что v6 нужен и ничего другого не будет,

Но при этом обязательно ныть, саботировать, цепляться за все столбы и углы и ждать пока в v6-будущее вас приволокут за ногу.

Это точно наиболее продуктивный способ работы?

Вась, вам шашечки или ехать? Не я утверждаю стандарты. И я не пойму, что вы хотели донести до меня своим сообщением?

 

Решения проблем могут быть разными, я например, рассматриваю вариант инкапсуляции Ipv6 внутри транспортной сети IPv4. Благо это вроде как реализуемо.

Ну и развернем CG-NAT на недорогих тарифах по полной пока.

[Умник]

Цитата

Посмотрите в сторону Nexus'ов 6ххх и 9ххх, ну и более современное железо других вендоров, где уже много 10Гб портов, ну и там где есть 40 и 100Гб..

Вы в качестве примера приводите датацентровую тему (Cisco Nexus). Там действительно бывает, что нужны ультра-короткие задержки на трафике "запад-восток". И это причина, по которой в них cut through. Дело не в скорости портов и не в древности свитчей. Дремучая древность железки Cisco Nexus 5000 не мешает ей тоже быть cut through.

Изменено 28 января, 2023 пользователем Умник

[sdy_moscow]

9 минут назад, Умник сказал:

Вы в качестве примера приводите датацентровую тему (Cisco Nexus).

Поверьте, эта "тема" при её нынешней цене, очень хорошо вписывается в ядро оператора на уровне квартала и района. И все остальные вендоры, фактически, так или иначе "догоняют" эту "тему".

Сейчас минимум 10Гб на дом или на 200-300 квартир примерно.А в большие дома может и по два 10Гб зайти.

[Умник]

Цитата

Поверьте, эта "тема" при её нынешней цене, очень хорошо вписывается в ядро оператора на уровне квартала и района.

Ваше право использовать DC-железки в условиях ISP, но это не имеет никакого отношения, к вашему предыдущему тезису, где вы объявили cut through обычным порядком дел в современных коммутаторах (причем это "давно уже", а то "или цена в космос, или потери").

 

На деле же cut through просто имеет свою нишу в применениях, где нужны ультра-низкие задержки.

 

Причем применять его нужно осознанно, держа в голове, что когда-нибудь может случиться, что-то подобное: https://blog.ipspace.net/2020/12/chasing-crc-errors-data-center-fabric.html. Не очень приятно. ISP такое точно не нужно.

 

И еще, для справки: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/93x/layer-2-switching/configuration/guide/b-cisco-nexus-9000-nx-os-layer-2-switching-configuration-guide-93x/b-cisco-nexus-9000-nx-os-layer-2-switching-configuration-guide-93x_chapter_01000.html

Изменено 28 января, 2023 пользователем Умник

[sdy_moscow]

 @Умник Скажите честно Вы оператор? И если да, то сколько у Вас домов с 10 Гб коммутаторами?

 

Мне кажется порою, что советы тут, как должно работать, дают или люди далекие от современных операторских сетей, или операторы перепродающие 1 Гб от большой четверки.

Плевать на СRC в нормальной сети с 10 Гб и 40 Гб интерфейсами, в том же v6 вообще отказались от него фактически.

 

Для оператора гораздо важнее задержки, джитер и буфер оверлоад. CRC ошибки - это "метероид" попавший в Луну. Попал - ну и хрен с ним.

 

Поищите информацию по cut-through и fast-forward у других вендоров, может и поймете, что это давно уже не уровень ДЦ, а нормальная практика для 10 Гб и более с джумбо фрэймз.

[jffulcrum]

Cut-through очень специфическая штука, призванная помочь ровно в одном случае: когда надо из высокоскоростных портов лить потоком в низкоскоростные с минимальной задержкой. То есть ситуация условного выделенного Гой-Пи-ТиВи, когда на узле 40G порт с ядра, а на выходе пара-тройка 10G портов на распределение пожиже. Очень уж специфическая ситуация. Гипотетически возможно лить между односкоростными портами для получения минимальных задержек, но для этого требуется императивная топология "порт к порту". Фактически это SAN, выделенный канал кластеризации (для синхронизации памяти), ну и может финтех. То есть источник и приемник имеют выделенные порты, никаких роутеров и фрагментации, и в один момент времени с вероятностью 99.99% отправляет только один из них. Иначе даже при включенном CT де-факто работать будет в режиме S&F, о чём, в лучшем случае, жаждущий zero latency узнает случайно на форуме вендора.

 

У меня в хозяйстве несколько Nexus 9000 в таком режиме, и там именно SAN&кластеризация. Сейчас приехал НетЖыр M4500-32C, который умеет в CT, надо будет проверить всхожесть на обычной сети и вообще наличие эффекта от CT. А то когда ASIC пашут на гигагерцовых частотах, там задержки сложно будет отличить.

[sdy_moscow]

3 минуты назад, jffulcrum сказал:

. То есть ситуация условного выделенного Гой-Пи-ТиВи, когда на узле 40G порт с ядра, а на выходе пара-тройка 10G портов на распределение пожиже. Очень уж специфическая ситуация.

....

Вы что, тоже 1 Гб продаете от билайна через микротик?

 

Вообще то, вся сеть так примерно и выглядит сейчас 100-40-10 Гб в ядре, 10 Гб на доме, 1 Гб у клиента. И весь трафик идет по этой цепочки в обе стороны.

[taf_321]

В 27.01.2023 в 16:00, FSA сказал:

А вот подскажите те, кто имел дело с провайдерским NAT. Какие скорости портов и сколько клиентов ходит через порт одновременно?

При правильной реализации клиентского подключения, вопросы с нарезкой скорости и NAT совершенно перпендикулярны даже в рамках реализации в одном устройстве. Современное серверное железо позволяет поднимать NAT с полосой 10G+10G на стандартных системных инструментах.

[taf_321]

В 29.01.2023 в 01:54, sdy_moscow сказал:

 

Поищите информацию по cut-through и fast-forward у других вендоров, может и поймете, что это давно уже не уровень ДЦ, а нормальная практика для 10 Гб и более с джумбо фрэймз.

Абаждите, не спешите. Я что-то пропустил, и v6 опустился до L2 и подменяет собой Ethernet-кадр? Так-то всем этим мегафичам cut-through и fast-forward всего и надо, это SRCMAC-DSTMAC и они могут спокойненько лить ваши джамбо-фреймы хоть по 100М размером. И похрену что там внутри - v4 или v6, на концах получатель с отправителем сами пусть разбираются что там и кому.

 

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

[sdy_moscow]

@taf_321 Фильтрация....

[Saab95]

Получается в v6 роутеры не нужны - можно снова сеть на L2 коммутаторах строить?

[taf_321]

15 часов назад, sdy_moscow сказал:

@taf_321 Фильтрация....

Фильтровать L3/L4 на железе, не предназначенном для этого... Как бы так сказать-то... В общем, ССЗБ.