Port mirroring

[sahi]

Ik heb op dit moment een werkende logger voor de data van mijn Solaredge volgens https://gathering.tweakers.net/forum/list_messages/1721977
Hiervoor maak ik gebruik van een oude hub en werkt prima. Mijn Solaredge heeft 192.168.2.6 (DHCP) en mijn logger 192.168.2.245(Statisch)

Nu wil ik de oude hub vervangen voor een Unifi Switch8 en heb poort 7 geconfigureerd als portmirroring van poort 6.

Als ik nu alles aansluit en de Solaredge in poort 6 en de Raspberry (Logger) in poort 7 kan ik de logger niet meer bereiken en kan ik dus ook niet controleren of hij de data logt. Op de logger draait ook een webserver zodat ik de gelogde data ook in een webpagina kan weer laten geven.

Kan iemand mij zeggen of ik iets fout doe of dat het hoort dat je logger niet meer op t statische ip bereikbaar is?

[jvanhambelgium]

Hmm, je gebruikt het concept-van port-mirroring nogal raar, maar het is redelijk normaal dat je "target" poort plots niet meer bereikbaar is voor regulier verkeer.

Ok, een device op Port6 (=omvormer) stuurt dus unicast data netjes naar Port7 (=je logger)

Waarom zit je met port-mirroring te prullen op switch-level en ga je gewoon niet op de logger kijken of je data toekomt. Een eenvoudige tcpdump op je Raspberry geeft je alle info of de data toekomt etc.

Wat je eigenlijk moet doen is op een andere poort, vb Poort8 een sniffer/analyzer steken en dan aangeven dat dit een "target" kan zijn en vb Port6 + Port7 => Port8 en dan zie je alles zonder je productie-stroom te onderbreken.

