Wer Visionen hat soll zum Hausarzt gehen Helmut Schmidt ----- On Mar 23, 2016, at 5:16 PM, Stephan von Krawczynski skraw@ithnet.com wrote:

Deine Interfaces liegen im selben Class-C und haben dieselben Broadcasts/Netmasks. Es ist logisch dass auf beiden Interfaces beide IPs beantwortet werden. Das Setup ist nicht wirklich sinnvoll...

Das ist hier nicht die Frage.

On Wed, 23 Mar 2016 16:37:58 +0100 (CET) "Lentes, Bernd" wrote:

...

Hallo ML,

ich habe hier ein sehr merkwürdiges Netzwerkproblem. 2 hosts im gleichen Subnetz (geswitcht). Host A hat zwei Interfaces:

sunhb65278:~ # ifconfig eth0 Link encap:Ethernet HWaddr 70:10:6F:47:0C:44 inet addr:10.35.23.97 Bcast:10.35.23.255 Mask:255.255.255.0 inet6 addr: fe80::7210:6fff:fe47:c44/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:74211 errors:0 dropped:8057 overruns:0 frame:0 TX packets:369 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6767963 (6.4 Mb) TX bytes:40643 (39.6 Kb) Interrupt:16

eth1 Link encap:Ethernet HWaddr 70:10:6F:47:0C:45 inet addr:10.35.23.96 Bcast:10.35.23.255 Mask:255.255.255.0 inet6 addr: fe80::7210:6fff:fe47:c45/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:7668 errors:0 dropped:1130 overruns:0 frame:0 TX packets:47 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:702610 (686.1 Kb) TX bytes:3979 (3.8 Kb) Interrupt:17

Host B hat ein Interface:

pc60181:~ # ifconfig br0 Link encap:Ethernet HWaddr 54:04:A6:94:F4:93 inet addr:10.35.23.36 Bcast:10.35.23.255 Mask:255.255.255.0 inet6 addr: fe80::5604:a6ff:fe94:f493/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:918057155 errors:0 dropped:16024538 overruns:0 frame:0 TX packets:594965822 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:219547010052 (209376.3 Mb) TX bytes:14869161358944 (14180337.2 Mb)

An host A habe ich das Netzwerkkabel von eth1 gezogen. ethtool bestätigt das:

sunhb65278:~ # ethtool eth1 Settings for eth1:

...

Link detected: no

sunhb65278:~ #

eth0 ist verbunden:

sunhb65278:~ # ethtool eth0 Settings for eth0: ... Link detected: yes

Ich kann von host B BEIDE IP's von Host A anpingen:

pc60181:~ # ping 10.35.23.97 PING 10.35.23.97 (10.35.23.97) 56(84) bytes of data. 64 bytes from 10.35.23.97: icmp_seq=1 ttl=64 time=3.68 ms 64 bytes from 10.35.23.97: icmp_seq=2 ttl=64 time=0.173 ms 64 bytes from 10.35.23.97: icmp_seq=3 ttl=64 time=0.157 ms

pc60181:~ # ping 10.35.23.96 PING 10.35.23.96 (10.35.23.96) 56(84) bytes of data. 64 bytes from 10.35.23.96: icmp_seq=1 ttl=64 time=6.99 ms 64 bytes from 10.35.23.96: icmp_seq=2 ttl=64 time=0.150 ms 64 bytes from 10.35.23.96: icmp_seq=3 ttl=64 time=0.155 ms

Das versteh ich ja schon nicht. Wieso antwortet 10.35.23.96, obwohl das dazugehörige Netzwerkkabel von eth1 abgezogen ist ? Und wenn ich dann arp -a mache, falle ich ganz aus den Wolken:

pc60181:~ # arp -a

sunhb65278.scidom.de (10.35.23.97) at 70:10:6f:47:0c:44 [ether] on br0 sunhb65277.scidom.de (10.35.23.96) at 70:10:6f:47:0c:44 [ether] on br0

Wieso antwortet Host A auf die pings von host B auf die 10.35.23.96, und wieso gibt er noch als Antwort die MAC von eth0 und nicht von eth1 ? Wieso fühlt sich quasi eth0 für eth1 zuständig ?

Wenn die arp-Tabelle leer ist und ich neu pinge gleiches Spiel. arp -a wieder gleiche Ausgabe. Wenn die Tabelle leer ist und host B die 10.35.23.96 pingt, fragt doch arp "Wer hat IP 10.35.23.96 und welche MAC ist damit verbunden ?" Wieso antwortet da die 10.35.23.97 ? Selbst wenn jetzt in einem switch die MAC 70:10:6F:47:0C:45 noch dem port von eth0 zugeordnet ist, müsste doch Host A sagen, dafür ist eth0 nicht zuständig und das Paket wird ignoriert.

