Pull to refresh
31
0

root, NOC

Send message

split - это разделение одного порта на несколько, тут в другом комментарии кто-то спрашивал.

Не, нет видел такое. Сейчас глянул - это какой-то общий фреймворк только, а где к нему что-то полезное искать? Со свичдевом не находится.

Split никто не мог. А как у systemd с переконфигурацией, как он это делает? Ещё у драйвера меланокса есть пара своих приколов, т.е. нельзя напрямую некоторые действия сделать и это тоже нужно "заложить" в систему конфигурации, иначе они об этом могут "споткнуться".

Ну и помимо адресов ещё и tc filter нужен, а этого тоже не найти.

Так-то да, у нас велосипед, но это не всегда плохо. Тут его поддерживать не сильно сложнее, чем допиливать или подстраиваться под ограничения других систем.

Вот тут доклад есть, я там рассматривал несколько вариантов:

https://netdevconf.info/0x15/session.html?Switchdev-Offload-Workshop

Но, конечно, не всё сильно копал. systemd и NM показалось, что не очень подходят, когда смотрел.

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

Ну да, там есть много проблем, которые приводят к забавным артефактам. Про это даже можно вполне научные работы писать (научным руководителям на заметку). И, конечно, в рамках презентации охватить все аспекты практически невозможно. Спасибо, что дополнили и добавили для не столь искушённых читателей информацию про разные нюансы работы с трассировками и TTL. Кстати, на просторах сети точно есть бесконечные циклы с вмешательством в TTL — упомянутое исследование с мидлбоксами об этом свидетельствует, но там их видно по побочным эффектам. А простыми пробами, наверное, их не обнаружить, как и многие другие циклы наверняка остались незамеченными, как я говорил - не всегда приходит такой ответ из цикла по разным причинам. Но если откуда-то пришёл ответ, то, думаю, что с большой долей уверенности можно считать, что цикл там есть.

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

Оно плохо работало, на время появляется только. Я сначала тоже думал, что уже не работает. Но потом кто-то сказал, что у него всё ок. Надо mtr запустить и долго подождать попробовать, если сразу не показало.

А что за маршрутизатор у вас? Обычно реализованы маршруты в null или blackhole. Например "ip route <net> Null0" на цисках или ip route add blackhole <net> в линуксе.

С точки зрения самого процесса коммутации/маршрутизации как раз своя ОС особо не поможет, т.к. тут мы ограничены возможностями датаплейна. Вопрос в принципе касается всех whitebox-коммутаторов. И разница в том что вы имеете на контролплейне: возможности по контролю доступа, использование разных демонов маршрутизации, ну и прочие возможности по управлению коммутатором, которые вы можете придумать, немаловажен также и контроль над обновлениями компонентов системы. Нам интересно, в основном, что мы можем использовать bird, что там понятные и известные вещи вроде ssh, а непонятно что неизвестного возраста и дырявости.
Да, наверное стоит сделать явный акцент на этом. Поправлю.
Нужно подвигать их туда-сюда переворачивая по пути. Y-движение вдоль этих 3 рёбер можно делать в разном направлении и таким образом переворачивать нужный кубик при смещении.
Например если будут 2 перевёрнуты, то можно сначала сместить в одну сторону, перевернув один из них, а потом сместить обратно, перевернув уже другой. Точно сам не уверен, но полагаю, что если все 3 на местах, то не может быть так, чтобы при этом были перевёрнуты все 3 или ровно 1.
Ну да, там вроде только центральные кубики можно повертеть. Остальные фиксированные места и ориентацию имеют.
Вот, получилось смоделировать похожую ситуацию (углы отличаются):

Исходное состояние

Убираем красно-зелёный на вертикальное ребро

Ставим его на место красно-белого

Убираем красно-белый на вертикальное ребро

Ставим его с правильной стороны от красно-зелёного

Поворачиваем эти кубики на своё место

Теперь получилось чётное число перестановок

Переставляем последние рёберные одним Y-движением

Или ещё возможно у вас кубик был неправильно собран.
Тут нечёное число перестановок как раз. Т.е. на последних 3-х рёберных кубиках у вас ровно 2 кубика не на своих местах — красно-синий и красно-жёлтый. Вам нужно, например, красно-белый переставить на место красно-зелёного, его дальше на соответствующее соседнее место. И после этого должны получиться последние 3 рёберных кубика либо все на местах, либо все не на местах.
PS. Исправил комментарий. Изначально показалось, что это оранжевый. Но вроде по расположению это красный.

Да, всё так. Тут как ни скажешь — получится не очень. Либо не так как везде принято, либо с корявой семантикой на проекции куба. Я решил придерживаться в этом месте общепринятых обозначений. Но также написано, что грани смежные используются. И картинка, собственно, тоже нужна, чтобы показать как на самом деле, если кто запутался.
Тут можно было бы введение в начало добавить, но меня остановила лень и некоторая избыточность этой затеи, т.к. информацю о нотации можно найти на той же википедии. Как вы считаете, если добавить предложение во введение, что рекомендуется ознакомиться с общими терминами – это поможет пониманию?

Ну вы сфоткайте что ли. Думаю и другим на примере полезно будет посмотреть.

После трёх движений вроде как попарно обменяются угловые кубики. Если только так с ними работать, то это наверное затруднительно. Но в статье описывается метод, который позволяет проще с ними работать и там больших сложностей нет с их перестановкой и ориентированием. Там используется трюк, похожий на то что предлагается в одном из видео в комментариях тут, когда мы делаем прямое и обратное движение или цикл из движений, сохраняющий конфигурацию, но в промежутки вставляем повороты грани, подсовывая нужные нам кубики для работы.
мозк начинает закипать :-).

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

"… если выполнить три раза по два движения, то кубики повернутся три раза и в результате вернутся в исходное состояние..."
А если два по три? А если шесть по одному?

Да, вы верно подметили, что 3 * 2 = 2 * 3 = 6 * 1. Но тут так написано, потому что рассматривается свойство двойного движения и его влияение на угловые кубики. Именно поэтому тут отмечается, что т.к. для полного поворота кубик нужно повернуть три раза, то нужно выполнить двойное движение три раза, чтобы угловые кубики оказались в исходном положении. Я полагал, что читатель сможет посчитать что это составит шесть одиночных движений.

«если выполнить Y-движение шесть раз подряд, то состояние кубика вернётся в изначальное»
Што? Так чем отличается «три по два» от «шесть раз подряд»?

Тем что в «три по два» идёт речь про угловые кубики, а тут объединяются два свойства. Ранее написано, что полный цикл для рёберных кубиков составляет 3, а для угловых 3 * 2 = 6. Поэтому полный цикл для всех кубиков, участвующих в движении будет 6. Тут просто так «совпало», что один из циклов является делителем другого, поэтому больший является общим циклом. Но если бы, например, у нас были циклы из 4 и 5 движений, то полный цикл составлял бы 20 движений.
Это точно не алгоритм скоростной сборки. Вроде как я читал про него, что он, обычно, требует больше поворотов чем «обычные послойные» алгоритмы.
1

Information

Rating
Does not participate
Registered
Activity