Ethernet-Bridging über MPLS

Der Cisco MPLS-Kurs ist zwar im großen und ganzen recht “rund”, beschränkt sich aber fast ausschließlich auf MPLS-VPNs für IPv4. Das man auch andere Protokolle transportieren kann ist nur am Rande erwähnt. Dafür habe ich hier ein kleines Beispiel wie man mit AToM (AnyTransport over MPLS) zwei Standorte per Bridging über das MPLS verbindet:

Als Router kommen mal wieder 7200er (im GNS3) mit IOS 15.0(1)M4 zum Einsatz:

Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.0(1)M4, RELEASE SOFTWARE (fc1)

Die fa0/0-Interfaces der Router C1 und C2 sollen sich dabei in einem IP-Netz (hier in einem IPv6-Netz) befinden und sich ohne eine Routing-Instanz erreichen können.

hostname C1
!
interface FastEthernet0/0
 description Link zum CE1
 no ip address
 ipv6 address 2001:DB8:1111::1/64
hostname C2
!
interface FastEthernet0/0
 description Link zum CE2
 no ip address
 ipv6 address 2001:DB8:1111::2/64

Die CE-Router müssen dafür IPv6 transparent bridgen. Das kann über eine traditionelle Bridge-Group erreicht werden:

bridge irb
!         
interface FastEthernet0/0
 description Link zum C1
 no ip address
 bridge-group 1
!         
interface FastEthernet0/1
 description Link zum PE1
 no ip address
 bridge-group 1
!
bridge 1 protocol ieee

Die PE-Router haben eine normale MPLS-Konfiguration, verwenden aber für AToM keine MPLS-VPNs, sondern sogenannte “Pseudo-Wires“. Daher werden auch keine VRF- oder BGP-Instanzen benötigt. Das ist im einfachsten Fall wie ein virtuelles Kabel zwischen zwei PE-Routern zu verstehen. Die Pseudo-Wires werden mit dem Befehl xconnect zwischen den Loopback-Adressen der PE-Router konfiguriert:

hostname PE1
!
interface Loopback0
 ip address 10.10.10.1 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/1
 description Link zum CE1
 no ip address
 xconnect 10.10.10.2 100 encapsulation mpls
!

Auf dem PE 1 wird also ein Pseudowire mit der Virtual Circuit-ID von 100 vom aktuellen Router zur Loopback des PE2 (10.10.10.2) aufgebaut. Der Transport läuft über das schon vorhandene MPLS.
Da diese Pseudo-Wire unidirektional arbeiten, wird das gleiche auch auf dem PE2 konfiguriert:

hostname PE2
!
interface Loopback0
 ip address 10.10.10.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/1
 description Link zum CE2
 no ip address
 xconnect 10.10.10.1 100 encapsulation mpls
!

Die PE-Router verwenden für den Austausch des VC-Labels eine gerichtete LDP-Sitzung:

PE1#sh mpls ldp neighbor 10.10.10.2
    Peer LDP Ident: 10.10.10.2:0; Local LDP Ident 10.10.10.1:0
	TCP connection: 10.10.10.2.45592 - 10.10.10.1.646
	State: Oper; Msgs sent/rcvd: 117/118; Downstream
	Up time: 01:33:43
	LDP discovery sources:
	  Targeted Hello 10.10.10.1 -> 10.10.10.2, active, passive
        Addresses bound to peer LDP Ident:
          10.10.2.1       10.10.10.2      

In meinem Setup hat der PE1 dem PE2 ein VC-Label von 1100 angekündigt, und ein VC-Label von 1200 erhalten:

PE1#sh mpls l2transport binding 
  Destination Address: 10.10.10.2,  VC ID: 100
    Local Label:  1100
        Cbit: 1,    VC Type: Ethernet,    GroupID: 0
        MTU: 1500,   Interface Desc: Link zum CE1
        VCCV: CC Type: CW [1], RA [2]
              CV Type: LSPV [2]
    Remote Label: 1200
        Cbit: 1,    VC Type: Ethernet,    GroupID: 0
        MTU: 1500,   Interface Desc: Link zum CE2
        VCCV: CC Type: CW [1], RA [2]
              CV Type: LSPV [2]

Die Eigenschaften des Virtual Circuits:

PE1#sh mpls l2transport vc 

Local intf     Local circuit              Dest address    VC ID      Status    
-------------  -------------------------- --------------- ---------- ----------
Fa0/1          Ethernet                   10.10.10.2      100        UP        

