Discussion

[goatatwork]

Is this this appropriate place to discuss this project? I don't want to muddy up "Issues" if it is not.

[GodfatherOfBandwidth]

This is the perfect place! Please feel free to ask / say anything about the project.

[goatatwork]

Cool. Thanks. I would like to contribute. I can't agree more with your reasons for starting this. I could write a short novel about adventures in DHCP, DNS, and IPAM management, specifically about trying to create reliable Web interfaces to these services. My skills are limited to PHP and Perl, although I'd be willing to add to that list for this project. Have you decided what to write this in? Are you thinking about using a framework? Have you decided on a list of "must have" features? Is there a place to discuss this live? I would love to be part of adding something like this to the universe.

[goatatwork]

Oh, and BTW, excellent idea.

[GodfatherOfBandwidth]

With the Christmas holidays my time is a bit strapped at the moment, but I will try to respond to comments as quickly as I can.

Have you decided what to write this in?

I have not made a firm decision, but I think it will be PHP at least for the majority. The project I was thinking about using for the GUI is PHPIPAM, which (as the name suggests) is mostly PHP. However, I am trying to stick with the KISS principal and any coding for the project should have a few things in mind.

The code should be as simple as possible; I would like to focus on ease of maintenance from the onset so the code is easy to work with. Well commented code is also important.

Are you thinking about using a framework?

I have not chosen a framework yet, and I am open to suggestions. Please feel free to let me know your thoughts.

Have you decided on a list of "must have" features?

For the initial PoC and Version .1 targets I would really like to see that when a subnet/reservation is created in PHPIPAM (with all its attendant options) that subnet/reservation should be created in Kea and also the necessary bits are added to DNS (A record, PTR record, etc). Also, and this may be pushing it for the initial releases, I would like to somehow force Kea and PHPIPAM to use the same DB for their configs and to keep track of DHCP leases, etc.

I worry that if I let them use independent DBs , if they fall out of sync somehow we can end up with a split brain scenario which can be troublesome to figure out.

As for must have features, for a full 1.0 release I think the GUI should be able to handle all (or at least the most common things) the day-to-day needs of managing DHCP and DNS requires.

Create/Delete DHCP scopes Create/Delete IP reservations Create/Delete DNS zones, views, etc Start/Stop DNS and DHCP services

Soon I will make a release target document with additional information.

Is there a place to discuss this live?

I have an IRC channel look for me on freenode ##FOSDDI

[goatatwork]

It looks like the holidays have taken me off track too. A few random notes:

• PHP, absolutely
• Framework, If I were starting this, I would definitely be starting it with Laravel. Just a personal opinion though, of course.
• Kea, this one is tough. A lot of the web UI work that I've done on top of the ISC DHCP server has been with the old-school version. I was super interested in Kea for a moment. However, since I needed to create classes and pools and do pattern matching on Option 82, it didn't appear to be the right solution. I could have misread or given up too soon, but it didn't seem to me that Kea supports this. ?? I hope I am wrong because I would absolutely love a db backend on DHCP. I loath trying to parse the *^%$# dhcpd.leases file!!
• Integration with phpipam, I think this is a good road to go down considering the amount of functionality already in phpipam. I see that it's got what appears to be a well documented API, so there's that. Also, putting effort into avoiding a split-brain situation is probably vital if any/all of this is to be based on phpipam's existing structure. I think it would help get some momentum going to think of this as a functionality-extending addition to phpipam.....like, start with that data and db schema as the backbone, and build on from there. I'm still pretty excited to see where this goes and I hope I can contribute to your project. I am going to dig into phpipam a bit more because I've only ever installed it in a few locations and haven't ever built on it. I'm looking forward to seeing where you take this - and I would love to have a more thorough conversation about Kea.

[GodfatherOfBandwidth]

I have uploaded a dev plan document which is very high level. It states the bits I think are necessary for an alpha release.

https://github.com/GodfatherOfBandwidth/FOSDDI/wiki/FOSDDI-Dev-Plan

I know things are missing and they will be added as development continues. I welcome anyone to make comments or suggestions.

[Thespis377]

Any traction on this? I would also like to suggest using NetBox. It's a FOSS IPAM written by the folks at Digital Ocean. It's written in Python though.

[GodfatherOfBandwidth]

NetBox looks interesting, I have never seen it before. However I'm not sure they are going the same direction I want to go.

