Pull to refresh

Comments 56

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

щас кто нибудь напишет что это ненужно в 21 веке и закидает меня минусами конечно, но я сторонник идеи что лучше иметь возможность и не использовать её чем не иметь возможности когда она понадобится.

как-то странно видео выглядит.. почему окна на одном экране.. что за..

к сожалению на одной видеокарте просто не получится, решение там — запустить второй x-сервер xephyr, работающий в окне первого

но да, при использовании двух видеокарт все очень и очень просто

Wayland не ограничивает эту возможность. Он просто отдает необходимость реализации этого функционала в реализацию сервера.

Речи про "ограничивает" и не шло. Просто пока не реализовано..

Речь идет об IPv4 и X11. Если первый из них практически во всех аспектах уступает IPv6,

Дальше читать не стал. Даже неискушённому читателю должно быть очевидно, что если и за 25 лет IPv6 так и не вытеснил IPv4, то не настолько он и лучше.

У IPv6 страшный длинный адрес, не предназначенный для запоминания админом... Т.к. его внедрение "долгое и упорное", никак не станет массовым, уровень отлаженности стэка в разных фирмварях и осях очень разный, что не способствует дальнейшему продвижению. Странно, но в линуксе стэк IPv6 на удивление шустрый. Данных сейчас нет, в прошлом году очень удивился, что при переходе на IPv6 скорость значительно выросла (возможно это не от того, что IPv6 шустрый, а от того, что для него firewall-ов в сети настроено небыло, докапываться до причин тогда времени небыло). Со стороны программиста разница минимальная.

Тут уже было отвечено по поводу IPv6 и его внедрению habr.com/ru/company/ruvds/blog/574266
IPv6 быстрее по двум основным причинам:
1. Из заголовка пакета убрали контрольную сумму, она не нужна и довольно дорогая операция. Расчет контрольный суммы и его сверка переложена с протокола на клиент-серверное ПО. Контрольная сумма есть на канальном уровне, и сетевые устройства сверяют ее, незачем контрольная сумма на сетевом уровне, только лишняя дублирующая операция и нагрузка на железо.
2. Не нужен NAT. NAT создает довольно большую нагрузку на оборудование.

IPv6 на оборудование создает минимум на 30% меньше нагрузку на оборудование, отсюда меньше задержки.

У меня лично большая часть трафика по IPv6 ходит.

Из заголовка пакета убрали контрольную сумму

В принципе вы правы, но на практике CRC считается на стороне железки и не стоит, практически ничего

Не нужен NAT. NAT создает довольно большую нагрузку на оборудование.

Не совсем так. Дело в том, что NAT состоит из двух частей: отслеживание соединений (conntrack в линуксе) и собственно трансляция адресов. Нетрудно догадаться, что отслеживание соединений куда более дорогая операция, чем трансляция. Ведь надо хранить собственно таблицу соединений и на каждый пакет бегать по ней. Так вот, отслеживание соединений всё-равно нужно, потому что мы не хотим пускать к пользователю любой мусор из интернета, имеющий адрес пользовательского терминала в своём пакете. Через это самая дорогая часть NATа останется с нами и в новом ipv6 мире, только теперь адреса там будут в 4 раза длиннее.

но на практике CRC считается на стороне железки

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

Дело в том, что NAT состоит из двух частей: отслеживание соединений (conntrack в линуксе) и собственно трансляция адресов.

Опять не совсем правильно. В IPv6 мы можем уменьшить количество промежуточных узлов, тем самым тоже уменьшить задержки. Изучайте стандарт. На нагруженных роутерах пропускную способность на практике удается повысить где-то на 30%. 30% это существенная экономия на оборудовании при масштабировании. В интернете можно найти графики крупных компаний, где показаны преимущество IPv6. Если не верите графикам, возьмите просто iperf и прогоните тест.
IPv6 не дураки придумали и самое главное он развивается, и есть кучу улучшений.

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

Но происходит это внутри сетевой карты, так что всем плевать.

