Windows Server 2012 R2 (Build 9600) auf HP Microserver N36L

In meinem Hardware-Park darf ich auch einen HP Microserver N36L mein eigen nennen. Im Jahr 2011 habe konnte ich bereits Testberichte über den N36L in Bezug auf Windows 7 bzw. Windows Server 2008 R2 liefern (hier, ich war der Projektkollege).

Nun folgt vor kurzem ein weiterer kleiner Machbarkeits-Test für die inzwischen etwas betagte Lady mit Windows Server 2012 R2 (Build 9600).

Leider verlief die Installation nicht ganz so reibungslos wie beim Windows Server 2008 R2.

Das initiale Betanken mit dem Image klappte, jedoch stockte es beim ersten in dem Punkt „Getting devices ready“ bei genau 84%. In meinem Microserver N36L war sowohl Remote Access Karte als auch eine Intel PRO/1000 PT Dual Port Netzwerkkarte verbaut. Da es sich offensichtlich um ein Hardwarethema begann ich Geräte zu deaktivieren. Erster Ansatz war der Onboard Netzwerkchipsatz (Sorry Broadcom), da dieser Port unter Windows Server 2008 R2 Hyper-V eh deaktiviert war kein starker Verlust und siehe da, die Maschine installierte nun sauber durch.

Die Installation von Windows Server 2012 R2 (Build 9600) klappte problemlos. Alle weiteren Geräte und Treiber wurden erkannt.

Die Intel PRO/1000 PT Dual Port Netzwerkkarte läuft im LACP Teaming. Eine weitere Intel Gigabit-CT-Desktop-Adapter dient als Management-Interface für den darauf laufenden Hyper-V Host.

Um der Parent-Partition etwas „boost“ zu geben hängt eine kleine SSD am SATA Port, der ursprünglich mal für ein 5,25″ Laufwerk gedacht war.

Noch ein Tipp:Der Original-Lüfter ist inzwischen gegen einen Sharkoon SILENT EAGLE 1000 (120mm) getauscht. So ist das Gerät nahezu geräuschlos.

Nützliche KMS Kommandos für die CLI

KMS steht für „Key Management Infrastrukture“ und dient zur Aktivierung der Betriebssysteme innerhalb einer Organisationsstruktur für Volumenlizenzen. Neben dem „KMS“ gibt es auch eine weitere Möglichkeit zur Aktivierung, dem „MAK“, für „Multiple Activation Key“.

Folgend nun ein paar Tipps und Kniffe aus dem Tagesgeschäft.

Ist der KMS im DNS veröffentlicht, so wird er automatisch von dem AD-Member in der Domain über den DNS SRV-Record discovered. Mit dem Tool nsloookup kann der KMS Server auch abgefragt werden:

U:\>nslookup -type=srv _vlmcs._tcp.jorde.it
Server: dc01.jorde.it
Address: 10.10.11.12

_vlmcs._tcp.jorde.it     SRV service location:
priority       = 0
weight         = 0
port           = 1688
svr hostname   = kms01.jorde.it
kms01.jorde.it internet address = 10.11.12.13

Man kann allerdings auch mit Hilfe des Tools slmgr.vbs eine Aktivierung gegen einen KMS forcieren.

slmgr.vbs /skms 10.11.12.13:1688
slmgr.vbs /ipk FJ82H-XT6CR-J8D7P-XQJJ2-GPDD4
slmgr.vbs /ato

Der Schalter /skms setzt hierbei den KMS, der Schalter /ipk hinterlegt den KMS-Client Key, der Schalter /ato forciert die Aktivierung gegen das Ziel mit dem Key.

Auch zur Aktivierung von Office kann der Windows Server KMS genutzt werden. Herbei ist das nützliche Tool ospp.vbs hilfreich

cd „%programfiles(x86)%\Microsoft Office\Office15“
cscript ospp.vbs /sethst:kms01.jorde.it
cscript ospp.vbs /act

Ob der KMS aufnahmebereit oder für Office freigegeben ist, kann mittels slmgr.vbs /dlv all bzw slmgr.vbs /dli all. Der Schalter dlv steht hierbei für erweiterte Informationen. Der Zusatz all für die Auflistung aller Activation IDs.

Die KMS Serverkeys sind im Volume Licensing Service Center (VLSC) erhältlich.

Die KMS Clientkeys sind public:

 

