Falsche IP Adresse im Report ?

[rumknapser]

Hallo,

Ich habe einen Report erstellt.
(Zum Report kommt Ihr via Control Panel => Info Center => Report. Wenn ein Report erstellt ist, kann man auf das Ergebnis klicken, dann kommt diese Art Report zum Vorschein.)



Gucke ich mir diesen an, kann ich auf die Links im Report klicken und irgendetwas müsste geschehen.

Tut es aber nicht, weil die "interne" IP Adresse, welche der Browser, bzw. die DS ansteuern möchte nicht existiert.
Meine Netzwerkeinstellungen sehen so aus:

Wireless gibts nicht.

Kann mir jmd. erklären, aus welchem Grund die Dateien, auf die der Report zugreifen möchte, mit dieser IP Adresse verknotet werden?

 

[stefan_lx]

also wenn ich diese Adresse richtig erkenne dann ist das eine APIPA-Adresse, die die Gerätschaften selber vergeben, wenn sie weder DHCP noch feste IP haben ...

Momentan fällt mir nur auf der Konsole ifconfig ein, um zu schauen welche Netzwerkkarte das ist ... ich vermute, dass entweder 1 oder 4 dahintersteckt, weil deine Link-Aggregation gar nicht funktioniert...

Stefan

 

[rumknapser]

Oh ja,
danke, habe ich nun nachgereicht

eth1 und eth2. eth4 gibts nicht?! Spannend, oder? (Jedenfalls für mich)

bond0     Link encap:Ethernet  HWaddr xxx
          inet addr:192.168.168.111  Bcast:192.168.168.255  Mask:255.255.255.0
          inet6 addr: xxx/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:9000  Metric:1
          RX packets:617167782 errors:0 dropped:0 overruns:0 frame:0
          TX packets:663869488 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1094185757681 (1019.0 GiB)  TX bytes:848417745549 (790.1 GiB)

eth0      Link encap:Ethernet  HWaddr xxx
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:616252162 errors:0 dropped:0 overruns:0 frame:0
          TX packets:663823765 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1093987248697 (1018.8 GiB)  TX bytes:848412075897 (790.1 GiB)