Hangt ook af van de mogelijkheden van het product. Ik heb enkel ervaring met Cisco spullen op dit vlak (waar ze dit "spanport" of "remote spanport" noemen.

[ik222]

Volgens mij is het issue dat die omvormer in principe alleen maar naar een portal van de fabrikant logt. De oplossing om toch eigen logging te kunnen doen is om het verkeer te mirroren naar de poort waar je logger op zit.

Bij een hub gaat dit inderdaad vanzelf en is bovendien je loghost zelf dan nog bereikbaar. Bij een switch is het vrij normaal dat een mirror poort verder geen verkeer meer afhandelt, dus deze opstelling werkt daarmee niet meer.

Beste wat je kan doen is de Raspberry zelf en daarmee de webserver benaderen via een 2e netwerk aansluiting die je op een normale switchpoort aansluit of eventueel via WiFi.

[sahi]

Bedankt voor de antwoorden.
Voor mij de eerste keer dat ik port mirroring ging gebruiken dus vandaar de vraag.

Voorlopig hou ik de hub er even tussen en ga even kijken hoe ik een tweede netwerk op mijn raspberry ga zetten.

[sypie]

Heb jij het netwerk zo ingesteld dat de DHCP range en het statische IP-adres elkaar niet in de weg kunnen zitten?

Heb je het netwerk zo ingesteld dat die in de hele range past? Dus 192.168.2.xxx.

Kun je eventueel de omvormer en de RPi in een aparte VLAN zetten? Dan kunnen ze in ieder geval bij elkaar komen indien port isolation uit staat.

[dion_b]

sahi schreef op donderdag 16 april 2020 @ 07:08:
Bedankt voor de antwoorden.
Voor mij de eerste keer dat ik port mirroring ging gebruiken dus vandaar de vraag.

Voorlopig hou ik de hub er even tussen en ga even kijken hoe ik een tweede netwerk op mijn raspberry ga zetten.

USB NIC erop is een optie.

Wat trouwens ook kan is verkeer op je router afvangen en doorsturen ergens heen. Mijn Mikrotik router kan packet capture doen en dat via TZSP sturen naar een logging server. Ik gebruik het incidenteel bij troubleshooting, maar het zou continu gebruikt kunnen worden voor het soort logging wat jij wilt.

Nu, of dit een optie is hangt af van je router. Wat gebruik je?

[Kabouterplop01]

jvanhambelgium schreef op woensdag 15 april 2020 @ 22:28:
Hmm, je gebruikt het concept-van port-mirroring nogal raar, maar het is redelijk normaal dat je "target" poort plots niet meer bereikbaar is voor regulier verkeer.

Ik denk eerder dat het loggen op een andere manier wordt gebruikt.
Als je een span port gebruikt dan is het device wat er achter hang geconfigureerd in promiscuous mode.
Daarom lijkt het niet meer te reageren (tenzij je het met tx en rx instelt)

@sahi
edit: Ik heb even gelezen hoe het werkt.
De opmerking over de extra USB NIC is het makkelijkst als je met een switch wil werken.

[ Voor 52% gewijzigd door Kabouterplop01 op 16-04-2020 21:46 ]

[SniperGuy]

Zet die pi op WIFI, kan je die gebruiken voor management en de NIC voor datacolelctie

[jvanhambelgium]

Kabouterplop01 schreef op donderdag 16 april 2020 @ 21:38:
[...]


Ik denk eerder dat het loggen op een andere manier wordt gebruikt.
Als je een span port gebruikt dan is het device wat er achter hang geconfigureerd in promiscuous mode.
Daarom lijkt het niet meer te reageren (tenzij je het met tx en rx instelt)

Vb op Cisco is het wel degelijk zo dat je "Destination Port" echt niet meer "normaal" werkt. Dit heeft in eerste instantie niets met het al dan niet in promiscuous-mode staan van een achterliggende device te maken.

Destination Port
Each local SPAN session or RSPAN destination session must have a destination port (also called a monitoring port) that receives a copy of traffic from the source ports or VLANs and sends the SPAN packets to the user, usually a network analyzer.

A destination port has these characteristics:

For a local SPAN session, the destination port must reside on the same switch stack as the source port. For an RSPAN session, it is located on the switch containing the RSPAN destination session. There is no destination port on a switch or switch stack running only an RSPAN source session.
When a port is configured as a SPAN destination port, the configuration overwrites the original port configuration. When the SPAN destination configuration is removed, the port reverts to its previous configuration. If a configuration change is made to the port while it is acting as a SPAN destination port, the change does not take effect until the SPAN destination configuration had been removed.
If the port was in an EtherChannel group, it is removed from the group while it is a destination port.
It can be any Ethernet physical port.
It cannot be a secure port.
It cannot be a source port.
It cannot be an EtherChannel group or a VLAN.
It can participate in only one SPAN session at a time (a destination port in one SPAN session cannot be a destination port for a second SPAN session).
When it is active, incoming traffic is disabled. The port does not transmit any traffic except that required for the SPAN session. Incoming traffic is never learned or forwarded on a destination port.
If ingress traffic forwarding is enabled for a network security device, the destination port forwards traffic at Layer 2.
It does not participate in any of the Layer 2 protocols (STP, VTP, CDP, DTP, PagP).
A destination port that belongs to a source VLAN of any SPAN session is excluded from the source list and is not monitored.
The maximum number of destination ports in a switch stack is 64.

[dion_b]

Idd heeft het niets met promiscuous mode te maken, maar met hoe de switch in span/mirror mode werkt. Ik heb een Netgear op het werk (iirc de GS108E) waarbij de mirror port wel nog data doorlaat. Wat beter is (niets a la Cisco, alles a la Netgear) is een tweede, wel doorlaten lijkt makkelijk, maar het is zo ook erg makkelijk om de kluts kwijt te raken - en om bestemmingsverkeer naar je capturebak mee te capturen!

Thuis heb ik naast de router die can capturen ook een paar oude Cisco monsters. Ben stiekem erg blij met hoe rechttoe-rechtaan die zijn. Tenminste, als ik oordoppen in heb