DE - GNS3Vault

Vor ein paar Tagen ist mir ein Tweet oder Retweet über gns3vault aufgefallen und da ich gerade etwas Zeit hatte, habe ich mir die Seite angesehen. Es sind eine Menge guter und vor allem interessanter Labs zu finden und die Seite ist auf jeden Fall einen Blick wert. Wer sich für den CCNA oder NP vorbereitet sollte dir vorbeischauen.

http://gns3vault.com

Viel Spaß beim Lab nachbauen

EN - GNS3Vault

So a few days ago I noticed a tweet or retweet about gns3vault and I decided to have a look at this page. I was really surprised about the amounts of labs they had already in place. If you are learning Cisco (CCNA / NP) it is definitely worth having a look.

http://gns3vault.com

have fun / good luck :)

DE - dynamisches Routeleanking oder "Inter VRF routing"

Dynamisches Route Leaking oder Routing Protokolle fürs Routing zwischen der globales Routingtabelle (GRT) und VRFs

Hallo zusammen,

das letzte mal gab es ein Beispiel, wie man statisch das Routing zwischen 2 VRFs einrichtet und dachte, daß es doch garnicht so schwer sein kann, dies auch dynamisch zu realisieren ... das war reichlich naiv ;)
Nach massig herumprobieren und mit dem Rat von ein paar anderen habe ich ein kleines Lab zusammengebaut, wo Routen zwischen der GRT und einem VRF dynamisch ausgetauscht werden.
Soweit ich es sagen kann, gibt es keine Möglichkeit Routen auf normalem Wege zu redistributen, wenn ein Routingprozess der globale ist. Wenn man es dennoch versucht, bekommt man eine kryptische Fehlermeldung wie diese:
VRF -> GRT [code]%OSPF process 1 is attached to Default-IP-Routing-Table[/code]
GRT -> VRF [code]OSPF process 22 already exists and is attached to Default-IP-Routing-Table[/code]

Dies müssen wir einfach "austricksen" und dafür brauchen wir einige Tunnelinterfaces und ein paar Loopbacks

So sieht mein Netzplan aus:


Der globale Client und der VRF_Client werden wieder durch missbrauchte Router dargestellt, die lediglich eine IP haben und eine Default Router auf das ausgehende Interface+Next Hop IP.

grt_host
[code]interface FastEthernet0/0
ip address 10.10.10.10 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.10.10.1 FastEthernet0/0[/code]

vrf_host
[code]interface FastEthernet0/1
ip address 20.20.20.20 255.255.255.0
ip route 0.0.0.0 0.0.0.0 20.20.20.1 FastEthernet0/1[/code]

Nun brauchen wir ein paar Grundkonfigurationen für den VRF Router:

ein vrf erstellen:
ip vrf zif
rd 1:1
route-target both 1:1

Interface config zum grt_host:
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
speed 100
full-duplex

Interface config zum vrf_host:
interface FastEthernet0/1
ip vrf forwarding zif
ip address 20.20.20.1 255.255.255.0
speed 100
full-duplex

Das alles ist kein Hexenwerk ... bis jetzt ;)

Das erste was wir uns überlegen müssen: wie tricksen wir die Grenzen des Designs aus?

Die erste Zutat sind "Tunnel-Interfaces", die andere sind "Loopbacks".

Unterm Strich brauchen wir:
ein Tunnel-Interface pro VRF,
ein Tunnel-Interface für die GRT
ein Loopback pro VRF und
ein Loopback für die GRT.

Wenn wir mehrere VRFs mit der GRT verknüpfen wollen, brauchen wir entsprechend der obigen Liste das gleiche nochmal pro zusätlichem VRF.

Beide Loopbacks werden in der GRT gelassen:
VRF Router
interface Loopback111
ip address 111.111.111.111 255.255.255.255

interface Loopback222
ip address 222.222.222.222 255.255.255.255

