2 Netzwerke - wie gehts ??

Hallo MCSE-MCT !

Habe mich den ganzen Abend mit dem Aufbau von Routing-Tabellen beschäftigt und habe jetzt kapiert, wie die funktionieren.
Die gute Nachricht für dich. Du hast völlig recht, dass das Problem des TO am einfachsten und elegantesten über eine geänderte Routing-Tabelle zu lösen ist. Die schlechte Nachricht : Dein und mein Vorschlag für eine Veränderung stimmte so nicht.

Wenn man, wie der TO, den Ethernet-Adapter für das LAN und den WLAN-Adapter für das Internet nutzen möchte, dann muss in der Routing-Tabelle nur der jeweilige Eintrag für die Schnittstelle geändert werden.

In der ersten Zeile steht z.B.:

Aktive Routen:

Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.105 20

Das bedeutet, dass alle Netzwerkadressen (außer denen, die zusätzlich in der Tabelle definiert sind, aber hier nicht von Belang sind) über das Gateway (hier der Router mit der IP des Routers ) geroutet werden. Die Schnittstelle ist hier die IP der beiden NICs (Ethernet-Adapter und WLAN-Adapter haben in diesem Szenario dieselbe IP).

Wenn ich nun mit dem Befehl:

route change -p 0.0.0.0 Mask 0.0.0.0 192.168.2.1 Metric 20 IF 20003

den obigen Eintrag ändere, wird jedes Routing ins Internet über den WLAN-Adapter (die haben diese merkwürdigen langen Interface-Nummern) laufen; eine Änderung der IP für den Adapter ist nicht nötig.

Der interne LAN-Verkehr wird weiter über die Ethernet-Karte laufen, wenn ich
für die dafür typischen Slots (eigenes Netzwerk 192.168.2.0,Multicast, Broadcast) mit dem route change-Befehl auf die Interface-Nummer der Ethernet-Karte umlege. Für das eigene Netztwerk müßte dann z.B. in der Tabelle stehen :


192.168.2.0 255.255.255.0 192.168.2.105 1 20

Die Metric-Angaben habe ich aus meiner eigenen Routing-Tabelle übernommen.

 

Gut. Dir hat es also die Schnittstellenliste (IF) angetan. Und damit vermeidest Du die Kreation des 2-ten IP-Netzes (bei mir 172-er). Mir ist nie wohl, wenn 2 NICs aus dem gleichen Subnetz kommen, es sei denn Port Trunking (Link Aggregation) ist irgendwo angesagt. Andererseits sind IP-Adr. verständlicher als Slot-Nummern...

Mein Ansatz über die Metric ist schlampig. Statisches Routing benutzt die Metric nicht. Insofern macht Deine 20 nichts. Falls jedoch RIP im Spiel wäre, wäre die Route ungültig (v.1 kann nur 15 Hops).


> interne LAN-Verkehr wird weiter über die Ethernet-Karte

Ja. Aber Du brauchst hier weitere Routenlenkung auf 0x1000003 (LAN). Genau dies veranstaltet einen Layer höher 'route add -p 172.28.1.0 Mask 255.255.255.0 192.168.1.1' (für Mitleser: lokaler Verkehr stets über Kabel, unter Beibehaltung der 192-er).

______________________

TCP/IP, o'reilly, Craig Hunt (mein Favorit)

 

Ich habe noch mal auf folgender Seite ein interessantes Beispiel gefunden, was im Prinzip unserer Problemstellung entspricht :

http://www.winnetmag.com/Article/ArticleID/27171/27171.html

Wenn ich die Ausführungen richtig verstehe, würde es sogar auf unseren Fall bezogen reichen, wenn man nur die Zeile :

route -p add 0.0.0.0 mask 0.0.0.0 192.168.1.1 metric 1 if 0x20003

hinzufügt.

 

Mir ist aufgefallen, es ist nicht bekannt, ob der TO für beide Netze gleiche oder verschiedene Netzwerkadressen verwendet hat.

Bei der Diskussion über das Routing ist mir nicht aufgegangen, wie sollen die Anwendungen (Explorer für CLAN, IE für WLAN) dazu gebracht werden, das jeweilige Interface auszuwählen?

 

