Bug #48053 for dhcp-public: DHCP 4.3.6 - Network will be flooded with answer packackes if multiple virtual Interfaces exists on a physical interface

Hello Thomas, current configuration is: shared-network { subnet for eth0 { } subnet for eth0:1 { } up to subnet for eth0:26 { } } If i understand you correctly i have to break it now into folowing structure: shared-network { subnet for eth0 { } } shared-network { subnet for eth0:1 { } } up to shared-network { subnet for eth0:26 { } } On 10.08.2018 14:15, Thomas Markwalder via RT wrote: > Hello Sachse: > > In version 4.3.5, the interface discovery code was updated to use getifaddrs(), to allow it to recognized VLANs as interfaces. Prior to this the server did not recognize them as interfaces. For instance, it was not possible to use the interface name on the command line, to tell the sever to specifically listen on a VLAN such as "enp0s10:1", or configure a subnet for a VLAN in the configuration file. > > Once the above changes were made, the server actually responds as it should, to a physical inteface with multiple "virtual" interfaces attached. To the server this looks like multiple real interfaces on the same link. Thus, each "nic" sees the broadcast solicit sent by a directly connected client, and thus is treated as an individual request. > > The behavior of the code prior to this, was for the server to only "see" the solicit on real interface as it cannot see the VLANs at all, and in turn would only respond with a single offer from the subnet defined on that interface. I am assuming that since this was what you wanted, that you are not defining different subnets for each VLAN. > > You can achieve this effect with the new code, simply by wrapping the subnet in a shared-network. > > Perhaps you could explain what it is you are trying to achieve with the VLANs. > > > Regards, > > Thomas Markwalder > ISC Software Engineering > > > > > > > > > > > On Thu Aug 09 09:22:26 2018, sachse@gmx.net wrote: >> Bug Report from www.isc.org: >> >> Name: sachse >> Email: sachse@gmx.net >> Software Version: DHCP 4.3.6 >> OS: Linux >> Subject:Network will be flooded with answer packackes if multiple >> virtual Interfaces exists on a physical interface >> >> >> Bug Detail >> =========== >> Handling of virtual interfaces is totally destroyed and floods the >> network so that switches disable there ports. >> >> Network configuration: >> physical: eth0 >> virtual: eth0:1 up to eth0:26 >> >> Old versions receives one request or information and send one answer. >> - CORRECT >> ---- 8< ---- >> DHCPINFORM from 192.168.100.102 via eth0 >> (in reality this is eth0:6) >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0 >> ---- 8< ---- >> >> Current version received one request or information an sends one >> answer per interface. - FAIL >> This causes in my example 27 answers instead of 1. >> In reality this is the same request and the same interface as in >> example above. >> It is independent which request the server receives, every request >> causes such a flood. >> ---- 8< ---- >> DHCPINFORM from 192.168.100.102 via eth0:26 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:26 >> DHCPINFORM from 192.168.100.102 via eth0:25 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:25 >> DHCPINFORM from 192.168.100.102 via eth0:24 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:24 >> DHCPINFORM from 192.168.100.102 via eth0:23 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:23 >> DHCPINFORM from 192.168.100.102 via eth0:22 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:22 >> DHCPINFORM from 192.168.100.102 via eth0:21 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:21 >> DHCPINFORM from 192.168.100.102 via eth0:20 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:20 >> DHCPINFORM from 192.168.100.102 via eth0:19 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:19 >> DHCPINFORM from 192.168.100.102 via eth0:18 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:18 >> DHCPINFORM from 192.168.100.102 via eth0:17 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:17 >> DHCPINFORM from 192.168.100.102 via eth0:16 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:16 >> DHCPINFORM from 192.168.100.102 via eth0:15 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:15 >> DHCPINFORM from 192.168.100.102 via eth0:14 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:14 >> DHCPINFORM from 192.168.100.102 via eth0:13 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:13 >> DHCPINFORM from 192.168.100.102 via eth0:12 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:12 >> DHCPINFORM from 192.168.100.102 via eth0:11 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:11 >> DHCPINFORM from 192.168.100.102 via eth0:10 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:10 >> DHCPINFORM from 192.168.100.102 via eth0:9 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:9 >> DHCPINFORM from 192.168.100.102 via eth0:8 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:8 >> DHCPINFORM from 192.168.100.102 via eth0:7 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:7 >> DHCPINFORM from 192.168.100.102 via eth0:6 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:6 >> DHCPINFORM from 192.168.100.102 via eth0:4 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:4 >> DHCPINFORM from 192.168.100.102 via eth0:3 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:3 >> DHCPINFORM from 192.168.100.102 via eth0:2 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:2 >> DHCPINFORM from 192.168.100.102 via eth0:1 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:1 >> DHCPINFORM from 192.168.100.102 via eth0 >> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0 >> ---- 8< ---- >> >> --- >> This email was received through isc.org Bug Submission Form >

---