Jetzt brauchen wir die dazugehörigen Tunnel-Interfaces.
Das für die GRT:
interface Tunnel102
ip address 100.100.100.1 255.255.255.0
tunnel source 111.111.111.111
tunnel destination 222.222.222.222
Und das für das VRF:
interface Tunnel201
ip vrf forwarding RED
ip address 100.100.100.2 255.255.255.0
tunnel source 222.222.222.222
tunnel destination 111.111.111.111

Was macht dieses Konstrukt? Wir zeigen mit dem dem Tunnel 201 auf die Loopback in der GRT, mit der Quelle in der GRT und packen das ganze dann ins VRF. Hört sich nicht nur komisch an, es ist komisch (und "fühlt sich komisch an), ABER es funktioniert ;)

Jetzt haben wir schicke Netzwerke, zwischen denen wir ein Routingprozess wie zB OSPF laufen lassen können.

Der globale Routingprozess:
router ospf 1
router-id 10.10.10.10
log-adjacency-changes
network 100.100.100.1 0.0.0.0 area 0
network 10.10.10.0 0.0.0.255 area 0

Der VRF Routingprozess:
router ospf 2 vrf zif
router-id 20.20.20.20
log-adjacency-changes
network 20.20.20.0 0.0.0.255 area 0
network 102.102.102.2 0.0.0.0 area 0

Die Routing Tabelle schaut danach wiefolgt aus::
global

VRF_Router#sh ip route
[...snip...]

Gateway of last resort is not set

102.0.0.0/24 is subnetted, 1 subnets
C 102.102.102.0 is directly connected, Tunnel102
200.200.200.0/32 is subnetted, 1 subnets
C 200.200.200.200 is directly connected, Loopback200
100.0.0.0/32 is subnetted, 1 subnets
C 100.100.100.100 is directly connected, Loopback100
20.0.0.0/24 is subnetted, 1 subnets
O 20.20.20.0 [110/11112] via 102.102.102.2, 00:24:29, Tunnel102
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, FastEthernet0/0
vrf

Router#sh ip route vrf zif

Routing Table: zif
[...snip...]

Gateway of last resort is not set

102.0.0.0/24 is subnetted, 1 subnets
C 102.102.102.0 is directly connected, Tunnel201
20.0.0.0/24 is subnetted, 1 subnets
C 20.20.20.0 is directly connected, FastEthernet0/1
10.0.0.0/24 is subnetted, 1 subnets
O 10.10.10.0 [110/11112] via 102.102.102.1, 00:26:19, Tunnel201



Und das wars auch schon!
Nun ist es möglich vom grt_host direkt den vrf_host zu pingen und umgekehrt.

Bei Fragen nutzt einfach die Kommentarfunktion

Bis dann,
Zif

DE - LAB Update

Ok es ist wieder eine Weile her, dass ich gepostet habe (passiert mir anscheinend öfter). Es gibt mehrere Grunde warum ich nicht gepostet hab. Zum einen habe ich mich seit August mit mehreren Trainings zum Thema CCNA und CCNA Security befasst. Mittlerweile habe ich den CCNA Test bestanden und bald kommt der CCNA Security dran. Danach geht es zum CCSP Training das ich hoffentlich auch irgendwann im Januar 2010 hinter mich gebracht hab.

Der zweite Grund ist, das ich mein Lab überarbeiten musste und zwar von Grund auf. Grund dafür ist das mein Lab bei weitem nicht den Anforderung entsprochen hat, die ich für meine Kunden brauchte und das ich damit keine CCNA Security Labs durchführen konnte.

Deshalb hier ein kurzer Überblick über mein jetziges LAB Setup:



Anbei eine Erklärung der wichtigsten Maschinen und Systeme:

Elysium:
- eine XP64 Arbeitsstation mit GNS3 und VMware Server 1.8
- die meisten kleinen Labs erarbeite ich hier (quick und dirty)
- bei großen Labs dient die Maschine auch als zusätzlicher Hypervisor
- beide Netzwerkkarten sind am Main und Lab Switch angebunden

Core01
- Win2k8 x64 (64 GB RAM 2x4 Core CPUs) – merkt man das ich stolz auf die Box bin
- alle VMs laufen via Hyper V
- beide Netzwerkkarten sind am Main und Lab Switch angebunden

VM Server:
Active Directory Server und AD Child Server
- um sich gegen AD Szenario zu authentifizieren
CA Server
- MS CA Server für PKI Szenarios zwischen den Routern
Nagios
- Nagios überwacht meine Labs und ein paar echte Maschinen
Radius
- Free Radius um Radius auth. zu simulieren
Tacacs
- TACACS+ um Tacacs auth. zu simulieren (noch nicht fertig eingerichtet)
SDM
- Die XP Maschine stellt den SMD für das CCNA Security Labs zur Verfügung
Workstation
- nur eine Testmaschine für VPN Clients et
MAIL
- Sendet Mails von Nagios
Cisco MARS
- eine virtuelle MARS Appliance (auch noch nicht ganz fertig)
Nicht aufgeführte Systeme:
Cisco ACS 4/5 (trial), CUCM 7/ 5

LAB-R001
- virtueller 7200 Router mit IOS 15.0.1.M
- komplett mit FE Anschlüssen ausgerüstet
- jeder FE Anschluss ist an ein LAB angebunden

LAB-SW01/SW02/SW03
- Cisco Lab Switches von Ebay
- Catalyst 2950 12.1.22-EA13

Home-SW02
- Netgear 8 Port Gigabit Switch

Router Labs
Jedes Router Lab läuft in einer eigenen Dynaslax VM die so viele Ressourcen wie nötig zugewiesen bekommen.

Ich würde mich über Anregungen Kommentare und Ideen zu meinem Labaufbau freuen.
Das war's fürs erste.

cheers NWG

EN - Lab update

It has been a while since I made my last post. This was due to several reasons.
First of all I was doing some training for my CCNA and CCNA Sec certification. I've already passed the CCNA stuff and now I'm up to do the CCNA Sec test.
Later on I've planed to do the CCSP tests, hopefully I'll have them finished in January 2010.

The second reason was that I've restructured my lab from the scratch. This was necessary since the old setup did not reflect the environments I've had to face at my customers location and it was not possible to train for the CCNA Sec stuff. :D

So here is a quick overview of my current lab setup


I'll go through the picture and explain the most important machines:

Elysium:
- Is a XP64 workstation running GNS3 and VMWare Server 1.8
- most small labs and tests are done here
- for larger labs this box is used as additional hypervisor
- 2xNICs connected to my main and my lab switch

Core01
- Win2k8 x64 (64 GB RAM 2x4 Core CPUs) – I'm happy with this box :D
- Hyper V is running all VMS
- 2xNICs connected to my main and my lab switch

VM Servers:
Active Directory Server and AD Child Server
- for authentication tests with Active Directory
CA Server
- MS CA Server to do the PKI stuff for router to router authentication
Nagios
- Nagios is monitoring my lab networks and some of my real workstations
Radius
- Free Radius implementation for authentication testing
Tacacs
- TACACS+ for Tacacs testing (still in deployment)
SDM
- Well this XP Machine provides the SDM that is required for CCNA Sec
Workstation
- This is just a testing machine (VPN client and so on)
MAIL
- Reporting from Nagios
Cisco MARS
- a virtual MARS appliance (not really deployed yet)
Machines not listed:
Cisco ACS 4/5 (trial), CUCM 7/ 5

LAB-R001
- virtual 7200 running IOS 15.0.1.M
- stuffed with lots of FE interfaces
- each FE connects to a router lab

LAB-SW01/SW02/SW03
- Cisco lab switches from Ebay
- Catalyst 2950 12.1.22-EA13

Home-SW02
- Netgear 8 Port Gigabit Switch

Router Labs
Each router lab is a own VM running Dynaslax with as much resources allocated as needed

I would be thank full for any comments and other ideas about the lab setup. Even for questions :D

Thats it for now :D
cheers NWG

EN - dynamic routleaking or Inter VRF routing

dynamic route leaking or routing protcols between global routing table (GRT) and VRFs

Hey Everybody,

last time I showed some exampel config for static roue leaking and thought that dynamic routing between GRT and VRF can't be that hard ... how green.
After some hard trys and help from other people I will now show you, how to exchange routes between GRT and VRF-RT dynamicly.
There is no chance to do a normal redistrubution between routing processes if one is the global one.
If you try so, you'll get some cryptic message like
VRF -> GRT [code]%OSPF process 1 is attached to Default-IP-Routing-Table[/code]
GRT -> VRF [code]OSPF process 22 already exists and is attached to Default-IP-Routing-Table[/code]

How ever, now we need to get this tricked. Therefor we use tunnel interfaces and some loopbacks.

This is my tiny topology:


The global Client and the VRF_Client are again just some as host missused routers with one IP address and a default route pointing on the outgoing IF.
grt_host
[code]interface FastEthernet0/0
ip address 10.10.10.10 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.10.10.1 FastEthernet0/0[/code]

vrf_host
[code]interface FastEthernet0/1
ip address 20.20.20.20 255.255.255.0
ip route 0.0.0.0 0.0.0.0 20.20.20.1 FastEthernet0/1[/code]

Now are some basic config for the vrf_router needed:

Create a vrf:
ip vrf zif
rd 1:1
route-target both 1:1

Link to grt_host:
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
speed 100
full-duplex

Link to vrf_host:
interface FastEthernet0/1
ip vrf forwarding zif
ip address 20.20.20.1 255.255.255.0
speed 100
full-duplex

This all was no rocket science yet, until now ;)

