Jump to content
Калькуляторы

Для внедрения IPv6 в России нет препятствий

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

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

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

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

Share this post


Link to post
Share on other sites

Цитата

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

Ну-ну.

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

 

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

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

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

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

12 minutes ago, sdy_moscow said:

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

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

 

13 minutes ago, sdy_moscow said:

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

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

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

Это не так.

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

1 minute ago, sdy_moscow said:

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

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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 потому что он сейчас типа работает отлично и потому что я его лучше знаю - смысла не вижу, это путь в никуда.

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

Share this post


Link to post
Share on other sites

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

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

Давно уже.

 

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

 

Ищи  - cut through и fast-forward.

Share this post


Link to post
Share on other sites

Цитата

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

Quote

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

Цитата

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

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

Edited by Умник

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

Цитата

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

Ваше право использовать 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

Edited by Умник

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

....

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.