Windows Server 2012 R2 „Recommended Hotfix List“

Gibt es jetzt auch als Neuauflage für Windows Server 2012 R2 Hyper-V:

http://social.technet.microsoft.com/wiki/contents/articles/20885.hyper-v-update-list-for-windows-server-2012-r2.aspx (wird ständig von Microsoft aktualisiert)

Das gleiche jetzt auch als KB Artikel direkt von Microsoft speziell für Failover Cluster:

http://support.microsoft.com/kb/2920151 (wird ständig von Microsoft aktualisiert)

 

Windows Server 2012 R2 (Build 9600) auf HP DL380 G5

Obwohl es seitens HP, meines Wissens, keinen offiziellen Support mehr für Windows Server 2012 R2 auf einem HP DL380 G5 gibt, war es mal einen Versuch wert. Erfolg!

Wie? Da in div. Foren ggf. Probleme mit dem Controller P400 dokumentiert sind, habe ich vor der Windows Server 2012 R2 Installation das Supportpack 2013.09.0 drüber laufen lassen (es war noch ein Windows Server 2008 R2 enthalten) um auch alle Firmware-Stände aktuell zu bekommen.

Die Installation des Windows Severs 2012 R2 lief problemlos durch. Einige Geräte wurden nicht sauber erkannt, jedoch konnte ich nach der Installation des Windows Servers 2012 R2 das Supportpack 2013.09.0 nochmal drüber laufen lassen. Beim ersten Durchlauf schlugen einige Installationen fehl, der zweite Rest lief dann sauber durch.

Alle Geräte im Device Manager laufen, IML als auch HP System Management Homepage sind sauber und Windows Eventlog auch. Danach der Hyper-V Test – auch hier alles ok.

Troubleshooting Cisco Aironet Client Disconnectes

Gestern hatte ich Gelegenheit ein WLAN-Problem zu entstören, bei dem ca. 50% der angebundenen Clients sofort nach der erfolgreichen Assoziierung sich wieder getrennt haben.

Auf dem Access Point wurde z. B. folgendes gelogged (man achte auf dem Timecode!):

Jan 28 13:30:57.230: %DOT11-6-ASSOC: Interface Dot11Radio0, Station   aaaa.bbbb.cccc Associated KEY_MGMT[WPAv2 PSK]
Jan 28 13:30:57.294: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station aaaa.bbbb.cccc Reason: Sending station has left the BSS
Jan 28 13:30:57.294: Dot11Radio0: Going to delete client aaaa.bbbb.cccc Reason: request

Um sich dem Thema zu nähern habe ich erstmal geprüft, ob ggf. ein Störer existiert:

AP# debug dot11 dot11Radio 0 carrier busy
Jan 28 12:53:28.577: **disc_send_reset_event, event=1
Jan 28 12:53:28.581: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to down
Jan 28 12:53:28.589: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
Jan 28 12:53:29.581: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
Jan 28 12:53:29.585: DOT11 EVENT:disc_config: root set device to 9E
Frequency  Carrier Busy %
———  ————–
2412         18
2417         18
2422          4
2427          7
2432         16
2437          7
2442          9
2447          7
2452         13
2457          7
2462         58
2467         11
2472         43
dot11_build_allowed_power_levels 8764 8000 0
Jan 28 12:53:44.673: DOT11 EVENT: dot11_build_allowed_power_levels 8764 8000 0
Jan 28 12:53:49.461: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to up
Jan 28 12:53:50.461: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

Zu beachten ist hier, dass das Radio-Interface für den Zeitraum in einen Reset-Status geht. Auch der aktuell ausgewählte Kanal kann abgerufen werden:

AP# show controllers do 0
!
interface Dot11Radio0
Radio Ibiza 2.4, Base Address cccc.dddd.ffff, BBlock version 0.00, Software version 4.18.1
Serial number: FOCxxxxxxxx
Unused dynamic SQRAM memory: 0x0000C8F0 (50 KB)
Unused dynamic SDRAM memory: 0x00089264 (548 KB)
Spectrum FW version: 1.15.0
Number of supported simultaneous BSSID on Dot11Radio0: 16
Carrier Set: EMEA (EU) (-E)
Uniform Spreading Required: No
Configured Frequency: 2447 MHz  Channel 8 

Notfalls, kann man bei Bedarf den automatisch gewählten Kanal auch nochmals automatisch suchen lassen oder den Access-Point in einen Kanal zwingen:

AP(config)# interface Do0
AP(config-if)# channel least-congested
Jan 28 12:51:14.680: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to down
Jan 28 12:51:14.688: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
Jan 28 12:51:15.680: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
Jan 28 12:51:15.684: DOT11 EVENT:disc_config: root set device to 9E
Jan 28 12:51:15.688: %DOT11-6-FREQ_SCAN: Interface Dot11Radio0, Scanning frequencies for 13 seconds
Jan 28 12:51:28.955: DOT11 EVENT: dot11_build_allowed_power_levels 8764 8000 0
Jan 28 12:51:33.147: %DOT11-6-FREQ_USED: Interface Dot11Radio0, frequency 2447 selected
Jan 28 12:51:33.147: DOT11 EVENT: dot11_build_allowed_power_levels 8764 8000 0
Jan 28 12:51:38.039: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to up
Jan 28 12:51:39.039: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up

Nun zurück zum Problem, dem sofortigen Trennen der Verbindung. Das Standardlog impliziert, dass der PC die Trennung forciert hat. Mit ein paar Debug-Befehlen kann man dies untermauern:

AP#deb dot11 mgmt interface
AP#deb dot11 mgmt msg
AP#deb dot11 mgmt ssid
AP#deb dot11 mgmt state-machine
AP#deb dot11 mgmt station
Jan 28 13:30:57.214: Dot11Radio0: Tx AssocResp client aaaa.bbbb.cccc
Jan 28 13:30:57.214: dot11_mgmt: dot11_mgmt_sta_deref (ref=3, sta_ptr=0x734648C, mac=aaaa.bbbb.cccc)
Jan 28 13:30:57.230: dot11_mgmt: recv AAA Auth resp for aaaa.bbbb.cccc, vlan name , id 10 and wnid 0
Jan 28 13:30:57.230: dot11_mgmt: same VLAN return from AAA
Jan 28 13:30:57.230: dot11_mgmt: dot11_mgmt_sta_ref (ref=2, sta_ptr=0x734648C, mac=aaaa.bbbb.cccc)
Jan 28 13:30:57.230: SM: —Open Authentication 0x734648C: AAA Auth OK (5)
Jan 28 13:30:57.230: SM:    AAA_Auth (6) –> Assoc (2)
Jan 28 13:30:57.230: %DOT11-6-ASSOC: Interface Dot11Radio0, Station   aaaa.bbbb.cccc Associated KEY_MGMT[WPAv2 PSK]
Jan 28 13:30:57.230: dot11_mgmt:aaaa.bbbb.cccc bss client assoc/reassoc updated stats curr_assoc 2 cur_bss_assoc 2 cur_rptrs 0 cur_bss_rptrs 0lwapp_session_timeout not starting for aaaa.bbbb.cccc
Jan 28 13:30:57.230: dot11_mgmt: dot11_mgmt_sta_deref (ref=3, sta_ptr=0x734648C, mac=aaaa.bbbb.cccc)
Jan 28 13:30:57.294: Dot11Radio0: Rx DisAssoc client aaaa.bbbb.cccc
Jan 28 13:30:57.294: dot11_mgmt:receive disassoc from aaaa.bbbb.cccc
Jan 28 13:30:57.294: Dot11Radio0: Tx Deauth client aaaa.bbbb.cccc
Jan 28 13:30:57.294:  dot11_mgmt: de-auth msg sent with reason = 2

Hier ist klar erkennbar, dass nach der erfolgreichen Assoziation zum WLAN sofort ein DisAssoc vom Client zum Access Point gesendet wird. Ab diesem Punkt habe ich dann gemeinsam mit dem x86-Plattformkollegen den Client „zerlegt“. Letztendlich konnte es auf ein fehlerhaftes verhalten des Virenscanners zurückgeführt werden bei dem eine Policy die Nutzung des WLANs versehentlicherweise geblockt hat.

Cisco NAT / PAT und ACL mit LOG

Möchte man, dass mehrere Nutzer eines internen Subnetzes z.B. das Internet über eine öffentliche IP nutzen möchten so kommt bekannterweise NAT/PAT zum Einsatz.

Beim folgenden Beispiel ist der Dialer1 das „überladene“ Interface Richtung Internet welches geshared werden soll.

ip nat inside source list 101 interface Dialer1 overload
access-list 101 permit ip 10.11.12.0 0.0.0.255 any