They specifically say that they want to represent the network as it SHOULD be not as it is.

I am trying to show a graphical representation of how the network ACTUALLY IS at the moment.

Also, my goal is to give users an easy to use GUI that can manage the DHCP and DNS infrastructure of their installation.

Thank you for the heads up though! If you see anything else please feel free to comment on it here.

[mailinglists35]

As for must have features, for a full 1.0 release I think the GUI should be able to handle all (or at least the most common things) the day-to-day needs of managing DHCP and DNS requires.

Create/Delete DHCP scopes Create/Delete IP reservations Create/Delete DNS zones, views, etc

it would be awesome if it can have these features:

• able to automatically create reverse zone
• able to generate static dhcp mac-ip assignments from discovered arp entries
• able to automatically create/update dns records from dhcp leases

[noci2012]

Anyone known with FreeIPA? https://www.freeipa.org/page/Documentation Website doesnt show DHCP, but googling on FreeIPA + DHCP shows: https://www.freeipa.org/page/DHCP_Integration_Design and https://www.freeipa.org/page/Howto/ISC_DHCPd_and_Dynamic_DNS_update

[GodfatherOfBandwidth]

@mailinglists35 Those are excellent ideas. Could you explain your second idea a bit more though?

Where would the ARP entries be discovered from? Would the switch arp table be queried or scrapped? Or are you saying that you would like to have the ability to create DHCP reservations using MACs discovered by arp?

[GodfatherOfBandwidth]

@noci2012 I'm not very familiar with FreeIPA, but it seems to be solving a different issue than we are going after with FOSDDI. Particularly FreeIPA seems to be a replacement for MS Active Directory. A noble cause to be sure, but not exactly what we are going for.

I appreciate the info though and please feel free to post anything you feel is pertinent to the project.

[goatatwork]

Regarding the static dhcp assignments based on discovered arp entries.... I've tried a couple of approaches to this with varying degrees of success.

1. DHCP server runs arpwatch. Then watch the logs (or feed them into a db and watch that), and take action based on "new station" and "changed station" messages. Unfortunately, this option was no good if the DHCP server was not in the same broadcast domain as the clients.

2. Scrape/pull/get the arp table from the switch. Programmatically, ssh in to execute cli commands, or, depending on what information the switch provides via SNMP, get the arp table via SNMP.

3. Watch the leases.... reactively create static assignments upon lease creation for a previously-unknown host. I know this isn't "discovered arp entries", but if the intention is that a host gets network access AND the end result is a static assignment, this probably fits that bill.

4. Provided the switch being used supports it, turn on Option 82 information and shift focus to managing the static assignments based on the switchport and not based on MAC address. Maybe arguably inferior in a corporate environment, but in anything resembling a provider network, accept no substitutes.

Speaking of Option 82... Does Kea support any Option 82 yet?

[mailinglists35]

Where would the ARP entries be discovered from? Would the switch arp table be queried or scrapped? Or are you saying that you would like to have the ability to create DHCP reservations using MACs discovered by arp?

yes, scraping the arp table

btw, I've found today a proprietary product and played a little with their demo vm. it's running on linux with a java main process and some proprietary binaries dancing around it. i won't put the name in clear as I don't want to promote them, but i believe it's the top search result for "DDI dhcp". I found a bit difficult to setup and haven't got too much time to figure out how enable dhcp and dns like in the manual (oh and the demo vm is a version behind the production - they offer 7.3 and i saw on their website documentation for v 8).