OS ist auf beiden SLES 11 SP4 64bit.

Ich versteh's nicht. Das Kabel zu eth1 ist gezogen. Ein anderer host im gleichen Subnetz will die IP von eth1 anpingen. Ich lösche den arp-Eintrag sunhb65277.scidom.de (10.35.23.96) in der Tabelle auf dem pingenden host. Dann pinge ich. Jetzt muß der pingende host erst eine arp-Anfrage per Ethernetbroadcast machen. Erstaunlicherweise antwortet eth0 und sagt ihre MAC (70:10:6F:47:0C:44) ist der IP 10.35.23.96 zugeordnet. Wieso antwortet eth0 für eine IP für die sie eigentlich nicht "zuständig" ist ? pc60181:~ # tcpdump -v -e ether host 70:10:6F:47:0C:44 or 70:10:6F:47:0C:45 tcpdump: WARNING: eth0: no IPv4 address assigned tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 14:32:39.545300 70:10:6f:47:0c:44 (oui Unknown) > 54:04:a6:94:f4:93 (oui Unknown), ethertype ARP (0x0806), length 60: arp reply sunhb65277.scidom.de is-at 70:10:6f:47:0c:44 (oui Unknown) Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen, Renate Schlusen (komm.) Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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

----- On Mar 24, 2016, at 2:53 PM, Werner Flamme werner.flamme@ufz.de wrote:

cat /proc/sys/net/ipv4/conf/all/rp_filter

Wenn da eine 0 steht, schreibe mal eine 1 rein. Eine 0 braucht man, wenn es mulihomed hosts sind, das ist bei Deiner Konfiguration offenbar nicht der Fall.

Hallo Werner, das hat auf mein Problem keinen Einfluss. Ich habe den Parameter geändert, gleiches Verhalten. Der Parameter wird hier ganz gut erklärt: http://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filterin... Er sagt aus, ob ein Paket bei einem Router auf der eingehenden Netzwerkkarte auch von dieser beantwortet wird. Ist er gesetzt, kommt die Antwort auch aus diesem Interface, wenn das Ziel von dieser Schnittstelle auch erreichbar ist. Da das Ziel, der pingenden host, ja erreichbar ist, ist das Setzen dieses Parameters für mein Problem unerheblich. Auch wenn aus meiner Sicht die "falsche" Netzwerkkarte antwortet, so ist ja das Ziel von diesem Interface erreichbar. Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen, Renate Schlusen (komm.) Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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

On Thu, 24 Mar 2016 15:02:28 +0100 Joerg Thuemmler wrote:

...

Wer Visionen hat soll zum Hausarzt gehen Helmut Schmidt

Der Spruch wird durch häufiges Zitieren nicht besser. Ohne die Vision von Linux würdest Du mit M$ arbeiten dürfen...

...

----- On Mar 23, 2016, at 5:16 PM, Stephan von Krawczynski skraw@ithnet.com wrote:

...

Deine Interfaces liegen im selben Class-C und haben dieselben Broadcasts/Netmasks. Es ist logisch dass auf beiden Interfaces beide IPs beantwortet werden. Das Setup ist nicht wirklich sinnvoll...

Das ist hier nicht die Frage.

...

On Wed, 23 Mar 2016 16:37:58 +0100 (CET) "Lentes, Bernd" wrote:

...

Hallo ML,

ich habe hier ein sehr merkwürdiges Netzwerkproblem. 2 hosts im gleichen Subnetz (geswitcht). Host A hat zwei Interfaces:

sunhb65278:~ # ifconfig eth0 Link encap:Ethernet HWaddr 70:10:6F:47:0C:44 inet addr:10.35.23.97 Bcast:10.35.23.255 Mask:255.255.255.0 inet6 addr: fe80::7210:6fff:fe47:c44/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:74211 errors:0 dropped:8057 overruns:0 frame:0 TX packets:369 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6767963 (6.4 Mb) TX bytes:40643 (39.6 Kb) Interrupt:16

eth1 Link encap:Ethernet HWaddr 70:10:6F:47:0C:45 inet addr:10.35.23.96 Bcast:10.35.23.255 Mask:255.255.255.0 inet6 addr: fe80::7210:6fff:fe47:c45/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:7668 errors:0 dropped:1130 overruns:0 frame:0 TX packets:47 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:702610 (686.1 Kb) TX bytes:3979 (3.8 Kb) Interrupt:17