Im gegebenen Beisp. ist 1.100 der lokale Rechner bzw. das einzige lokale Interface, beachte die localhost-Abbildung. 1.100 benutzt (vermutl. einen WLAN-Router) 1.1 (Standardgate). Die Routen für Netz-/ IP- Broadcasts für 1.100 sind ausformuliert. Das zugrundeliegende System ist XP (beachte: 2000 hat fürs Multicast den Bug SubnetMask= /3 = 224). Und es gibt VLAN (Variante IPSEC über L2TP) vermöge 0x4.


Unterschiede...

Der OP hat pro Rechner 2 Interfaces (WLAN / LAN). Seine Routing-Tab. benötigt NOCH die Abbildungen vom 2-ten Interface bzgl. üblichen Broadcasts + auf ein lokales Gate.

> würde es sogar auf unseren Fall bezogen reichen
Von daher mindestens ein Doppel-Nein.


> wie sollen die Anwendungen...
Wie üblich über Schichten 7..1. Bei 3->4 kommt HOSTS ins Spiel. 4->3 benötigt die Ausformulierung geeigneter Broadcasts. Und schon sind wir in der Routing-Tab.

 

@MCSE-MCT

Magst auch da wieder recht haben Ich habe mir überlegt, dass es ja auch Probleme im ARP-Cache geben könnte, wenn eine IP mehreren MACs zugeordnet ist, was der Fall wäre, wenn die Rechner IP bei beiden NICs identisch ist.
Welche konkreten route add/change-Befehle müßten denn deiner Meinung nach ausgeführt werden ?

@lefg

Dass würde über die Routing-Tabelle geregelt werden, indem der Internet-Verkehr 0.0.0.0 0.0.0.0 allein über den WLAN-Adapter geleitet würde.

route change -p 0.0.0.0 Mask 0.0.0.0 192.168.2.1 IF 0x20003

bedeutet : Alle IP-Zieldadressen werden mit dem WLAN-Adapter über den Router mit der IP 192.168.2.1 geleitet.Der WLAN-Adapter ist in der Interface-Liste der Routing-Tabelle mit einer Kennung wie 0x20003 eingetragen.

 

*konkret* gibt es die genannten Netz- lokal- / Broadcasts etc. + !! dann erst Umleitungen einzubringen. Die Dinge sind vorgenannt und in Deinem Beisp. beschrieben. NUR, für je eine IP. Und genau das richtet man ein.

