[Xen] Netzwerk

Lord_Icon

Lord_Icon

Member
moin,

Xen läuft bei mir auf OS 10.3 und diverse Gäste.

eth0 = die externe Leitung (internet)
eth1 = die interne Leitung (Backup, etc)

Das ganze System läuft auch wunderbar. Aber mit der internen Leitung habe ich ein Problem.

Vom GAST auf den WIRT kann ich pingen. (über die Interne Leitung)
[DomU <=> Dom0 = ok.]

Nun das ganze unter berücksichtigung des Backup-Servers.
vom Gast auf den Backup-Serverkann ich intern pingen
[DomU <=> Backup-Server = ok.]

Was nicht geht, ist das ich mit den Wirts System auf den Backup-Server pingen kann.
[DomO <=> Backup-Server = failed]

Der Backup-Server ist im übrigen eine pys. vorhande Maschine die Netzwerkmäßig genauso konfiguriert ist wie das oben genante System (natürlich mir anderen IP's)


Einer eine Idee, woran das liegen könnte ?


P.s. Xen is auf default. Also brigend
 
Du erreichst von der DomO deinen Backupserver auch nicht? Kann ja sein, dass nur IMCP geblockt ist.

Wenn nicht: erreichst du von der dumO denn irgendwas in deinem Internen Netz?

Wenn nicht: Was sagt denn die Firewall zum Thema: domO und Internes Netz?

Ausserdem: Was sagt denn die routing Tablle?
 
nope.... du hast was falsch verstanden.

Seitens DomU kann ich ALLES erreichen. Intern Extern.
Auch Dom0 und den Backup-Server.

Dom0 ist das Problem. Ich möchte einen Gast-Container über die interne Leitung auf den Backup Server verschieben. Wenn ich das über die externe (internet) Leitung mache, dann wird mir das als Traffic berechnet.

Also: Dom0 (vom Hauptserver) kann nicht über die interne Leitung die Dom0 (vom Backup-Server) zugreifen.

GEDACHT habe ich mir mittlerweile schon

Verbindungsaufbau von Dom0 (hauptserver) auf daraufliegende DomU.
Diese DomU leitet die Datei dann über die Interne Leitung auf Dom0 vom Backup-Server.
Aber hier habe ich noch keine Lösung gefunden. Zumindest nicht, ohne die Container-Datei direkt in die DomU zwischenzuspeichern.


Ausserdem: Was sagt denn die routing Tablle?
Click to expand...
uuuups. What ?
Sorry. Das sagt mir grad nichts. Zumindest weiß ich nicht, wie ich mir diese Information ausgeben könnte. (brctl ?)

Firewall auf Main-Server:
Auf den Hauptserver läuft garnichts. Weder die "hauseigene" Firewall von Suse noch iptabels. Das war damals als minimal System installiert worden und bis dato noch nie behoben worden. Das ist auch der Grund, warum ich den Server platt machen möchte und komplett neu einrichten möchte. Zuerst muß ich aber die Conainer-Datein auf den Backup-Server verschieben.

Firewall auf Backup-Server: iptable -L
Alles noch deafult:
Code: 
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            state ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere            state RELATED
input_ext  all  --  anywhere             anywhere
input_ext  all  --  anywhere             anywhere
input_ext  all  --  anywhere             anywhere
input_ext  all  --  anywhere             anywhere
input_ext  all  --  anywhere             anywhere
LOG        all  --  anywhere             anywhere            limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-IN-ILL-TARGET '
DROP       all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            PHYSDEV match --physdev-is-bridged
LOG        all  --  anywhere             anywhere            limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-FWD-ILL-ROUTING '   

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            state NEW,RELATED,ESTABLISHED
LOG        all  --  anywhere             anywhere            limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-OUT-ERROR '

Chain forward_ext (0 references)
target     prot opt source               destination

Chain input_ext (5 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere            PKTTYPE = broadcast
ACCEPT     icmp --  anywhere             anywhere            icmp source-quench
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request
LOG        tcp  --  anywhere             anywhere            limit: avg 3/min burst 5 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-ACC-TCP '
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh
LOG        tcp  --  anywhere             anywhere            limit: avg 3/min burst 5 tcp dpt:ftp flags:FIN,SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-ACC-TCP '
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ftp
LOG        tcp  --  anywhere             anywhere            limit: avg 3/min burst 5 tcp dpt:ftp flags:FIN,SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-ACC-TCP '
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ftp
LOG        tcp  --  anywhere             anywhere            limit: avg 3/min burst 5 tcp dpts:30000:30100 flags:FIN,SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-ACC-TCP '
ACCEPT     tcp  --  anywhere             anywhere            tcp dpts:30000:30100
LOG        all  --  anywhere             anywhere            limit: avg 3/min burst 5 PKTTYPE = multicast LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP-DEFLT '
DROP       all  --  anywhere             anywhere            PKTTYPE = multicast
LOG        tcp  --  anywhere             anywhere            limit: avg 3/min burst 5 tcp flags:FIN,SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP-DEFLT '
LOG        icmp --  anywhere             anywhere            limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP-DEFLT '
LOG        udp  --  anywhere             anywhere            limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP-DEFLT '
LOG        all  --  anywhere             anywhere            limit: avg 3/min burst 5 state INVALID LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP-DEFLT-INV '
DROP       all  --  anywhere             anywhere

Chain reject_func (0 references)
target     prot opt source               destination
REJECT     tcp  --  anywhere             anywhere            reject-with tcp-reset
REJECT     udp  --  anywhere             anywhere            reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere            reject-with icmp-proto-unreachable


Edit:
ICh hab jetzt mal schnell auf den Main-Server iptabels nachinstalliert um zu schaun, ob doch was gesetzt worden ist. Aber da nichts dergleiches lief, könnte ja theoreisch auch nix eingerichtet sein.
Was folgende Ausgabe auch beweißt.

Code: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Edit2:
tabelle routing... ich denke mal über rounte -n
Wenn ja, dann:

Hauptserver
Code: 
route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
x1x.x2x.222.224  0.0.0.0         255.255.255.224 U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         x1x.x2x.222.225  0.0.0.0         UG    0      0        0 eth0

Backup-Server
Code: 
route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
x1x.x2x.222.224  0.0.0.0         255.255.255.224 U     0      0        0 br0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         x1x.x2x.222.225  0.0.0.0         UG    0      0        0 br0
 
Last edited by a moderator:
Lord_Icon said:
Sorry. Das sagt mir grad nichts. Zumindest weiß ich nicht, wie ich mir diese Information ausgeben könnte.
Click to expand...

/sbin/route -n

Falls Du die Ausgabe anonymisierst, schreib' bitte umbedingt dazu, welches die interne und welches die externe IP ist.

Meine vermutung geht dahin, daß DomU auf eth1 gebriget ist, der Host/Dom0 aber nur eine Defaultroute auf eth0 haben.

Dann wäre das mit einem einfachen
Code: 
route add -host (Backup-Server-IP) gw (IP-von-eth1)
zu lösen.
 
Danke wi

MEin Edit2 hat sich ja ein paar Sekunden mit dein Posting überschnitten.

Falls Du die Ausgabe anonymisierst, schreib' bitte umbedingt dazu, welches die interne und welches die externe IP ist.
Click to expand...
Jupp.. da ich oben schon geschrieben hab => keine Firewall, wäre es wohl nicht sehr überlegt, da ne öffendliche IP zu posten. Wobei das "nackige" online gehen überhaupt schon n Fehler war. Aber das is ne andere Sache.

anonymisierst => teilweise.
x1x = ist immer mit der gleichen IP ersetzt worden.
ebendfalls x2x.

Sollte ja egal sein, ob es 123 oder x1x lautet.

Gilt im nach hinein dein Vorschlag trotzdem ?
Also auf berücksichtigung auf Edit2 ?

...welches die interne und welches die externe IP ist.
Click to expand...
eth0 = IMMER externe (Internet) Leitung. Auf beiden Servern.
Wobei auf den Backup Server schon Xen3.2 läuft und es dort über br0 läuft.
 
Ja, ich hatte den Edit auch gerade gesehen.

Nochmal zu meinem Verständnis:

192.168.0.0/24 ist Dein internes Netzwerk, eth1 vom Hauptserver und br1 vom Backupserver haben jeweils IPs aus diesem Bereich und sind direkt miteinander verbunden?

eth0 vom Hauptserver und br0 vom Hauptserver sind jeweils mit dem Internet (und damit indirekt auch miteinander) verbunden?

Warum hat der Backup-Server eigentlich br-Interfaces, ist er virtuell?

Eigentlich stimmt alles, die /24-Route müßte wegen der spezifischeren Maske vor der 0.0.0.0-Route bevorzugt werden.

Was sagt denn ein traceroute statt dem Ping Dom0 -> Backupserver?

PS: eth0 und br0 haben auch jeweils verschiedene IPs aus dem x1x.x2x.222.224/27er Bereich?
 
Last edited by a moderator:
huii... viele Fragen... aber is auch n schwieriges Thema.

192.168.0.0/24 ist Dein internes Netzwerk, eth1 vom Hauptserver und br1 vom Backupserver haben jeweils IPs aus diesem Bereich und sind direkt miteinander verbunden?
Click to expand...
hmm... vielen Fragen in einen Satz.
Lass es mich mal Detailierter Ausdrücken:

Dom0 (Hauptserver)
eth0 = x1x.x2x.222.232 = Externe Leitung
eth1 = 192.168.0.10 = Interne Leitung
DomU (auf Hauptserver)
eth0 = x1x.x2x.222.240 = Externe Leitung
eth1 = 192.168.0.11 = Interne Leitung

Dom0 (Backup-Server)
eth0 alias br0 = x1x.x2x.222.233 = Externe Leitung
eth1 alias br1 = 192.168.0.20 = Interne Leitung

eth0 vom Hauptserver und br0 vom Hauptserver sind jeweils mit dem Internet (und damit indirekt auch miteinander) verbunden?
Click to expand...
Falsch.
eth0 ist vom Hauptserver.
br0 ist vom Backup-Server. (siehe nächste Antwort)
Aber ja... bei beiden Leitungen handelt es sich um die Externe Leitung, die im Internet sind und auch erreichbar sind.

Warum hat der Backup-Server eigentlich br-Interfaces, ist er virtuell?
Click to expand...
Das hat mich auch viel Zeit gekostet.
Also. Der Hauptserver hat noch Xen3.0 drauf.
Da hießen die virtuellen Netzwerkkarten auch noch xenbr0.
UND: Die IP Adressen wurden hier über die realen Netzwerkkarten eingerichtet. Also eth0 und eth1. Eine Brige wurde dann anscheind von Xen selbst eingerichtet. Also eth0 => xenbr0 etc.

Auf den Backup-Server läuft nun aber Xen3.2.
Hier hat sich anscheind einiges getan. Denn nach der ersteinrichtung bin ich nicht ins Web gekommen. Grund war, das ich die Statische IP wie gewohnt über eth0 eingerichtet habe. Erst als ich auf den (eher verzweifelten) Versuch gekommen bin, br0 die Statische IP zu geben, hat alles geklappt.
Hier scheint XEN es nun genau umgedreht zu machen. Es scheint eine briged von br0 auf eth0 und dann ins Web zu gehen. (eigendlich logischer)


Was sagt denn ein traceroute statt dem Ping Dom0 -> Backupserver?
Click to expand...
Code: 
Haupt-Server:~ # traceroute 192.168.0.20
traceroute to 192.168.0.20 (192.168.0.20), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  192.168.0.10 (192.168.0.10)(H!)  2944.162 ms (H!)  2940.173 ms (H!)  2936.173 ms

Wenn ich das ganze aber von der DomU ausführe, dann sieht das so aus.
(Die DomU liegt auf den Hauptserver)
Code: 
Testsystem:~ # traceroute 192.168.0.20
traceroute to 192.168.0.20 (192.168.0.20), 30 hops max, 40 byte packets
 1  localhost (192.168.0.20)  0.155 ms   0.128 ms   0.110 ms
 
Code: 
Testsystem:~ # traceroute 192.168.0.20
traceroute to 192.168.0.20 (192.168.0.20), 30 hops max, 40 byte packets
 1  localhost (192.168.0.20)  0.155 ms   0.128 ms   0.110 ms

Das "localhost" sieht sehr komisch aus - es handelt sich doch um den anderen Server.

Was sagt denn brctl show?
 
Das "localhost" sieht sehr komisch aus - es handelt sich doch um den anderen Server.
Click to expand...

Jupp.. hab ich ja auch gesagt. DAS ist die Ausgabe von ein Gast, der auf den Hauptserver läuft.
GÄSTE/DomU selbst können auf den Backup Server pingen.
WIRT/Dom0 aber nicht.

Und da es sich hierbei um den Gast handelt, hat dieser auch kein brctl.
 
ok... es is n schweres Thema.
Damit man mal duchsieht => hier mal was grafisches.

(bin aber kein picasso)
 

Attachments

  • Image1.jpg
    Image1.jpg
    71 KB · Views: 200
Bist Du wirklich sicher, daß Du vom Gast aus wirklich auf den Backup-Server kommst oder beantwortet nur "irgendwer" Deine Pings. Mir kommt es so vor, als ob der Gast meint, 192.168.0.20 wären lokal und nicht auf dem Backup-Server. Das sollte sich aber mittels http oder ssh überprüfen lassen.

Der andere Trace sieht in dieser Beziehung auch seltsam aus. Die Sternchen kommen daher, daß Deine Firewall auch ICMP blockt (eventuell kannst Du das mal kurzzeitig freigeben), die Anzahl der Zeilen und die Tatsache, daß 192.168.0.20 irgendwann mal als unreachable angezeigt wird, deuten aber darauf hin, daß der Pfad übers Internet/eth0 und nicht über eth1 läuft.

Mit brctl meinte ich die Bridges auf den Hostsystemen (Hauptserver und Backup, nicht den Gast). Da ist irgendwas seltsam.
 
Mit brctl meinte ich die Bridges auf den Hostsystemen
Click to expand...

Main-Server:
Code: 
Haupt-Server:~ # brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr0          8000.feffffffffff       no              vif0.0
                                                        peth0
                                                        vif51.0
                                                        vif9.0
                                                        vif10.0
                                                        vif27.0
                                                        vif53.0
                                                        vif63.0
                                                        vif62.0
xenbr_intern            8000.003048317fc9       no              eth1
                                                        vif51.1
                                                        vif9.1
                                                        vif10.1
                                                        vif27.1
                                                        vif53.1
                                                        vif63.1
                                                        vif62.1

Backup-Server:
Code: 
backup-server:~ # brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0030487abc24       no              eth0
br1             8000.0030487abc25       no              eth1


Bist Du wirklich sicher, daß Du vom Gast aus wirklich auf den Backup-Server kommst
Click to expand...
110%tig !!!
Weil 2 der Gäste machen tätglich ein Vollbackup auf den Backup-Server.
Und die sind auch da.(Backups)
Und auf mein Traffic-Volumen brauch ich nicht schauen, weil die Backups um die 7-10 GB ausmachen. Wenn das tatsächlich über die offizelle gehen würde, hätt ich schon längst ne Mail :D
 
Ich gebe Dir recht - das sieht eigentlich alles völlig korrekt aus.

Vielleicht gibt es hier ja noch einen Xen-Spezialisten, dem der Fehler ins Auge fällt.

Beim Durchschauen von XenNetworking - Xen Wiki fiel mir noch der Unterschied eth0 / peth0 auf, in der Bride-Konfiguration vom Hauptserver steht letzteres, in der Routing-Tabelle aber ersteres.
Interessant wäre vielleicht, auf welches nun welche IP gebunden ist.

Was sagt denn "ip addr" (ggf. wieder anonymisieren) auf Haupt- und Backupserver?
 
:( und ich dachte, das es mit ein Befehl getan wäre.

Aber gut:
Beim Mainserver poste ich mal nur das wichtigste. Die Liste geht bis nummer: 139, wobei die Nummerierung nicht gleichmäßig ist. Würder abder den Rahmen hier sprengen:

Main-Server:
Code: 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: peth0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:10:48:20:7f:c9 brd ff:ff:ff:ff:ff:ff
    inet [COLOR="Red"]192.168.0.10/24 brd 192.168.0.255[/COLOR] scope global eth1
    inet6 fe80::230:48ff:fe31:7fc9/64 scope link
       valid_lft forever preferred_lft forever
4: vif0.0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 00:15:48:31:7f:07 brd ff:ff:ff:ff:ff:ff
    inet [COLOR="Red"]x1x.x2x.222.232/27 brd x1x.x2x.222.255[/COLOR] scope global eth0
    inet6 xxxx:xxx:48ff:fe31:7fc8/64 scope link
       valid_lft forever preferred_lft forever            
...
...         
12: xenbr0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
27: xenbr_intern: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 00:30:48:31:7f:c9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:48ff:fe31:7fc9/64 scope link
       valid_lft forever preferred_lft forever


Backup-Server:
Code: 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100
    link/ether 00:30:48:7a:bc:24 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:48ff:fe7a:bc24/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:30:48:7a:bc:25 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:48ff:fe7a:bc25/64 scope link
       valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:30:12:7a:bc:10 brd ff:ff:ff:ff:ff:ff
    inet [COLOR="Red"]x1x.x2x.222.233/27[/COLOR] brd [COLOR="Red"]x1x.x2x.222.255[/COLOR] scope global br0
    inet6 xxxx::xxxx:48ff:fe7a:bc24/64 scope link
       valid_lft forever preferred_lft forever
5: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:30:40:7a:bc:20 brd ff:ff:ff:ff:ff:ff
    inet [COLOR="Red"]192.168.0.20/24 brd 192.168.0.255[/COLOR] scope global br1
    inet6 fe80::230:48ff:fe7a:bc25/64 scope link
       valid_lft forever preferred_lft forever

Sag mal: Wirf mal ein Blick auf lo (die 1:)
Bekommt JEDES interface einen Eintrag?

Wenn ja, dann würde ich ja sagen = auf den Backup-Server ist es korrekt.
Main-Server würde dann ein Eintrag fehlen
 
Last edited by a moderator:
öhmm... mir ist das grad mal so eine Frage eingefallen.

Meines Wissens nach, müßte Suse ja damit umgehen können... aber vielleicht weiß einer ja.

eth0 läuft ja über die Maske: 255.255.255.224 (wg. x1x.x2x.222.232)
eth1 läuft aber über die Maseke: 255.255.255.0 (wg. 192.168.0.10)

Somit sind beide Karte in verschiedene Netzwerke drin. So wie ich es eigendlich wollte. Aber kann es sein, das hier evtl. das Problem liegt ?
Kann ich mir zwar nicht vorstellen... aber lieber einmal mehr gefragt.
 
Wieder ein Mosaiksteinchen mehr, das Bild formt sich :o

Es fällt auf, daß das interne Netz auf dem Hauptserver in der Dom0 anders konfiguriert ist, als alle anderen Netze.

Auf dem Backupserver haben eth0 und eth1 keine IP, sondern sind im Promiscuous Mode mit je einer Bridge verbunbden. Die IPs sind auf die virtuellen Brückeninterfaces br0 / br1 gebunden.

Auf dem Hauptserver ist es für eth0 genauso. Das ist der Punkt, der mir am meisten Kopfzerbrechen gemacht hat, bis ich
http://wiki.xensource.com/xenwiki/XenNetworking#head-04ebcc1760dbc4678e83b116afa310dc0612dc39 said:
4. real interface eth0 is renamed peth0
5. virtual interface veth0 is renamed eth0
6. peth0 and vif0.0 are attached to bridge xenbr0
Click to expand...
gelesen hatte.

Dein Hardware-Interface heißt also im Moment peth0, was die gepostete Liste auch bestätigt (2. Eintrag).
Verwirrend, aber halt "the Xen way" :confused:
eth0 ist ein virtuelles Interface dieser Brücke (xenbr0) und trägt die externe IP.

eth1 hingegen ist nicht umbenannt und das Hardware-Interface, an welches auch die zweite Brücke (xenbr_intern) hängt.
Trotzdem ist die interne IP des Hauptservers (genau die, welche Probleme macht) dorthin gebunden und nicht an ein virtuelles Interface - und damit quasi an der Brücke vorbei.

Versuch doch mal probeweise, die IP an die Brücke zu binden, also etwa
Code: 
ifconfig eth1 0.0.0.0
ifconfig xenbr_intern 192.168.0.10/24
(oder so ähnlich, ich habe gerade kein Testsystem).

Dann wäre die Konfiguration wieder symmetrisch.

Die Gäste auf dem Hauptserver sollte die Änderung nicht betreffen, da sie ja eh über die Brücke und ihre eigenen Interfaces (vif51.1 usw.) zugreifen.
Allerdings sollte Dom0 mittels 192.168.0.10 jetzt über die Brücke auf das interne Netz zugreifen und damit auch den Backupserver erreichen (was ja der Ausgangspunkt des threads war).

Danach nochmal mit ifcinfig/ip addr und route kontrollieren - eigentlich sollte die Route gleich vom ifconfig angelegt werden.
Code: 
Ziel        Router  Genmask       Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U     0      0   0   xenbr_intern
 
juhuhuuuu... ich könnt dich knu..... aber da du warscheinlich männlich bist, könnte das den falschen Eindruck erwecken :p

that's works !!!


Ich verstehe auch, was du mir vorgeschlagen hast.... und ärgere mich ein wenig, das nicht schon vorher probiert zu haben.

Verwunderlich das ganze...

Xen < oder = Version 3.0 lässt es zu, die Netzwerkeinstellungen direkt an die phy. Netzwerkkarte vorzunehmen.
Anscheind baut Xen sich da eine Brücke von
eth0 => br0 => eth0 => internet
(die virtuellen zwischenkarten peth0 etc. lass ich mal weg)

In gewisser Hinsicht eine recht unsinnige Brigde.

In Xen 3.2... und das hat mich ja ne gute Stunde an Zeit gekostet, das rauszubekommen.... werden die Netzwerkeinstellungen direkt an den Virtuellen Karten eingestellt. Auch wenn man die korrekten IP Einstellungen an eth0 vornimmt = man kommt nicht raus. Auch wenn man im nicht Xen Modus startet.
Was ja eigendlich recht gut ist... wenn man es weiß :D

Denn dann macht dir Brigde sinn:
br0 => eth0 => internet


Und meine nächste Aufgabe ist es, mir das Xen 3.0 Handbuch aus n Schrank zu kramen und mal die Konfiguration bezgl. Netzwerk rauszusuchen. Mal schaun, ob es da über eth0 oder über br0 (damals ja noch xenbr0) erklärt worden ist :cool:



VIELEN³³³ Dank
 
You must log in or register to reply here.
Back
Top