PE1#
PE1#
PE1#sh mpls l2transport vc 100 detail       
Local interface: Fa0/1 up, line protocol up, Ethernet up
  Destination address: 10.10.10.2, VC ID: 100, VC status: up
    Output interface: Se1/0, imposed label stack {1000 1200}
    Preferred path: not configured  
    Default path: active
    Next hop: point2point
  Create time: 00:10:27, last status change time: 00:09:58
  Signaling protocol: LDP, peer 10.10.10.2:0 up
    Targeted Hello: 10.10.10.1(LDP Id) -> 10.10.10.2
    Status TLV support (local/remote)   : enabled/supported
      Label/status state machine        : established, LruRru
      Last local dataplane   status rcvd: no fault
      Last local SSS circuit status rcvd: no fault
      Last local SSS circuit status sent: no fault
      Last local  LDP TLV    status sent: no fault
      Last remote LDP TLV    status rcvd: no fault
    MPLS VC labels: local 1100, remote 1200 
    Group ID: local 0, remote 0
    MTU: local 1500, remote 1500
    Remote interface description: Link zum CE2
  Sequencing: receive disabled, send disabled
  VC statistics:
    packet totals: receive 377, send 76
    byte totals:   receive 25754, send 8835
    packet drops:  receive 0, seq error 0, send 0

Nachdem alles konfiguriert wurde kann die Verbindung getestet werden:

C1#ping ipv6 2001:DB8:1111::2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2001:DB8:1111::2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 36/36/36 ms
C1#
C2#
*Apr 12 14:59:25.659: ICMPv6: Received echo request, Src=2001:DB8:1111::1, Dst=2001:DB8:1111::2
*Apr 12 14:59:25.663: ICMPv6: Sent echo reply, Src=2001:DB8:1111::2, Dst=2001:DB8:1111::1
C2#

Im Capture auf dem Link zwischen PE1 und PE kann man die zwei Label und den darüber transportierten Ethernet-Frame sehen:

No.     Time        Source                Destination           Protocol Info
    299 146.171341  2001:db8:1111::1      2001:db8:1111::2      ICMPv6   Echo (ping) request id=0x0fc4, seq=0

Frame 299: 130 bytes on wire (1040 bits), 130 bytes captured (1040 bits)
Cisco HDLC
MultiProtocol Label Switching Header, Label: 1000, Exp: 0, S: 0, TTL: 255
MultiProtocol Label Switching Header, Label: 1200, Exp: 0, S: 1, TTL: 255
PW Ethernet Control Word
Ethernet II, Src: ca:05:ac:17:00:08 (ca:05:ac:17:00:08), Dst: ca:06:ac:18:00:08 (ca:06:ac:18:00:08)
Internet Protocol Version 6, Src: 2001:db8:1111::1 (2001:db8:1111::1), Dst: 2001:db8:1111::2 (2001:db8:1111::2)
Internet Control Message Protocol v6

Das äußere Label (1000) ist das vom P-Router generierte Transport-Label zum PE2, das innere Label (1200) ist das vom PE2 generierte VC-Label.

Bleibt zu klären, warum ich bei diesem Beispiel entgegen meiner früheren Ankündigung das SP-Netz mit IPv4 anstelle IPv6 aufgebaut habe. Das liegt daran, das LDP noch nicht über IPv6 laufen kann.

Advertisements
Ethernet-Bridging über MPLS

Cisco IOS: EIGRP-Authentifizierung mit Key-Rollover

Über die Qualität der Cisco Schulungsunterlagen habe ich mich schon ab und an mal ausgelassen.
Und während ich mich gerade auf eine neue Kursversion eines Security-Kurses vorbereite, fällt mir schon wieder eine Sache auf, die man besser nicht so macht, wie es im Kurs beschrieben ist. Beim Thema Routing-Protokoll-Authentifizierung findet sich dort eine Key-Chain mit den folgenden send- und accept-lifetimes:

key chain MYKEYS
 key 1
   key-string ThisIsKey1
   accept-lifetime 04:00:00 Jan 1 2010 04:00:00 Feb 1 2012
   send-lifetime 04:00:00 Jan 1 2010 04:00:00 Jan 1 2012
 key 2
   key-string ThisIsKey2
   accept-lifetime 04:00:00 Jan 1 2012 04:00:00 Feb 1 2014
   send-lifetime 04:00:00 Jan 1 2012 04:00:00 Jan 1 2014

