[Problem] FB7530: Erkennung von IP Adressen hinter 3rd party Router im Heimnetz

[FantasticPauly]

Ich betreibe in meinem Heimnetz noch einen 3rd party Router (Cisco), an dem ich 3 weitere IP-Subnetze konfiguriert habe. Diese Subnetze werden über den Cisco Router in das 192.168.178.0 Netz der FB7530 geroutet. Die FB7530 hat 3 statische Routeneinträge, die auf den Cisco Router zeigen. IP Routing und Adressierung der Geräte funktionieren problemlos.

Was mir störend auffällt, ist, dass die FB Geräte in den fremden Subnetzen sogar mit MAC Adressen (!) erkennt, diesen Geräten aber IP-Adressen aus dem 192.168.178.0 Netz zuordnet. Dummerweise sind dies z.T. IP-Adressen, die von anderen Geräten im 192.168.178.0 Netzwerk per DHCP bezogen wurden und somit in der Anzeige der FB doppelt erscheinen. Die Gateway-Adressen des Cisco Routers erscheinen alls 3 sogar mit der IP-Adresse 192.168.178.1 der FB.

Wie es aussieht, scheint das Problem nur in der Anzeige der FB7530 zu existieren (Aktuelle OS-Version 7.14 ist installiert). Hat jemand dieses Problem in ähnlicher Weise beobachtet? Gibt es einen Workaround dafür bzw. ist das evtl. ein bekannter Bug der FBs?

Als Layer 3 Router sollte die FB in der Lage sein, die fremden IP Adressen zu erkennen und korrekt anzuzeigen.

 

[eisbaerin]

Wie es aussieht, scheint das Problem nur in der Anzeige der FB7530 zu existieren

Das Problem der falschen Anzeige gibt es schon seit ca. 10 Jahren (FB7170).
Deshalb nutze ich diese Anzeige der FB fast nie.

 

[Axel37]

also habe schon seit 15J so eine Konfiguration mit verschiedenen Routern und nie solche Probs gehabt.
Allerdings haben meine SubNetze eigene DHCP-Server im Router aktiviert und natürlich eigene IP-Bereiche.
Generell sind auch alle Ports erstmal geschlossen

 

[FantasticPauly]

Allerdings haben meine SubNetze eigene DHCP-Server im Router aktiviert und natürlich eigene IP-Bereiche.

So ist es bei mir auch. Wüsste auch nicht wie es anders funktionieren sollte. Die FB macht nur den DHCP Server für das 192.168.178.0 Netz.
Heisst dann aber, bei Dir funktioniert die Anzeige? Würde mich interessieren.

Das Problem der falschen Anzeige gibt es schon seit ca. 10 Jahren (FB7170).

Ok, das Problem ist also bekannt und offenbar nur kosmetischer Natur. Schade, dass AVM es dann in 10 Jahren nicht geschafft, das zu fixen.

 

[eisbaerin]

offenbar nur kosmetischer Natur

Ja, damals vor 10 Jahren schon.
Aber jetzt in Zeiten von "Mesh" bin ich mir nicht sicher, welche Informationen AVM dort benutzt.
IMO gibt es dort nicht umsonst so viele Fehler.
Deshalb hasse ich das "Mesh" so wie der Teufel das Weihwasser.
Schließlich ging es 'zig Jahre auch ohne "Mesh".

Schade, dass AVM es dann in 10 Jahren nicht geschafft, das zu fixen.

Richtig!
Und ich bin immer noch der Meinung, solange sie das nicht schaffen, brauchen sie mit "Mesh" gar nicht erst anzufangen.
Das ist dann IMO der 2. Schritt vor dem 1.

 

[FantasticPauly]

Mesh nutze ich auch nicht. FB ist bei mir nur wegen DECT und als DSL Modem/Router im Einsatz. Für alles andere, speziell WLAN, nutze ich andere Hardware, da ich dort auch die Einstellungen granularer anpassen kann.

 

[eisbaerin]

Mesh nutze ich auch nicht

Hast du es dann auch abgeschaltet?
Ein Bild von deinen Fehlern wäre für die Diskussion nicht schlecht.

 

[FantasticPauly]

Jetzt auch mit Bild

Hier sieht man, dass alle Geräte eine IP Adresse im 192.168.178.0 Netz zugewiesen haben. DOOR-CAM und kodi-mc sind aber (und waren immer) Hosts im 30.30.30.0 Netz. Die IP-Adressen liegen im DHCP Range der Fritzbox (192.168.178.30 - 200) und es kam auch schon vor, dass DHCP Clients genau diese Adressen zugewiesen bekamen.

