Александр Карабанов

Вам надо настроить ip rule и route листы к ним. То есть примерно так: Если пакет приходит на адрес из сети 1, то шлюз будет 1, а если на адрес из сети 2, то шлюз = 2.
(man ip rule, man ip route)

Ещё как вариант это BGP с вашим оператором.

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

Как-то так:

dd if=/dev/sda bs=65536 | ssh target-ip 'dd of=/dev/sda bs=65536'.

На агрегированном канале 2x1Gbit выдает 100 мегабайт в секунду. Если подшаманить размеры блока bs= и mtu, и еще шифрование у ssh выключить, можно, я думаю, и все 200 мегабайт выжать.

Проводить, на отмонтированном! (или смонтированном в readOnly) диске!
Не зря dd расшифровывается как DestroyData.
Варианты настройки шифрования (-c) и скорость (лучше - больше):

Положительная обратная связь и самовозбуждение. Возможные последствия - выход из строя или срабатывание защиты. Функциональность будет нарушена в любом случае.

Пиксели и сантиметры как раз через dpi и связаны. На отображение картинки на экране монитора dpi никак не влияет, так как 1 px картинки всегда занимает 1 px монитора. Этот параметр отвечает исключительно за размер изображения на печати, так как, грубо говоря, на один дюйм бумаги можно нанести разное количество точек (пикселей). Когда вы меняете dpi с 300 на 72, то вы этим самым задаете более низкое разрешение печати (меньше пикселей на дюйм). При постоянном разрешении изображения в пикселях, естественно, значение в сантиметрах возрастает, так как "плотность" пикселей при печати уменьшается.

Для печати вам нужно оперировать только размерами изображения при печати (в сантиметрах), меняя dpi картинки, но не трогая размер в пикселях. Допустим, вам нужно распечатать изображение на бумаге 21x15 см. Для качественной печати в 300 dpi размер картинки должен быть не меньше 2480x1772 px. Если картинка меньше в 2 раза, то будьте готовы к качеству как при 150 dpi, даже если в самом изображении будет указано 300 dpi. Принтер не дурак и сам увеличит картинку под необходимый размер печати. Есть всяческие конвертеры, позволяющие узнать требуемый размер изображения в пикселях для определенного разрешения печати и размеров бумаги.

Надеюсь, я помог вам с этим вопросом.

Если Вы о быстрых ссылках (иначе сложно представить, о каком меню в выдаче может идти речь), то поисковик их формирует сам, ему можно только помочь в этом сделав "грамотную", по его мнению, структуру сайта.
Вот ссылки на рекомендации от самих поисковиков:
от google: https://support.google.com/webmasters/answer/47334...
от yandex: https://help.yandex.ru/webmaster/search-results/qu...

Это юникод - написано "Ура"

Существует ли в спецификации Ethernet какое-нибудь обязательное оповещение со стороны сетевой карты после появления физического соединения?

Честно говоря, не знаю, потому как не читал спецификации на 802.1D (MAC bridges) или 802.3 целиком ни разу. Думаю, нет. Коммутатор (точнее, раз уж речь зашла о спецификациях, мост) может определить состояние физического линка при помощи L1-сигнализации (FLP и прочая).

Или коммутатор получит информацию о MAC-адресе только после отправки первого пакета?

Думаю, да. Я полагаю, логика здесь такова. Хост, подключившийся к ethernet-сегменту, должен узнать MAC-адрес либо обычного соседа по сегменту, либо маршрутизатора по умолчанию (который, кстати, тоже является его соседом по сегменту), для этого он отправляет ARP-запрос, при этом фактически сообщая свой MAC-адрес в широковещательной посылке. В этот момент коммутатор (фильтрующий мост, простите) добавляет запись в таблицу MAC-адресов.

Это все верно для случая IPv4-over-Ethernet, в случае IPv6-over-Ethernet все аналогично, с другими протоколами поверх Ethernet (даже не знаю что предположить, IPX?) я не работал.

Давай по-порядку. Зачем вообще юзать IPSec - для того, чтобы защитить трафик идущий по публичным (или не очень) сетям. Сделать возможность перехвата, расшифровки или компрометации трафика минимальной. Для этих целей подходят туннели типа OpenVPN и IPSec (всё остальное либо проприетарное, либо ломается на ура).
Имхо, oVPN больше подходит для приземления клиентов, а IPSec для связи сетей.

Дальше. IPSec способен работать в двух режимах, туннельном и транспортном.

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

Транспортный режим - соединяет трафик идущий между двумя точками - между двумя устройствами - без построения туннеля. Т.е. просто (де)шифрование пакетов. И для построения туннель нужно будет использовать отдельно IPIP, или L2TP или любой другой протокол Point to Point.

Нафига же нам может такой понадобиться? Например если у тебя соединяются не две отдельные сети, а несколько с каждой стороны (политик в этом случае нужно в X*Y). А может ты строишь множественную связность, когда нельзя однозначно сказать через какой Peer доступна та или иная сеть (например с ospf внутри). А может быть у тебя по туннелю гоняется не IP трафф (а телефония или мультикаст или FoIP или ATAIP). А может так же ты гоняешь l2 пакеты (например, сбриджевал два офиса и у них общая адресация - при небольшом расстоянии вполне себе решение). А ещё иногда нужно перестроить сеть без сброса всех активных туннелей (что в предыдущем случае невозможно). В целом использование транспорта IPSec - гораздо более удобнее.