Die accept-lifetime des zweiten Keys schließt sich hier genau an die sent-lifetime des ersten Keys an.
Was passieren kann, wenn man es genau so konfiguriert, habe ich in GNS3 nachgestellt (GNS3-Datei und Konfiguration):

EIGRP-Authentication zwischen Router1 und
Router2
R0#ping ipv6 R2-Loopback0 repeat 500
Type escape sequence to abort. Sending 500, 100-byte ICMP Echos to 2001:DB8:2222::12, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!...............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
R1:
Jan 1 03:59:56.435: IPv6-EIGRP: received packet with MD5 authentication, key id = 1
Jan 1 04:00:01.135: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:03.971: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:03.983: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C202:30FF:FE3F:0 (FastEthernet0/0) is down: Interface Goodbye received 
Jan 1 04:00:08.495: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:13.423: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:17.767: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:22.339: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:26.723: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 04:00:31.683: IPv6-EIGRP: received packet with MD5 authentication, key id = 2 
Jan 1 04:00:32.551: IPv6-EIGRP: received packet with MD5 authentication, key id =2
R2:
Jan 1 03:59:28.843: IPv6-EIGRP: received packet with MD5 authentication, key id = 1 
Jan 1 03:59:33.271: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live 
Jan 1 03:59:33.271: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 5 invalid authentication)
Jan 1 03:59:33.271: EIGRP: Dropping peer, invalid authentication 
Jan 1 03:59:33.275: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C201:30FF:FE3F:0 (FastEthernet0/0) is down: Auth failure 
Jan 1 03:59:37.823: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live 
Jan 1 03:59:37.823: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 5 (invalid authentication) ... 
Jan 1 03:59:57.347: IPv6-EIGRP: pkt authentication key id = 2, key not defined or not live 
Jan 1 03:59:57.347: EIGRP: FastEthernet0/0: ignored packet from FE80::C201:30FF:FE3F:0, opcode = 1 (invalid authentication) 
Jan 1 04:00:01.851: IPv6-EIGRP: received packet with MD5 authentication, key id = 2 
Jan 1 04:00:01.851: EIGRP: Received HELLO on FastEthernet0/0 nbr FE80::C201:30FF:FE3F:0 
Jan 1 04:00:01.851: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 
Jan 1 04:00:01.851: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 100: Neighbor FE80::C201:30FF:FE3F:0 (FastEthernet0/0) is up: new adjacency

Was ist da passiert? Für dieses Beispiel habe ich die Uhren beider Router mit einer Differenz von 30 Sekunden konfiguriert. Solche und größere Zeitabweichnungen habe ich auch schon in Netzen mit NTP gesehen. Im Normalbetrieb sollte das zwar nicht auftreten, aber durch Konfigurations-Probleme kann ein NTP-Server halt auch mal nicht erreichbar sein. Und ein Grundsatz guten Netzwerk-Designs heißt halt mit Recht “Always Plan for Problems”.
Für 30 Sekunden (das ist die Zeitspanne am 1.1.2012 von 04:00:00 bis 04:00:30 auf Router1 bzw. von 03:59:30 bis 04:00:00 auf Router2) wird der Router1 den ersten Key nicht mehr verwenden, dieser würde aber von Router2 noch akzeptiert werden. Dafür verwendet Router1 den zweiten Key, dieser wird aber von Router2 noch nicht akzeptiert:

Die sent- und accept-lifetimes (nicht proportional gezeichnet)

Der Verbindungsabbruch von ca. 30 Sekunden ergibt sich daher, das der Router2 bei einer fehlerhaften
Authentifizierung sofort die Nachbarschaftsbeziehung abbricht und erst wieder aufbaut, wenn beide Router den Key 2 benutzen können. Router1 hat in dieser Zeit keine fehlerhaften Authentifizierungen.
Das Problem lässt sich recht einfach vermeiden, indem man die accept-lifetime nicht nur länger laufen lässt als die sent-lifetime, sondern auch vor der sent-lifetime des nächsten Keys beginnen lässt:

Die accept-lifetime beginnt jetzt vor der send-lifetime

Was passiert jetzt in diesen 30 Sekunden:

  • Router1 sendet seine Pakete schon mit Key 2, der auch von Router 2 akzeptiert wird.
  • Router2 sendet seine Pakete noch mit Key 1, der von Router 1 noch akzeptiert wird.

Die (relevante) Konfiguration von Router2 sieht dabei folgendermaßen aus. Wie lang man dabei die accept-lifetime überlappen lässt hängt natürlich von den persönlichen Vorlieben ab. Ich habe für dieses Beispiel einfach fünf Minuten genommen:

