[Linux/Debian] Bindung IP phys. Interfac

Malte_4b1c84 · 9. November 2019 um 16:27

Hallo,

ich habe gerade unter einem

Linux test2 2.6.16.16-he-xeon-4g-fai #1 SMP Thu May 18 16:25:33 CEST 2006 i686 GNU/Linux

folgendes seltsame Phänomen erlebt:

test2:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:10:smiley:C:1C:F0:EC 
 inet addr:192.168.72.102 Bcast:192.168.73.255 Mask:255.255.254.0
 UP BROADCAST **RUNNING** MULTICAST MTU:1500 Metric:1
 RX packets:369134 errors:0 dropped:0 overruns:0 frame:0
 TX packets:12411 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000 
 RX bytes:27098732 (25.8 MiB) TX bytes:1086040 (1.0 MiB)
 Interrupt:5

test2:~# ping 192.168.72.102
PING 192.168.72.102 (192.168.72.102) 56(84) bytes of data.
64 bytes from 192.168.72.102: icmp\_seq=1 ttl=64 time=0.087 ms
64 bytes from 192.168.72.102: icmp\_seq=2 ttl=64 time=0.038 ms

--- 192.168.72.102 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.038/0.062/0.087/0.025 ms

**test2:~# ifconfig eth0 down**

test2:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:10:smiley:C:1C:F0:EC 
 inet addr:192.168.72.102 Bcast:192.168.73.255 Mask:255.255.254.0
 BROADCAST MULTICAST MTU:1500 Metric:1
 RX packets:369160 errors:0 dropped:0 overruns:0 frame:0
 TX packets:12411 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000 
 RX bytes:27100292 (25.8 MiB) TX bytes:1086040 (1.0 MiB)
 Interrupt:5 

test2:~# ping 192.168.72.102
PING 192.168.72.102 (192.168.72.102) 56(84) bytes of data.
64 bytes from 192.168.72.102: icmp\_seq=1 ttl=64 time=0.074 ms
64 bytes from 192.168.72.102: icmp\_seq=2 ttl=64 time=0.043 ms

--- 192.168.72.102 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.043/0.058/0.074/0.017 ms

Von außen ergibt sich das ebenso, die Maschine antwortet also auf ARP, ping etc. an eine IP-Adresse über ein Interface, auf dem diese IP gar nicht konfiguriert ist, zudem ist das Interface, zu dem die IP gehört - und damit nach meinem Verständnis - auch die IP selbst „down“.

FreeBSD verhält sich nicht so, sondern wie erwartet (Interface down = IP weg).

Der verwendete Kernel stammt aus einer fai-debian-Installation, und ist - so wie mir gesagt wurde - an Besonderheiten nur mit PXE-Boot-Fähigkeit und dem no ARP-Patch ausgestattet (no ARP wird aber auf der fraglichen Maschine nicht benutzt).

Deshalb die Fragen:

Ist das normal?
Ist das Linux-typisch?
Ist das Debian-typisch?
Ist das RFC-konform?
Warum würde man sowas wollen?
Wie kann man das abstellen?

Gruß,

Malte

Schorsch_de7743 · 9. November 2019 um 16:28

Von außen ergibt sich das ebenso, die Maschine antwortet also
auf ARP, ping etc. an eine IP-Adresse über ein Interface, auf
dem diese IP gar nicht konfiguriert ist, zudem ist das
Interface, zu dem die IP gehört - und damit nach meinem
Verständnis - auch die IP selbst „down“.

Ebenfalls unter 2.6.16 machen meine Rechner das so nicht. Zwar lässt sich die eigene Adresse auch nach ifconfig eth0 down noch anpingen, von aussen aber ist das Interface nicht mehr zu erreichbar.

Gruss
Schorsch

Moritz_fe1b4f · 9. November 2019 um 16:28

Hallo,

Linux test2 2.6.16.16-he-xeon-4g-fai #1 SMP Thu May 18
16:25:33 CEST 2006 i686 GNU/Linux

hier Linux $hostname 2.6.18.1 #4 Thu Oct 19 19:12:19 BST 2006 i686 GNU/Linux