В IPv6 мы можем уменьшить количество промежуточных узлов, тем самым тоже уменьшить задержки

Да пожалуйста. Но причём тут NAT?

Как уже было отмечено выше, самая дорогая часть NAT — отслеживание адресов — никуда не денется, так что выгоды от отмены NAT не такие уж и значительные

В принципе вы правы, но на практике CRC считается на стороне железки и не стоит, практически ничего

Вы не путаете с чексуммой канального уровня? Я что-то не помню, чтобы карты считали чексуммы в IP самостоятельно… См., например, arch/x86/include/asm/checksum_64.h в линуксе (ip_fast_csum)

Конечно по стандарту карты должны считать только суммы в датаграммах канального уровня. Однако, на практике, в современных картах столько мощи, что они могут делать всякое. Бывают даже встроенные ПЛИС для предобработки. Но это если по-дорогому. В обычных картах есть всякие техники известные под общим термином offload. В линуксах можно настроить/посмотреть с помощью ethtool -k.Например, на моей ( Marvell 88E8072 PCI-E Gigabit Ethernet Controller) вот так:

event@tosh ~ $ ethtool -k enp7s0
Features for enp7s0:
rx-checksumming: on
tx-checksumming: on
	tx-checksum-ipv4: on
	tx-checksum-ip-generic: off [fixed]
	tx-checksum-ipv6: off [fixed]
	tx-checksum-fcoe-crc: off [fixed]
	tx-checksum-sctp: off [fixed]
scatter-gather: on
	tx-scatter-gather: on
	tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
	tx-tcp-segmentation: on
	tx-tcp-ecn-segmentation: off [fixed]
	tx-tcp-mangleid-segmentation: off
	tx-tcp6-segmentation: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
...

rx-checksumming — это как раз проверка контрольной суммы входящих пакетов. Причём, по-моему, она протоколы 4-го уровня тоже проверяет сразу

Точно, там ж ещё проверка. Туплю, извините.

раньше дешевые сетевые карты всё на процессор складывали. В случае сетевого шторма ПК вис из-за обработки пакетов. Лично наблюдал сие чудное явление. При этом на ПК с более умными сетевухами всё было отлично.

Можно перечислять много особенностей и практически ни одну нельзя будет назвать однозначно позитивной: длинный адрес — трудно запомнить, ограничения на MTU — "а как посылать маленькие пакеты?", нет широковещания — "аналог ping 255.255.255.255?". Вместо простых и привычных ARP и DHCP, в ipv6 NDP, ICMPv6 и (иногда) DHCPv6. Единственное, что практически однозначно хорошо — убрали контрольные суммы. Достаточно тех что есть на канальном уровне и в протоколах верхних уровней. Но это улучшение, в общем-то незначительное.

По-этому внедрение и идёт черепашьими темпами.

Вы пишете полный бред. IP адреса в здравом уме никто не запоминает. Даже в локальной сети все к серверам обращаются по имени. Роутеры и промежуточные узлы, зачастую имеют короткую форму в IPv6, которую запомнить не сложнее IPv4. Внедрение стопорится больше из-за мифов, типа тех, что распространяете вы и из-за безграмотности людей, и их психологических проблем.

Скажи, насколько сложно запомнить?
2606:4700:4700::64
2606:4700:4700::6400

IP адреса в здравом уме никто не запоминает

Вы излишне категоричны. Если никто из вашего окружения не запоминает, это не значит что никто вообще не запоминает. Да и вы сами, наверняка, знаете, что такое 8.8.8.8 или 1.1.1.1, но не знаете их ipv6 аналогов.

Внедрение стопорится больше из-за мифов, типа тех, что распространяете вы и из-за безграмотности людей, и их психологических проблем.

То есть, необходимость покупки провайдероми нового оборудования и разработки стратегии миграции при отсутствии внятного выхлопа — это фигня. А вот "мифы" — это да. Настоящая проблема.