Hello Thomas, your solution works fine. At start of dhcpd the are messages that multiple interfaces are in the same shared network. Is this an information or a warning? On 08/10/2018 08:11 PM, Thomas Markwalder via RT wrote: > Hello: > > No, I assumed you were not specifying subnets per VLAN.  You are likely > not specifying any interface names on the command line when you start > dhcpd, correct?  Unless you do, the server will discover and listen on > all interfaces, including VLANs.  Prior 4.3.5, the server simply cannot > see the > VLANs. Try invoking with the server and specifying only eth0 (and any > other real interfaces you want it to listen on): > >  dhcpd -c <your config file>  eth0 > > Leave your configuration as is. > > Cheers, > > Thomas > > > > > On 08/10/2018 01:54 PM, sachse via RT wrote: >> Hello Thomas, >> >> current configuration is: >> >> shared-network >> { >> subnet for eth0 >> { >> >> } >> subnet for eth0:1 >> { >> >> } >> up to >> subnet for eth0:26 >> { >> >> } >> } >> >> >> >> If i understand you correctly i have to break it now into folowing >> structure: >> >> shared-network >> { >> subnet for eth0 >> { >> >> } >> } >> shared-network >> { >> subnet for eth0:1 >> { >> >> } >> } >> up to >> shared-network >> { >> subnet for eth0:26 >> { >> >> } >> } >> >> >> >> On 10.08.2018 14:15, Thomas Markwalder via RT wrote: >>> Hello Sachse: >>> >>> In version 4.3.5, the interface discovery code was updated to use getifaddrs(), to allow it to recognized VLANs as interfaces. Prior to this the server did not recognize them as interfaces. For instance, it was not possible to use the interface name on the command line, to tell the sever to specifically listen on a VLAN such as "enp0s10:1", or configure a subnet for a VLAN in the configuration file. >>> >>> Once the above changes were made, the server actually responds as it should, to a physical inteface with multiple "virtual" interfaces attached. To the server this looks like multiple real interfaces on the same link. Thus, each "nic" sees the broadcast solicit sent by a directly connected client, and thus is treated as an individual request. >>> >>> The behavior of the code prior to this, was for the server to only "see" the solicit on real interface as it cannot see the VLANs at all, and in turn would only respond with a single offer from the subnet defined on that interface. I am assuming that since this was what you wanted, that you are not defining different subnets for each VLAN. >>> >>> You can achieve this effect with the new code, simply by wrapping the subnet in a shared-network. >>> >>> Perhaps you could explain what it is you are trying to achieve with the VLANs. >>> >>> >>> Regards, >>> >>> Thomas Markwalder >>> ISC Software Engineering >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu Aug 09 09:22:26 2018, sachse@gmx.net wrote: >>>> Bug Report from www.isc.org: >>>> >>>> Name: sachse >>>> Email: sachse@gmx.net >>>> Software Version: DHCP 4.3.6 >>>> OS: Linux >>>> Subject:Network will be flooded with answer packackes if multiple >>>> virtual Interfaces exists on a physical interface >>>> >>>> >>>> Bug Detail >>>> =========== >>>> Handling of virtual interfaces is totally destroyed and floods the >>>> network so that switches disable there ports. >>>> >>>> Network configuration: >>>> physical: eth0 >>>> virtual: eth0:1 up to eth0:26 >>>> >>>> Old versions receives one request or information and send one answer. >>>> - CORRECT >>>> ---- 8< ---- >>>> DHCPINFORM from 192.168.100.102 via eth0 >>>> (in reality this is eth0:6) >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0 >>>> ---- 8< ---- >>>> >>>> Current version received one request or information an sends one >>>> answer per interface. - FAIL >>>> This causes in my example 27 answers instead of 1. >>>> In reality this is the same request and the same interface as in >>>> example above. >>>> It is independent which request the server receives, every request >>>> causes such a flood. >>>> ---- 8< ---- >>>> DHCPINFORM from 192.168.100.102 via eth0:26 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:26 >>>> DHCPINFORM from 192.168.100.102 via eth0:25 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:25 >>>> DHCPINFORM from 192.168.100.102 via eth0:24 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:24 >>>> DHCPINFORM from 192.168.100.102 via eth0:23 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:23 >>>> DHCPINFORM from 192.168.100.102 via eth0:22 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:22 >>>> DHCPINFORM from 192.168.100.102 via eth0:21 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:21 >>>> DHCPINFORM from 192.168.100.102 via eth0:20 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:20 >>>> DHCPINFORM from 192.168.100.102 via eth0:19 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:19 >>>> DHCPINFORM from 192.168.100.102 via eth0:18 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:18 >>>> DHCPINFORM from 192.168.100.102 via eth0:17 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:17 >>>> DHCPINFORM from 192.168.100.102 via eth0:16 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:16 >>>> DHCPINFORM from 192.168.100.102 via eth0:15 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:15 >>>> DHCPINFORM from 192.168.100.102 via eth0:14 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:14 >>>> DHCPINFORM from 192.168.100.102 via eth0:13 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:13 >>>> DHCPINFORM from 192.168.100.102 via eth0:12 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:12 >>>> DHCPINFORM from 192.168.100.102 via eth0:11 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:11 >>>> DHCPINFORM from 192.168.100.102 via eth0:10 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:10 >>>> DHCPINFORM from 192.168.100.102 via eth0:9 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:9 >>>> DHCPINFORM from 192.168.100.102 via eth0:8 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:8 >>>> DHCPINFORM from 192.168.100.102 via eth0:7 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:7 >>>> DHCPINFORM from 192.168.100.102 via eth0:6 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:6 >>>> DHCPINFORM from 192.168.100.102 via eth0:4 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:4 >>>> DHCPINFORM from 192.168.100.102 via eth0:3 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:3 >>>> DHCPINFORM from 192.168.100.102 via eth0:2 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:2 >>>> DHCPINFORM from 192.168.100.102 via eth0:1 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0:1 >>>> DHCPINFORM from 192.168.100.102 via eth0 >>>> DHCPACK to 192.168.100.102 (xx:xx:xx:xx:xx:xx) via eth0 >>>> ---- 8< ---- >>>> >>>> --- >>>> This email was received through isc.org Bug Submission Form >> >> > > >

---