> **test2:~# ifconfig eth0 down**  
>   
> test2:~# ifconfig eth0  
> eth0 Link encap:Ethernet HWaddr 00:10:smiley:C:1C:F0:EC  
> inet addr:192.168.72.102 Bcast:192.168.73.255   
> Mask:255.255.254.0  
> BROADCAST MULTICAST MTU:1500 Metric:1  
> RX packets:369160 errors:0 dropped:0 overruns:0  
> frame:0  
> TX packets:12411 errors:0 dropped:0 overruns:0  
> carrier:0  
> collisions:0 txqueuelen:1000  
> RX bytes:27100292 (25.8 MiB) TX bytes:1086040 (1.0  
> MiB)  
> Interrupt:5  
>   
> test2:~# ping 192.168.72.102  
> PING 192.168.72.102 (192.168.72.102) 56(84) bytes of data.  
> 64 bytes from 192.168.72.102: icmp\_seq=1 ttl=64 time=0.074 ms  
> 64 bytes from 192.168.72.102: icmp\_seq=2 ttl=64 time=0.043 ms

Von außen ergibt sich das ebenso, die Maschine antwortet also
auf ARP, ping etc. an eine IP-Adresse über ein Interface, auf
dem diese IP gar nicht konfiguriert ist, zudem ist das
Interface, zu dem die IP gehört - und damit nach meinem
Verständnis - auch die IP selbst „down“.

Ich verstehe das genauso, mit ein bisschen älteren Kerneln hatte ich das unter Debian (Sarge+backports) auch so beobachtet wie es sein sollte, d.h. Interface down => keine Antwort mehr.

Mit dem oben zitierten neuen Kernel kommt es bei mir auch vor, dass sich Interfaces nicht abschalten lassen (anpingen habe ich noch nicht probiert, und will gerade meine Verbindungen auch nicht killen).

Deshalb die Fragen:

Ist das normal?

Eher nein.

Ist das Linux-typisch?

Nein

Ist das Debian-typisch?

Vielleicht.

Ist das RFC-konform?

Hm, gibts denn nen RFC, der das beschreibt?

Warum würde man sowas wollen?

