Unknown "vlan" and DNS requests...?

Airw0lf

Active Member
Apr 11, 2021
83
5
28
it-visibility.net
Team,

Part of the output of "ip a" looks like this:
19: vmbr1v999: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether d2:75:49:62:ca:8c brd ff:ff:ff:ff:ff:ff 20: enp3s0f1.999@enp3s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr1v999 state UP group default qlen 1000 link/ether 90:e2:ba:29:40:01 brd ff:ff:ff:ff:ff:ff

This implies there is a vlan with tag 999 attached to enp3s0f1.
However, when looking into the ifup-config /etc/network/interfaces, there is no shuch thing:
# Capture port iface enp3s0f1 inet manual # 10-Gbps mirror port auto vmbr1 iface vmbr1 inet manual bridge_ports enp3s0f1 bridge_stp off bridge_fd 0 bridge_ageing 0

While I can delete all these things, they keep coming back after a reboot.

Is there any other place where this config is stored? Where?


Thank you - Will
 
Somehow this just disapeared?!

Instead the DNS server receives a few 100 A-requests per hour for vmbr1.itv.lan and vmbr1.staging.itv.lan.

It looks like something within the Promox services. Because it stops if I stop the pve-cluster service
If I restart the service the issues comes back (as expected).

Anyone an idea where this might be coming from?
Or where start troubleshooting this?
Is there a config file that may contain interface names?
 
Last edited:
Did some more testing on this...
Seems to be related to the config until a few days ago.
Until then all user traffic was going via vmbr1. A few days ago I switched this to vmbr0.

It looks as if the storage/CIFS part is still doing something with vmbr1 - even after removal and re-adding.
Because every time I add a share it tries to access this vmbr1.itv.lan and vmbr1.staging.itv.lan.

Does this ring any bells? Somebody?
 
It turned out to be a Samba issue.
Meaning that the config file /etc/samba/smb.conf was still based on the interface vmbr1 (i.e. vmbr1 and vmbr1.*).
After changing this to vmbr0 and vmbr0.* everything was working as expected - no more strange vlans and/or DNS requests.

:)