Это сработает только если коммутатор L3, и только для сегментов сети, в которых он является также маршрутизатором. На коммутаторах попроще надо смотреть таблицу изученных mac-адресов.
Вместо того, чтобы бегать и дергать патчкорды, нервируя пользователей, можно залогиниться на коммутатор Сisco по telnet/ssh (или через консольный порт RS-232, если коммутатор не сконфигурирован), и посмотреть таблицу изученных коммутатором мак-адресов, а также списки анонсирующих себя по CDP и LLDP устройств. Соответствующие команды IOS для просмотра (предварительно может понадобиться перейти в режим enable соответствующей командой):
show mac address-table
show cdp neighbors
show lldp neighbors
Потом сопоставляете маки с ip-адресами устройств, и получаете представление, что на какой порт скоммутировано.
Никогда ничего не заземляйте на квартирные трубы. Вы хотите, что-бы, например, кто-нибудь из ваших соседей погиб из-за удара током во время принятия ванны?
Такие нюансы обычно можно уточнить у реселлеров, причем желательно у тех, которые не просто продают, но и занимаются системной интеграцией. И применительно к СХД надо понимать, что даже если вендорлока официально нет, то работоспособность конкретного диска с конкретной моделью хранилки все равно лучше уточнять заранее. В моей практике был случай, когда СХД Infortrend отказалась работать с SSD Seagate Nytro, несмотря на то, что он позиционировался как накопитель корпоративного класса.
Т.к. таблицу разделов с /dev/nvme0n1 на /dev/nvme1n1 скопировали, то и раздел /dev/nvme1n1p2 существует. Теперь видимо нужно его отформатировать в FAT32, подмонтировать и скопировать в него содержимое с /dev/nvme0n1p2
Вообще "есть есть ли пир 101 то идти на такой то астериск, если 201-идти на друго" - это задача стопроцентно не для микротика. Такое нужно на ip-атс разруливать, диалпланом Asterisk например. А в Mikrotik уже применять обычную обработку трафика по ip-адресам sip-пиров.
Вопрос - чего именно вы хотите достичь? Представляется, что какой-либо практический смысл может иметь маркировка голосового RTP-трафика, но средствами Микротика связать конкретный RTP-поток с породившей его SIP-сессией будет не менее затруднительно, чем просто отпарсить транзитный SIP-пакет.
Дропать вообще весь входящий трафик на роутере - не очень-то полезный совет. И главное, какой в этом практический смысл? Например протокол icmp - это не только ping/traceroute, но и всякие служебные сообщения, необходимые для корректной работы TCP (простейший пример - icmp-сообщение fragmentation needed). Блокировать нужно корректные порты, а не все подряд.
Чтобы доступ заработал, нужно еще в настройках брандмауэра Windows разрешить подключение с недоверенных сетей. Но вообще выставлять RDP в интернет - очень плохая идея в плане безопасности. Нужен или VPN, или хотя бы ограничивать подключение белым список ip-адресов, а смена порта только немного отсрочит время, когда могут случиться большие неприятности.
Если маршрутизатор уже виртуализованный, то так ли необходимо его резервирование в виде второй независимой виртуалки? Системы виртуализации ведь имеют много средств для обеспечения бесперебойной работы виртуалок - миграцию, автоматический перезапуск и т.д.
Смотря какой накопитель и как прошивать. Однажды восстанавливал после сбоя накопитель Smartbuy, который потерял данные и стал определяться как SATAFIRM. После заливки firmware накопитель стал считать, что он новый - все ресурсные счетчики в Smart обнулились.
Попробуйте запустить систему в виртуализованном окружении, например в Virtualbox, пробросив флешку в виртуалку как физическое устройство. Как это сделать, описано например здесь - https://remontcompa.ru/virtualnye-mashiny/page,1,2...
Если получится, то далее с большой вероятностью получится средствами VirtualBox сделать образ диска, с которого можно будет успешно грузиться.
