GNS3 und Lab

dynamips&GNS3 ist wirklich interessant um schnell mal was zu checken - wollte mit bgp cluster-ids spielen und mein phyisches lab ist noch nicht wieder aufgebaut - da hab ich mal mit GNS3 herumgespielt. bin normaler weise ein fan von realen routern (und bin es immer noch) aber wenn es schnell mal was zum checken gibt geht dynamips&GNS auch.
Apropos LAB .. bekomme jetzt wahrscheinlich doch noch etwas ATM material - aber die voice sachen müssen auch noch ran geschafft werden.
muss mir jetzt fixe ziele für die voice sachen setzten - möchte doch das written in den ersten drei monaten machen und dazu die CCNP voice also step-by-step aproach verwenden.
aber mal wieder mit BGP und ATM spielen muss auch sein. sonst rostet man einfach. aber die cluster-id sachen für routereflectoren vergesse ich nie mehr ... hat mich den ersten lab versuch gekostet.

dbreplication ...

interessantes feature .. scheinbar sind versionen von callmanager unterschiedlich bei CLI commands.
final hat der dbreplication reset nun funktioniert .. nur nicht mit der IP (da passiert einfach nix) .. der hostname muss verwendet werden.
so wie ich es verstanden habe wird zuerst ein "pre-flight" file zum node geschickt (ver sftp oder ssh)
dann werden die definitions der tabellen geschickt und danach jede tabelle einzeln gesynced
wenn nun diese preflight file nicht rübergeht dann passiert nix einfach nix und man kann per normalem cli access nicht einfach kontrollieren ob die replication nun passiert .. es gibt ein paar informix logfiles die man checken kann dort steht dann was drinnen cm/logs/informix... oder so ..

was ich aber gesehen habe ist das man mit dem file list activelog * auf der kist stöbern kann

callmanager DBreplication, TFTP und sonstiges ..

hatte vorgestern ein erlebnis mit dem TFTP server unseres clusters. Nach dem konfiguieren von eine paar neuen phones hat alles soweit gut augschaut - nur die timezone auf den phones hat gefehlt .. hab alles kontrolliert aber nix auffälliges - beim kontrolieren des TFTP servers ist dann herausgekommen das das cnf.xml file des phones nicht in ordung war (war das alte files des phones).
Wollte dann den TFTP server neustarten - hatte jedoch kein glück es kann immer die meldung das der publisher nicht auf den subscriber zugreifen kann (Unable to connect). Hab dann einen TAC case aufgemacht da ansonsten keine Errors von dem TFTP server zu sehen waren. der TAC mann hat die config, die replication usw. schliesslich sind wir bei einem reboot angelangt.
Nach dem reboot war zwar der server wieder erreichbar via die servicability seite - jedoch das TFTP file ware immer noch falsch.
Ein check der replication mit "utils dbreplication status" via CLI hat dann ergeben das 33tabeln auf der subscriber DB nicht dem entsprachen was auf dem publisher war.
Nach weiterem schauen hat der TAC mann (sehr guter engineer diesmal) gemeint das nur ein neu sync der DB hilft. gesagt getan "utils dbprelication stop" zuerst auf dem sub dann auf dem pub und ein "utils dbreplication reset ". nachdem das gelaufen ist sind 19 der 33 tabellen nun ok. Der TFTP liefert auch das richtig file aber 14 tabellen sind immer noch nicht sync.
werde wohl nochmal mit dem TAC reden wie man die restlichen auch noch in sync bringt.
Diesmal war der TAC engineer wirklich fit - hat gleich den root access aufgemacht und mit den informix commands die checks gemacht.
der remote_access ist interessant - würde gerne wissen wie das genau funktioniert. man schaltet über das CLI einen account frei (der wird generiert mit passwort und allem) dann bekommt man einen passphrase - da muss dann der TAC ein tool haben damit er das richtige passwort bekommt. also kann es nicht etwas wie MD5 sein. Hab mal auf meiner VMWARE version etwas herumgestöbert und auch das program gefunden was den account generiert. mal sehen ob man da etwas herausfindet.
Im Web gibt es nur anleitungen wie man den account dann mit einem neuen PW versieht. das geht zwar auf einer VMWARE aber auf dem produktiven system ist da vielleicht nicht so schlau. hab da dieses gefunden was auch gut funktioniert

admin:utils remote_account create abcdefg 30
admin:utils system restart
-Proceed to insert the CentOS 5.2 Disk 1
-on the Boot option enter linux rescue
boot:linux rescue
-Once you are in the linux shell
-Proceed to do the following
#lsattr /etc/passwd /etc/group /etc/shadow /etc/gshadow
#chattr -i /etc/passwd /etc/shadow /etc/group /etc/gshadow
#passwd [enter the username that you have created for the remote account user]
-Enter the new password that you want for the new remote account user twice
-eject the CentOS 5.2 DISK 1
-Reboot the server by doing the following

danach kann man mit dem account einloggen und hat eine root shell - praktisch ....

Unity - alle guten dinge sind drei

final ist nun unity soweit das die roten errors weg sind. Permissions war ein punkt - der andere war TCP Chimney auf dem server auf dem Unity installiert ist. Mit 2003 Server SP2 wird die TCP Chimney funktion default halber eingeschaltet. Es ist nichts anderes als das TCP Stack funktionen auf den server ausgelagert werden wenn der NIC es unterstützt -- nun ist der punkt das der NIC das halt auch richtig machen muss - bzw der treiber dafür. M$ nimmt einfach als gegeben an das der treiber der neueste ist. Blöd gelaufen.
Nach dem abschalten der TCP Chimney funktion hat MAPI mal wieder richtig funktioniert. Danach war noch etwas mit dem BMUS_Connector was jedoch noch nicht bestätigt ist. Danach waren die Errors weg.. magic !?!?

Muss mir die TCP sachen von 2003 server mal genauere anschauen. jedoch hab ich im moment wenig zeit.