martian source Meldungen
Hallo, nochmal der Versuch auf "geistige" Unterstützung ;) diesmal richtig geschrieben ;). Seit ich einen neuen Switch habe, laufen bei mir die log über, mit martian source Meldungen. Im Prinzip müsste das ja auf eine Fehlkonfiguration hinauslaufen (?). ich betreibe meinen eigenen DNS Server. Aber ehrlich gesagt finde ich das Problem nicht :(. Ich weiß ich könnte die logs einfach abdrehen, lieber würde es mir sein dem Problem auf den Grund zu gehen, oder ist das einfach Protokoll bedingt? Im Internet findet man (ich) nicht wirklich was darüber, so Frage ich mal bei Euch nach wo / wie man das ganze eingrenzen könnte. Das Problem scheint irgendwie IPv6 zu sein? Ich habe in diesem Rechner 3 Netzwerkkarten für jedes Netz eine, also local, extern, IPv6 auf allen "Rechnern" (XEN) erscheinen diese Meldungen oder ähnlich. Oct 24 10:35:25 asmtp kernel: [691782.146317] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.820574] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.820579] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.821098] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.821100] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.821579] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.821581] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.821976] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.821980] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.822406] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.822409] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.827468] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.827473] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:29 asmtp kernel: [691784.829409] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 ...... aber eth2 ist rein IPv6 konfiguriert. -- mit freundlichen Grüßen / best Regards. Günther J. Niederwimmer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Günther, solche Meldungen hatte ich auch schon einmal. Ich nehme an, die findest Du in der /var/log/messages. Mein Verdacht damals war, dass es sich um DHCP-Anfragen handelt, die von Deinem Rechner nicht beantwortet werden. Die Buchstaben/Ziffernkombination ist in den letzten 6 Paaren (fe:18:a6:1e:08:00) wahrscheinlich die MAC-Adresse des anfragenden Rechners. Damit könnte er identifizierbar sein. Mein Verdacht war seinerzeit, dass es ein Windows-Rechner sei, der diese Anfragen stellt. Aber im Prinzip kann ich mir das auch von einem Linux-Rechner vorstellen. Solange die DHCP-Anfragen nicht beantwortet werden, kann der Rechner keine sinnvolle IP-Adresse in den Header schreiben. Also erscheint das Deinem Rechner als "Quelle vom Mars". Ist das völlig unlogisch? Gruß Jan P.S.: Als Rechner kommen natürlich auch andere Gräte infrage, die eine IP haben wollen: WLAN-Router, Drucker, Handies, ... Am 24.10.2012 10:48, schrieb Günther J. Niederwimmer:
Hallo,
nochmal der Versuch auf "geistige" Unterstützung ;) diesmal richtig geschrieben ;).
Seit ich einen neuen Switch habe, laufen bei mir die log über, mit martian source Meldungen.
Im Prinzip müsste das ja auf eine Fehlkonfiguration hinauslaufen (?). ich betreibe meinen eigenen DNS Server.
Aber ehrlich gesagt finde ich das Problem nicht :(.
Ich weiß ich könnte die logs einfach abdrehen, lieber würde es mir sein dem Problem auf den Grund zu gehen, oder ist das einfach Protokoll bedingt?
Im Internet findet man (ich) nicht wirklich was darüber, so Frage ich mal bei Euch nach wo / wie man das ganze eingrenzen könnte.
Das Problem scheint irgendwie IPv6 zu sein? Ich habe in diesem Rechner 3 Netzwerkkarten für jedes Netz eine, also local, extern, IPv6
auf allen "Rechnern" (XEN) erscheinen diese Meldungen oder ähnlich.
Oct 24 10:35:25 asmtp kernel: [691782.146317] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.820574] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.820579] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.821098] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.821100] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.821579] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.821581] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.821976] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.821980] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.822406] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.822409] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:28 asmtp kernel: [691784.827468] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2 Oct 24 10:35:28 asmtp kernel: [691784.827473] ll header: ff:ff:ff:ff:ff:ff:00:24:fe:18:a6:1e:08:00 Oct 24 10:35:29 asmtp kernel: [691784.829409] martian source 192.168.100.255 from 89.26.XXX.XXX, on dev eth2
......
aber eth2 ist rein IPv6 konfiguriert.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 24.10.2012 um 10:48 schrieb Günther J. Niederwimmer <gjn@gjn.priv.at>:
Oct 24 10:35:29 asmtp kernel: [691784.829409] martian source192.168.100.255 from 89.26.XXX.XXX, on dev eth2
Scnhellschuß: Dein eth2 hat die Adresse 89.26.xxx.xxx und sieht ein IP-Paket mit der Absenderadresse 192.168.100.255 (riecht nach broadcast und damit nach Windows), die dort nicht auftauchen darf, einfach weil es keinen Routing-Eintrag für dieses 192-er Netz via eth2 gibt. Du sprichst von XEN, kann es sein, daß Du eine Bridge hast, in der eth2 steckt sowie die vif's für Deine (Windows-?)VMs? Aber wie gesagt: alles geraten :-) Rainer-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Mittwoch, 24. Oktober 2012, 12:33:22 schrieb Rainer Sokoll:
Am 24.10.2012 um 10:48 schrieb Günther J. Niederwimmer <gjn@gjn.priv.at>:
Oct 24 10:35:29 asmtp kernel: [691784.829409] martian source192.168.100.255 from 89.26.XXX.XXX, on dev eth2
Scnhellschuß: Dein eth2 hat die Adresse 89.26.xxx.xxx und sieht ein IP-Paket mit der Absenderadresse 192.168.100.255 (riecht nach broadcast und damit nach Windows), die dort nicht auftauchen darf, einfach weil es keinen Routing-Eintrag für dieses 192-er Netz via eth2 gibt. Du sprichst von XEN, kann es sein, daß Du eine Bridge hast, in der eth2 steckt sowie die vif's für Deine (Windows-?)VMs?
Aber wie gesagt: alles geraten :-) ;).
Du hast nicht fertig gelesen ;) eth2 ist NUR für IPv6 konfiguriert Ja ich habe auf allen drei Karten eine Bridge (br0 > eth0,br1 > eth1 ,br2 > eth2) und auch darauf geachtet das keinen Fehler bei der Zuordnung passieren br0 ist intern, br2 IPv6, br1 ist IPv4 extern. Mir kommt vor das hängt mit den Netzwerkkarten zusammen 3 Stück, dass es da Probleme gibt (?) Etwas genervt :)). -- mit freundlichen Grüßen / best Regards. Günther J. Niederwimmer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 24.10.2012 um 13:33 schrieb Günther J. Niederwimmer <gjn@gjn.priv.at>
Du hast nicht fertig gelesen ;) eth2 ist NUR für IPv6 konfiguriert
Ja ich habe auf allen drei Karten eine Bridge (br0 > eth0,br1 > eth1 ,br2 > eth2) und auch darauf geachtet das keinen Fehler bei der Zuordnung passieren br0 ist intern, br2 IPv6, br1 ist IPv4 extern.
Na dann zeig' doch mal: ifconfig eth2 ifconfig br2 brctl show br2 was sagt denn ein tcpdump auf eth2 respektive br2? Rainer-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Mittwoch, 24. Oktober 2012, 14:44:19 schrieb Rainer Sokoll:
Am 24.10.2012 um 13:33 schrieb Günther J. Niederwimmer <gjn@gjn.priv.at>
Du hast nicht fertig gelesen ;) eth2 ist NUR für IPv6 konfiguriert
Ja ich habe auf allen drei Karten eine Bridge (br0 > eth0,br1 > eth1 ,br2
eth2) und auch darauf geachtet das keinen Fehler bei der Zuordnung passieren br0 ist intern, br2 IPv6, br1 ist IPv4 extern.
Na dann zeig' doch mal:
ifconfig eth2 ifconfig br2 brctl show br2
ja, ja wird ja schon gemacht ;) brctl show br2 bridge name bridge id STP enabled interfaces br0 8000.001cc0a39f4b no eth0 vif1.0 vif2.0 vif3.0 vif4.0 vif5.0 vif6.0 vif7.0 br1 8000.000e0c6459fe no eth1 vif1.1 vif2.1 vif3.1 vif4.1 vif5.1 vif6.1 vif7.1 br2 8000.000e0c6459ff no eth2 vif1.2 vif2.2 vif3.2 vif4.2 vif5.2 vif6.2 vif7.2 ifconfig br2 br2 Link encap:Ethernet Hardware Adresse 00:0E:0C:64:59:FF inet6 Adresse: fe80::20e:cff:fe64:59ff/64 Gültigkeitsbereich:Verbindung inet6 Adresse: 2001:15c0:65ff:868c::XXXXX/64 Gültigkeitsbereich:Global UP BROADCAST RUNNING MULTICAST MTU:1480 Metric:1 RX packets:512207 errors:0 dropped:2396 overruns:0 frame:0 TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:52621952 (50.1 Mb) TX bytes:1546 (1.5 Kb) auf einer XEN Instanz: ifconfig eth2 eth2 Link encap:Ethernet Hardware Adresse 00:16:3E:C1:35:77 inet6 Adresse: fe80::216:3eff:fec1:3577/64 Gültigkeitsbereich:Verbindung inet6 Adresse: 2001:15c0:65ff:868c::XXXXX/64 Gültigkeitsbereich:Global UP BROADCAST RUNNING MULTICAST MTU:1480 Metric:1 RX packets:731612 errors:0 dropped:513577 overruns:0 frame:0 TX packets:6066 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:74779759 (71.3 Mb) TX bytes:586283 (572.5 Kb) die dropped: dürften die martian source sein (?)
was sagt denn ein tcpdump auf eth2 respektive br2?
da stehe ich im Walde, so gut bin ich dann auch nicht ;) -- mit freundlichen Grüßen / best Regards. Günther J. Niederwimmer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Wed, 24 Oct 2012, Günther J. Niederwimmer schrieb:
Am Mittwoch, 24. Oktober 2012, 14:44:19 schrieb Rainer Sokoll:
Am 24.10.2012 um 13:33 schrieb Günther J. Niederwimmer <gjn@gjn.priv.at>
Du hast nicht fertig gelesen ;) eth2 ist NUR für IPv6 konfiguriert
Ja ich habe auf allen drei Karten eine Bridge (br0 > eth0,br1 > eth1 ,br2
eth2) und auch darauf geachtet das keinen Fehler bei der Zuordnung passieren br0 ist intern, br2 IPv6, br1 ist IPv4 extern.
Bitte auch noch die Ausgabe von route -n und/oder ip route list sowie vielleicht noch die von ip addr list Alles jew. auf dem Host/Xen-Gast bei dem die Meldungen das Log fluten. -dnh -- "Wenn mer die Linke an der Macht beteiligt, flüchtet das bürgerliche Kapital ins Ausland." "Des glaub isch ned, des is doch scho fott." -- Neues a. d. Anstalt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. Oktober 2012, 01:34:13 schrieb David Haller:
Hallo,
Am Wed, 24 Oct 2012, Günther J. Niederwimmer schrieb:
Am Mittwoch, 24. Oktober 2012, 14:44:19 schrieb Rainer Sokoll:
Am 24.10.2012 um 13:33 schrieb Günther J. Niederwimmer <gjn@gjn.priv.at>
Du hast nicht fertig gelesen ;) eth2 ist NUR für IPv6 konfiguriert
Ja ich habe auf allen drei Karten eine Bridge (br0 > eth0,br1 > eth1 ,br2
eth2) und auch darauf geachtet das keinen Fehler bei der Zuordnung passieren br0 ist intern, br2 IPv6, br1 ist IPv4 extern.
Bitte auch noch die Ausgabe von
route -n
host: route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 0.0.0.0 89.26.108.14 0.0.0.0 UG 0 0 0 br1 89.26.108.0 0.0.0.0 255.255.255.240 U 0 0 0 br1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 XEN Klient route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.100.210 0.0.0.0 UG 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Wo kommt da zB. die 169.xxx.xxx.xxx her ?
und/oder
ip route list host: ip route list default via 89.26.108.14 dev br1 89.26.108.0/28 dev br1 proto kernel scope link src 89.26.108.XX 127.0.0.0/8 dev lo scope link 192.168.100.0/24 dev br0 proto kernel scope link src 192.168.100.210
XEN Klient ip route list default via 192.168.100.210 dev eth0 127.0.0.0/8 dev lo scope link 169.254.0.0/16 dev eth0 scope link 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.213
sowie vielleicht noch die von
ip addr list Host: ip addr list 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: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UP qlen 1000 link/ether 00:0e:0c:64:59:fe brd ff:ff:ff:ff:ff:ff inet6 fe80::20e:cff:fe64:59fe/64 scope link valid_lft forever preferred_lft forever 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000 link/ether 00:1c:c0:a3:9f:4b brd ff:ff:ff:ff:ff:ff inet6 fe80::21c:c0ff:fea3:9f4b/64 scope link valid_lft forever preferred_lft forever 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast master br2 state UP qlen 1000 link/ether 00:0e:0c:64:59:ff brd ff:ff:ff:ff:ff:ff inet6 fe80::20e:cff:fe64:59ff/64 scope link valid_lft forever preferred_lft forever 5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:1c:c0:a3:9f:4b brd ff:ff:ff:ff:ff:ff inet 192.168.100.210/24 brd 192.168.100.255 scope global br0 inet6 fe80::21c:c0ff:fea3:9f4b/64 scope link valid_lft forever preferred_lft forever 6: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:0e:0c:64:59:fe brd ff:ff:ff:ff:ff:ff inet 89.26.108.4/28 brd 89.26.108.15 scope global br1 inet6 fe80::20e:cff:fe64:59fe/64 scope link valid_lft forever preferred_lft forever 7: br2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP link/ether 00:0e:0c:64:59:ff brd ff:ff:ff:ff:ff:ff inet6 2001:15c0:65ff:868c::d2/64 scope global valid_lft forever preferred_lft forever inet6 fe80::20e:cff:fe64:59ff/64 scope link valid_lft forever preferred_lft forever 9: vif1.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 32 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 10: vif1.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 32 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 11: vif1.2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast master br2 state UNKNOWN qlen 32 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 12: vif2.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 32 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 13: vif2.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 32 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 14: vif2.2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast master br2 state UNKNOWN qlen 32 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 15: vif3.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 32 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 16: vif3.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 32 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 17: vif3.2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast master br2 state UNKNOWN qlen 32 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 18: vif4.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 32 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 19: vif4.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 32 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 20: vif4.2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast master br2 state UNKNOWN qlen 32 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 21: vif5.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 32 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 22: vif5.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 32 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 23: vif5.2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast master br2 state UNKNOWN qlen 32 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 24: vif6.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 32 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 25: vif6.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 32 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 26: vif6.2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast master br2 state UNKNOWN qlen 32 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 27: vif7.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 32 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 28: vif7.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 32 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 29: vif7.2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast master br2 state UNKNOWN qlen 32 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
XEN Klient: ip addr list 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 UNKNOWN qlen 1000 link/ether 00:16:3e:4a:a5:d0 brd ff:ff:ff:ff:ff:ff inet 192.168.100.211/24 brd 192.168.100.255 scope global eth0 inet6 fe80::216:3eff:fe4a:a5d0/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:16:3e:2d:3b:fc brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:16:3e:c1:35:77 brd ff:ff:ff:ff:ff:ff inet6 2001:15c0:65ff:868c::d3/64 scope global valid_lft forever preferred_lft forever inet6 fe80::216:3eff:fec1:3577/64 scope link valid_lft forever preferred_lft forever
Alles jew. auf dem Host/Xen-Gast bei dem die Meldungen das Log fluten.
das ganze ist leider ausgeartet, auf meinem kleinen "Keller" Server war es eigentlich erträglich HoST und 4 Xen Klient, seit ich meinen neuen Switch (ProCurve 2510G-24) und den Test Rechner habe, HoST & 7 x XEN Klient läuft alles über, auf beiden Rechnern. -- mit freundlichen Grüßen / best Regards. Günther J. Niederwimmer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 25.10.2012 um 11:11 schrieb Günther J. Niederwimmer <gjn@gjn.priv.at>:
XEN Klient route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.100.210 0.0.0.0 UG 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Wo kommt da zB. die 169.xxx.xxx.xxx her ?
Rfc 5753: 169.254.0.0/16 - This is the "link local" block. As described in RFC3927 it is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server cannot be found. Du hast Zeroconf angeknipst im Client. Rainer-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 25. Oktober 2012, 12:41:35 schrieb Rainer Sokoll:
Am 25.10.2012 um 11:11 schrieb Günther J. Niederwimmer <gjn@gjn.priv.at>:
XEN Klient route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.100.210 0.0.0.0 UG 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Wo kommt da zB. die 169.xxx.xxx.xxx her ?
Rfc 5753:
169.254.0.0/16 - This is the "link local" block. As described in RFC3927 it is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server cannot be found.
Du hast Zeroconf angeknipst im Client.
Bin ich mir zwar nicht bewusst, aber ich finde auch keinen Punkt zum ausknipsen. Wo ist das versteckt ? Am host läuft das auch nicht.
Rainer-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org -- mit freundlichen Grüßen / best Regards.
Günther J. Niederwimmer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hab auch bei uns solche Einträge. Und zwar unter folgender Situation: Auf unserem Web-Server lautet der DNS Eintrag von www.beiuns.ch auf 192.54.xx.xx für das Internet. Vom Intranet aus lautet www.beiuns.ch auf 192.168.10.10. Der Browser (intern) ist so eingestellt, dass auf 192.168.10.0/24 ohne Proxy zugegriffen wird. Wenn ich nun von Intern www.beiuns.ch zugreife, sehe ich auf dem Web-Server/Proxy-Server solch schöne Meldungen. Eine Lösung ist mir noch nicht ganz klar. Wird wohl im Squid-Proxy Setting zu fixen sein... Logs: ct 24 16:28:13 bastion kernel: [1676077.738499] martian source 192.168.10.10 from 192.168.10.10, on dev eth0 Oct 24 16:28:13 bastion kernel: [1676077.738502] ll header: 00:1c:c0:74:60:52:00:1a:8c:15:6a:90:08:00 Oct 24 16:28:16 bastion kernel: [1676080.744643] martian source 192.168.10.10 from 192.168.10.10, on dev eth0 Oct 24 16:28:16 bastion kernel: [1676080.744646] ll header: 00:1c:c0:74:60:52:00:1a:8c:15:6a:90:08:00 Tschüss und viel Glück bei Fehlersuche Toni -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (5)
-
Anton Renner -
David Haller -
Günther J. Niederwimmer -
Jan Handwerker -
Rainer Sokoll