Hier sieht man, dass die Gateway Adressen auf dem Router jeweils mit der IP-Adresse der Fritzbox in der Übersicht erscheinen.

Die Geräte befinden sich hinter devolo PowerLAN Adaptern und sind dort z.T. in eigenen WLAN Netzen hinter dem Router verbunden. Die Fritzbox sieht die Geräte daher alle als LAN Geräte.

Wie schaltet man Mesh komplett ab? Ich finde dazu außer Master/Repeater Auswahl keine Einstellmöglichkeiten in der GUI der Fritzbox.

 

[eisbaerin]

Jetzt auch mit Bild

Sehr schön! Da kann man sich das doch gleich viel besser vorstellen.
Hätte IMO gleich in #1 gehört.
Unser Slogan hier:
1 Bild sagt mehr als 1000 Worte

(und waren immer)

Bist du dir da zu 100% sicher, daß die nie im Hauptnetz waren?
IMO merkt sich die FB den Hostnamen und verwendet den dann immer mit der gelernten MAC und auch mit falscher IP.

Ja, auch die FB hat die Sammelwut gepackt (oder ist es AVM?) und sammelt alles, was sie nur kann, egal ob sinnvoll oder nicht.
Wenn sie es dann wenigstens sinnvoll anwenden würde ...
Und auch sinnloses mal vergessen/löschen würde ...

 

[FantasticPauly]

Bist du dir da zu 100% sicher, daß die nie im Hauptnetz waren?

Definitiv. Ich hab die FB 7530 erst letzte Woche in Betrieb genommen, da war das Netzwerk schon so konfiguriert. Die Clients mit der falsch angezeigten IP-Adresse hat die Fritzbox also nie in Ihrem lokalen Netz gesehen.

Ich hatte vorher eine 7390, wo der DHCP Dienst auf der Fritzbox deaktiviert war und stattdessen auf einem Raspberry Pi lief. Da hatte ich die Probleme mit der Anzeige nicht oder nicht bemerkt. Wenn ich mich richtig erinner, hat die Fritzbox die Hosts korrekt mit den IP-Adressen aus den externen Netzen angezeigt. Ich möchte aber ungern den DHCP Dienst auf dem Raspberry Pi wieder in Betrieb nehmen, da es damit in letzter Zeit (andere) Probleme gab.

 

[eisbaerin]

Ich hab die FB 7530 erst letzte Woche in Betrieb genommen

Und dabei auch nicht die Konfiguration der 7390 übernommen?
Alles neu per Hand eingegeben?

 

[FantasticPauly]

Alles neu per Hand eingegeben?

Jepp, alles neu eingeben.
Ich hab jetzt mal ausproboert, die Fritzbox kurzfristig vom LAN zu trennen und alle "falschen EInträge" zu löschen. Nach dem Wiederverbinden werden nun einige Hosts mit den richtigen Adressen angezeigt, ein Host ist aktiv, zeigt aber gar keine IP-Adresse an und eine Gateway-Adresse wird wieder mit 192.168.178.1 angezeigt. Ganz toll... Sieht nicht unbedingt nach einem reproduzierbaren Verhalten aus.

Was ich immer noch relativ spannend finde, ist, dass die Fritzbox überhaupt die MAC-Adressen der Clients in den Fremdnetzten kennt. Nach meinem - veilleicht naivem - Verständnis von Layer 2 und Layer 3 dürften an der Fritzbox für die Clients außerhalb des eigenen Subnetzes doch max. die MAC Adresse des Gateways/Routers bekannt sein.

 

[eisbaerin]

dass die Fritzbox überhaupt die MAC-Adressen der Clients in den Fremdnetzten kennt.

Dann muß in den Ciscos was falsch eingestellt sein.
Wie heißen die genau? Wie ist die Konfiguration?

doch max. die MAC Adresse des Gateways/Routers bekannt sein.

Richtig!

 

[sf3978]

Was ich immer noch relativ spannend finde, ist, dass die Fritzbox überhaupt die MAC-Adressen der Clients in den Fremdnetzten kennt. Nach meinem - veilleicht naivem - Verständnis von Layer 2 und Layer 3 dürften an der Fritzbox für die Clients außerhalb des eigenen Subnetzes doch max. die MAC Adresse des Gateways/Routers bekannt sein.

Lass mal einen Client in diesem der FritzBox fremden Netz, einen "gratuitous arp reply" machen und schau mit einem geeigneten Client im Subnetz der FritzBox nach, ob man diesen arp reply dort sieht.