Host B hat ein Interface:

pc60181:~ # ifconfig br0 Link encap:Ethernet HWaddr 54:04:A6:94:F4:93 inet addr:10.35.23.36 Bcast:10.35.23.255 Mask:255.255.255.0 inet6 addr: fe80::5604:a6ff:fe94:f493/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:918057155 errors:0 dropped:16024538 overruns:0 frame:0 TX packets:594965822 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:219547010052 (209376.3 Mb) TX bytes:14869161358944 (14180337.2 Mb)

An host A habe ich das Netzwerkkabel von eth1 gezogen. ethtool bestätigt das:

sunhb65278:~ # ethtool eth1 Settings for eth1:

...

Link detected: no

sunhb65278:~ #

eth0 ist verbunden:

sunhb65278:~ # ethtool eth0 Settings for eth0: ... Link detected: yes

Ich kann von host B BEIDE IP's von Host A anpingen:

pc60181:~ # ping 10.35.23.97 PING 10.35.23.97 (10.35.23.97) 56(84) bytes of data. 64 bytes from 10.35.23.97: icmp_seq=1 ttl=64 time=3.68 ms 64 bytes from 10.35.23.97: icmp_seq=2 ttl=64 time=0.173 ms 64 bytes from 10.35.23.97: icmp_seq=3 ttl=64 time=0.157 ms

pc60181:~ # ping 10.35.23.96 PING 10.35.23.96 (10.35.23.96) 56(84) bytes of data. 64 bytes from 10.35.23.96: icmp_seq=1 ttl=64 time=6.99 ms 64 bytes from 10.35.23.96: icmp_seq=2 ttl=64 time=0.150 ms 64 bytes from 10.35.23.96: icmp_seq=3 ttl=64 time=0.155 ms

Das versteh ich ja schon nicht. Wieso antwortet 10.35.23.96, obwohl das dazugehörige Netzwerkkabel von eth1 abgezogen ist ? Und wenn ich dann arp -a mache, falle ich ganz aus den Wolken:

pc60181:~ # arp -a

sunhb65278.scidom.de (10.35.23.97) at 70:10:6f:47:0c:44 [ether] on br0 sunhb65277.scidom.de (10.35.23.96) at 70:10:6f:47:0c:44 [ether] on br0

Wieso antwortet Host A auf die pings von host B auf die 10.35.23.96, und wieso gibt er noch als Antwort die MAC von eth0 und nicht von eth1 ? Wieso fühlt sich quasi eth0 für eth1 zuständig ?

Wenn die arp-Tabelle leer ist und ich neu pinge gleiches Spiel. arp -a wieder gleiche Ausgabe. Wenn die Tabelle leer ist und host B die 10.35.23.96 pingt, fragt doch arp "Wer hat IP 10.35.23.96 und welche MAC ist damit verbunden ?" Wieso antwortet da die 10.35.23.97 ? Selbst wenn jetzt in einem switch die MAC 70:10:6F:47:0C:45 noch dem port von eth0 zugeordnet ist, müsste doch Host A sagen, dafür ist eth0 nicht zuständig und das Paket wird ignoriert.

OS ist auf beiden SLES 11 SP4 64bit.

Ich versteh's nicht. Das Kabel zu eth1 ist gezogen. Ein anderer host im gleichen Subnetz will die IP von eth1 anpingen. Ich lösche den arp-Eintrag sunhb65277.scidom.de (10.35.23.96) in der Tabelle auf dem pingenden host. Dann pinge ich. Jetzt muß der pingende host erst eine arp-Anfrage per Ethernetbroadcast machen. Erstaunlicherweise antwortet eth0 und sagt ihre MAC (70:10:6F:47:0C:44) ist der IP 10.35.23.96 zugeordnet. Wieso antwortet eth0 für eine IP für die sie eigentlich nicht "zuständig" ist ?

pc60181:~ # tcpdump -v -e ether host 70:10:6F:47:0C:44 or 70:10:6F:47:0C:45 tcpdump: WARNING: eth0: no IPv4 address assigned tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 14:32:39.545300 70:10:6f:47:0c:44 (oui Unknown) > 54:04:a6:94:f4:93 (oui Unknown), ethertype ARP (0x0806), length 60: arp reply sunhb65277.scidom.de is-at 70:10:6f:47:0c:44 (oui Unknown)

Bernd

Ich denke schon, dass der Host ja "weiß", dass er zwei IPs im gleichen Subnetz hat, d.h. für ihn ist ...97 eine legale Route zu ...96. Wenn er also "gefragt" wird, ob er ...96 kennt, sagt er nicht, dass er dafür nicht zuständig ist, sondern dass er ...96 kennt und leitet das Paket an ihn weiter. Wenn Du das nicht magst, musst Du evt. per FW verhindern.

