'Среда передачи не прошла проверку' на ethernet-интерфейсе

Недавно позвонил товарищ, пригласил поучаствовать в траблшутинге сетевых проблем windows xp по телефону. Я, конечно, легко обойдусь без подобных развлечений, но ведь никто, кроме нас. Симптом - "нет интернета", порт на маршрутизаторе не загорается. После обычных махинаций (смена кабеля и прочая), обратил внимание на вывод ipconfig (продекламированный мне по телефону), а именно: в статусе ethernet-интерфейса было указано 'Среда передачи не прошла проверку подлинности'. Ключевые слова 'среда передачи' и 'проверка' натолкнули меня, не так давно сдавшего-таки 642-813 SWITCH,  на мысль, что в деле замешан 802.1x. Так и вышло. Единственное, что заставило потратить дополнительных 10 минут - 802.1x отключался не вместе с IPv4/v6, службой принтеров, LLDP и прочая, а на отдельной вкладке.

Из этого непримечательного, в общем-то, случая я сделал выводы:

1) Надо бы углубить знания настройки сети в ОС Windows. Думаю, команда netsh при правильном подходе помогла бы сократить время диагностики проблемы.

2) Баребоны (это был баребон, маленький такой компьютер) могут идти в комплекте с довольно специфическими колокольчиками и свистелками (вроде включенного 802.1x на 'медном' интерфейсе. А еще там была программа от Juniper для постройки тоннеля неизвестно куда) 

3) Системный подход часто помогает решить проблему даже при отсутствии релевантного опыта (ни разу не настраивал 802.1x в Windows, например)

клиенты-серверы

Читая книгу Робачевского-Немнюгина-Стесик про юниксы, поймал себя на мысли. Раньше, когда речь заходила о клиент-серверной архитектуре, я сразу представлял один мощный компьютер или их ферму (сервер/ы) и множество других компьютеров попроще, клиентов. Причем связь всегда подразумевалась через сетевые интерфейсы (чтоугодно-over-IP). В этой книге же представлена историческая перспектива  средств взаимодействия процессов, и соответственно сервер определяется как процесс, предоставляющий некие сервисы (вычисляющий, предоставляющий данные по запросу извне). Такое определение или, скорее, описание, кажется мне более общим и корректным.

Verification of your TeamViewer version failed

English version here.
Недавно попросили разобраться с утилитой Teamviewer, внезапно начавшей вываливаться с указанной в заголовке ошибкой. В качестве операционной системы выступала Windows XP. Как выяснилось, бинарник подписан ЭЦП, соответственно для прохождения проверки нужны :
1) рабочая крипто-инфраструктура.
2) загруженные корневые сертификаты.

Пункт 1) описан здесь http://support.microsoft.com/kb/958045/en-us, там же предложено решение (выполнить в консоли):

regsvr32 Softpub.dll /s
regsvr32 Wintrust.dll /s
regsvr32 Initpki.dll /s
regsvr32 Mssip32.dll /s

Пункт 2) заключается в установке корневых сертификатов отсюда: http://www.verisign.com/support/roots.zip (почитать: https://www.symantec.com/page.jsp?id=roots)

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

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

Задумался недавно о различных вариантах ведения документации на сеть, точнее о журнале адресации и различных (L3,L3 и т.д.) схемах сети.

Есть уже ощущение, что в 21 веке как-то грустно вносить руками префикс в excel-таблицу или дорисовывать новый линк в Visio, отдельно на L2-карте, отдельно на L3-карте. С другой стороны, многие автоматизированные решения предполагают использование CLI рабочего оборудования роботом с целью выяснения топологии. В таком варианте вполне вероятна ситуация, когда в результате ошибки робот начнет генерировать тяжелые для процессора запросы с высокой частотой, что приведет к высокой утилизации процессора и последующим неприятным событиям. Конечно, в некоторых устройствах некторых вендоров management plane и control plane независимы, но в общем случае не хотелось бы иметь такие риски. С другой стороны, в лучших домах Европы уже, как правило, реализовано архивирование и отслеживание версий конфигураций, так почему бы просто не парсить конфиги? Конечно, сначала необходимо задать базовую структуру сети (роли устройств и их связи), но затем добавление нового L3-линка, например, элементарно отследить по изменению конфигов. В случае включенных L2-discovery протоколов (CDP, LLDP) доступ к их данных можно [попытаться] получить через SNMP. В идеале из полученных данных можно собрать граф и визуализировать его стильным-молодежным js-фреймворком. Такие мысли.

TL;DR: пускать кого попало в cli неок, безопаснее парсить конфиги.

уна палабра нуэва

Недавно вычитал новое слово - "сормировать", в смысле направлять трафик на оборудование СОРМ-2. Занятно.

вот интересно, почему так:
Bridge Virtual Interface
Switch Virtual Interface
но
Virtual Tunnel Interface, а не Tunnel Virtual Interface?

mikov active-active HA & graceful service degradation

Дощелкался.
Есть у меня нож автоматический, Mikov, чешский. Вот такой (фото из интернета).

В сложенном состоянии клинок спрятан внутри рукояти, и при нажатии рычажка выбрасывается наружу пружиной. Точнее пружинами, их там две одинаковых. И вот недавно одна из них лопнула, и теперь нож иногда недораскрывается. Раньше их делали с одной пружиной, и в те времена в такой ситации надо было ждать новую. По мне, так вполне наглядный пример active-active HA (пружины работают одновременно) и graceful degradation (при поломке одной пружины в целом функциональность сохраняется). Занятно, как одни и те же принципы применимы в совершенно разных, казалось бы, областях.