EDIT:

Befinden sich die Geräte aus dem fremden Netz evtl. auch im arp-/neighbor-cache der Geräte aus dem Subnetz der FritzBox?

 

[FantasticPauly]

Dann muß in den Ciscos was falsch eingestellt sein.
Wie heißen die genau? Wie ist die Konfiguration?

Cisco Device ist ein Catalyst 3560CX. Konfig ist ziemlich einfach gehalten (Ist halt nur für mein Heimnetz zum Testen); bis auf die DHCP, VLAN und Port -Einstellungen habe ich fast nichts gegenüber den Standardeinstellungen verändert:

Spoiler: Switch config

C3560CX#sh runn
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname switch
!
boot-start-marker
boot-end-marker
!
logging buffered 32768
enable secret 5 XXX
!
username admin privilege 15 secret 5 XXX
aaa new-model
!
aaa authentication login default local
!
aaa session-id common
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
system mtu routing 1500
!
no ip source-route
ip routing
no ip gratuitous-arps
no ip cef optimize neighbor resolution
ip dhcp excluded-address 10.10.10.1
ip dhcp excluded-address 20.20.20.1
ip dhcp excluded-address 30.30.30.1
!
ip dhcp pool Home
 import all
 network 10.10.10.0 255.255.255.0
 default-router 10.10.10.1
 dns-server 208.67.222.222 208.67.220.220
 lease 0 2
!
ip dhcp pool Guests
 import all
 network 20.20.20.0 255.255.255.0
 default-router 20.20.20.1
 dns-server 208.67.222.222 208.67.220.220
 lease 0 2
!
ip dhcp pool PhysSec
 import all
 network 30.30.30.0 255.255.255.0
 default-router 30.30.30.1
 dns-server 208.67.222.222 208.67.220.220
 lease 0 2
!
ip domain-name internal
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
device classifier
!
!interface GigabitEthernet0/1
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/2
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/3
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/4
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/5
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/6
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/7
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/8
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/9
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/10
 description Access-Point
 switchport trunk allowed vlan 1,10,20,30
 switchport mode trunk
!
interface GigabitEthernet0/11
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/12
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/13
 switchport mode access
 spanning-tree portfast edge
!
interface GigabitEthernet0/14
 description Uplink to LAN
 switchport trunk allowed vlan 1,10,20,30
 switchport mode trunk
!
interface GigabitEthernet0/15
!
interface GigabitEthernet0/16
!
interface Vlan1
 description LAN
 ip address dhcp
!
interface Vlan10
 description Home Network
 ip address 10.10.10.1 255.255.255.0
!
interface Vlan20
 description Guest Network
 ip address 20.20.20.1 255.255.255.0
!
interface Vlan30
 description PhysSec Network
 ip address 30.30.30.1 255.255.255.0
!
ip forward-protocol nd
!
ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip ssh authentication-retries 2
ip ssh source-interface Vlan1
ip ssh version 2
!
i
line con 0
line vty 0 4
 privilege level 15
 length 0
 transport input ssh
line vty 5 15
 privilege level 15
 transport input ssh
!
ntp update-calendar
ntp server 192.168.178.1
!
end

Beiträge zusammengefügt - HabNeFritzbox

Lass mal einen Client in diesem der FritzBox fremden Netz, einen "gratuitous arp reply" machen und schau mit einem geeigneten Client im Subnetz der FritzBox nach, ob man diesen arp reply dort sieht.

EDIT:

Befinden sich die Geräte aus dem fremden Netz evtl. auch im arp-/neighbor-cache der Geräte aus dem Subnetz der FritzBox?

Das mit dem gratouitous arp reply krieg ich hin, aber wie man das im LAN der Fritzbox sieht ist mir noch unklar. Ich könnte ein neues Gerät (RAspberry PI) in einem der Fremdnetze aufsetzen und schauen, ob dessen MAC/IP-Adresse irgendwann in der Übersicht der Fritzbox erscheint. Alle Geräte in den Fremdnetzen senden Ihre Daten mit VLAN Tag.

Dass die Geräte-Adressen sich im arp-/neighbor-cache der Geräte im LAN befinden, würde ich ausschließen, da sie von Anfang an, separiert waren. Die Abfrage des arp-cache auif Geräten im LAN zeigt auch keine der "falschen" IP-Adressen den MAC-Adressen aus den Fremdnetzen zugeordet an.

 

[sf3978]

..., aber wie man das im LAN der Fritzbox sieht ist mir noch unklar. Ich könnte ein neues Gerät (RAspberry PI) in ...