Ich kann auch nicht begreifen, wozu eine solche Konfig gut sein könnte, allenfalls als NIC-Ausfallsicherung...

cu jth

Vielleicht bringt der OP Sprueche eines drogenabhaengigen gewesenen Bundeskanzlers weil er meine Antwort einfach nicht verstanden hat. Wenn diesen Kasten auf gleich welchem Interface ein Arp Request fuer eine der beiden IPs aus demselben Subnetz erreicht wird er egal auf welchem Interface darauf mit der jeweiligen MAC des Interfaces antworten, weil er beide IPs selbst hat. Dieses Verhalten ist so seit Kernel 2.6. Bei 2.4 war das anders. Da haette das vielleicht so reagiert wie der OP denkt. Aber das ist lange her. Genau diese Sache fuehrt gerne dazu dass bei Kisten mit mehreren Interfaces das tatsaechliche Paketrouting u.U. anders laeuft als man sich das gedacht hatte. Mit folgenden sysctls sollte das "alte" Handling hergestellt werden: net.ipv4.conf.all.arp_ignore=1 net.ipv4.conf.all.arp_announce=2 Das war jedenfalls der alte Tipp vor Jahren ... -- MfG, Stephan -- 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

On Fri, 25 Mar 2016 16:16:14 +0100 (CET) "Lentes, Bernd" wrote:

----- On Mar 24, 2016, at 9:29 PM, Stephan von Krawczynski skraw@ithnet.com wrote:

...

Vielleicht bringt der OP Sprueche eines drogenabhaengigen gewesenen Bundeskanzlers weil er meine Antwort einfach nicht verstanden hat. Wenn diesen Kasten auf gleich welchem Interface ein Arp Request fuer eine der beiden IPs aus demselben Subnetz erreicht wird er egal auf welchem Interface darauf mit der jeweiligen MAC des Interfaces antworten, weil er beide IPs selbst hat. Dieses Verhalten ist so seit Kernel 2.6. Bei 2.4 war das anders. Da haette das vielleicht so reagiert wie der OP denkt. Aber das ist lange her. Genau diese Sache fuehrt gerne dazu dass bei Kisten mit mehreren Interfaces das tatsaechliche Paketrouting u.U. anders laeuft als man sich das gedacht hatte. Mit folgenden sysctls sollte das "alte" Handling hergestellt werden:

net.ipv4.conf.all.arp_ignore=1 net.ipv4.conf.all.arp_announce=2

Das war jedenfalls der alte Tipp vor Jahren ...

Hallo,

lieber Sprüche eines "drogenabhängigen" Altbundeskanzlers mit Ecken und Kanten als die Visionen eines glattpolierten Politikers heutzutage ;-)

...

net.ipv4.conf.all.arp_ignore=1 net.ipv4.conf.all.arp_announce=2

Das war's. Danke. Und ja, ich hatte Deine erste Mail nicht verstanden. Erschien mir irgendwie seltsam, daß ein Netzwerkinterface so weit "mitdenken" kann, ohne daß ich da in linux einen Einfluß drauf habe :-).

Bernd

Das genau ist der Knackpunkt. Wenn Du so willst ist das Netzwerk ab 2.6 nicht mehr interface-based sondern host-based. Du kannst das mal testen und wirst feststellen, dass das nicht nur so ist wenn die Interfaces im gleichen Subnetz sind. Das passiert auch exakt gleich wenn es sich um voellig verschiedene Netze handelt. Und dann kann man sich schon mal wundern wie bestimmte Pakete eigentlich den Weg finden obwohl es vielleicht gar kein klassisches Routing gibt. -- MfG, Stephan -- 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

----- On Mar 24, 2016, at 3:02 PM, Joerg Thuemmler listen@vordruckleitverlag.de wrote:

...

Wer Visionen hat soll zum Hausarzt gehen Helmut Schmidt

Der Spruch wird durch häufiges Zitieren nicht besser. Ohne die Vision von Linux würdest Du mit M$ arbeiten dürfen...

Na ja. Wenn ich mir die e-Mail von Linus anschaue, mit der er sein Betriebssystem präsentiert hat, ist da von einer Vision wenig zu spüren: "I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones." "and it probably never will support anything other than AT-harddisks, as that’s all I have :-(." http://www.thelinuxdaily.com/2010/04/the-first-linux-announcement-from-linus... Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen, Renate Schlusen (komm.) Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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