hostname R1
!
key chain MYKEYS
 key 1
   key-string ThisIsKey1
   accept-lifetime 04:00:00 Jan 1 2010 04:00:00 Feb 1 2012
   send-lifetime 04:00:00 Jan 1 2010 04:00:00 Jan 1 2012
 key 2
   key-string ThisIsKey2
   accept-lifetime 03:55:00 Jan 1 2012 04:00:00 Feb 1 2014
   send-lifetime 04:00:00 Jan 1 2012 04:00:00 Jan 1 2014
!
interface FastEthernet0/0
 ipv6 address 2001:DB8:2::11/64
 ipv6 eigrp 100
 ipv6 authentication mode eigrp 100 md5
 ipv6 authentication key-chain eigrp 100 MYKEYS
!
ipv6 router eigrp 100
 router-id 1.1.1.1
 no shutdown

Wer sich darüber wundert, das ich dieses Beispiel mit IPv6 aufgebaut habe, dem sei der Beitrag Blog Examples Going IPv6 Next Year von PacketLife.net zu empfehlen. Diese Idee werde ich aufgreifen und ab sofort meine Beispiele auch mit IPv6 implementieren, wo es möglich ist.

Cisco IOS: EIGRP-Authentifizierung mit Key-Rollover

Tagebuch eines DRM-Opfers

Cisco hat sich schon vor einiger Zeit entschieden, die von den Trainern benötigten Kursunterlagen, als DRM-geschützte PDFs an seine CCSIs (Cisco Certified Systems Instructors) herauszugeben. Das hat mich mit meinen Kursen (hauptsächlich CCSP und CCIP) bisher nicht gestört, da die noch alle als PPT vorlagen. Aber für die neuen Kursversionen musste ich mich jetzt auch damit befassen:

Tag 0: Eine E-Mail erreicht mich, in der mir beschrieben wird, wie ich den Locklizard PDF-Viewer herunter laden kann. Sowohl Windows, als auch MacOS sind die unterstützten Plattformen. Erste Ernüchterung, die Mac-Version kann nicht drucken. Die Software ist trotzdem schnell installiert.

Tag 1: Ich verbringe ca. zwei Stunden auf der Cisco-Seite, auf der Suche nach den Downloads der Trainer-Materialien. An der Stelle, an der man den Download starten möchte, lädt der Browser immer automatisch eine .exe herunter. Einen Mac-User bringt das aber nur bedingt weiter.

Tag 2: Auf der Seite kann man per Chat Hilfe anfordern. Dies mache ich und werde in freundlicher deutscher Sprache im Chat begrüßt: “Guten Tag Karsten Iwen, mein Name ist Harish, wie kann ich Ihnen helfen?” Auf Deutsch formuliere ich mein Problem, erste Antwort, “please send your question in english”.
Alles noch einmal auf Englisch formuliert. Bekomme dann die Antwort, dass es zwar einen Viewer für den Mac gibt, aber der Download zwingend unter Windows erfolgen muss.
Ich starte meine VM-Session, da kommt von Harish der Nachsatz “weder der Downloader, noch der Viewer funktionieren in einer VM”. Klasse. 😦

Tag 3: Ich stelle fest, dass ich keinen PC mit Windows mehr habe. Auch alle PCs in meinem Lab laufen mit Linux und mein Arbeits-Rechner ist halt der MAC. Windows ist zwar in mehreren Version vorhanden, aber immer virtualisiert. Ich mache ein Notebook platt und installiere ein XP, zu welchem ich noch eine CD gefunden habe.

Tag 4: Von dem Win-Notebook (komplett installiert und durchgepatched) lade ich die Download-Anwendung erneut herunter. “Die Anwendung konnte nicht richtig initialisiert werden (0xc0000135). Klicken Sie auf OK, um die Anwendung zu beenden”. Im Chat ist wieder Harish.
Harish: “ich solle nur ein oder zwei Dateien zur Zeit herunterladen”
Ich: “Aber die Software läuft noch nicht einmal, sie stürzt beim Starten ab”
Harish , einige Minuten später: “ist es eine nicht-Win-Umgebung?”
Ich: “WinXP SP3”
Harish will meine CCO-ID haben, ich frage ob eventuell .NET benötigt wird, den Hinweis habe ich bei Google gefunden.
Harish , einige Minuten später: “ich müsse sicherstellen, dass zum Download die Ports 80, 443 und 21 offen sind”
Ich: “so weit bin ich noch nicht, die Anwendung startet nicht”
Harish, einige Minuten später: “Ob ich das .NET-Framework 2.0 installiert hätte, das würde nämlich benötigt”
Ich: sprachlos …