Wenn Du einen PI im LAN der FB hast, kannst Du das mit:

sudo tcpdump -c 50 -vvveni <Interface> arp

(Interface anpassen und ohne spitze Klammern) zeigen lassen.

BTW: Du könntest in einem der Fremdnetze, vom pi aus auch einen arping auf die IP-Adresse der FB machen. Z. B.:

sudo apt-get install iputils-arping
sudo arping -c 3 -I <Interface> 192.168.178.1

(Interface anpassen und ohne spitze Klammern).

 

[PeterPawn]

Hängt die fragliche FRITZ!Box da direkt an Port 14 und kriegt damit den ganzen Traffic inkl. VLAN-Tags für 1, 10, 20 und 30 ab oder ist da noch einmal ein (VLAN-fähiger) Switch dazwischen, der in Richtung FRITZ!Box die Tags entfernt?

Nach meiner Erfahrung kommen die FRITZ!Boxen nur sehr schlecht damit klar, wenn sie "tagged traffic" nach 802.1Q vorgesetzt bekommen und nur solchen ohne VLAN-Tags erwarten an ihren Switch-Ports. Da würde ich also mal versuchen, die Tags von den Paketen zu entfernen und schauen, ob sich an der Anzeige etwas bessert (die Funktion ist ja nicht beeinträchtigt, wie oben irgendwo steht ... wobei mich das auch ein wenig verwundert - werden da tatsächlich Pakete aus diesen Subnetzen inkl. Tags auch über die Box geroutet oder sind die nur mal eben sichtbar, weil das auf L2 verbunden ist?).

Braucht man die Tags noch für andere Geräte im "LAN" hinter dem GbE-Port 14, muß man dann entweder die FRITZ!Box getrennt anschließen oder eben einen weiteren Switch dazwischen setzen, der das Tagging entfernt - immer unter der Annahme, daß es bei "untagged packets" auch in der FRITZ!Box (irgendwann mal, weil die Neighbor-Infos auch erst mal vergammeln müssen) normal aussieht.

Das alles zumindest dann, wenn man die originale AVM-Firmware verwendet, die keinerlei VLANs im LAN unterstützt - auch das "Gastnetz" auf Ethernet-Basis ist ja rein portbasiert (und selbst das arbeitet ohne VLAN). Für die Unterscheidung der WLAN-Netze verwendet hingegen auch AVM entsprechende Tags, wie man sich unter "/proc/net/vlan/" ansehen kann - wenn man Shell-Zugang zu seiner Box hat.

Wer sich das antun will, kann ja versuchen, den Switch in der FRITZ!Box irgendwie umzukonfigurieren ... nur sind einige Einstellungen wohl eher "fix" im "dsld" abgelegt und eine eigene Umkonfiguration (z.B. mit "switch_cli", das bei einigem Firmware-Versionen dabei ist (iirc bei den GRX-Boxen), aber einen Shell-Zugang braucht) hat u.U. nur eine begrenzte Lebensdauer, bis der "dsld" sie dann wieder auf der Basis der Angaben in der "ar7.cfg" und einiger fester Einstellungen "übermalt". Außerdem riskiert man dort mit eigenen Einstellungen eben auch, dem FRITZ!OS in die Parade zu fahren - eher etwas für die "ganz Harten".

 

[FantasticPauly]

@sf3978: Danke für die ausführliche Erläuterung. Ich hoffe, ich komme kurzfristig dazu, das umzusetzen. Werde auf jeden Fall berichten.

@PeterPawn:

Die Fritzbox ist vollkommen "unbehandelt", also kein Freetz oder ähnliches. Ich hab mittlerweile alles, was ich an extra Funktionen im Netz brauche, auf meiner kleinen Raspberry Pi Farm laufen .

Am Port 14 hängt der Devolo PowerLAN Adapter. Ein ebensolcher hängt an Port 1 der Fritzbox. Es gibt noch weitere Devolo PowerLAN Adapter im Haus, an denen die Access Points hängen, und worüber für die verschiedenen WLAN SSIDs ebenfalls getaggte Pakete laufen.

So gesehen kriegt die Fritzbox über die PowerLAN Adapter eben alles ab, was so im Hausnetz unterwegs ist. Ich gehe bisher davon aus, auch weil es ansonsten recht gut und wie erwartet funktioniert, dass die Fritzbox alle getaggten Pakete ignoriert. Nur der Switch soll die getaggten Pakte über Port 14 sehen und ggfs. in die Zielnetze routen.

