Issue discovering devices on a VLAN

[ProtossGP32]

Hi all! I've been testing NetAlertX for some days and I'm excited to use it for a better network monitoring in our internal clusters. I've decided to stick with version 25.6.7 because the latest versions don't seem to properly complete the Network map rendering, getting stuck with the Loading popup and Firefox console showing errors like myHierarchy not having a type attribute. Anyway, this is not the issue I'm willing to discuss here.

I've deployed NetAlertX using Podman compose and using Host as network. I've also configured the APP_CONF_OVERRIDE variable to define the subnets and interfaces where to look for devices:

APP_CONF_OVERRIDE={"SCAN_SUBNETS":"['10.0.26.0/24 --interface=enp1s0f0', '10.0.25.0/24 --interface=eno1', '10.0.27.0/24 --interface=enp1s0f0.27']"}

where:

• eno1 and enp1s0f0 are physical interfaces where the default NetAlertX plugins properly discover devices as shown in this screenshot:

• enp1s0f0.27 is a VLAN with ID=27. NetAlertX doesn't discover any device through this device even though arp-scan launched from within the container does:

(.venv) [root@redacted netalertx]# podman exec -i -t netalertx_redacted /bin/sh
/ # arp-scan --interface=enp1s0f0.27 10.0.27.0/24
Interface: enp1s0f0.27, type: EN10MB, MAC: <redacted>, IPv4: 10.0.27.50
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
10.0.27.15	<redacted>	Fujitsu Technology Solutions GmbH
10.0.27.16	<redacted>	Fujitsu Technology Solutions GmbH
10.0.27.40	<redacted>	Fujitsu Technology Solutions GmbH
10.0.27.42	<redacted>	Intel Corporate

4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.10.0: 256 hosts scanned in 1.916 seconds (133.61 hosts/sec). 4 responded

One thing that bothers me is that even though I know this enp1s0f0.27 is a VLAN, I don't need to specify the vlan parameter on arp-scan call nor use the name of the physical interface, but I guess this is normal as this is how the interface appears in the NetAlertX UI System Info panel:

Any thoughts on how to proceed from here on? It would be much appreciated!

UPDATE: While browsing the NetAlertX UI, I've found out that the devices' events from enp1s0f0.27 interface are being held in the Unprocessed events tab. Is this normal?

[jokob-sk]

Hi,

The only docs on VLANS is here - I don't use them so can't help much more: https://jokob-sk.github.io/NetAlertX/SUBNETS/?h=vlan#vlans-on-a-hyper-v-setup

Maybe someone else can chip in.

The unprocessed events might be caused by application restart, check your logs if the application is restarting for any reason. See debugging issues for details: https://jokob-sk.github.io/NetAlertX/LOGGING/?h=log

[ProtossGP32]

Thanks for the quick reply! I've done further analysis on the events history and logs and I might have found out what's going on:

• According to the app logs, ARPSCAN does indeed find all the devices from all the interfaces, including the VLAN:

10:55:15 [Scheduler] run for ARPSCAN: YES
10:55:15 [Plugin utils] ---------------------------------------------
10:55:15 [Plugin utils] display_name: Arp-Scan (Network scan)
10:55:15 [Plugins] Executing: python3 /app/front/plugins/arp_scan/script.py userSubnets={subnets}
10:55:48 [Plugins] Output: [plugin_helper] reading config file
10:55:15 [ARP Scan] In script 
10:55:15 [ARPSCAN] userSubnetsParam: 10.0.26.0/24 --interface=enp1s0f0,10.0.25.0/24 --interface=eno1,10.0.27.0/24 --interface=enp1s0f0.27
10:55:15 [Database] Opening DB
10:55:26 [ARPSCAN] arpscan_output: Interface: enp1s0f0, type: EN10MB, MAC: <redacted>:61:23, IPv4: 10.0.26.50
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
10.0.26.15      <redacted>:b8:cc       Fujitsu Technology Solutions GmbH
10.0.26.16      <redacted>:b8:f8       Fujitsu Technology Solutions GmbH
10.0.26.40      <redacted>:60:b5       Fujitsu Technology Solutions GmbH
10.0.26.42      <redacted>:7d:f4       Intel Corporate