То есть, необходимость покупки провайдероми нового оборудования и разработки стратегии миграции при отсутствии внятного выхлопа — это фигня. А вот «мифы» — это да. Настоящая проблема.

Какое новое оборудование? Даже старое оборудование поддерживает IPv6. Вы же сами писали, что протоколу 25 лет. По вашему за 25 лет в оборудование не смогли завезти IPv6? Мы гоняли IPv6 еще в 2004 году…

Ну, у себя дома вы могли гонять всё что угодно. У провайдеров другая история: оборудование дорогое, меняют его редко, а перенастраивать никто не любит, потому что дорого и простои. По-этому, кое-где присутствуют системы без поддержки ipv6. Может на коммутаторах этой проблемы и нету, но кроме коммутаторов, там куча всякого разного. Представляете, мы такие модные и молодёжные переехали на ipv6 а у нас биллинг сломался. Или аналитика. Будет обидно.

event1 работал в провайдеринге, и стоял у истоков интернета в своем городе.

Тут скорее "перенастраивать не любит". Потому что мне сложно себе представить провайдера у которого за 25 лет оборудование не поменялось нигде.

Да и вы сами, наверняка, знаете, что такое 8.8.8.8 или 1.1.1.1, но не знаете их ipv6 аналогов

Запомнить труднее, но все же можно: 2001:4860:4860::8888 ; 2606:4700:4700::1111

Вопрос тут в другом - а зачем?

ping 8.8.8.8 — это самый простой и надёжный способ проверить, подключена ли система к интернету. Эту команду легко запомнить и легко передать. Даже по телефону, даже непрофессионалу, даже если и мой и его английский оставляют желать лучшего.

Совсем с памятью плохо, что сложно запомнить 2606:4700:4700::64? Так память надо развивать, чтобы в старчестве снизить риск болезни паркинсона.

Расскажете это бабушке- пользователю интернета!! Или бухгалтеру тети Клаве

Worky а зачем им рассказывать, если есть DNS и DHCP? Честно говоря, в современном мире не видел ни одного провайдера или компании без DHCP и DNS.

Давайте мух от котлет отделим.

Во-первых, 'ping 8.8.8.8' это несерьезно. Ну да, удобно. Но тогда уж давайте 'ping ok.ru' раз мы скатились на этот уровень ;-) Мы так и DNS заодно проверим. А вот мне интересно, вот говорите вы по телефону "плиз, тайп пинг, спейс, зен ейт дот ейт дот ейт дот ейт енд прес ентер... йес, зэт биг батон он зе райт сайд оф ьор кейборд, мэм". Ну тетка такая "Request timed out". И что? О чем это говорит? Возможных проблем - тьма. Куда копать в начале? Почему именно туда? Это в корне неверный подход, потеря времени. Легче просто спросить "фейсбук открывается?". Если нет, тогда начинать уже нормальный траблшутинг - ARP (ND для IPv6), routing table, traceroute, nslookup...

Во-вторых, а что ' ping -6 google.com' это как-то сложнее? Ну или 'traceroute -6 google.com'? Скажете "А если проблема с DNS?" Ну так и ошибка же будет "Name or service not known", сразу поймете что к чему. Да и nslookup в помощь.

Я к чему клоню - у вас привычки, которые вы не хотите менять и которые мешают вам работать с IPv6 сетями.

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

Если позволите, я дам один непрошеный совет - никогда не стройте IPv6 сети без DNS. Это крайне не рекомендуется. Понимаю, что иногда это кажется избыточным, но человеку почти невозможно запомнить IPv6 адрес (если только его специально не сделали легко запоминающимся). Поэтому можно колхозить и выдумывать легкие адреса для loopback интерфейсов сетевых устройств, но сами понимаете, это не масштабируется на все use cases.

Starwalker так даже с IPv4 без DNS строить сеть это перебор, даже в страшном сне себе не могу представить ситуацию, когда мне надо будет запоминать IPv4 адреса: 172.20.77.36 Главбух, 172.22.38.65 — Генеральный директор и т.д… Мне приходилось работать в компаниях с 3000+ сотрудников. Даже если компьютеров всего 100 будет в сети их не запомнить!

