WAN-Simulieren (VMNet Speed=64k)

[potsdam]

Hallo,

ich habe unter VM (Host WinXP, VMWare 4.5.1) unser Netz (in Teilen) nachgebaut, um momentan die Migration von NT4 nach Windows 2003/AD mal durchzuspielen. (siehe http://www.admins-tipps.net/software/microsoft/migration_nt4_w2k3/testumgebung_der_migration.htm)

Nun möchte ich die WAN-Anbindung der Aussenstelle auch realitätsnah nachbilden, d.h. Simulation einr 64k Standleitung zwischen VMnet1 und VMNet2.

Als Router fungiert momentan ein Guest mit NT4 Workstation (hatte das Image grade rumliegen.)

Ist es möglich, in VMWare die Geschwindigkeit für einen NIC im Guest, oder ein VMNet vorzugeben um die Leitungsgeschwindigkeit auf ISDN-Niveau zu drosseln ??

Ein weiterer Anwendungsfall hierfür ist der Test von Software über eine WAN-Verbindung (Datenbankapplikationen in Aussenstelle, die auf DB-Server in Zentrale zugreifen).

Vielen Dank schon mal für die Hilfe,

[continuum]

Hi Potsdamer
dein Projekt ist interessant - ich betreue im Moment ein aehnliches Projekt - eine Domain mit 3 Standorten soll von NT4 nach XP upgedatet werden - Probelaeufe in VMware ...
zu deinem Problem: mir ist nur eine einzige Loesung bekannt - ich denke mal eine throttle-Funktio wird in spaeteren VMwareversionen enthalten sein. Bis es soweit ist muss man eine transparente Bridge mit throttle Funktion dazwischen setzen.

Ich denke mal bei dir ist vmnet2 als simulierte 64k Leitung vorgesehen. Der Router routet das an vmnet1 - stimmt das ungefaehr?
Jetzt kommt eine 3. VM ins Spiel - 2 Nics: vmnet 3 und vmnet 2 - diese VM arbeitet als Paketfilter- laesst alles durch aber begrenzt den Durchsatz fuer Anfragen aus vmnet3.
Dein NT-router bekommt vmnet1 und vmnet3 und denkt er waere immer noch mit vmnet2 verbunden da die throttle-VM transparent ist.

Ich wollte schon immer mal so eine VM aufsetzen - wenn du ein bisschen Druck machst, kannst du eine solche VM von mir kriegen.

Ulli

[potsdam]

Hallo Ulli,

na dann "drück" ich doch mal.

VMNet2 soll an sich schon mit Wirespeed laufen.
Der zu drosselnde Punkt ist die Routing-Verbindung zwischen VMNET1/2.

Wenn ich Deinen Vorschlag Nachvollziehe müsste das dann in etwa so aussehen:

[VMNET2] - <throttleVM> - [VMBET3] - <Router> - [VMNET1]

korrekt??

Kann man die throttle-Funktion nicht gleich in den Router integrieren - spart eine VM.

[VMNET2] - <throttle Router> - [VMNET1]

Mir ist allerdings keine SW bekannt mit der sowas geht.


Für Deine Unterstützung bin ich sehr Dankbar.
Wir überlegen gerade die langsamen 64k-Leitungen aufzubohren, weil es Performance-Probleme mit Applikationen gibt.
Wenn ich in VMWare testen könnte, ob das was bringt - wäre super!!

[potsdam]

Hat sich erledigt, dank den Hinweisen von Ulli (throttle) bin ich im englischen Forum fündig geworden und habe eine Lösung implementiert.

Als Router läuft nun eine monowall mit traffic shaper.

Ich werde ein kleines Tutorial machen und auf meine Seiten stellen.

Poste den Link dann hier.

Danke für den Denkanstoss,

[continuum]

Die monowall waere meine 2. Wahl gewesen - FreeBSD hat leider Probleme mit dem lnc-Treiber. OpenBSD dagegen ist stabil wie nur irgendwas.
Obwohl ... - die Monowall scheint da eine Ausnahme zu machen ...
achte mal darauf ob du irgendwelche dropouts im Netz registrierst.

Kannst du vielleicht mal den link ins US-Forum posten - ich wollt nur mal schauen was das fuer ein thread war.

Ulli

[potsdam]

Der gewünschte Link: http://www.vmware.com/community/thread.jspa?forumID=20&threadID=5245&messageID=32441

Scheint auch aus deiner Feder zu stammen Ulli, oder?

Werde das Netz mal beobachten, obs Probleme gibt.

[potsdam]

... und da sind sie schon - die Probleme

die bisherigen Tests waren reine IP-Geschichten: Funktionstests mit Ping, tracert und Geschwindigkeitsmessungen ob der traffic shaper funktioniert. Alles ohne Probleme.

Nun habe ich die monowall in mein Testnetz integriert:

trotz der Regeln pass all from any to any auf WAN und LAN-Interface werden diverse Pakete geblockt.

Windows RPC, Wins, etc funzt nicht über die Monowall.


Habt Ihr irgendwelche Tipps??

[continuum]

Hi
poste doch mal die XML auf dem Floppy - dann gucken wir uns die Regeln mal an ...

Ulli

[potsdam]

Und hier isse:

Code: Alles auswählen

<?xml version="1.0"?>
<m0n0wall>
   <version>1.4</version>
   <system>
      <hostname>m0n0wall</hostname>
      <domain>test.lan</domain>
      <username>admin</username>
      <password>$1$2xGLA75j$W/jiJc00HYBZX7kFjxjQv0</password>
      <timezone>Europe/Berlin</timezone>
      <time-update-interval>0</time-update-interval>
      <timeservers>pool.ntp.org</timeservers>
      <webgui>
         <protocol>http</protocol>
         <port/>
      </webgui>
      <dnsserver>172.24.48.16</dnsserver>
   </system>
   <interfaces>
      <lan>
         <if>lnc0</if>
         <ipaddr>172.24.24.1</ipaddr>
         <subnet>16</subnet>
      </lan>
      <wan>
         <if>lnc1</if>
         <spoofmac/>
         <mtu/>
         <ipaddr>192.168.220.1</ipaddr>
         <subnet>24</subnet>
         <gateway>192.168.220.1</gateway>
      </wan>
   </interfaces>
   <staticroutes/>
   <pppoe/>
   <pptp/>
   <dyndns>
      <type>dyndns</type>
      <username/>
      <password/>
      <host/>
      <mx/>
   </dyndns>
   <dhcpd>
      <lan>
         <range>
            <from>192.168.1.100</from>
            <to>192.168.1.199</to>
         </range>
      </lan>
   </dhcpd>
   <pptpd>
      <mode/>
      <redir/>
      <localip/>
      <remoteip/>
   </pptpd>
   <dnsmasq/>
   <snmpd>
      <syslocation/>
      <syscontact/>
      <rocommunity>public</rocommunity>
   </snmpd>
   <diag>
      <ipv6nat>
         <ipaddr/>
      </ipv6nat>
   </diag>
   <bridge/>
   <syslog>
      <reverse/>
      <nentries>100</nentries>
      <remoteserver/>
   </syslog>
   <nat/>
   <filter>
      <rule>
         <type>pass</type>
         <interface>wan</interface>
         <source>
            <any/>
         </source>
         <destination>
            <any/>
         </destination>
         <frags/>
         <descr>VMNet5 -&gt; LAN</descr>
      </rule>
      <rule>
         <type>pass</type>
         <interface>lan</interface>
         <source>
            <any/>
         </source>
         <destination>
            <any/>
         </destination>
         <frags/>
         <descr>LAN -&gt; VMNet5</descr>
      </rule>
   </filter>
   <shaper>
      <pipe>
         <bandwidth>64</bandwidth>
         <descr>Definition des WAN-Speed</descr>
      </pipe>
      <rule>
         <interface>lan</interface>
         <source>
            <any/>
         </source>
         <destination>
            <any/>
         </destination>
         <direction/>
         <iplen/>
         <tcpflags/>
         <descr>Piping von VMNET1 -&gt;VMNET2</descr>
         <targetpipe>0</targetpipe>
      </rule>
      <rule>
         <interface>wan</interface>
         <source>
            <any/>
         </source>
         <destination>
            <any/>
         </destination>
         <direction/>
         <iplen/>
         <tcpflags/>
         <descr>Piping von VMNET2 -&gt;VMNET1</descr>
         <targetpipe>0</targetpipe>
      </rule>
      <enable/>
   </shaper>
   <ipsec/>
   <aliases>
      <alias>
         <name>Firma</name>
         <address>172.24.0.0/16</address>
         <descr>LAN</descr>
      </alias>
   </aliases>
   <proxyarp>
      <proxyarpnet>
         <range>
            <from>192.168.220.1</from>
            <to>192.168.220.255</to>
         </range>
         <descr/>
      </proxyarpnet>
      <proxyarpnet>
         <range>
            <from>172.24.0.0</from>
            <to>172.24.64.255</to>
         </range>
         <descr/>
      </proxyarpnet>
   </proxyarp>
</m0n0wall>


[potsdam]

Und gleich noch ein Log der FW mit geblockten Paketen hinterher:

Code: Alles auswählen

18:42:00.759919 lnc0 @0:11 b 172.24.48.16,445 -> 192.168.220.10,1170 PR tcp len 20 48 -AS IN
18:42:00.759654 lnc0 @0:11 b 172.24.48.16,139 -> 192.168.220.10,1171 PR tcp len 20 48 -AS IN
18:41:57.520833 lnc0 @0:11 b 172.24.48.16,445 -> 192.168.220.10,1170 PR tcp len 20 48 -AS IN
18:41:57.520819 lnc0 @0:11 b 172.24.48.16,139 -> 192.168.220.10,1171 PR tcp len 20 48 -AS IN
18:41:37.766237 lnc0 @0:11 b 172.24.48.45,139 -> 192.168.220.10,1169 PR tcp len 20 48 -AS IN
18:41:34.551527 lnc0 @0:11 b 172.24.48.45,139 -> 192.168.220.10,1169 PR tcp len 20 48 -AS IN
18:41:14.935834 lnc0 @0:11 b 172.24.48.44,139 -> 192.168.220.10,1168 PR tcp len 20 48 -AS IN
18:41:11.640715 lnc0 @0:11 b 172.24.48.44,139 -> 192.168.220.10,1168 PR tcp len 20 48 -AS IN
18:40:51.933411 lnc0 @0:11 b 172.24.48.45,139 -> 192.168.220.10,1167 PR tcp len 20 48 -AS IN
18:40:48.640407 lnc0 @0:11 b 172.24.48.45,139 -> 192.168.220.10,1167 PR tcp len 20 48 -AS IN
18:38:58.594114 lnc0 @0:11 b 172.24.48.80,139 -> 192.168.220.10,1162 PR tcp len 20 48 -AS IN
18:38:55.387798 lnc0 @0:11 b 172.24.48.80,139 -> 192.168.220.10,1162 PR tcp len 20 48 -AS IN
18:38:35.493026 lnc0 @0:11 b 172.24.48.42,139 -> 192.168.220.10,1161 PR tcp len 20 48 -AS IN
18:38:32.457896 lnc0 @0:11 b 172.24.48.42,139 -> 192.168.220.10,1161 PR tcp len 20 48 -AS IN


Auch das Anlegen von expliziten Regeln für Diese IPs und Ports bringt keine Änderung

[potsdam]

Das Problem ist gelöst - Danke an alle die mitgegrübelt haben.

Es muß neben den Allow all Regeln unter NAT - Outbound die Option Enable advanced outbound NAT gesetzt werden. Dann klappts auch mit Windows.

Danke für den Tipp Matthias!!