Tag 5: .NET ist installiert, jetzt kann der Download endlich losgehen. Oder doch nicht? Nach ca. 50 MB stoppt das Download-Programm einfach und lädt nicht mehr weiter … Neustart hilft nicht. Irgendwie habe ich jetzt schon keine Lust mehr!

Tag 6 (genauer eine Woche später): Der Download hat geklappt! Ich kopiere die Dateien auf meinen Mac, auf dem ich die Lizenz installiert habe. Leider lassen sich die meisten Dateien nicht öffnen: “Invalid server response”.

Tag 7: Harish ist wieder im Chat, ich schildere mein Problem. Ich deinstalliere die Lizenz, installiere sie erneut und muss mehrmals erklären, dass ich die Dateien nicht öffnen kann. Harishs Antwort, dass das Problem beim Drucken auftaucht, bringt mich irgendwie nicht weiter, denn dass das nicht auf dem MAC geht, ist ja dokumentiert. Nach einer halben Stunde kommt Harish auf die Idee, meine Lizenz neu zu erzeugen. Nach der erneuten Installation ist das Problem aber immer noch da. Harish muss erstmal das “concern department” kontaktieren und will sich dann wieder melden.
Später: Per e-Mail erfahre ich, dass die Probleme gelöst seien und jetzt alles funktionieren soll. Öffnen lassen sich die Dokumente leider immer noch nicht.
Noch einmal später: Bei weiteren Tests merke ich, dass man es nur mehrmals hintereinander probieren muss. Eine Datei öffnete nach fünf Fehlversuchen, eine andere nach 17 Fehlversuchen (alle mitgezählt, nachdem mir das aufgefallen ist).

Tag 8: Shan vom Cisco Marketplace Support Team mailt mir, dass ich für drm.mediuscorp.com einen statischen Host-Eintrag anlegen müsse. Ich entgegne, das DNS funktioniert (inklusive DIG-Ausgabe), füge den Eintrag aber trotzdem hinzu, um bei der Problemlösung mitzuarbeiten. Der Fehler ist erwartungsgemäß trotzdem nicht weg.
Später: Shan schlägt vor, die Lizenzdatei zu bearbeiten und die URL zum DRM-Server von https auf http zu ändern. Schlechte Idee, denn danach lässt sich die Lizenz überhaupt nicht mehr installieren.

Tag 9: Harish schlägt vor, die Software zu deinstallieren und neu von vorne anzufangen. Schon bevor ich das gemacht habe, wusste ich eigentlich, wie viel das bringen würde …
Um das Problem weiter zu ergründen, wollte ich die Lizenz auf einem Windows-Rechner installieren, nachdem ich die Lizenz auf dem MAC deaktiviert habe. Geht leider auch nicht, da ich “keine Lizenz zur Verfügung habe …”. Ich will überhaupt nicht die Stunden zählen, die ich mit diesem Kram schon verbracht habe. 😦

Tag 10 (wieder eine gute Woche später): Ich habe eine Lösung gefunden. Mein Plan, diese Arbeit unter MacOS zu machen, war von vornherein zum Scheitern verurteilt. Der Mac-Viewer mag zwar zum Lesen von Dokumenten geeignet sein, aber nicht, um Präsentationen zu zeigen. So hat er z.B. keinen Vollbildmodus und auch keine sinnvolle Tastatur-Steuerung zum Wechseln der Seiten. Von der fehlenden Unterstützung einer Fernbedienung mal ganz abgesehen. Auf meine diesbezügliche Anfrage beim Support habe ich dann auch überhaupt keine Antwort bekommen.

Ich habe jetzt Bootcamp installiert und dort eine neue Lizenz aktiviert, was dann auch funktioniert hat. Jetzt muss ich für Trainings zwar immer neu booten und habe auch keinen Zugriff auf meine normale Arbeits-Umgebung, um mal etwas aus der Reihe zu zeigen, wie z.B. aus GNS3. Aber zumindest komme ich mehr oder weniger an die Dokumente. Wie ich mich damit auf neue Kurse oder Kurs-Versionen vorbereiten kann, weiß ich aber noch nicht. Denn um mal nebenbei in den Unterlagen zu lesen, müsste ich ja auch neu booten (die Benutzung einer VM widerspricht den Lizenzbedingungen). Und das Ausdrucken ist nur auf lokale Drucker erlaubt (und das auch nur zweimal), aber alles, was ich für diese eher umfangreichen Druckjobs an Druckern zur Verfügung habe, sind Netzwerk-Drucker.

