opennetadmin / ona

OpenNetAdmin IP Address Management (IPAM) system
opennetadmin.com
GNU General Public License v2.0
136 stars 35 forks source link

shared-network blocks causing issues. #112

Closed ChinookTx closed 7 years ago

ChinookTx commented 7 years ago

Hi there:

I can't seem to figure out how to prevent ONA from generating shared-network blocks from my configs. Is there something I'm doing wrong?

I have a linux box, with a single interface, eth0. This is my lan. In addition, I have created an eth0.X and eth0.Y, for, you guessed it, vlans X and Y. My switch trunks the 3 vlans together and sends traffic over my dhcp server.

When I create my DHCP server, I add all 3 subnets to it, and the generated file looks like:

# -SHARED SUBNETS (count=3)-

shared-network HOME-1-LAN {

    # LAN
    subnet ...
}

shared-network HOME-X-WLAN {

    # WLAN
    subnet ...
}

shared-network HOME-Y-VPS {

    # VPS
    subnet ...
}

This seems to cause IPs to be assigned on wrong interfaces, i.e. IPs from the X subnet get assigned on the Y interface, etc.

For example:

Jun 28 16:32:09 dhcp dhcpd: DHCPREQUEST for 192.168.193.34 from 00:25:00:3e:9e:d0 via eth0: wrong network.

If I strip the shared-network {} containers, everything works as expected.

How can I keep ONA from generating shared-network blocks?

Thanks!

mattpascoe commented 7 years ago

I'll explain what ONA is doing and hopefully that translates to your environment.

For ISC DHCP, a shared network is a list of subnets that are all on the same layer 2 segment. This is how ISC determines that a request coming from a shared layer2 like this may have different subnets associated with it.

ONA knows how to define a shared-network based on how you define your VLAN definitions. What it looks like to me is that you have 3 layer 2 vlans defined (HOME-1,HOME-X,HOME-Y) and there is a subnet defined in each of those. This is why it is separated out in shared-networks as your example config shows.

If you simply remove the vlan definition from the subnet it will remove the shared-network from the DHCP config.

Now, in trying to understand your environment, there are gaps I have.. to me, this looks like you have one layer2 segment which eth0 is physically connected to. You then have sub interfaces on various subnets that are all on the same layer2 interface eth0.

So if you set this up say with a VLAN in ONA called 'HOME' and associated that to the 3 subnets you have then it should also fix your problem.

So you should have 3 networks in ONA called HOME-1, HOME-X, HOME-Y as I see above. They should ALL be part of the same VLAN called simply 'HOME'..

That should generate a config that looks like this:

shared-network HOME {
    # HOME-1-LAN
    subnet 1.2.3.0 netmask 255.255.255.0 { ... }
    # HOME-Y-VPS
    subnet 2.2.2.0 netmask 255.255.255.0 { ... }
    # HOME-X-WLAN
    subnet 3.3.3.0 netmask 255.255.255.0 { ... }
}

Hope that helps with understanding what ONA is trying to do. With that said, there are some situations where you might actually have VLAN trunking to the host that are more complex. I'm not certain if that is how you have things here.

Thanks

ChinookTx commented 7 years ago

Thanks for the detailed information and sorry for the lack of response, I was away for the past few days. What you explain is not exactly my setup, sorry for not being clear enough.

My network has 3 subnets, each with their own VLAN.

VLAN 1 (native) is LAN, and it's subnet is 192.168.192.0/24 VLAN 193 is WLAN, and it's subnet is 192.168.193.0/24 VLAN 194 is VPS, and it's subnet is 192.168.194.0/24

I have a router that routes each vlan/subnets where needed, and a switch to assign ports to different vlans. Because I'm using a Raspberry Pi for my DHCP server, which has a single physical network interface, I trunk all the vlans together on a single interface at the switch and send them to the Pi on a single wire (using tags). The Pi then "splits back" the vlan on their own subinterface, for example, eth0.193, eth0.194, etc.

So in my case, I believe I DON'T want to use shared-network, as I want to preserve subnet-to-vlan assignments. I unfortunately can't see how to do this. Would I need multiple DHCP Servers, with each their own specific subnet? I.e. One server for 192.168.192.0/24, a seperate one for 192.168.193.0/24, etc?

mattpascoe commented 7 years ago

Ok I think I'm with you now. I found the following document that explains things pretty well. https://www.novell.com/support/kb/doc.php?id=7004091

So, while it looks that you can actually have multiple differing VLANS associated in a single shared network statement, that is not how ONA has implemented things. What was implemented was the ability to share multiple subnets to a single VLAN definition. The VLAN is what determines the grouping of subnets.

I'll have to think more on it but this is not a simple fix based on how ONA is currently tracking things.

Typically in the environments I've worked with, I use 'helper-addresses' on the routers/switches. This way I have one interface on my DHCP server that all the VLANS forward traffic from on behalf of the broadcast messages happening within the respective VLANS. This seems to work fine with the both my shared-network definitions as well as non-shared. I suspect this is due to the fact that there is a forwarding device involved and thus different physical interfaces.

Basically at this point, you will have to remove the VLAN assignment from ONA. While tracking it in ONA is nice, the only real thing the VLAN information is actually used by ONA is to group for the shared-network statements. So simply dont define the VLAN in ONA on the subnets and it should produce the configuration you are looking for.

Additionally, I dont think it would be worth setting up multiple DHCP servers. This is just complex and can get confusing, plus I'm not sure it would work due to them all being on the same physical (eth0) even with the subinterfaces.

Not exactly the best of answers.. :)

ChinookTx commented 7 years ago

Matt, thanks for the help. Deleting the VLAN assignments from ONA did the trick and removed the shared-network statements. Using helper-addresses is probably more elegant, I'll see if I can change my setup to do just that!