|
|
We got a to have some kind of subnet/vlan and a network interface object, thinking of that we tought about a mini ipam concept.
|
|
|
|
|
|
The demand was
|
|
|
|
|
|
* Ability to define subnets in FD.
|
|
|
* Ability to map subnets to VLANs.
|
|
|
* Ability to automatically assign next free IP in a subnet when creating a new system.
|
|
|
* Ability to map IP addresses to specific mac addresses
|
|
|
|
|
|
### ipam plugin
|
|
|
|
|
|
* Allow to creating subnet and vlan object
|
|
|
* Allow to list them
|
|
|
|
|
|
#### subnet attributes
|
|
|
|
|
|
##### General info
|
|
|
|
|
|
* Organisation
|
|
|
* Name
|
|
|
* State (active/non active)
|
|
|
* Type
|
|
|
* Note
|
|
|
* applicant
|
|
|
* Allocation date
|
|
|
* Release date
|
|
|
|
|
|
##### IP Informations
|
|
|
|
|
|
* Subnet IP : 10.246.24.0
|
|
|
* Netmask : 255.255.252.0/22
|
|
|
* Gateway ip: 10.246.27.254
|
|
|
* IP de broadcast: 10.246.27.255
|
|
|
|
|
|
#### Vlan attributes
|
|
|
|
|
|
VLAN objects contain a name, an inner VLAN ID (0-4094), and an optional metro QinQ VLAN ID (0-4094) for the outer tag. The VLAN IDs don't need to be interpreted by anything in Fusion Directory, they're purely for our use/use by dynamic networking services. FreeRADIUS can dynamically assign VLANs (both tagged an untagged) to devices as they complete Mac-Auth or 802.1X, and that's what we'll be using the VLAN IDs for.
|
|
|
|
|
|
##### General info
|
|
|
|
|
|
* Organisation
|
|
|
* Name
|
|
|
* Inner VLAN ID
|
|
|
* QinQ VLAN ID
|
|
|
* State
|
|
|
* Description
|
|
|
* Applicant for the VLAN
|
|
|
|
|
|
### system plugin
|
|
|
|
|
|
* Move the network information from the core tab on a new tab on system
|
|
|
* Add the edition and storage of the new interface object
|
|
|
|
|
|
#### interface attributes
|
|
|
|
|
|
An interface would consist of a name, a mac-address, an optional VLAN, and whether that VLAN is tagged or untagged. The interface would also reference one or more subnets, and allow IP addresses to be assigned from those subnets.
|
|
|
|
|
|
* Name
|
|
|
* IP
|
|
|
* MacAddress
|
|
|
* VLAN
|
|
|
* VLAN TAG
|
|
|
* subnet(s) reference(s)
|
|
|
|
|
|
## mode of Operation
|
|
|
|
|
|
### Assignement subnet / vlan
|
|
|
|
|
|
**Which subnets are shown depends on whether a VLAN is selected:**
|
|
|
|
|
|
If a VLAN were selected for the interface, the subnets available for selection would be the subnets available in the VLAN.
|
|
|
If no VLAN were selected for the interface, the subnets available for selection would be all subnets.
|
|
|
|
|
|
### assignement interface / vlan
|
|
|
|
|
|
Multiple interfaces with the same VLAN should be allowed on the same system, but the cardinality of mac-address + VLAN should be 1 within the system, i.e. you can't use the same mac + VLAN combination on multiple interfaces, but you can use the same mac-address with different VLANs on different interfaces within the same system.
|
|
|
|
|
|
This is imagining interfaces as a 1:1 mapping with host interfaces, i.e. we'd generally name the interfaces to reflect the OS enumerated interfaces on the system (em0, em1 etc..). We'd then use salt to configure the interfaces correctly on the host, and FreeRADIUS to do the correct dynamic tagged/untagged assignment when the machine authenticates to the network..
|
|
|
|
|
|
## Benefits:
|
|
|
|
|
|
* Easy to list the interfaces of a system (just put in subtree on the machine)
|
|
|
* We can also list the interfaces of the systems of a department (subtree on the department)
|
|
|
* ACL management via the object type interface
|
|
|
* Allows the user to configure the column and company display, to sort as he wants (to verify that it works in a tab but it should do it. A priori there will be no filter box)
|
|
|
* The interfaces are defacto linked to the system: we delete it, they are deleted, we move it they are moved
|
|
|
* The interface <> system link is directly modeled and does not require an LDAP field + an LDAP search, we can see directly in the dn / tree which is associated with whom. |
|
|
\ No newline at end of file |