Я сетевик, в основном на хосты не лажу, но согласен, DNS решает. Кстати, один раз наблюдал забавное. Огромная корпорация, новый датацентр готовится к запуску в продакшн, идут тесты. Что-то где-то не сходилось, не помню уже, но вроде EVPN на некоторых Leaf работал не так, как нужно. Ок, мы (саппорт вендора) с одной стороны, консультант, ответственный за сеть с другой. Ну вобщем запись сессии, все контролируется, пришлось через его комп лезть. Чтоб он видел что и почему мы делаем. Банальшина, нужен SSH к пятку устройств. Говорю ему: "давай, брат, нам доступ вот к этим устройствам... "

Увиденное превзошло все ожидания. Вобщем картина маслом - топология сети в Visio, на ней из полезной информации только хостнеймы устройств. Консультатнт находит в визио хост, копирует его хостнейм. Затем лезет в одну Excel таблицу, там в хреновой туче вкладок находит вкладку - таблица с айпишниками лупбеков и хостнеймами, ищет запись, копирует айпишник. Ок, открывает терминал. SSH, Ctrl+V, Enter. Коммутатор просит юзернейм и пароль. Консультант открывает опять какие-то Excel таблицы, там уже находит пароль, вводит... И так для каждого коммутатора.

Вот люди со стальными шарами - не ленятся как некоторые с такаксами да радиусами - отважно пароли хранят в эскеле... DNS себе ручной придумали через Excel. А вы тут разленились, 100 айпишников не хотите запомнить ;-)

P.S. Надеюсь перед запуском в продакшн там прошелся безопасник и каленым железом выжег это все. Но опыт подсказывает, что не факт ;-)

да, боже упаси меня вообще строить сети. Я ж программист, а не сетевик. Это клиенты проклятые. Думают, если сеть IoT, то DNS и не нужен. Там же людей нет, правильно? Я бы и рад им сказать: "ну раз вы такие дураки, то мы с вами бизнес не будем делать!" Но, меня за такое лишат довольствия, а мне без довольствия никак нельзя.

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

Но он работает в рамках одного VLAN, если не городить на роутерах mDNS gateway ну или полноценную маршрутизируемую мультикаст сеть с PIM'ом и Join'ами ;-)

если и за 25 лет IPv6 так и не вытеснил IPv4, то не настолько он и лучше

Как-то сомнительно звучит, как аргумент. Проблемы с имплементацией IPv6 вначале были в кривой поддержке протокола ASIC'ами. Сейчас все уже давно работает в line-rate, особых проблем с поддержкой IPv6 на нормальном оборудовании не встречал. На данном этапе проблема с внедрением IPv6 одна - люди.
Люди, которые привыкли запоминать айпишники.
Люди, которые "ниасилили" разные виды IPv6 адресов и им физически больно от отсутствия RFC1918 адресов в их уютной сеточке.
Люди, которые не могут поднять нормальный DNS в сети.
Люди, которые думают, что NAT это такой инструмент обеспечения безопасности.

Я могу долго перечислять все проблемы, но root cause всегда один - человек.

Выход - "бесчеловечные" сетки вроде всяческих SDN. Возможно, после их повсеместного внедрения ситуация с IPv6 изменится в лучшую (для прогресса) сторону.

<sarcasm> Повсеместное внедрение линукса на десктопе тормозится из-за людей. Эти глупые пользователи просто не могу выучить несколько десятков простых команд и почему-то недовольны прекрасным чёрным терминалом с красивыми зелёненькими буквами </sarcasm>

Люди следуют первому правилу инженера: не надо чинить то, что работает. Если выгоды от внедрения меньше чем затраты на него, разумно и правильно от внедрения отказаться.