though what I liked about it was that it allowed easy creation of dns and dhcp static lease for discovered hosts (they nmap the network to discover). you can poke around inside it by launching mingetty -> bash as root from the inittab (they don't use systemd), as by default they don't give shell access.

[mailinglists35]

@GodfatherOfBandwidth regarding the first and third suggestion, I've tried recently zentyal, clearos and univention. except clearos, the others dhcp and dns modules both seem to be able to do both suggestions. i particularly found very nice the way zentyal does it internally (isc dhcp and bind). however they are very heavy on ram as they are designed with the active directory in mind so there are lots of other stuff running

[mailinglists35]

@goatatwork according to isc both latest isc dhcp and kea support option 82 https://kb.isc.org/article/AA-01323/0/Standard-DHCP-Options-Defined-in-ISC-DHCP-and-Kea.html

[goatatwork]

@mailinglist35 Thanks. That's good to know. I have been really interested in Kea for a while because of the database backend, but upon last looking into it, decided that "normal" isc dhcp was going to have to stay for a while longer because at the time I couldn't find much love for Option82 in Kea. I'll dig into it again-again.

[noci2012]

@GodfatherOfBandwidth, FreeIPA uses a LDAP as a database with a web frontend, and serving out LDAP access (also allowing for AD), kerberos for single signon, DNS. As they say Identity from the IP up. LDAP is used as the core database. And there are propsals to also fee DHCP from that. Also there are integrations possible with RADIUS.

@mailinglists35 , the DDI provider you mention (I6x) already are in that business for the better part of 10-11 years or so. The company started as a firewall builder, that part was sold to a big network eq. provider and this was kept.

[noci2012]

BTW, i see talk about DNS, DHCP but then there is one missing item: support for radius/diameter. Dynamic access may cause a switch port to request access (802.1x access) on behalf of the attached system for a part of the configuration of the port f.e. VLAN, and other port properties. DHCP can only start after that.

[GodfatherOfBandwidth]

@noci2012, I didn't think about RADIUS. FreeRADIUS is the obvious choice.

Do you think RADIUS is within the scope of this project?

I'm not saying I'm not interested, I just don't want to bite off more than I can chew.

If there is a compelling reason to have it then of course it should be there, but I want to avoid attempting too much and only producing a mediocre product.

I would rather do a few things really well than do a lot of things poorly.

If RADIUS is a feature we want to move forward with it may not be an alpha release target.

Speaking of alpha release targets, if you have a feature that you think should be in the alpha release please let me know.

[goatatwork]

@GodfatherOfBandwidth

I didn't think about RADIUS

Me either. More to the point, I don't think about RADIUS. I've been trying to forget that it exists since about 1999. Why won't it die already? Imo, it seems a bit outside of the scope of the project. That said, if the project is going to incorporate RADIUS at all, I agree that FreeRADIUS is the way to go.

[noci2012]

Well there is 802.1x ethernet, where switch ports (not dialups) can be configured depending on who connects. Authentication by certificates/username or whatever etc. Like a kind of wired equivalent of WiFi. [ the PC side is xsupplicant ] Think a systems manager's PC connects to a port and is connected to the Management VLAN, and a regular PC connects to Internal LAN or random PC connects and is connected to GUEST network. I guess it isn't for first tries, but it definitely should not be left out IMHO.

[GodfatherOfBandwidth]

@noci2012 What you are referencing there is Network Access Control (NAC). NAC is a very complex subject. If NAC is what you want I suggest PacketFence it is a FOSS NAC that I have been using in production for over 5 years and am very happy with. Version 7 is coming out soon and I am very excited!

NAC is squarely outside the scope of this project though. The goal is to have this project work in tandem with NAC (although it does not require NAC to operate).

[noci2012]

Ok PacketFence almost looks like it is.... (just from description), it only seems to miss DNS ;-) and possibly IPAM faciities, i still need to investigate it. Didn't know this one. So if you are using PacketFence for DHCP..., then the IPAM needs to handle a link to the PacketFence for management.... Or do you expect to see FOSDDI as an extension to PacketFence. adding the missing parts to it.

[GodfatherOfBandwidth]

Packetfence runs its own DNS and DHCP (if you want, you can easily use your own) it does not have any IPAM at all.

The way I intend on FOSDDI integrating with PF is FOSDDI takes care of the DHCP for all hosts and the DNS for all authenticated hosts. PF provides DNS for hosts that are unauthenticated (PF uses a DNS blackhole for its web portal). PF is responsible for all NAC functions like AAA, posturing, etc.

However, the more I think about it I may move all DDI functions to FOSDDI and not rely on PF for DHCP or DNS at all. There is nothing wrong with that and it may make things easier over all ... this is something I will need to investigate further!

Back to your question though; I think I see FOSDDI as taking on a more complete feature set for DDI related functions compared to PacketFence. PF's DHCP and DNS functions are very much centered around fulfilling its mission as a NAC solution, which makes perfect sense. FOSDDI is targeted at people who desire a more complete (and open source) DDI solution.

In a NAC enabled network this could mean off-loading the DHCP and DNS functions from PF on to FOSDDI but it doesn't necessarily have to.