Weil man dunc-bank unterstützt? (http://dunc-bank.zoy.org/) *SCNR*

Wie kann man das abstellen?

Keine Ahnung. Hast du mal die Bugreports durchgeschaut, ob da was passendes dabei ist?

Grüße,
Moritz

Sebastian · 9. November 2019 um 16:28

Hallo,

Ich verstehe das genauso, mit ein bisschen älteren Kerneln
hatte ich das unter Debian (Sarge+backports) auch so
beobachtet wie es sein sollte, d.h. Interface down => keine
Antwort mehr.

Hmm …

root@radioactive:/home/niehaus# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 08:00:20:A2:2A:smiley:3
 inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
 inet6 addr: fe80::a00:20ff:fea2:2ad3/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:392270 errors:0 dropped:0 overruns:0 frame:0
 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:42414287 (40.4 MiB) TX bytes:1044 (1.0 KiB)
 Interrupt:160 Base address:0xa800

root@radioactive:/home/niehaus# ifconfig eth1 down
root@radioactive:/home/niehaus# ping -c 1 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp\_seq=1 ttl=64 time=0.461 ms

--- 192.168.2.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.461/0.461/0.461/0.000 ms
root@radioactive:/home/niehaus# ifdown eth1
root@radioactive:/home/niehaus# ping -c 1 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp\_seq=1 ttl=64 time=0.492 ms

--- 192.168.2.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.492/0.492/0.492/0.000 ms
root@radioactive:/home/niehaus# 
root@radioactive:/home/niehaus# uname -a
Linux radioactive 2.6.8-3-sparc64 #1 Thu Sep 7 01:58:23 UTC 2006 sparc64 GNU/Linux

*Grübel*

Malte_4b1c84 · 9. November 2019 um 16:28

Nachtrag: ping und arp Antworten

Von außen ergibt sich das ebenso, die Maschine antwortet also
auf ARP, ping etc. an eine IP-Adresse über ein Interface, auf
dem diese IP gar nicht konfiguriert ist, zudem ist das
Interface, zu dem die IP gehört - und damit nach meinem
Verständnis - auch die IP selbst „down“.

Ebenfalls unter 2.6.16 machen meine Rechner das so nicht. Zwar
lässt sich die eigene Adresse auch nach ifconfig eth0 down
noch anpingen, von aussen aber ist das Interface nicht mehr zu
erreichbar.

Das mit dem Ping war wohl zum Teil bedingt durch ein etwas schmutziges Setup meinerseits und eigenwillige defaults auf den beteiligten Switches, wie ich mittlerweile herausfinden konnte.

Es bleibt aber dabei, dass das Interface auf fremde Namen hört:

test2:~# tcpdump -ent -i eth1 arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
00:11:6b:30:2f:b8 \> 00:11:6b:31:75:c7, ethertype IPv4 (0x0800), length 98: IP 192.168.0.3 \> 192.168.0.2: icmp 64: echo request seq 1
00:11:6b:31:75:c7 \> 00:11:6b:30:2f:b8, ethertype IPv4 (0x0800), length 98: IP 192.168.0.2 \> 192.168.0.3: icmp 64: echo reply seq 1
00:11:6b:30:2f:b8 \> 00:11:6b:31:75:c7, ethertype IPv4 (0x0800), length 98: IP 192.168.0.3 \> 192.168.0.2: icmp 64: echo request seq 2
00:11:6b:31:75:c7 \> 00:11:6b:30:2f:b8, ethertype IPv4 (0x0800), length 98: IP 192.168.0.2 \> 192.168.0.3: icmp 64: echo reply seq 2

00:11:6b:31:75:c7 \> 00:11:6b:30:2f:b8, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.3 tell 192.168.0.2
00:11:6b:30:2f:b8 \> 00:11:6b:31:75:c7, ethertype ARP (0x0806), length 60: arp reply 192.168.0.3 is-at 00:11:6b:30:2f:b8

Bis hier alles wunderbar.

00:11:6b:30:2f:b8 \> ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.72.102 tell 192.168.72.100
00:11:6b:31:75:c7 \> 00:11:6b:30:2f:b8, ethertype ARP (0x0806), length 42: arp reply 192.168.72.102 is-at 00:11:6b:31:75:c7

Hier sollte er schon nicht mehr drauf antworten, die ARP reply schon seltsam.
_{NB: Die Source-Adresse ist die 72.100, weil ich die Maschine auf die Schnelle nicht anders dazu bewegen konnte, den ARP Request über ihr Interface in diesem Segment rauszuschubsen. Dafür hat vorher das schmutzige Setup in Verbindung mit proxy ARP gesorgt.}

00:11:6b:30:2f:b8 \> 00:11:6b:31:75:c7, ethertype IPv4 (0x0800), length 98: IP 192.168.72.100 \> 192.168.72.102: icmp 64: echo request seq 1
00:11:6b:31:75:c7 \> 00:13:5f:19:3c:00, ethertype IPv4 (0x0800), length 98: IP 192.168.72.102 \> 192.168.72.100: icmp 64: echo reply seq 1
00:11:6b:30:2f:b8 \> 00:11:6b:31:75:c7, ethertype IPv4 (0x0800), length 98: IP 192.168.72.100 \> 192.168.72.102: icmp 64: echo request seq 2
00:11:6b:31:75:c7 \> 00:13:5f:19:3c:00, ethertype IPv4 (0x0800), length 98: IP 192.168.72.102 \> 192.168.72.100: icmp 64: echo reply seq 2

Tja, und das sind die echo replies, die auch nicht sein dürften.

Weitere Ideen?

Gruß,

Malte

Schorsch_de7743 · 9. November 2019 um 16:28

Tja, und das sind die echo replies, die auch nicht sein
dürften.

Ich bekomme auf

edv-notenbuch:~# ping -c 1 192.168.0.222
PING 192.168.0.222 (192.168.0.222) 56(84) bytes of data.
From 192.168.0.100 icmp\_seq=1 Destination Host Unreachable

--- 192.168.0.222 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

die Antwort

edv-notenbuch:~# tcpdump -ent -i eth0 arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:03:0d:39:fd:8f \> ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.222 tell 192.168.0.100
00:03:0d:39:fd:8f \> ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.222 tell 192.168.0.100
00:03:0d:39:fd:8f \> ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.222 tell 192.168.0.100
[...]

Deine Ergebnisse sind in meiner Umgebung also nicht nachvollziehbar.
So ins blaue geschossen, würde ich zunächst behaupten, dass einer
deiner Switches aus einem arp-cache heraus geantwortet hat. Aber das
würde weder die MAC-Adresse in der Antwort auf die arp-Anfrage noch
die Antwort auf den ping erklären.

Kannst du die Switches testweise mal gegen irgendwelche Billigdinger
austauschen? Dass das was ändert, kann ich mir nicht vorstellen, es
wäre aber immerhin eine (eigentlich un-)mögliche Fehlerquelle
ausgeschlossen.

Eine andere Frage, aufgrund meiner geringen Linux-Kenntnisse weiss
ich aber nicht, ob sie von Belang ist: Bekommst du nach einem
/etc/init.d/networking stop die gleichen Ergebnisse?

Gruss
Schorsch

Der_Frank_176821 · 9. November 2019 um 16:33

Hallo,

Hi,

[ping trotz shutdown des if]
Von außen ergibt sich das ebenso, die Maschine antwortet also
auf ARP, ping etc. an eine IP-Adresse über ein Interface, auf
dem diese IP gar nicht konfiguriert ist, zudem ist das
Interface, zu dem die IP gehört - und damit nach meinem
Verständnis - auch die IP selbst „down“.

Ist das normal?

Ja. Manchmal. Also, bis vor kurzem (ungefaehr 10min vor Deinem Beitrag) dachte ich noch, ich haette das kapiert: die IP# gehoert dem IP stack, nicht dem interface. Das Runterfahren des if loescht nur alle Routen des if aus der routing table. Wenn nichts weiter ARP blockiert antwortet der IP stack brav weiter, dass er unter der IP# erreichbar ist…

Jetzt habe ich das soeben nochmal auf meinem heimischen Laptop probiert und es geht einfach nicht mehr. Das ist ein 2.6.16. Ich dachte, mein Rechner auf Arbeit haette den gleichen Kernel. Dort habe ich das Phaenomen definitiv schon beobachtet (und eigentlich auch „verstanden“). Ausserdem laesst mich ein Blick auf

 $ /sbin/ip -s addr

gerade an meiner Theorie, dass IP#s dem IP stack gehoerten, zweifeln. Ich glaube, ich muss da doch nochmal etwas dran rumknobeln, vielleicht meld ich mich nochmal. Du bist auf jeden Fall nicht alleine.

Gruss vom Frank.

Malte_4b1c84 · 9. November 2019 um 16:33

Hi,

[ping trotz shutdown des if]

laesst mich ein Blick auf

$ /sbin/ip -s addr

gerade an meiner Theorie, dass IP#s dem IP stack gehoerten,
zweifeln. Ich glaube, ich muss da doch nochmal etwas dran
rumknobeln, vielleicht meld ich mich nochmal. Du bist auf
jeden Fall nicht alleine.

Wäre schon von Dir noch was zu hören. Bei uns in der Firma war nur die vage Erinnerung herauszukitzeln, $jemand habe da mal auf irgendeiner Liste was gelesen, $irgendwer habe sich genau über dieses Verhalten gestritten, inwiefern das nun so „by design“ gewünscht sei oder eben nicht. Die unterschiedliche Reproduzierbarkeit verwirrt mich allerdings noch zusätzlich, und im Netz hab ich auf die Schnelle nichts gefunden, was mich wirklich erhellt, nur mehr oder minder diffuse Beschreibungen dieses Phänomens:

http://www.ams-ix.net/technical/config_guide/linux_c…
http://lkml.org/lkml/2003/7/27/181

Ich würde es aber gerne *verstehen*, mir schwant nämlich, dass dieses Phänomen in etwas extravaganteren Netzwerkszenarien durchaus Probleme bereiten könnte.

Gruß,

Malte

Schorsch_de7743 · 9. November 2019 um 16:34

Ich dachte, mein Rechner auf Arbeit haette den gleichen
Kernel.

Auf Arbeit habe ich jetzt auch mal probiert, und Maltes Ergebnisse reproduzieren können:

segmentor:/home/admin# uname -a
Linux segmentor 2.6.8-sk98lin-napi-off #1 SMP Thu Jun 1 12:42:45 GMT-1 2006 i686 GNU/Linux
segmentor:/home/admin# ifconfig eth7
eth7 Protokoll:Ethernet Hardware Adresse 00:10:F3:0A:38:0B
 inet Adresse:192.168.170.254 Bcast:192.168.170.255 Maske:255.255.255.0
 inet6 Adresse: fe80::210:f3ff:fe0a:380b/64 Gültigkeitsbereich:Verbindung
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
 Kollisionen:0 Sendewarteschlangenlänge:1000
 RX bytes:0 (0.0 b) TX bytes:128 (128.0 b)
 Interrupt:177 Speicher:d0428000-0

Anderer Rechner:

C:\temp\>ping 192.168.170.254 -n 1

Ping wird ausgeführt für 192.168.170.254 mit 32 Bytes Daten:

Antwort von 192.168.170.254: Bytes=32 Zeit

Wieder zurück:


    
    segmentor:/home/admin# ifconfig eth7 down
    segmentor:/home/admin# ifconfig eth7
    eth7 Protokoll:Ethernet Hardware Adresse 00:10:F3:0A:38:0B
     inet Adresse:192.168.170.254 Bcast:192.168.170.255 Maske:255.255.255.0
     BROADCAST MULTICAST MTU:1500 Metric:1
     RX packets:0 errors:0 dropped:0 overruns:0 frame:0
     TX packets:4294967291 errors:0 dropped:0 overruns:0 carrier:0
     Kollisionen:0 Sendewarteschlangenlänge:1000
     RX bytes:0 (0.0 b) TX bytes:4294966898 (3.9 GiB)
     Interrupt:177 Speicher:d0428000-0



Und wieder auf den anderen Rechner:


    
    C:\temp\>ping 192.168.170.254 -n 1
    
    Ping wird ausgeführt für 192.168.170.254 mit 32 Bytes Daten:
    
    Antwort von 192.168.170.254: Bytes=32 Zeit
    
    Gruss
    Schorsch

Schorsch_de7743 · 9. November 2019 um 16:35

Nur so ne Idee
Kann es sein, dass dieses Verhalten abhängig ist von der Zahl der konfigurierten Interfaces? Ich kann’s im Moment nicht verifizieren, aber die Vermutung drängt sich auf (man kann zumindest auf diesen absurden Gedanken kommen). In dem Fall sollte aber ein /etc/init.d/networking stop m. E. eine Antwort auf Anfragen auf beliebige Interfaces unterbinden.

Ich werd’s morgen mal testen. Falls mir keiner zuvor kommt.

Gruss
Schorsch

Der_Frank_176821 · 9. November 2019 um 16:35

Ich dachte, mein Rechner auf Arbeit haette den gleichen
Kernel.

Auf Arbeit habe ich jetzt auch mal probiert, und Maltes
Ergebnisse reproduzieren können:

Na, dann ist’s doch offensichtlich, woran es liegt: Rechner auf Arbeit. Malte, kannst Du das bestaetigen? (FAI braucht man eigentlich nur auf Arbeit.)

Gruss vom Frank.

Schorsch_de7743 · 9. November 2019 um 16:35

Ich dachte, mein Rechner auf Arbeit haette den gleichen
Kernel.

Auf Arbeit habe ich jetzt auch mal probiert, und Maltes
Ergebnisse reproduzieren können:

Na, dann ist’s doch offensichtlich, woran es liegt: Rechner
auf Arbeit. Malte, kannst Du das bestaetigen? (FAI braucht
man eigentlich nur auf Arbeit.)

Es wäre immerhin nicht ganz schlecht, wenn das Problem sich reproduzierbar darstellen liesse. Dass Kernel 2.6.16 und 2.6.8 hier eine grosse Rolle spielen, halte ich für sehr unwahrscheinlich. Obwohl, wenn ich die Datenlage betrachte - Nein.

Gruss
Schorsch

Malte_4b1c84 · 9. November 2019 um 16:36

Ich dachte, mein Rechner auf Arbeit haette den gleichen
Kernel.

Auf Arbeit habe ich jetzt auch mal probiert, und Maltes
Ergebnisse reproduzieren können:

Na, dann ist’s doch offensichtlich, woran es liegt: Rechner
auf Arbeit. Malte, kannst Du das bestaetigen? (FAI braucht
man eigentlich nur auf Arbeit.)

ACK. Ich werde das an die Kollegen so weitergeben

Mann, irgendwie ist das ein sehr unbefriedigendes Phänomen. So undeterministisch. Mittlerweile vermute ich sogar unseren ferngesteuerten Bürohelikopter als Ursache.

Gruß,

Malte