[Kea-users] KEA DHCP and VLANS...
talk.about at gmx.de
Mon Feb 3 17:39:01 UTC 2020
I tried your „dirty“ solution but unfortunately it is now compatible with my nfsroot boot mechanism. Nevertheless I was able to solve my issue in a different way. For anybody who might have the same Problem in the future:
- Create a macvlan device via systemd-networkd:
MACAddress=xx:xx:xx:xx:xx:xx (generate a unique mac address and put it here)
Address=192.168.xx.xx/24 (put a valid ip from your subnet for all 3 values)
- on the physical device definition you need to define that it belongs to the created mac vlan:
Name=eth0 (your physical device)
... (keep previous values)
When now systemd-networkd gets restarted, eth1 device is considered a separate network interface with a valid hardware address and ip. Now creating a "raw" bind on that device does not interfere with the vlan any more and KEA DHCP Server is assigning correct ips.
Gesendet von Mail für Windows 10
Von: Dajka Tamás
Gesendet: Sonntag, 2. Februar 2020 21:14
An: 'Talkabout'; 'Oehlrich, Benedikt'
Cc: kea-users at lists.isc.org
Betreff: RE: [Kea-users] KEA DHCP and VLANS...
that’s why I’ve written the dirty workaround. Since you’ve only trouble with the native vlan, than a possible solution is to ’tag’ the native vlan with a crosslink on the swicht (looping back to itself). This way you can tag the native vlan transparently.
So you create a new vlan – vlan 20 let’s say – remove the ip from the pysical interface and assign it to interface vlan20. On the switch you cross connect a native vlan port with a vlan 20 access port „bridgeing” it together (all packets in the native vlan will appear to KEA as vlan 20 packets).
With openvswitch you’ll to nearly the same, but virtually. If openvswitch honors the tagged/untagged scenario correctly, than it’ll work.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kea-users