eth1      Link encap:Ethernet  HWaddr xxx
          inet addr:169.254.82.203  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST NOTRAILERS MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth2      Link encap:Ethernet  HWaddr xxx
          inet addr:169.254.251.71  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST NOTRAILERS MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth3      Link encap:Ethernet  HWaddr xxx
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:915620 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45723 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:198508984 (189.3 MiB)  TX bytes:5669652 (5.4 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:6598071 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6598071 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:958553251 (914.1 MiB)  TX bytes:958553251 (914.1 MiB)

 

[stefan_lx]

dass es eth4 nicht gibt ist ok, die Zählung fängt mit eth0 an..
also eth1 (=LAN2) hat die IP aus dem Bericht... da war meine Vermutung mit der Link-Aggregation falsch, ...

Allerdings verstehe ich nicht, wieso die im Bericht genommen wird... bei mir wird im Bericht immer die "echte" IP genommen..

Stefan

 

[fbl1]

So wie es aussieht ist eth0 und eth3 für Link-Aggregation was aber fehlerhaft ist. Darum denke ich nimmt der Report die erste die Fehler frei ist und das ist die eth1.

 

[rumknapser]

hmmm Danke erstmal für Eure Antworten.

Heute Nachmittag ist hier ein Steckdosenstecker explodiert... Entsprechend wurde die betroffene Kiste zwar mit Totalausfall wegen Stromausfall bestraft, aber auch nach einem Neustart, quasi, verhält es sich wie vorher.

Ich habe jetzt auch einen Logausschnitt, der mir sagt, dass die IP Adressen -augenscheinlich- absichtlich vergeben werden.

Nur warum, ist nicht zu klären.

Kabeltechnisch sieht es so aus:

1 + 4 belegt, 2 + 3 kein Kabel.


Wo könnte ich denn noch nachgucken, weswegen diese IP Adressen vergeben werden ?

Und gehe ich richtig in der Annahme, das
LAN Port 1 = eth0
LAN Port 2 = eth1
LAN Port 3 = eth2
LAN Port 4 = eth3
ist ?

 

[stefan_lx]

diese Adressen werden automatisch vergeben, das ist so, sobald kein DHCP von der Netzwerkkarte "auffindbar" ist.
Hintergrund ist, dass sich auf diese Art und Weise PCs/Server/Geräte verbinden können, ohne dass man selber eine IP-Adresse eingeben muss oder DNS/DHCP konfigurieren muss. Das ist also ganz normales Verhalten, (Stichworte: APIPA, zeroconf)

Das mit den LAN-Ports siehst du richtig.

So wie fbl1, vermute ich auch einen Zusammenhang mit der Linkaggregation, funktioniert die jetzt oder hat die immer noch einen Fehler?

Stefan

 

[rumknapser]

So wie fbl1, vermute ich auch einen Zusammenhang mit der Linkaggregation, funktioniert die jetzt oder hat die immer noch einen Fehler?

Erst einmal, danke ob der reichhaltigen Informationen!

Die Lingaggregation habe ich testweise eingerichtet und beobachte das Verhalten in freier Wildbahn nun ein gefühltes halbes Jahr.

Ich verstehe nicht genau, was Du mit "immer noch einen Fehler" meinst, doch feststellen konnte ich ab dem Zeitpunkt zu dem ich die MTU auf 9000 gesetzt und die Linkaggregation eingerichtet habe, dass sich die Daten im Netzwerk zwar (subjektiv gefühlt) etwas schneller bewegen als vorher (Default MTU und nur eine Netzwerkkarte aktiv), es allerdings auch mehrere Fehler gibt, bzw. Abbrüche oder kurzzeitiges auflösen einer Verbindung. Von daher würde ich deine Frage mit 'Ja' beantworten.

Jedenfalls verstehe ich nun, warum eth1 und eth2 IP Adressen zugewiesen bekommen haben und eth0 und eth3 nicht. Die beiden letzten sind im bond0 Device vereint. Die beiden ersten dösen so vor sich hin und warten ... auf irgendetwas...

Meine Fragen sind jedenfalls geklärt und ich schliesse mal, dass ich mich an Synology wenden sollte, wenn es nun noch um eine "Änderung" der Tatsache geht, dass beim Klick auf einen Report-Link eine nicht verwendete IP Adresse verscriptet wird... Das werden die aber sicherlich beim nächsten Update in 2-3 Jahren schaffen Für mich nicht kritisch.

 

[fbl1]

So lange du denn Fehler bei deinem Bond0 hast wird immer die falsche ip verwendet. So wie ich das sehe kann dein Router kein Link aggregation oder du hast es nicht konfiguriert.
Macht wenig Sinn es dann zu verwenden. Es wird hier immer nur ein Eingang verwendet.

 

[stefan_lx]

in deinem zweiten Screenshot steht unten in rot "Failed to establish ... 802.3ad connection", und 802.3ad ist die Link-Aggregation... es wird also nur eine der beiden Karten genutzt... auf welche Hälfte der Frage antwortest du mit Ja?

Stefan

 

[rumknapser]

...Jedenfalls ist es nun so, dass, nachdem ich die Link-Aggregation deaktiviert habe, die Links in einem neuen Browserfenster mit der lokalen und korrekten URL geöffnet werden.
Soweit dazu
Um den Rest kümmer ich mich dann auch noch.
Danke.

 

[rumknapser]

Zum "Rest":
(Meine Idee/Hoffnung mit der LinkAggegation war nicht eine Ausfallsicherheit zu gewährleisten, sondern eher einen Kapazitätengewinn an Bandbreite zu erreichen...)

Also,
nach nunmehr längerer Beobachtungszeit bei ausgeschaltetem Bond0, bzw. ausgeschalteter Link Aggregation stelle ich keinen Geschwindigkeitsverlust oder sonstige Einbußen fest.
Im Gegenteil, der "defekte" oder "irgendwie -warum auch immer- nicht funktionierende Bond0" sorgte für spontane Netzwerkauffälle, die nun auf ein normales Minumum reduziert sind.

Normales Minimum?

Ab und an ist halt mal plötzlich das "Netzwerk" weg und die an der DS angemeldeten SMB User müssen sich spontan neu an den Shares anmelden, an denen sie noch vor 5 Minuten angemeldet waren und munter Daten kopiert haben.

Ab und an ist halt plötzlich mal ein nicht-mehr-enden-wollender SMB Prozess bei 99% CPU Load oder es gibt ca. 2345546 SMB Prozesse auf der DS und die DS lässt sich auch garnicht mehr sauber herunterfahren/rebooten.

Das erlebe ich allerdings schon -gefühlt- seit 20 Jahren, als ich mir noch irgendwelche Linux-Server zusammengeschraubt und Samba händisch installiert/konfiguriert hatte. Ergo ein normales Verhalten, wie schade/traurig/kritisch das auch immer im konkreten Moment ist. (Windows ist ja als Quelle nun auch nicht wirklich auszuschliessen...obwohl die besagten Punkte auch mit Macs zu beobachten sind.)


Da ich bei der Konfiguration eines Bond ja eigentlich nichts falsch machen kann, werde ich ihn in den nächsten Wochen wohl mal wieder aktivieren und gucken, wie er sich dann verhält.
Es ist ja inzwischen eine neue Firmware draussen und wer weiss, was noch alles so passiert ist, in der zwischenzeit