Möchte man sich die Treffer der Access-List ins Log schreiben lassen ergänzt man das access-list statement bekanntermaßen um ein „log“

access-list 101 permit ip 10.11.12.0 0.0.0.255 any log

Nicht so beim NAT. Nutzt man access-listen für das NATting so ist hier der Zusatz „log“ nicht supported. Das NATting wird mit dem Zusatz „log“ nicht funktionieren.

Das Thema ist auch offiziell seitens Cisco dokumentiert in Dokument 26704 vom 26.04.2013 auf cisco.com.

 

 

Virtuelle Maschine sporadisch nicht erreichbar

Gestern erreichte mich ein Problem, dass nach dem Umbau div. Hyper-V Singlehosts zwei virtuelle Maschinen auf einem neuen Host sporadisch nicht mehr erreichbar waren. Die Umgebung bestand aus div. HP Procuve Switchen incl. einem L3 Switch sowie div. HP Proliant DL Servern. Die Hyper-V Hosts hatten Windows Server 2008 R2 Enterprise und die virtuellen Maschinen Windows Server 2008 R2 Standard.

Ein Dauerping auf eine der betroffenen virtuellen Maschinen zeigte sporadische Timeouts.

Das riecht nach Troubleshooting. Beginnen wir mit dem Layer 1 – nachdem die Verkabelung zum betroffenen Singlehost geprüft und die Zuordnung der virtuellen Netze im Hyper-V Manager geprüft war ging direkt auf die nächste Ebene. Da es nach einem Netzwerkproblem aussieht (sogar ICMPs gehen nicht durch) könnte der Fehler bereits im Layer 2 liegen.

Gesagt getan, erster Punkt, pingen vom Routerinterface des VLANs. Auch hier klappte es mal und mal nicht – gleiches Fehlerbild.

sw1# ping 10.10.1.10
10.10.1.10 is alive, time = 6 ms
Request timed out.
Request timed out.
Request timed out.
10.10.1.10 is alive, time = 1 ms
10.10.1.10 is alive, time = 1 ms
10.10.1.10 is alive, time = 1 ms

Als nächstes liegt es also nahe zu prüfen, ob die MAC Adresse hinter der virtuellen Maschine mit der IP 10.10.1.10 auch wirklich an dem Port des Public-Interfaces vom Hyper-V Host bekannt ist.

sw1# sh mac-address 00155d-32fb04
Status and Counters – Address Table – 00155d-32fb04
Port VLAN
Trk1 21

Der Ping lief zunächst, plötzlich brach der Ping weg und selbiger Befehl auf dem Switch sw1 zeigte nun folgendes:

sw1# sh mac-address 00155d-32fb04
Status and Counters – Address Table – 00155d-32fb04
Port VLAN
Trk2 21

Ok, die Ursache für die sporadische Nichterreichbarkeit scheint gefunden aber warum wechselt die ist die gleiche MAC plötzlich auf einem anderen Interface bekannt?

Es galt zu hinterfragen was genau beim Umbau passiert ist:

Es waren vor dem Umbau zwei Hyper-V Singlehost VH1 und VH2. Die IP des VH2 wurde geändert und es kam ein dritter Hyper-V Singlehost, VH3, hinzu und bekam die IP des VH2.

Ok der Fall wird klarer. Bei Hyper-V arbeitet Microsoft mit dynamischen MAC Adress Pools welche wie folgt zusammengesetzt sind:

Z. B. die MAC Adresse 00:15:5D:32:FB:01

  • 00:15:5D is the OEM identifier
  • 32:FB letzten zwei Oktetts des ersten Hyper-V Netzwerkadapters konvertiert in HEX
  • 01 aufsteigende Nummerierung

Nun war es relativ einfach, die dynamischen MAC Address Pools beider Hyper-V Singlehosts waren identisch. Warum? Als die Hyper-V Rolle auf dem VH2 zur Installation aktiviert wurde, wurde der MAC Adresspool generiert (wird abgelegt unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization bzw. ist im Hyper-V Netzwork Manager auch sichtbar) – der VH2 hatte zum Zeitpunkt der Aktivierung der Rolle „x.x.50.251“ gebunden insofern kam es zu „32:FB“. Während der Laufzeit des VH2 wurde die IP geändert aber der dynamische MAC Pool bleibt natürlich gleich.

