Cisco Networkers 2011, Tag 1
Der erste Tag ging um 7:00 mit dem Networkers-Frühstück los. Über den Kaffee redet man besser nicht, süße Gebäck-Sachen gibt es jede Menge, die Bagel sind ok, von denen sollte man aber immer nur einen nehmen, da es immer viel zu wenig Toaster gibt. Ein Highlight ist aber, das jeden Tag frische Früchte zum Frühstück vorhanden sind:
Danach folgte ein acht-stündiges Techtorial, dieses Jahr habe ich das Thema “The CCDE” gebucht. Die Program-Manager (u.a. Russ White) berichten über die Zertifizierung zum Cisco Certified Design Expert. Ich bin mir zwar nicht sicher, ob ich jemals den CCDE Practial-Test machen werde, aber den CCDE-Written wollte ich auf jeden Fall angehen, u.a., um den CCIE zu rezertifizieren.
Am Vormittag wurde sehr viel erzählt was der CCDE ist und was nicht. Der Teil hatte viel von Politiker-Reden oder John Chambers-Keynotes. Viel reden, aber wenig sagen. Am Nachmittag gab es dann Beispiele des CCDE-Written und der CCDE-Practical. Bei den CCDE-Written-Beispielen war ich dann doch etwas erstaunt, denn alle Beispiele bewegten sich maximal auf Professional-Level. Auf Nachfrage bestätigte Russ White allerdings das die echte Prüfung deutlich anspruchsvoller sei. Der Sinn dieser Beispiele wurde mir daher nicht wirklich klar.
Bei den Beispielen zum CCDE-Practical verschwand dann endgültig der Wunsch, diese Zertifizierung zu machen. In dem Beispiel-Design gab es eine Firma, bei der Kunden ihre IPSec- und SSL-VPNs auf einem Router terminieren. Die Design-Dokumente zeigten u.a., das die Firewall keine SSL-Beschleunigung beherrscht. Im Zuge eines Redesign wurde gefragt, ob eine Verschiebung des IPSec-Endpoints von dem Router zur Firewall die Komplexität erhöht. Da man damit aber nur eine Änderung für IPSec-Kunden erreicht hätte, und nicht für die per SSL angebundenen Kunden, würde diese Lösung in meinen Augen die Komplexität erhöhen, da für die SSL-Kunden eine zusätzliche Lösung implementiert werden muss. Die richtige Lösung wäre aber, das es keine Auswirkungen auf die Komplexität hat, da der SSL-Bereich überhaupt nicht betrachtet wurde. Das neue Design bringt einen zwar nicht zum Ziel, ist aber trotzdem richtig. “Do not overthink the solution” …
In einem anderen Beispiel ging es darum, ob man per GRE-Tunnel Ethernet transportieren kann. Richtige Antwort ist “nein”, denn O-Ton Russ White: “Ethernet over GRE? Never in my Network”.
Ein Kollege, der diese Session im letzten Jahr besucht hat meinte zwar, das ich lieber eine andere buchen sollte, aber ich wollte ja wieder nicht hören. Im Gegensatz zu einem anderen Teilnehmer in der ersten Reihe habe ich aber trotzdem der Session zugehört. Warum der eine Session für $800 bucht und dann auf seinem PC Youtube-Videos schaut und Testkings o.ä. macht, hat sich mir nicht wirklich erschlossen.
Nach den Sessions gab es dann auch wieder einen kleinen Netzwerk-Zusammenbruch. Die meisten Thin-Clients hatten keine Verbindung zu ihren Servern, von einigen, die eine Verbindung hatten konnte man sich nicht anmelden, und als ich dann einen gefunden hatte an dem man sich anmelden konnte, ging es auf dem nur bis zur Hauptseite, aber nicht irgendwie weiter. So eine IT-Umgebung ad hoc zur Verfügung zu stellen ist sicher nicht ganz einfach, aber irgend etwas bricht jedes Jahr zusammen …
Cisco Networkers 2011, Tag 0
Heute war der “Material-PickUp” angesagt. Diesmal hat das Registrierungs-System leider meinen NetVet-Status vergessen, so dass ich das hier nachmelden musste. Im Nachhinein fällt mir dann auch auf, das ich während der Registrierung nicht gefragt wurde welches kostenlose CiscoPress-Buch ich haben möchte und die Einladung zur CCIE-NetVet-Reception mit John Chambers habe ich auch nicht bekommen. Aber auch das wird sich schon noch regeln lassen.
Die empfangene Grundausstattung sieht dann so aus:
Zur Qualität des Rucksacks möchte ich jetzt dann doch lieber noch nichts sagen. Der USB-Stick mit den Präsentationen hat wieder eine Kapazität von 2 GB. Ja, auch eine zukunftsweisende Firma darf die Vergangenheit nicht leugnen. Und in der Vergangenheit gab es USB-Sticks mit dieser Kapazität. Wann das war, erinnere ich mich aber nicht mehr so recht …
Weitere Besonderheit: Die PCs, an denen man seine Sessions planen, oder auch die Bewertungen eintragen kann, waren Cisco Virtualization Experience 2200-Clients. Die Cisco-Tastaturen sind das schlechteste, was ich je unter den Fingern hatte, und da es Thin-Clients waren, gab es auch keinen Barcode-Scanner, um sich mit Hilfe der Badges an den PCs anzumelden. Der Login musste also wieder manuell per Username/Password geschehen.
Dafür hat aber heute schon das WLAN funktioniert (diesmal sogar mit WPA2-Personal gesichert), und die CiscoLive-iPhone-App ist auch recht vielversprechend.
Cisco Networkers 2011, Tag -1
Morgen geht die Cisco Live in Las Vegas los und gestern bin ich angekommen.
Was fällt als erstes auf dem Flughafen in Newark auf? Auch in Amerika wird Müll getrennt:
So ganz haben sie es aber dann doch nicht verstanden. Alle drei Öffnungen des Mülleimers gingen in einen gemeinsamen Müllbeutel …
Dave the Network Engineer: Relationship on the Rocks
So kann es kommen, wenn man nicht vorbereitet ist:
IPv6 Transition Update
Beim IEEE gibt es eine ca. 90-minütige Cisco-Präsentation mit dem obigen Titel:
http://www.comsoc.org/form/tutorial-registration-building-comprehensive-ipv6-transition-strategy
Früher, als Linux meine Hauptplattform war, konnte ich die IEEE-Tutorials nie betrachten. Das es jetzt auf meinem Mac auch nicht funktioniert hat, hat mich bei den Rechner-Empfehlungen auch nicht wirklich gewundert:
Viewing Recommendations: IE 8 or higher and Adobe Flash Player 10
(Auf meine Anfrage, ob Mac und Linux nicht eine unterstützenswerte Plattform für eine technisch orientierte Gesellschaft wäre, bekam ich damals übrigens nur die Antwort, das die meisten Mitglieder Windows verwenden …)
Wer wie ich als Mac-User dieses Tutorial trotzdem sehen möchte, dem kann natürlich geholfen werden. Im Seiten-Quelltext sind die Video-URLs hinterlegt:
http://host.comsoc.org/freetutorial/cisco4/Part1/draft-metz-ipv6-transition-tutorial-update-4-ieee-2011-part-1.pptx.mp4
http://host.comsoc.org/freetutorial/cisco4/Part2/draft-metz-ipv6-transition-tutorial-update-4-ieee-2011-part-2.pptx.mp4
Und diese URLs lassen sich direkt in Quicktime verwenden.
IPv6: Verwendung von /127er Prefixen
Unter IPv4 ist heutzutage die Verwendung von /30er oder /31er Netzen auf Point-to-Point-Links der Standard. Während früher Links noch häufig mit einer 30-bit Maske konfiguriert, und auch auf Point-to-Point-Links eine Netz- und Broadcast-Adresse vorsehen wurde, so verwendet man heute fast ausschließlich /31er Netze um keine Adressen zu verschwenden. Und besser rechnen lässt sich mit /31er Adressen auch.
Im IPv6 wurde die Verwendung von /127er Netzen lange Zeit sehr kontrovers diskutiert. Oftmals wurden diese mit Hinweis auf die nicht-Konformität mit den geltenden RFCs abgelehnt. Vielfach wurde es auch einfach damit begründet, dass man im IPv6 keine Adressen sparen müsse.
Jetzt haben die /127er Netze im IPv6 aber doch den offiziellen Segen des IETFs bekommen:
Während ich mir des “Ping-Pong”-Problems bisher nicht bewusst war (Section 5.1), hat mich das Problem der Neighbor Cache Exhaustion (Section 5.2) auch schon beschäftigt und ich fand die Verwendung von /127er Netzen auch keine schlechte Idee.
Schön, das man diese Prefixe jetzt auch “offiziell” auf Inter-Router Links verwenden darf.
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.
Cisco IOS: Content-Filtering
Das Filtern von URLs ist eine Funktion, die ich normalerweise auf einem dedizierten Proxy implementieren würde. Aber wenn kein Proxy zur Verfügung steht, kann diese Funktion auch lokal auf dem IOS-Router ab Version 12.4(20)T konfiguriert werden. Dabei stehen drei Mechanismen zur Verfügung:
- Ein lokal installierter Websense oder Secure Computing Server
- Abfrage des “cloud-based” Trend Micro URL-Filtering Dienstes
- lokale Black- oder Whitelists
Um zu testen, ob die Trend Micro-Lösung als Alternative in Branch-Offices einsetzbar ist, habe ich auf meinem Cisco 1841 mit IOS 15.1(3)T die Test-Lizenz installiert. Diese kann pro Router einmal aktiviert werden und läuft dann für dreißig Tage. Der Straßenpreis der Lizenz für die 1800er oder 1900-Serie liegt für 1 Jahr bei ca. 200 Euro, was die Sache recht interessant macht.
Die Konfiguration des Content-Filters ist in die Zone-Based-Firewall integriert, was die Implementierung sehr flexibel macht (wobei böse Zungen behaupten “flexibel” wäre nur eine Umschreibung für “unnötig kompliziert”; eine Behauptung, der ich nur schwer widersprechen kann).
In der Cisco-Dokumentation ist die Konfiguration auch recht gut beschrieben, weshalb ich hier nicht näher darauf eingehe. Nach der “Fleiß-Arbeit”, mit der Cisco Common Classification Policy Language (C3PL) die Zonen-basierte Konfiguration anzufertigen, gilt es aus den 70 URL-Kategorien (wie z.B. Auctions, Games, Nudity, Pornography, Shopping, Travel, Weapons) und den 10 Security-Kategorien (wie z.B. ADWARE, HACKING, PHISHING) die richtigen auszuwählen, die geblockt werden sollen.
Was kam weiter beim Test heraus:
- Wie ich vorher auch schon bei N2H2 — jetzt Secure Computing — festgestellt habe, ist der Filter bei deutschen Seiten bei weitem nicht so gut wie bei englischem Content (z.B. beim Zugriff auf .com-Seiten).
- Viele Seiten, die eigentlich bei meinen Tests hätten geblockt werden sollen, wurden vom Filter erlaubt. Schade eigentlich. Oftmals zeigte sich auch, das nur Teile zu blockender Seiten nicht angezeigt wurden. Wenn ich die Kategorie “Violence-hate-racism” blocke und die Seite des Ku Klux Klan aufrufe, dann werden zwar alle Bilder und Elemente der Webseite geblockt, der Text der Hauptseite erscheint aber trotzdem. Genauso z.B. beim Blocken von “Real-estate”. Die Seite immonet.de erscheint schon, es werden aber keine sonstigen Elemente dargestellt.
- “Photo-Searches” blockt nicht photoblog.msnbc.msn.com.
- “Nudity” blockt kein www.coupe.de, keine BILD und auch keine getesteten FKK/Nudisten-Seiten.
- Von den im Bundestag vertretenen Parteien werden in der Kategorie “Political” nur die Linken geblockt, NPD geht, die DVU hingegen nicht.
- Die Kategorie “Auctions” filtert recht gut, wenn auch der Zugriff auf www.zoll-auktion.de nicht geblockt wird. Das hätte ich allerdings auch nicht erwartet.
- Die CPU-Belastung steigt durch die Nutzung des Content-Filters natürlich auch. Mit dem getesteten Cisco 1841 an meinem 16000er DSL-Anschluss erreiche ich bei HTTP-Downloads zwar wie auch ohne Content-Filter eine Geschwindigkeit von ca. 1,6 bis 1,7 MByte/s. Die CPU-Last liegt dabei aber durchgängig bei über 95%. Der “normale” Wert bei Downloads beträgt ca. 85%, was natürlich auch grenzwertig ist, aber halt auch nur bei längeren Downloads vorkommt. Dieser Anstieg reicht aber schon, das ich diese Lösung für meine Kunden, die in den Branches meist 1800er Router haben, für nicht geeignet halte. Wenn neuere Standorte mit 1900er Routern bestückt werden sollte man die Sache aber erneut analysieren. Bei den deutlich schnelleren ISR-G2 kann ich mir aber vorstellen, das es schon ganz anders aussieht.
Weitere Informationen zum Thema IOS Content-Filter und Zone-Based-Firewalls:
- Cisco IOS Content Filtering
- Cisco IOS Content Filtering FAQ
- Cisco IOS Content Filtering Configuration Guide
- Subscription-based Cisco IOS Content Filtering Configuration Guide
- Zone-Based Policy Firewall
- Zone-Based Policy Firewall Design and Application Guide
- CiscoPress: Implementing Cisco IOS Network Security (IINS)
Klare Worte
Na, da weiß man doch gleich, was bei der Registrierung auf Cisco.com schief gelaufen ist:
Die Bestätigungs-Mail war dann schon etwas klarer:
Sobald Sie Ihr Konto aktiviert haben, könnte es bis zu 15 Minuten aktiv zu werden. Einmal aktiviert, wenn Sie nicht anmelden können, versuchen Sie es nach 15 Minuten.
Goodbye SSLv2
Aus RFC 6176 – Prohibiting Secure Sockets Layer (SSL) Version 2.0 (Standards Track):
This document … requires that TLS clients and servers never negotiate the use of SSL version 2.0.
Tschüss SSL Version 2, wir werden Dich nicht vermissen.