Übergang: Man vermeidet AUTO+ DYN. -Konig. (und damit jedes RIP / OSPF ( etc,) - Bleibt STAT. ... vorliegender Fall.

Der *konkrete* OP hat den Supp. mangels Verständnis abgelehnt. Die Dinge liegen auf der akademischen Seite. Daher erlaube ich mir den Verweis auf die Realisierung von 'Beowulf-Clustern' (sieh Dir die Uni-Bilder an). - Die Jungs färben die beiden switched Netwerke anders. Einen Steuer-Kanal + einen Daten-Kanal. Verfolge das!!. Fälle, wo der Cluster-Host kein Router ist, aber zweifach angesprochen werden kann. GENAU DAS ist die Grundidee im vorliegendden Fall... Je rechner 2 NICs, keiner ist Router. Statisches Routing. Auto + Dyn. würden die Routes beizeiten killen... (ähmm die Def. eines Protokolles)


Eine MAC unter Nutzung mehrerer IPs. => Registry. Aber hier offtopic.

 

Kann man den Internetzugang nicht über die Priorität der Schnittstellenmetrik festlegen?

 

@Franzkat

Thx

 

@MSCE-MCT

Das verstehe ich eben nicht; warum brauche ich Einträge für Broadcast,Limited Broadcast, Multicast, wenn ich das Netz lokal überhaupt nicht nutzen möchte. Dass man einen Eintrag :

route add -p 172.28.1.0 Mask 255.255.255.0 172.28.1.1 172.28.1.1

benötigt, um das 172er-Netz bekannt zu machen, leuchtet mit ja noch ein; aber der Verwaltungskram ist doch in diesem speziellen Fall überflüssig.

BTW :

Du erinnerst dich, dass ich mich schon mal über deine etwas fragwürdige Art der sprachlichen Darstellung von Problermen geärgert hatte ?

Wenn das auf Deutsch für dich schwierig ist (vielleicht bist du ja kein native speaker), schreib doch den Beitrag einfach auf Englisch.

 

@MaxMaster

Metriken werden bei statischem Routing nicht berücksichtigt. Dynamisches, vermöge RIP, ist hier nicht im Spiel. Bleibt... die Arbeit über IPs und Interfaces.

 

Noch mal zur Erläuterung :

http://www.lanline.de/html/lanline/lexikon/lex/routing-verfahren.htm

 

statische Routing

"Router benötigen keine R.Protokolle"... Besser wäre: Dürfen keine haben. Routing P. verwerfen auch Routen (Stichwort: Metrik=16 bei RIP v.1). Das wäre das Ende der sorgsam erstellten (manuellen) Routen.

Dass Metriken beim statischen Routing unbeachtet bleiben, fehlt.


dynamisches Routing
...hmm


automatisches Routing

...fehlt.
Z.B. ICMP Redirect.


@franzkat
> Noch mal zur Erläuterung :
War es die, die dem alten Fuhrmann das Peitscheknallen beibringt?

Ich bleibe auch hier dabei: TCP/IP, o'reilly, Craig Hunt. Beste(n)s auch zum Thema Routing. Zwar stark LINUX- / BSD-/ Solaris- orientiert, aber auch nachvollziehbar für (uns) PE-Builder ;-)

 

Nein, wer mir das Peitschenknallen beibringt, hatte ich dir ja schon mal erzählt :

TCP/IP- Holzer/Pflugmann Data Becker (damals hattest du über Data Becker die Nase gerümpft und ich hatte dir versucht klarzumachen, dass dieses Buch - auch wenn das für Data Becker beileibe nicht selbstverständlich ist - ein gutes Buch ist.

Das schließt ja nicht aus, dass man auch andere Lehrer nutzt. Craig Hunt ist mir aber in der Tat zu unix-orientiert.

Was ich nicht verstehe : du schreibst :

Hier M$ im Originalton :[ Statische Routen für Routing und RAS verwenden http://support.microsoft.com/default.aspx?scid=kb;DE;178993] :

Im route-add-Befehl ist die Metrik als Parameter enthalten. Wie paßt das mit deiner Aussage zusammen ?

 

Dein Link [0] sagt, wie man statische Routen (in einem R-Prot-losen Szenario) hinzufügt. Es fällt aber auch der Satz: die Metrik spielt hier keine Rolle.



[1]-p.147ff.: Einträge in Routingtabs werden von statischen Einträgen, ICMP-Redirects (aka autom. Routing) und durch Routingprotokolle erstellt (dyn. Routing).

Einträge in der Routing-Tab sind flüchtig (-> RAM). Sollen sie auch ein Reboot überstehen, kommt die Option -p(ersistent) ins Spiel. soll das nicht so sein (Anstoss einer Konvergenz etc.) lässt man -p weg.

Es gibt nicht mehrere Routingtabs, etwa eine für manuell erstellte (mit / ohne -p) und eine für RIP etc., sondern nur eine. Operiert kein R-Prot. auf einer Tabelle hat man stat. Routing., die Veränderung mit ROUTE ist erzwungen (Redirects aussen vor). Man will KEINE Veränderung. Soll eine Tabelle jedoch dynamisch gepflegt werden, sprich ein R-Prot. soll grundsätzlich weiterpflegen, spricht auch hier nichts gegen eine Manipulation mit ROUTE. Das RAS-Admin-Tool zeigt den gleichen Inhalt wie netstat -rn (vgl. route print). Die persistenten Routen stecken in der Registry [2], seit SP2 sogar fehlerfrei mit Metriken [4]. Aus diesem Grund ist der ROUTE-Befehl auch nicht (metric-)beschnitten (nochmal: da er nicht weiss, für welche Philosophie er gerade Routen erzeugt) bzw. ob die Routen für andere Geräte / mit R-Prots. kopiert werden sollen.

> Im route-add-Befehl ist die Metrik
> als Parameter enthalten.
Ist damit abgefrühstückt.



Zum Thema Metrik. Was ein Routing-Prot. dabei denkt, ist verschieden. OSPF verändert Metriken (zB. aus Konvergenzgründen). RIP v.1 betrachtet M > 15 als unerreichbar (RFC 1058) und *uups* wertet Subnet-Masks nicht aus (weil es ein klassenbasiertes Protokoll ist). In der RIP v.2 wurde das verbessert (RFC 1723).

Und jetzt bleibt eigentlich nur noch eine Frage offen: Was wertet das System aus einer Routing-Tab. aus, wenn KEIN Routing-Prot. im Einsatz ist? Ich hätte kürzer fragen sollen: Ist die Metrik irgendwo Bestandteil der TCP <--> IP <--> MAC- Kapselung (TTL= Hopcount nicht mit Metrik verwechseln).


Überraschung: Es ist systemabhängig. Beim Betrachten von [2] fiel mir [1]-p.166 ein... (die Rede ist von multihomed rechnern) "...nutzt TCP/IP für Win2000 eine Standard-Route auf der Grundlage _der ersten Netzadapter-Bindung_. Dies kann zu unerwünschtem Verhalten, also... Auf Server RRAS aktivieren und auf Prof. Reg.Eintrag [5] auf 1 setzen".

Heisst für mich: Per Metrik ist (auf Prof.-Systemen) nichts zu machen, bis der Reg.Eintrag auf 1 steht. Dann allerdings kann man per Metric eine sog. Backup-Route anlegen, die anspringt, falls die Primary-Route ausfällt. Vermutung: Die ausgefallene Route bekommt (wie bei RIP v.1) eine Metric=16 (unerreichbar) und die vormalige Backup-Route (mit niedrigerer Metrik) ist aktuell. Dass dies kein statisches Routing ist, ist klar oder anders: M$ macht sein eigenes Ding [6]. LINUX macht das nicht so. [5] steht auf 2000 + XP (per default) auf 0.

> Dass Metriken beim statischen Routing
> unbeachtet bleiben, fehlt.
Kann man also nicht uneingeschränkt fordern.


Na ja. Und dem OP werden Backup-Routen nicht helfen. Den interessiert die Umlenkung des WLAN-IP-Kreises auf den LAN-Kreis lokal und als Standard-Gate ein WLAN-Schnittstelle. Das WLAN kann bestenfalls Backup des CLAN werden.

___________________________

Ergänzung: RRAS kann zur Verwendung von RIPv.1/2 (auch bei Prof.-Versionen), etwa fürs Silent-RIP konf. werden [3]. Die Philosophie ist JETZT nicht mehr statisch (auch wenn der Bestand mit ROUTE angelegt wurde).

___________________________

[0] http://support.microsoft.com/default.aspx?scid=kb;DE;178993
[1] Lee / Davies, Win2000 TCP/IP Prot. + Dienste
[2] HKLM/ System/ CCS/ Services/ TCPIP/ Para/ PersistR.
[3] [Win]+[F1] -> Routen-> Aktiv.v.RIP-Listeing
[4] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/w2kmsgs/1776.asp
[5] HKLM/ System/ CCS/ Services/ TCPIP/ Para/ IpEnableRouter
[6] http://www.microsoft.com/technet/community/scriptcenter/network/scnet123.mspx

 

Hallo,

hier die Konfiguration eines Rechners des OP.

Windows-IP-Konfiguration
Hostname. . . . . . . . . . . . . : SERVER
Primäres DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Unbekannt
IP-Routing aktiviert. . . . . . . : Nein
WINS-Proxy aktiviert. . . . . . . : Nein

Ethernetadapter Drahtlose Netzwerkverbindung:
Verbindungsspezifisches DNS-Suffix: home
Beschreibung. . . . . . . . . . . : WLAN miniUSB Adapter
Physikalische Adresse . . . . . . : 00-01-24-B0-76-DE
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IP-Adresse. . . . . . . . . . . . : 192.168.1.2
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.1.1
DHCP-Server . . . . . . . . . . . : 192.168.1.1
DNS-Server. . . . . . . . . . . . : 192.168.1.1
Lease erhalten. . . . . . . . . . : Freitag, 16. Juli 2004 21:39:17
Lease läuft ab. . . . . . . . . . : Samstag, 17. Juli 2004 21:39:17

Ethernetadapter LAN-Verbindung:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Realtek RTL8139-Familie-PCI-Fast Ethernet-NIC
Physikalische Adresse . . . . . . : 00-20-ED-4C-58-FD
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IP-Adresse. . . . . . . . . . . . : 192.168.0.2
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.0.1
DHCP-Server . . . . . . . . . . . : 192.168.0.1
DNS-Server. . . . . . . . . . . . : 192.168.0.1
Lease erhalten. . . . . . . . . . : Freitag, 16. Juli 2004 22:09:22
Lease läuft ab. . . . . . . . . . : Montag, 19. Juli 2004 22:09:22

 

Habe selbes Problem... zu hülf

Ciao SunboX