Это не правило инженера, это правило плохого специалиста, который не уверен в своих силах. Инженеры создали IPv6 для решения существующих проблем безопасности и производительности. И эти люди на голову умнее и опытнее вас, сотрудничают с трансмагистральными компаниями и спонсируются ими для решения существующих проблем. Садитесь опять двойка!

Это, кстати, распространённая ошибка начинающих инженеров: мол сетевые протоколы, прошивки и ядра операционных систем разрабатываются некими магическими супер-программистами с двумя головами. На самом деле, там работают точно такие же обычные люди как мы с вами.

event1 если вы такой гений, что же тогда что-то свое не напишите и не представите миру? В современном ИТ очень много еще не решенных задач. Где можно увидеть ваши гениальные изобретения и алгоритмы?

Как типичный представитель фриков "btw, I use Arch" чуть не бомбанул, спасибо за теги ;-)

Смотрите, что затратнее по-вашему - CG-NAT или IPv6 dual-stack? Кстати, сам я ответа не знаю, но CG-NAT вызывает рвотный рефлекс даже в виде схемы, как это чудо поддерживается провайдерами даже знать не хочу, надеюсь им больно. Вот скажите мне, чем можно объяснить неготовность провайдера городить NAT64 (что задумывалось как временное решение пока не перейдем на IPv6-only) но пионерское "Всегда готов!" городить это уродство CG-NAT, без сомнения являющееся тупиком? Вот в чем различие кроме неграмотности сетевиков?

На мой взгляд сейчас есть проблема с дуал-стеком. На самом деле неприятно поддерживать 2 протокола, особенно если IPv6 мало пользуются. Я понимаю это, все же ресурсы ограничены и во многих коммутаторах ресурсы делятся между IPv4 и IPv6. Естественно нужно оправдание использования этих ресурсов под дополнительный протокол, без которого (будем честны) пока еще жить можно.Есть большие провайдеры, которые до сих пор для домашних потребителей не внедрили IPv6 и никто не чешется, никто не требует его внедрения. Замкнутый круг. IPv6 не используется, потому что многие провайдеры его не поддерживают. Провайдеры его не поддерживают, потому что IPv6 не используется.

Но все же есть огромное психологическое неприятие IPv6 среди сетевиков, которые не привыкли к нему и не хотят меняться. Этот протокол им непонятен, некомфортен. Но если бы они вникли хоть немного, возможно что-то бы изменилось. А то, что вникать не хотят, это я знаю не понаслышке. Ну например когда вижу в сети OSPFv2 и OSPFv3 работающие параллельно. Зачем? Ну как, v2 для IPv4, v3 для IPv6 ... Шапито... :-D

Starwalker так все магистральные провайдеры его уже давно поддерживают, все уперлось в последнюю милю. Притом с каждом годом доля IPv6 растет во всем мире. Проблема внедрения сугубо психологическая. Протокол даже в чем-то проще IPv4. Но люди привыкли себе придумывать несуществующие проблемы на ровном месте, когда их нет. Сами не знают IPv6, но зато столько мифов про IPv6 могут рассказать.

Подписываюсь под каждым вашим словом, я именно это и пытаюсь коллеге объяснить. Все дело в закостенелых и ленивых сетевиках. Технически уже нет никаких проблем, даже на last mile, даже с клиентскими устройствами. Уже по-моему любой чайник поддерживает IPv6...

цена на IPv4 адреса в конце концов сломает спину слона. Времена когда ещё была WinXP и теоретически могли быть проблемы давно прошли. Большинство клиентов провайдера сами не настраивают роутеры, а те кто настраивают могут и в IPv6. Так что остаётся только одна проблема - лень менять пока стоимость владения остаётся приемлемой.

Смотрите, что затратнее по-вашему - CG-NAT или IPv6 dual-stack?

Если CG-NAT уже есть, а DS надо строить? Тогда DS затратнее.

Но все же есть огромное психологическое неприятие IPv6 среди сетевиков, которые не привыкли к нему и не хотят меняться