VLAN 1 ist an den Ports mit 802.1Q VLAN Tagging immer native VLAN und ungetaggt, so dass diese Daten auch die Fritzbox sehen sollte.

Also entweder kriegt die Fritzbox über die PowerLAN Adapter doch mehr mit als ich bisher glaubte oder die MAC-Adressen "leaken" irgendwie aus dem Router/Switch.

 

[eisbaerin]

Catalyst

Da hast du uns ja ganz schön an Nase rumgeführt!
Na, das ist ja gar kein Router, sondern ein Switch.
Eventuell kann er auch ein wenig und langsam routen, aber das willst du dir nicht antun.
Das hättest du aber auch gleich in #1 schreiben können, dann hätten wir nicht so lange rätseln müssen.

Konfig ist ziemlich einfach gehalten

Das schließt aber nicht aus, daß sie trotzdem falsch ist.
Ich sehe z.B. noch nicht einmal das Netz 192.168.178.0, wie soll er dann dorthin routen?
Auch finde ich kein Gateway.
Ach das soll er sich per DHCP holen? Das macht man bei Routern fast nie!

Die FB7530 hat 3 statische Routeneinträge, die auf den Cisco Router zeigen.

Wohin zeigen die genau?
Bitte mal ein Bild davon.

Alles in allem ein absolutes Chaos was du dort fabriziert hast.
Und da wunderst du dich, daß angeblich die FB was falsch macht?
Zuerst mal an die eigene Nase fassen!

 

[FantasticPauly]

Al

Da hast du uns ja ganz schön an Nase rumgeführt!
Na, das ist ja gar kein Router, sondern ein Switch.
Eventuell kann er auch ein wenig und langsam routen, aber das willst du dir nicht antun.
Das hättest du aber auch gleich in #1 schreiben können, dann hätten wir nicht so lange rätseln müssen.

Sorry, aber das ist ... so nicht ganz richtig. Der Catalyst 3560 ist ein Multilayer-Switch und längst kein dummer Layer 2 Switch mehr. Das Teil routet in Hardware genauso schnell wie er switcht (Line Rate) und kann sonst auch (fast) alles was ein Router so können sollte.
Was wäre Deiner Meinung nach ein "echter" Router und was würde sich hier ändern, wenn er anstelle des Catalyst stünde?

Auch finde ich kein Gateway.
Ach das soll er sich per DHCP holen? Das macht man bei Routern fast nie!

Die DHCP-Konfiguration des VLAN 1 Interfaces ist noch ein Überbleibsel. Darüber bezieht der "Switch" tatsächlich seine Adresse im 192.168.178.0-Netz der Fritzbox und auch sein Gateway. Da ich hier eh nur eine einfache Default Route brauche, sehe ich das nicht als kritisch an, dass er diese Einstellungen per DHCP erhält. Im Netz und im Routing läuft ja auch alles so wie erwartet. Die IP Adresse 192.168.178.5 habe ich auf der Fritzbox für das Catalyst Interface im VLAN 1 reserviert. Dorthin zeigen auch die statischen Routeneinträge auf der Fritzbox:

Da alle Geräte im 192.168.178.0-Netz die Fritzbox als Default-Gateway nutzen, funktioniert das auch aus der Richtung wie gewünscht. Die 20.x.x.x. und 30.x.x.x Adressen werde ich kurzfristig noch in den 10.x.x.x Block migrieren um konform im RFC 1918 Adressbereich zu bleiben.

Alles in allem ein absolutes Chaos was du dort fabriziert hast.

Das finde ich jetzt ein wenig übertrieben, das allein daraus abzuleiten, dass ich einen Catalyst und DHCP auf dem Interface verwende. Alles in allem läuft mein "absolutes Chaos" für mich doch recht zufriedenstellend. Ich bin einigermaßen sicher, dass wenn ich einen ISR mit statischer Interface-Konfiguration anstelle des Catalyst einsetze, sich am Anzeigeverhalten der Fritzbox nichts ändern wird (ich probiere es am WE einfach mal aus, dann brauchen wir das hier nicht theoretisch diskutieren und haben relativ schnell Klarheit).

Natürlich kann und will ich gar nicht ausschließen, dass hier eine Fehlkonfiguration die Ursache des Anzeigeproblems ist (meist sitzt das Problem ja doch vor dem Gerät), allerdings hoffe ich dafür eine konkret nachvollziehbaren Ursache zu finden, bevor ich mein ganzes Setup unter Pauschalverdacht stelle. Es viel anders aufzubauen ist leider aufgrund der baulichen und Geräte-Situation auch leider nicht so einfach möglich.