First thing to figure out: how to outsmart the limitations of design?

One credential are "Tunnel-Interfaces", an other one "loopbacks".

In sum we need one tunnel-IF per VRF and GRT plus one loopback for each.

Both loopbacks are left in GRT:
VRF Router
interface Loopback111
ip address 111.111.111.111 255.255.255.255

interface Loopback222
ip address 222.222.222.222 255.255.255.255

Now we need the correspondent tunnel IFs.
The global one:
interface Tunnel102
ip address 100.100.100.1 255.255.255.0
tunnel source 111.111.111.111
tunnel destination 222.222.222.222
And the VRF one:
interface Tunnel201
ip vrf forwarding RED
ip address 100.100.100.2 255.255.255.0
tunnel source 222.222.222.222
tunnel destination 111.111.111.111

What this is doing: pointing with the tunnel 201 to a GRT loopback with a source in GRT putting itself in a VRF. It sounds, strange, it looks strange, it feels strange, BUT it works ;)

Now you have sweet networks which you can add to routing processes like OSPF.

The global routing process:
router ospf 1
router-id 10.10.10.10
log-adjacency-changes
network 100.100.100.1 0.0.0.0 area 0
network 10.10.10.0 0.0.0.255 area 0

The VRF routing process:
router ospf 2 vrf zif
router-id 20.20.20.20
log-adjacency-changes
network 20.20.20.0 0.0.0.255 area 0
network 102.102.102.2 0.0.0.0 area 0