Вот представьте, что я техдир какого-нибудь провайдера на миллион абонентов. И я, прям борец за IPv6. И вот, я прихожу в совет директоров и говорю, мол ребята, есть охренительная штука: новая версия IP-протокола. Там новые технологии, 21ый век и вообще всё отлично. Даже гугл рекомендует. Тогда совет директоров мне и говорит: "а сколько это стоит?". Я прикинул расходы на замену оборудования, обучение персонала и т.п. и такой говорю уверено: "лям!". А совет мне в ответ: "а сколько мы на этом заработаем? Будет ли у нас больше пользователей, или сможем ли мы повысить абонентскую плату". А я, такой: "нет не будет и не сможем. Пользователям всё равно какая версия IP протокола работает в их сетях. Они и слов таких не знают". А совет мне и отвечает: "не дадим мы тебе денег. Не нужен нам IPv6. Лучше будем ретроградами, но с лямом".

event1 бред полнейший. Читайте еще раз комментарии, не нужно новое оборудование. Выигрыш там от снижения затрат на масштабирование, часть трафика пойдет по IPv6 и разгрузит оборудование. Выиграют как пользователи так и сам провайдер.

Логика неправильная, скорее всего новое оборудование не понадобится.

Хотя сама ситуация типичная, спорить не буду. Именно из за нее, как я уже упоминал, у многих даже больших провайдеров нет IPv6 для домашних потребителей. Замкнутый круг. Хотя есть надежда - в один момент айпишники закончатся, юзверей, которые хотят "белый" адрес станет много. Тогда может что-то поменяется. Жаль, конечно, потому что сама технология вполне ничего, много интересных идей. В том числе для провайдеров. К примеру идея о том, что next-hop не должен быть global unicast address. Сколько лет провайдеры лепили эти вечные 'ip unnumbered' на внутренних линках. Или даже IS-IS вообще без айпишников на линках. А тут тебе "искаробки" next-hop на link-local соседа. Суммаризация маршрутов на IPv6 - песня. Адресов - хренова туча, поэтому таблица маршрутизации может быть меньше на несколько порядков. Если только конечно сети не планировались заклятыми "четверочниками", которые делят /64 на сабнеты :))))

даже если не понадобится именно оборудование, то надо будет обучить персонал или хотя бы переписать скрипты для индусов из поддержки, надо будет переписать конфиги, надо будет починить падения после переписывания конфигов. Всё это выльется в какую-то сумму.

С другой стороны, внедрение, конечно движется по-тихонечку. Но очень неспешно. У меня, например, ipv6 распространяется путём письма провайдеру с просьбой переключить на ipv6. Там DS-lite. В мобильных сетях у нас, да и в Европе (за исключением Германии) ipv6 пока редкий гость.

Не такой уж и редкий, во многих странах (даже в России) есть IPv6 хотя бы у одного крупного оператора. Смотрел в регионе "Восточная Европа" на stats.labs.apnic.net/ipv6.
В России и Беларуси у МТС, в Польше - Orange, в Чехии O2 и Vodafone, в Венгрии Magyar Telekom / Vodafon / Telenor, в Румынии Digi. Только на Украине и в Болгарии всё плохо с IPv6.

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

Как уже указывалось выше, самая толстая часть NAT — connection tracking — никуда не денется. Провайдеры просто не могут открыть конечных пользователей в дикий интернет. Кроме того, само отслеживание будет дороже, из-за более длинных адресов: раньше ключ (два адреса и два порта) в таблице соединений был 12 байт, а теперь 68 байт. Это 3 линии кэша, если что.

Это почему провайдеры не могут выпустить пользователей? Достаточно примитивнейшей настройки фаервола, чтобы отрубить большинство ботов. А в остальных случаях NAT не поможет.

Достаточно примитивнейшей настройки фаервола, чтобы отрубить большинство ботов

Да, она называется "запретить инициировать соединения снаружи вовнутрь". Но чтобы её реализовать нужно отслеживать соединения

Only those users with full accounts are able to leave comments. Log in, please.