On Thu, 24 Mar 2016 15:02:28 +0100 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...
----- 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" <bernd.lentes@helmholtz-muenchen.de> 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