Frittenbude 10 Geschrieben 6. Januar 2011 Melden Teilen Geschrieben 6. Januar 2011 (bearbeitet) Hallo zusammen, ich möchte NATing gerne in Verbindung mit VRFs auf einem Cisco Router 1812 nutzen. D.h. auf drei getrennte DSL-Verbindungen soll jeweils ein NAT-Pool für interne Nutzer (in insgesamt 3 VLANs) genutzt werden. Ich habe die Konfiguration auch soweit durchgeführt. NATing wird laut "sh ip nat translations" durchgeführt, wenn ich beispielsweise eine IP-Adresse im Internet von einem Client versuche anzupingen. Die Internetverbindung wird von dem besagten Router über Dialer (PPPoE) aufgebaut und funktioniert soweit. Nachfolgend ein Konfigurationsauszug mit den relevanten Teilen. Kurze Erklärung: Getestet wird erst nur mit einem DSL-Anschluss für Dialer1. Ein Client befindet sich derzeit in VLAN201 an FastEthernet6. Alles weitere sollte aus dem Konfigurationsauszug ersichtlich sein. ... ip cef no ip dhcp use vrf connected ip dhcp excluded-address 192.168.101.1 192.168.101.9 ip dhcp excluded-address 192.168.102.1 192.168.102.9 ip dhcp excluded-address 192.168.103.1 192.168.103.9 ! ip dhcp pool DSL_Modem_1 network 192.168.101.0 255.255.255.0 default-router 192.168.101.1 dns-server 192.168.101.1 lease 0 0 1 ! ip dhcp pool DSL_Modem_2 network 192.168.102.0 255.255.255.0 default-router 192.168.102.1 dns-server 192.168.102.1 lease 0 0 1 ! ip dhcp pool DSL_Modem_3 network 192.168.103.0 255.255.255.0 default-router 192.168.103.1 dns-server 192.168.103.1 lease 0 0 1 ! ! ip vrf DSL_Modem_1 description DSL_Modem_1 ! ip vrf DSL_Modem_2 description DSL_Modem_2 ! ip vrf DSL_Modem_3 description DSL_Modem_3 ! vpdn enable ! vpdn-group 1 ! vpdn-group 2 ! vpdn-group 3 ! ! ! ! ! ! ! ! interface BRI0 no ip address encapsulation hdlc shutdown ! interface FastEthernet6 switchport access vlan 201 ! interface FastEthernet7 description To DSL Modem 3 switchport access vlan 103 no cdp enable ! interface FastEthernet8 description To DSL Modem 2 switchport access vlan 102 no cdp enable ! interface FastEthernet9 description To DSL Modem 1 switchport access vlan 101 no cdp enable ! interface Vlan1 no ip address ! interface Vlan101 description To DSL Modem 1 ip vrf forwarding DSL_Modem_1 no ip address pppoe enable group 1 pppoe-client dial-pool-number 1 ! interface Vlan201 description LAN_1_for_DSL_1 ip vrf forwarding DSL_Modem_1 ip address 192.168.101.1 255.255.255.0 ip nat inside ip virtual-reassembly ! interface Dialer1 bandwidth 100000 ip vrf forwarding DSL_Modem_1 ip address negotiated ip nat outside ip virtual-reassembly encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer hold-queue 30 dialer-group 1 no cdp enable ppp authentication pap callin ppp chap hostname 0815@t-online.de ppp chap password 7 xxxxx ppp pap sent-username 0815@t-online.de password 7 xxxxx ppp ipcp dns request ! ip route vrf DSL_Modem_1 0.0.0.0 0.0.0.0 Dialer1 ip route vrf DSL_Modem_2 0.0.0.0 0.0.0.0 Dialer2 ip route vrf DSL_Modem_3 0.0.0.0 0.0.0.0 Dialer3 ! ! no ip http server no ip http secure-server ip dns view-list DSL_Modem_1 ip dns server ip nat pool DSL_Modem_1 192.168.101.10 192.168.101.254 prefix-length 24 ip nat inside source list 1 pool DSL_Modem_1 vrf DSL_Modem_1 match-in-vrf overload ! access-list 1 permit 192.168.101.0 0.0.0.255 access-list 2 permit 192.168.102.0 0.0.0.255 access-list 3 permit 192.168.103.0 0.0.0.255 dialer-list 1 protocol ip permit ... Kann mir jemand sagen, was ich noch beachten muss.? Übrigens, es soll kein Load-Balancing oder eine Fall-Back-Lösung für die drei DSL-Zugänge genutzt werden. Lediglich drei voneinander getrennte DSL-Zugänge für unterschiedliche Nutzergruppen. Daher auch die Nutzung von VRFs... Für Hilfe wäre ich Euch sehr dankbar, denn ich komme selbst nicht weiter. Gruß, Frittenbude bearbeitet 6. Januar 2011 von Frittenbude Zitieren Link zu diesem Kommentar
Servidge 10 Geschrieben 6. Januar 2011 Melden Teilen Geschrieben 6. Januar 2011 Wenn es mit einer Kennung geht sollte es auch mit mehreren funktionieren. Mit der Anzahl der VLANs kommst du auch noch nicht an die Grenze. Sieht soweit eigentlich ganz gut aus. Was geht denn nicht? Edit: doch noch was. die DHCP Pools sollten auch noch in die entsprechenden VRFs konfiguriert werden. .. ip dhcp pool DSL_Modem_1 vrf DSL_Modem_1 network 192.168.101.0 255.255.255.0 default-router 192.168.101.1 dns-server 192.168.101.1 lease 0 0 1 ... Zitieren Link zu diesem Kommentar
Frittenbude 10 Geschrieben 6. Januar 2011 Autor Melden Teilen Geschrieben 6. Januar 2011 Danke für die Rückmeldung. Die VRF-Zuweisung habe ich von den DHCP-Pools wieder herausgenommen, da sonst keine IP-Adressen zugewiesen wurden. Könnte aber sein, dass ich gleichzeitig auch andere Änderungen an der Konfiguration vorgenommen hatte. Ich nehme die VRF-Zuweisung morgen testweise noch einmal rein. Also, folgendes geht: - Zuweisung von IP-Adressen per DHCP an Clients im jeweiligen User-VLAN - Aufbau der Internetverbindung (Ping aus VRF DSL_Modem_1 auf eine öffentliche IP-Adresse im Weg geht) - Routingeinträge im VRF DSL_Modem_1 sind korrekt - NAT Eintrag im Router wird erstellt, wenn ein Client eine öffentliche IP-Adresse im Weg anpingt Folgendes geht nicht: - Ein Client erhält beim Pingen einer öffentlichen IP-Adresse im Web keine Antwort (Server im Web ist dabei definitv erreichbar) - Ein Traceroute auf die selbe öffentliche IP-Adresse von dem selben Client führt nur bis zu seinem ersten HOP (also 192.168.101.1). Es kommt also keine Verbindung ins Web zustande. Übrigens habe ich bisher auch nur die Verbindung für das VRF DSL_Modem_1 getestet. Die anderen VRFs sind quasi erst mal nur vorbereitend angelegt. Ich weiß auch nicht, wie ich noch weiter debuggen soll, wenn ich weiß, dass die Routingeinträge stimmen und ein NAT-Eintrag auf dem Router für den Ping (ICMP) erzeugt wird. Gruß, Frittenbude Zitieren Link zu diesem Kommentar
Servidge 10 Geschrieben 6. Januar 2011 Melden Teilen Geschrieben 6. Januar 2011 so, An dem NAT stimmt was nicht. Die beiden Zeilen ip nat pool DSL_Modem_1 192.168.101.10 192.168.101.254 prefix-length 24 ip nat inside source list 1 pool DSL_Modem_1 vrf DSL_Modem_1 match-in-vrf overload würde ich rauswerfen und durch folgendes ersetzen ip nat inside source list 1 interface Dialer1 vrf DSL_Modem_1 match-in-vrf overload Damit wird dann alles was in der aceessliste 1 bestimmt ist auf die IP des Dialer1 Interface umgesetzt. Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 7. Januar 2011 Melden Teilen Geschrieben 7. Januar 2011 ist das nur ein Test oder warum hat man sich für diese komplexe Lösung entschlossen ? Sparen bie den Wartungskosten für Ciscokomponenten ? ;) Zitieren Link zu diesem Kommentar
Frittenbude 10 Geschrieben 7. Januar 2011 Autor Melden Teilen Geschrieben 7. Januar 2011 Erst einmal vielen Dank, Servidge. Es funktioniert nun. Mir ist zwar nicht klar, warum das mit dem Pool anstelle der Interfaceangabe nicht funktioniert hat. Aber Hauptsache es läuft nun. ;-) @ Otaku19: Es hat zwei Gründe, warum ich das so gewählt habe. 1. Ich hatte nur einen Router zur Verfügung und sehe auch keinen Mehrwert darin, für jede DSL-Verbindung einen eigenen Cisco-Router einzusetzen. Es sollten drei voneinander getrennte Internetzugänge für unterschiedliche Benutzergruppen sein, die jeweils einen zugesicherten DSL-Anschluss erhalten sollen. Hintergrund: Es gab bisher drei separate DSL-Anschlüsse für drei voneinander getrennte Benutzergruppen (Trennung und Zusicherung der Performance ist erforderlich). Diese waren über einfache Speedport-Router angebunden. Da diese Router jedoch nur schlecht managebar (fernwartbar) sind und häufig mit Instabilität zu kämpfen war, wollte ich die drei Speedport-Router durch einen Cisco-Router ersetzen. Es nervt auch, wenn man alle zwei Wochen einen der Router neustarten muss - gerade, wenn die Geräte nicht direkt in näherer Umgebung sind. Ziel war es also quasi auch, die eigenen Aufwände für die Wartung zu reduzieren, um sinnvollere Aufgaben machen zu können. 2. Ich war daran interessiert zu testen, ob ein solcher Aufbau möglich und wie es im Detail funktioniert. Welche Lösung hättest Du denn gewählt? Gruß, Frittenbude Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 7. Januar 2011 Melden Teilen Geschrieben 7. Januar 2011 Interessant ist der Aufbau ja, aber grade wenn du sagst Neustart...all dieser Wartungskram muss ja dann mit 3 verschiedenen Parteien abgeklärt werden und wenn der Router den Geist aufgibt (auch Cisco ist nicht für die Ewigkeit gebaut) sind alle 3 Zugänge weg. Du baust dir somit gleich bei 3 unterschiedlichen Kunden einen SoF ein. Und was ist wenn einer der Kunden irgendeinen Unsinn treibt und den Zugang der anderen 2 beeinträchtigt ? Klar, die Dataplane ist quasi getrennt, die controlplane aber nicht. Ich hätte für jeden einzeln einen passenden 800er gewählt und fertig. Damit sind wahrscheinlich auch auch die externen Modems obsolet und du kannst einen 800er parat halten wenn einer defekt ist. Das alle 3 gleichzeitig den Geist aufgeben ist eher unwahrscheinlich (aber dennoch möglich) Zitieren Link zu diesem Kommentar
Frittenbude 10 Geschrieben 7. Januar 2011 Autor Melden Teilen Geschrieben 7. Januar 2011 @ Otaku19: Okay, ich kann Deinen Einwand nachvollziehen. Andererseits ist die Wahrscheinlichkeit dafür, dass einer von drei Routern ausfällt höher als bei einem Gerät. Klar, dafür steht dann natürlich alles, wenn denn der Router defekt ist. An ein Ersatzgerät komme ich relativ zeitnah. Die DSL-Zugänge sind bei Ausfällen für einen gewissen Zeitraum für die Nutzer zu verkraften. Ich denke der Einsatz des Cisco-Routers ist sowohl für sie als auch für uns zukünftig eine erleichterung. Drei separate Router hätte ich auch bevorzugt. Nur ob ich die für das Projekt bekommen werde ist leider fraglich. Daher bin ich erst mal von der Ein-Router-Lösung ausgegangen. @ all: Eine Sache funktioniert leider noch nicht. Und zwar die DNS-Auflösung - sowohl für Clients als auch auf dem Router selbst (im VRF). DNS-Server bekomme ich vom Provider automatisch übermittelt. Für Clients dient der Router mit seiner Router-IP-Adresse als DNS-Server. Hat jemand einen Hinweis? Gruß, Frittenbude Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 7. Januar 2011 Melden Teilen Geschrieben 7. Januar 2011 dazu musst du sie importieren,dazu ist am dialer irgendwas mit ipcp und im dhcp pool import all einzutragen. Zitieren Link zu diesem Kommentar
Frittenbude 10 Geschrieben 7. Januar 2011 Autor Melden Teilen Geschrieben 7. Januar 2011 Hab ich so drin: ip dhcp pool DSL_Modem_1 import all ... ! interface Dialer1 ppp ipcp dns request ... ! Funktioniert leider aber nicht. Gruß, Frittenbude Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 7. Januar 2011 Melden Teilen Geschrieben 7. Januar 2011 dann trag sie auf die schnell halt manuell im dhcp pool ein und lass die clients direkt den dns draussen befragen, solange du am router selbst keine eigene zone machst, ist es perfomancetechnisch eh gscheiter das DNS nicht den Router machen zu lassen Zitieren Link zu diesem Kommentar
Frittenbude 10 Geschrieben 7. Januar 2011 Autor Melden Teilen Geschrieben 7. Januar 2011 Okay, habe es jetzt so übernommen - in der Hoffnung, dass die DNS-Server-Adressen sich nicht in den nächsten Monaten ändern. Für den Fall der Fälle wäre mir daher ne dynamische Zuweisung schon lieber gewesen. Aber so tut's es erst einmal auch. Gruß, Frittenbude Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 7. Januar 2011 Melden Teilen Geschrieben 7. Januar 2011 ne, sowas ändert ein ISP normalerweise nicht ständig. So sollte es zumindest mal fürs erste funkitonieren und man kann sich in Ruhe anschauen wo genau das mit der dynamischen Zuweisung hapert Zitieren Link zu diesem Kommentar
daking 10 Geschrieben 7. Januar 2011 Melden Teilen Geschrieben 7. Januar 2011 Hi, um DHCP mit vrf spezifischen Pools zu aktivieren: ip dhcp use vrf connected Zum Weiterleiten der via IPCP empfangenen DNS Server Adresse (die wird in der vrf empfangen und nicht in der globalen Routinginstanz - siehe oben) sollte die Config passen. ciao Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.