The routintg tables looks like this:
global

VRF_Router#sh ip route
[...snip...]

Gateway of last resort is not set

102.0.0.0/24 is subnetted, 1 subnets
C 102.102.102.0 is directly connected, Tunnel102
200.200.200.0/32 is subnetted, 1 subnets
C 200.200.200.200 is directly connected, Loopback200
100.0.0.0/32 is subnetted, 1 subnets
C 100.100.100.100 is directly connected, Loopback100
20.0.0.0/24 is subnetted, 1 subnets
O 20.20.20.0 [110/11112] via 102.102.102.2, 00:24:29, Tunnel102
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, FastEthernet0/0
vrf

Router#sh ip route vrf zif

Routing Table: zif
[...snip...]

Gateway of last resort is not set

102.0.0.0/24 is subnetted, 1 subnets
C 102.102.102.0 is directly connected, Tunnel201
20.0.0.0/24 is subnetted, 1 subnets
C 20.20.20.0 is directly connected, FastEthernet0/1
10.0.0.0/24 is subnetted, 1 subnets
O 10.10.10.0 [110/11112] via 102.102.102.1, 00:26:19, Tunnel201


And thats it! Now you are able to ping from you grt_host straight through the vrf_host.

For questions just use the comments.

so long,
Zif

EN - Upcomming: dynamic route leaking or routing protcols between global routing table (GRT) and VRFs