Bleiben mir nur die folgenden Gedanken:

  1. Derjenige, der sich das ausgedacht hat, der hat noch nie vor einer Klasse gestanden! Denn vor dem Training hat man anderes zu tun, als darüber zu grübeln, ob man überhaupt seine Unterlagen öffnen kann.
  2. Warum nur hasst Cisco seine Trainer so abgrundtief, dass die so etwas machen??? 😦
  3. XKCD und Brad Colbow haben halt doch Recht.
  4. Ich fühle mich darin bekräftigt, doch lieber eigene Workshops zu machen. Bei denen arbeite ich entweder am Whiteboard (für manche Sachen habe ich auch Slides) oder die Teilnehmer sitzen an der Konsole. Das macht einfach mehr Spaß.
  5. Bei der Suche nach einer Lösung bin ich auch auf den “LockLizard PDC Un Protector” gestoßen. Aber wer den benutzt, muss als “Raubkopierkinderschandmörder” bestimmt gleich mit einer Hausdurchsuchung rechnen. 😦 Weiterhin sind diese Crackprogramme sowieso nur “Trojanerschleudern” und schon deshalb nicht zu benutzen.
Tagebuch eines DRM-Opfers

Tautologie

Ob es mit einem der letzten Comics von XKCD zu tun hat, das mir gerade heute in den Cisco-Schulungsunterlagen zum IAUWS (Implementing Advanced Cisco Unified Wireless Security) die folgenden Weisheiten bei der Erklärung der Bildschirmausgaben aufgefallen sind?

  • Fake Attacks shows the number of fake attacks.
  • AP Missing shows the number of missing access points.
  • AP Impersonations shows the number of access point impersonations.
  • AP Invalid SSID shows the number of invalid access point Service Set Identifiers (SSIDs).
  • AP Invalid Preamble shows the number of invalid access point preambles.
  • AP Invalid Encryption shows the number of invalid encryption events.
  • AP Invalid Radio Policy shows the number of invalid access point radio policies.
  • Denial of Service shows the number of DOS requests.

Nicht, dass ich die Qualität der Unterlagen in Frage stellen wollte, aber manchmal bin ich mir nicht sicher, welche Zielgruppe wirklich ins Auge gefasst wird.

Tautologie

Cisco Certified Wireless Professional

Es gibt mal wieder Neues zu Ciscos kommender Wireless-Zertifizierung in der Professional-Schiene.
Zum einen soll die Zertifizierung formell auf der Cisco Live vorgestellt werden und im September verfügbar sein, zum anderen gibt es bald neue Wireless-Kurse, deren Prüfungen vermutlich Bestandteil des CCWP werden:

Cisco Certified Wireless Professional

Training Implementing Cisco MPLS

Besucher des Kurses Implementing Cisco MPLS, die nach dem Training noch mehr üben möchten, können das problemlos mit Dynamips/GNS3 machen. Die “Fleißarbeit” dazu habe ich schon einmal gemacht und die .net-Datei, sowie die Startkonfigurationen der Router angefertigt.
Dieses Labor beinhaltet 17 Router, die aber nicht alle gleichzeitig laufen müssen. Die Konfiguration benutzt 7200er mit einem AdvEnterprise 12.4(15)T8-Image. Die Pfade in der mpls22.net müssen natürlich an die eigene Umgebung angepasst werden.

Die physikalische Topologie benutzt — wie beim Original-Training — einen FR-Switch, über den alle Router seriell angeschlossen sind:
mpls22-physical

Die gewünschten Verbindungen werden per PVC hergestellt, so daß logisch die folgende Topologie hergestellt wird:
logische MPLS-Topoligie
Wenn in der .net-Datei oder in den Startkonfigurationen noch Fehler enthalten sein sollten, dann sagt bitte Bescheid, damit ich die korrigieren kann. Auch wenn jemand von euch einen besseren IdlePC-Wert herausfindet, würde ich mich über einen Kommentar freuen. Viel Spaß beim Üben.

Download der Dateien

Update 29.2.: Da MPLS ohne Backdoor-Links keinen Spaß macht, habe ich diese in der Konfiguration hinzugefügt.
Update 3.4.: Jetzt auch wieder mit .NET-Datei zum Download.

Training Implementing Cisco MPLS