Environment
Open Enterprise Server
Service Location Protocol (SLP)
Service Location Protocol (SLP)
Situation
There is no one-size-fits all recommendation for SLP. Every environment is different and therefore every SLP deployment differs as well. The goal of this document is not to be an exhaustive best practice document, but more of a guide to be used to aid in your initial SLP deployment and design. In this document, Directory Agent will be abbreviated to DA.
Resolution
Scoped or Unscoped?
Unscoped SLP environments have not been utilized in quite some time (SLP v1 to be exact). A scope should always be defined via the:
net.slp.useScopes = <SCOPENAME>
line of the slp.conf. If you leave this line commented out, then you will be utilizing a scope named DEFAULT, that works fine; however many administrators choose to define a scope name to match their organization.
How many DAs do I need?
This can vary greatly from environment to environment. A few common scenarios:
You have 1 site where all servers are local to the users and all reside on the same network segment, a DA is not required. Individual nodes can multi-cast for SLP information.
If you have 1 site where all servers are local to the users and utilize multiple network segments, you could probably get away with having just a single DA in the environment. Some additional considerations could be made (putting an A record for the tree name in the DNS configuration) in the unlikely event that the SLPDA daemon isn't available.
You have multiple sites with reliable WAN links. In this case, it would be advisable to have two DAs running in a location similar to primary eDirectory replica holders. If there are many users at a particular site, feel free to deploy one of the DAs at that site locally.
You have multiple sites with unreliable WAN links. Many customers like to deploy DAs at each site where users could potentially login. While this is certainly possible, unless there is a local eDirectory server that contains real copies of all of the objects required for a login at that site; being able to resolve server names and IP addresses won't help much if the WAN link is unreliable.
The only thing to keep in mind is the opportunity cost of the additional DA traffic on the wire. While this traffic by itself is no problem on any form of modern network, it still will need to be accounted for in your network bandwidth requirements.
How many DAs do I need to support my 'large' environment?
While this question is asked frequently, the answer is it varies greatly. A great starting point is to start as simple as possible with the minimum requirement to achieve your design goals as mentioned above. You may then add DAs to provide fault tolerance or improved response times. From a configuration standpoint, it is easier to add DA servers on an ad-hoc basis than removing 'global' DA servers that were configured and under-utilized.
Do I need to add the server itself to the net.slp.DAAddresses?
Yes, if the server being configured is functioning as a DA (i.e. if net.slp.isDA = true).
Should I use a DNS name or IP address when configuring the net.slp.DAAddresses?
There are pros and cons of using an IP address vs a DNS name in this parameter. What you gain in flexibility (by being able to change the IP address of a server while using the same name) you lose in ease of troubleshooting as you have now made SLP dependent on a functional / correct DNS system. The choice is up to the Administrator, however both are supported.
Should I enable net.slp.isDABackup = true
This allows the DA to backup service registrations locally (/etc/slp.reg.d/slpda/DABackup) to populate the cache on OPENSLP DA startup. Otherwise, the DA has to wait for the individual servers to register their services to the DA. (eDirectory, for example, can take up to an hour for this registration to take place).
Do I need to use net.slp.DASyncReg = true if I have more than one DA?
This option is used to sync registrations on SLP DA startup. After the initial startup, it is still up to the individual servers to register their services with EACH DA defined in the net.slp.DAAddresses parameter. Please do not rely on startup sync to keep multiple DA's service lists in sync.
Does the net.slp.interfaces control which address this particular server registers with other DAs?
No, it does not. It controls the IP address on which the DA/SA will listen on for SLP requests. Each individual service is in charge of the address it uses to register.
Should I have logging and tracing enabled by default?
The options:
net.slp.traceDATraffic
net.slp.traceReg
net.slp.TraceDrop
net.slp.traceMsg
are used specifically when troubleshooting service registrations. Unless you are actively troubleshooting something, it is suggested to leave these options at their default value of off.
Unscoped SLP environments have not been utilized in quite some time (SLP v1 to be exact). A scope should always be defined via the:
net.slp.useScopes = <SCOPENAME>
line of the slp.conf. If you leave this line commented out, then you will be utilizing a scope named DEFAULT, that works fine; however many administrators choose to define a scope name to match their organization.
How many DAs do I need?
This can vary greatly from environment to environment. A few common scenarios:
You have 1 site where all servers are local to the users and all reside on the same network segment, a DA is not required. Individual nodes can multi-cast for SLP information.
If you have 1 site where all servers are local to the users and utilize multiple network segments, you could probably get away with having just a single DA in the environment. Some additional considerations could be made (putting an A record for the tree name in the DNS configuration) in the unlikely event that the SLPDA daemon isn't available.
You have multiple sites with reliable WAN links. In this case, it would be advisable to have two DAs running in a location similar to primary eDirectory replica holders. If there are many users at a particular site, feel free to deploy one of the DAs at that site locally.
You have multiple sites with unreliable WAN links. Many customers like to deploy DAs at each site where users could potentially login. While this is certainly possible, unless there is a local eDirectory server that contains real copies of all of the objects required for a login at that site; being able to resolve server names and IP addresses won't help much if the WAN link is unreliable.
The only thing to keep in mind is the opportunity cost of the additional DA traffic on the wire. While this traffic by itself is no problem on any form of modern network, it still will need to be accounted for in your network bandwidth requirements.
How many DAs do I need to support my 'large' environment?
While this question is asked frequently, the answer is it varies greatly. A great starting point is to start as simple as possible with the minimum requirement to achieve your design goals as mentioned above. You may then add DAs to provide fault tolerance or improved response times. From a configuration standpoint, it is easier to add DA servers on an ad-hoc basis than removing 'global' DA servers that were configured and under-utilized.
Do I need to add the server itself to the net.slp.DAAddresses?
Yes, if the server being configured is functioning as a DA (i.e. if net.slp.isDA = true).
Should I use a DNS name or IP address when configuring the net.slp.DAAddresses?
There are pros and cons of using an IP address vs a DNS name in this parameter. What you gain in flexibility (by being able to change the IP address of a server while using the same name) you lose in ease of troubleshooting as you have now made SLP dependent on a functional / correct DNS system. The choice is up to the Administrator, however both are supported.
Should I enable net.slp.isDABackup = true
This allows the DA to backup service registrations locally (/etc/slp.reg.d/slpda/DABackup) to populate the cache on OPENSLP DA startup. Otherwise, the DA has to wait for the individual servers to register their services to the DA. (eDirectory, for example, can take up to an hour for this registration to take place).
Do I need to use net.slp.DASyncReg = true if I have more than one DA?
This option is used to sync registrations on SLP DA startup. After the initial startup, it is still up to the individual servers to register their services with EACH DA defined in the net.slp.DAAddresses parameter. Please do not rely on startup sync to keep multiple DA's service lists in sync.
Does the net.slp.interfaces control which address this particular server registers with other DAs?
No, it does not. It controls the IP address on which the DA/SA will listen on for SLP requests. Each individual service is in charge of the address it uses to register.
Should I have logging and tracing enabled by default?
The options:
net.slp.traceDATraffic
net.slp.traceReg
net.slp.TraceDrop
net.slp.traceMsg
are used specifically when troubleshooting service registrations. Unless you are actively troubleshooting something, it is suggested to leave these options at their default value of off.
Additional Information
Any use of the titlie "best practices" is for searchability.