4 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.10.0: 256 hosts scanned in 11.063 seconds (23.14 hosts/sec). 4 responded

10:55:37 [ARPSCAN] arpscan_output: Interface: eno1, type: EN10MB, MAC: <redacted>:0b:f4, IPv4: 10.0.25.251
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
10.0.25.15      <redacted>:af:a9       Fujitsu Technology Solutions GmbH
10.0.25.16      <redacted>:af:98       Fujitsu Technology Solutions GmbH
10.0.25.40      <redacted>:a6:cf       Fujitsu Technology Solutions GmbH
10.0.25.50      <redacted>:3e:6e       Fujitsu Technology Solutions GmbH
10.0.25.60      <redacted>:a2:20       Brocade Communications Systems LLC

5 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.10.0: 256 hosts scanned in 11.060 seconds (23.15 hosts/sec). 5 responded

10:55:48 [ARPSCAN] arpscan_output: Interface: enp1s0f0.27, type: EN10MB, MAC: <redacted>:61:23, IPv4: 10.0.27.50
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
10.0.27.15      <redacted>:b8:cc       Fujitsu Technology Solutions GmbH
10.0.27.16      <redacted>:b8:f8       Fujitsu Technology Solutions GmbH
10.0.27.40      <redacted>:60:b5       Fujitsu Technology Solutions GmbH
10.0.27.42      <redacted>:7d:f4       Intel Corporate

5 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.10.0: 256 hosts scanned in 11.063 seconds (23.14 hosts/sec). 4 responded

10:55:48 [ARPSCAN] Found: Devices without duplicates 9
10:55:48 [ARPSCAN] Devices List len:13

• It also states that from the 13 discovered devices, only 9 are non-duplicated!

This leads me to think about what are the requisites for a device to be considered unique:

• As you can see in the ARPSCAN logs, devices from the subnets 10.0.26.0/24 and 10.0.27.0/24 share the same MAC address because both share the same interface enp1s0f0, being the second one a VLAN.
• When looking at the events history in the UI, I see that the events with IPs within the subnet 10.0.27.0/24 share the same hostname as the 10.0.26.0/24 ones:

So I guess the issue is in the devices sharing the same MAC address and thus not creating new device entries in the UI? 🤷🏽

UPDATE: I've checked the existing devices and I see that the ones with duplicated entries do show the events with the different IPs in the ARPSCAN plugin section. Is this the expected behaviour?

If so, I understand that in the Network Map there's no way to show the rest of the Plugin objects apart from the first discovered one, right? Would NetAlertX still send alert notifications on those additional IPs, once the notifications for that devices are configured?

Also, sorry about not mentioning before that these duplicates come from the same device having an IP for the parent interface and another IP for a VLAN on top of that same interface! I'm sure this has introduced some unnecessary noise 🙇🏽 .

[jokob-sk]

Hi @ProtossGP32 ,

So I guess the issue is in the devices sharing the same MAC address and thus not creating new device entries in the UI? 🤷🏽

Yes, the MAC is treated as the unique identifier for devices. You can however create a dummy device with a specific IP and use the ICMP plugin to monitor it if you'd like to do so. You can then use this dummy device in the network map

Check the below docs for details:

• https://jokob-sk.github.io/NetAlertX/DEVICE_MANAGEMENT/?h=dummy#dummy-devices
• https://jokob-sk.github.io/NetAlertX/NETWORK_TREE/?h=topo
• https://jokob-sk.github.io/NetAlertX/REMOTE_NETWORKS/?h=icmp#manual-entry

[jokob-sk]

Also - thank you for the detailed write up - makes it much easier to help you.

[jokob-sk]

You can also fine tune notifications via various settings (if you don't want to receive notifications for a specific IP or mac range):

• https://jokob-sk.github.io/NetAlertX/NOTIFICATIONS/?h=notifi (see ignoring devices)