By using the edit button or double clicking the Client, the Client details will be opened. This allows you to modify the information of the Client, the supernets and the custom attributes.

You can assign supernets to clients. This can be both ipv4 and ipv6 (in which case they are called prefixes). You can assign this with the “new”-button under their respective forms.

You select the ipv4 supernet and ipv6 prefix based on an ip plan. The size of the ip plan dictates the size of the supernet you will assign. You can select a previously used supernet, or create one yourself, as long as it's not in use already.

You can also assign a supernet or prefix to a site. You can use the SiteCode field for this. Otherwise you can just leave this field empty. If you really want to, this can be any site across your environment, however this is not recommended.

Supernets can be deleted. If you want to modify a supernet, you can delete it and then reassign it once it's free.

The Client details form includes a 'Servers' tab to manually manage any server references. Servers are a handy way to easily include server names, fqdn or their ip-addresses in templates or scenarios. Server references are useful for situations where local dhcp servers or file servers are present as need to be included in an ACL or DHCP configuration. The 'local' servers are assigned to the Client and/or Site.

Multiple servers using the same reference (Server_key or Server_parameter) are allowed. Thus when creating servers for e.g. 'Ipt_callmgr', several ip-addresses or hostnames can be found using a relation and included in the configuration. To allow managing the order of the servers, the Server_status uses 3 priorities for 'active' use apart from 'obsolete' and 'planned' states.

The pre-defined relations for servers are 'Servers_client' and 'Servers_site'. Servers are stored in the YCE.Ip_servers table.

Servers can also be managed using Service-types, about 14 different manipulation options are present.

Servers are shortcuts for ip addresses that can be defined per client, and used in templates. For example the template:

 interface Vlan<Vlan_id>
  description <Net_name>-vl<Vlan_id>:<Vrf_name> -vlan-
  ip binding vpn-instance <Vrf_name>
  ip address <Net_ip_gateway> <Net_mask>
  dhcp select relay
 |[Eval(('<Vlan_id>' %2) == '1')]| dhcp relay server-address <RL_DHCP_Odd@Servers_client>
 |[Eval(('<Vlan_id>' %2) == '0')]| dhcp relay server-address <RL_DHCP_Even@Servers_client>
  dhcp relay source-address interface Vlan-interface<Vlan_id>
  undo shutdown

Servers_client is the relation where the servers are taken from, and you can reference them by their Server_parameter value, in this case RL_DHCP_Odd and RL_DHCP_Even. These get substituted by the server address that is found.

Servers also have IPv6 addresses (Server_ipv6_address). In order to get a server's ipv6 address, you need to enter the following in your template:

 interface Vlan<Vlan_id>
  description <Net_name>-vl<Vlan_id>:<Vrf_name> -vlan-
  ip binding vpn-instance <Vrf_name>
  ip address <Net_ip_gateway> <Net_mask>
  dhcp select relay
 |[Eval(('<Vlan_id>' %2) == '1')]| dhcp relay server-address <Ipv6_address@Server_client:'RL_DHCP_Odd'> 
 |[Eval(('<Vlan_id>' %2) == '0')]| dhcp relay server-address <Ipv6_address@Server_client:'RL_DHCP_Odd'> 
  dhcp relay source-address interface Vlan-interface<Vlan_id>
  undo shutdown

Servers have a status, anything higher than 1 is an active status and they have a server name. It can be the server variable, but it can also be the name of the server or its fqdn. They can also be linked to a site, for that you can use the Servers_site relation.

Within the servers tab in the client form, you can add, edit and delete your servers. Do note that when you delete a server, there might still be a template that uses it. There are no checks to make sure that the server in question is still used, so it is up to the operator to make sure a server can be safely deleted.