Hey everyone,

due to NWG asked me for this I started investigation about a way to do some dynamic redistribution between a VRF and the GRT. Everyone trying to solve this by a simple "redistribute" command in the routing process knows, thats that is not the way ;)

At the moment I am preparing the entry for this blog. At this point big thanks to "conspathas" from the dynamip forum for his time explaining this way.

See ya soon,
Zif

Update 09-07-10: due to heavy load @work there is a delay in publication, please stand by :)

DE – Tools update

In den letzten Wochen hat sich mein Lab doch etwas verändert, daher hier ein kurzes Update.

Tools:
GNS3 Version 0.6

Ich musste feststellen das die 7200 Router ab einer bestimmten Anzahl dazu tendieren einfach so zu crashen. Bei meinem Arbeitsnotebook ist das zwischen 3 und 4 Router. Daher habe ich die Wahl dieser Boxen verworfen. Seit kurzem setze ich daher auf 3725, ich wollte zuerst die 3745er nehmen aber die leiden unter einem Dynamips Bug und so kann man die Konfig nicht reimportieren nachdem man sie gespeichert hat. Die 3725 laufen mit dem IOS 12.4.15T8.

Ach so ich habe eine der 5505 ASAs ausgetauscht gegen eine 5510 aber leider ist die Box im produktiven Umfeld. Daher wird es auf der keinen großen außergewöhnlichen Configs geben.

Bei VMWare bleibt alles beim alten.
Cheers NWG

ENG – Tools update

Well within the last weeks my environment slightly changed.

Just to give you a quick update
Tools:
GNS3 version 0.6

I've noticed that the 7200 routers tend to crash, if you run more than a certain amount of them. On my notebook it is often between 3 or 4 7200 routers, even if the are doing nothing. I dropped them and only use them if I need features of 12.4.22T1.
My main routers are now 3725, I tried the 3745 but due to some kind of dynamips bug the do not re import saved configs. So I keep the 3725s running IOS 12.4.15T8.

I changed one of the ASA 5505 to an ASA 5510 but this equipment is now in productive environment so their is no big chance of using them in tricky configs. Both ASAs are still running v8.0.3

VMWare stays the same
Cheers NWG

ENG - Tools and Hardware

To build my labs I use several tools here are some of them including some links

Tools
GNS3 – graphical interface for the router simulator Dynamips
* mainly I use the 7200 routers with 12.4.22T IOS

Pemu – PIX and ASA simulator
* my PIX are running v7.2.4 or v8.0.4
* the ASA is running v8.0.3

VMWare – nothing more to say I guess


Hardware
2x ASA 5505
* both ASAs are running 8.0.4

DE - Tools und Hardware

Um die Labs zu bauen werde verschiedene Tools benutzt hier eine kleine Auflistung mit Links.

Tools
GNS3 – grafische Oberfläche zum Router Simulator Dynamips
* Hauptsächlich arbeite ich mit den 7200 Router und IOS 12.4.22T

Pemu – PIX und ASA Simulator
* die PIXen laufen mit v7.2.4 oder v8.0.4
* die ASA mit v8.0.3

VMWare – Was soll ich hierzu noch sagen

Hardware
2x ASA 5505
* beide ASAs laufen mit 8.0.4