Als der VH3 nun mit der alten IP des VH2 konfiguriert und dessen Hyper-V Rolle aktiviert wurde generierte er nach der gleichen Logik auch „32:FB“ und seine erste Maschine bekam die „01“ verpasst.

Btw: so ein Fehlerbild erhält man auch in größeren Umgebungen wenn jmd eine virtuelle Maschine von z.B. Singlehost A auf Singlehost B umzieht jedoch die alte VM auf Singlehost A heruntergefahren liegen lässt und dann später versehentlich hochfährt.

Hier ein weiterer interessanter Artikel zum Thema der MAC Address Kollision:

  • http://blogs.technet.com/b/jhoward/archive/2008/07/15/hyper-v-mac-address-allocation-and-apparent-network-issues-mac-collisions-can-cause.aspx

 

Cisco CLI mit Befehls-Alias

Wer häufig bestimmte komplexere Befehle auf Cisco Routern nutzt dem werden Aliase sehr gefallen.

Wer Linux kennt wird ab und zu auch mal den Befehl „top“ verwenden welcher die Top CPU Prozesse auflistet. Auf Cisco Routern und Switchen kann man sich mit dem befehl

router1#show processes cpu

Die CPU Prozesse incl. deren Last ausgeben lassen. Aufgelistet werden hier jedoch alle unabhängig ob sie Last verursachen oder nicht. So könnte man mit
einem gepipeden Exclude von „0.00% 0.00% 0.00%“ sich die ausgabe etwas zurecht filtern.

router1#show processes cpu | e 0.00% 0.00% 0.00%
CPU utilization for five seconds: 1%/0%; one minute: 1%; five minutes: 1%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
5 3953752 496538 7962 0.00% 0.11% 0.11% 0 Check heaps
12 3719304 48936 76003 0.00% 0.07% 0.10% 0 Licensing Auto U
13 2449332 2936043 834 0.00% 0.06% 0.05% 0 Environmental mo

Auf Dauer geht es einfacher gehts mit dem Befehls-Alias:

router1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
router1(config)#alias exec top show processes cpu | e 0.00% 0.00% 0.00%
router1(config)#exit
router1#top
CPU utilization for five seconds: 1%/0%; one minute: 1%; five minutes: 1%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
2 352 587977 0 0.00% 0.01% 0.00% 0 Load Meter
5 3953912 496558 7962 0.00% 0.13% 0.11% 0 Check heaps
12 3719380 48937 76003 0.00% 0.07% 0.10% 0 Licensing Auto U
13 2449408 2936157 834 0.00% 0.07% 0.05% 0 Environmental mo
58 836 1138 734 0.23% 0.11% 0.03% 132 SSH Process
84 1268 587995 2 0.00% 0.01% 0.00% 0 Compute load avg

IIS, WPI, date.timezone=Asia/Kuwait und Cacti

Bei der Vorbereitung einer Cacti-Installation auf einem Windows Server 2012 kann man sehr bequem PHP mit dem sogenannten „Microsoft Web Platform Installer“ installieren. Das ist eine sehr smarte Geschichte beim Deployment, die viel Zeit spart da bei der Installation sämtliche Abhängigkeiten mit installiert und konfiguriert werden (den WPI in der jeweils aktuellen Version gibt es hier http://www.microsoft.com/web/downloads/platform.aspx).

Nach der Installation und Konfiguration der Cacti-Komponenten konnte ich jedoch keine Datenpunkte in den jeweiligen Graphen sehen:

fehlende Daten im Cacti-Graphen

Es wurde lediglich ein „-1.#J“ im Interface-Graph angezeigt.

Ein Studium des Logs brachte auch keine Ergebnisse.

Die Jobs liefen sauber durch:

06/24/2013 06:35:16 PM – POLLER: Poller[0] CACTI2RRD: c:/rrdtool/rrdtool.exe update C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_191.rrd –template traffic_in:traffic_out 1372091715:0:0
06/24/2013 06:35:16 PM – POLLER: Poller[0] CACTI2RRD: c:/rrdtool/rrdtool.exe update C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_190.rrd –template traffic_out:traffic_in 1372091715:0:0
06/24/2013 06:35:16 PM – CMDPHP: Poller[0] Host[9] DS[259] SNMP: v2: 10.41.254.254, dsname: traffic_out, oid: .1.3.6.1.2.1.31.1.1.1.10.7, output: 0
06/24/2013 06:35:16 PM – CMDPHP: Poller[0] Host[8] DS[221] SNMP: v2: 10.41.254.250, dsname: traffic_in, oid: .1.3.6.1.2.1.31.1.1.1.6.10019, output: 0

… und auch die RRD-Dateien wurden aktualisiert…

C:\rrdtool>rrdtool.exe info C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_183
.rrd
filename = „C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_183.rrd“
rrd_version = „0003“
step = 300
last_update = 1372103415

C:\rrdtool>rrdtool.exe info C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_183
.rrd
filename = „C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_183.rrd“
rrd_version = „0003“
step = 300
last_update = 137210371

Die Erkenntnis kam dann nach dem Abendessen, als ein von mir beim Troubleshooten noch nicht gelöschter Graph plötzlich doch Datenpunkte anzeigte – ein Zeitthema lag nah.

Also fix die PHP.ini gecheckt (liegt bei einer WPI Installation C:\Program Files (x86)\PHP\v5.4), dort unter „Module Settings“ die „date.timezone“ auf:

date.timezone = Europe/Berlin

konfiguriert, IIS durchgestartet und erneut geprüft. Kein Erfolg – in der phpinfo(); stand die Zeit noch immer auf „Asia/Kuwait“. Also nochmal ab in die PHP.ini und auch fündig geworden:

[WebPIChanges]
date.timezone=Asia/Kuwait

In dem vom Microsoft Web Platform Installer konfigurierten Änderungen beim Deployment vom PHP wurde auch nochmal ganz am Ende der php.ini eine Zeitzone gesetzt.

Diesen Eintrag also raus (habe ja den korrekten Eintrag gesetzt), IIS durchgestartet und es lief.

Kabelfehler via Zeitbereichsreflektometrie erkennen

Hallo zusammen,

ein sehr interessantes Feature auf vielen Catalyst Switchen von Cisco ist der Bereich „cable-diagnostics“.

Über Zeitbereichsreflektometrie (Time Domain Reflectometry, kurz TDR) können mittels Impulse Längen und Fehler am Kabel erkannt werden.

Nun kurz Anbei kurz skizziert, wie das Verfahren beispielsweise auf einem WS-C2960-48TC-L angewendet wird.

hydra#sh int description | include host
Fa0/5                          up             up       host#pub1
hydra#test cable-diagnostics tdr int fa 0/3
hydra#show cable-diagnostics tdr int fa 0/1
TDR test last run on: March 21 05:05:22

Interface Speed Local pair Pair length        Remote pair Pair status
——— —– ———- —————— ———– ——————–
Fa0/1     100M  Pair A     8    +/- 15 meters Pair A      Normal
Pair B     8    +/- 15 meters Pair B      Normal
Pair C     N/A                Pair C      Not Supported
Pair D     N/A                Pair D      Not Supported

Der 2960er, auf dem ich getestet habe supportet TDR auch auf den Fa’s, testet dort natürlich nur die A und B Pärrchen.

Hier noch ein Beispiel von einem Gi, wo aktuell kein Kabel aufgesteckt ist:

hydra#test cable-diagnostics tdr interface gigabitEthernet 0/1
TDR test started on interface Gi0/1
A TDR test can take a few seconds to run on an interface
Use ’show cable-diagnostics tdr‘ to read the TDR results.
hydra#show cable-diagnostics tdr interface gigabitEthernet 0/1
TDR test last run on: March 21 05:31:34

Interface Speed Local pair Pair length        Remote pair Pair status
——— —– ———- —————— ———– ——————–
Gi0/1     auto  Pair A     0    +/- 2  meters N/A         Open
Pair B     0    +/- 2  meters N/A         Open
Pair C     0    +/- 2  meters N/A         Open
Pair D     0    +/- 2  meters N/A         Open

Was bedeutet nun Open, Normal und Not Supported?

  • Normal – alles ok (bei Fa nur A/B bei Gi A/B/C/D)
  • Open – mindestens ein Pin hat keinen Kontakt
  • Short – Kurzschuss
  • Impenance Mismatched – Schlechtes Kabel, „das Signal schafft es nicht“

Abschließend ein prima weiterführender Link aus dem Cisco Forum.

Fortsetzung folgt… es gibt auch eine Möglichkeit über Intel PROSet seitens Client/Server. Hierzu später mehr.