slp DA not showing itself (?) in OES

OES 11 SP2 (yeah I know)

3 servers in the tree.

Server1 = 10.10.1.10
Server2 = 10.10.1.11
Server3 = 10.10.1.13

Server1 and Server3 are both openslpDA servers (Server1 is a DS Master, Server2 and Server3 have RW replicas of everything)

Server1 slp.conf (well end part anyway):

net.slp.useScopes = ACME_SLP_GLOBAL
net.slp.isDA = true
net.slp.isBroadcastOnly = false
net.slp.DAAddresses = 10.10.1.10,10.10.1.13
net.slp.MTU = 1450

net.slp.DASyncReg = true
net.slp.isDABackup = true
;net.slp.DABackupLocalReg = true
net.slp.DABackupInterval = 900



Server3 slp.conf (end part as well):

net.slp.useScopes = ACME_SLP_GLOBAL
net.slp.isDA = true
net.slp.isBroadcastOnly = false
net.slp.DAAddresses = 10.10.1.13,10.10.1.10
net.slp.MTU = 1450
net.slp.interfaces = 10.10.1.13

net.slp.DASyncReg = true
net.slp.isDABackup = true
net.slp.DABackupInterval = 900


Server3 was rebooted 2 weeks ago.

All three servers show the same output from:
slptool findsrvs service:bindery.novell:

service:bindery.novell:///Server2,2835
service:bindery.novell:///Server1,810


Server3 is missing.

OES Client on pc's also only show two "bindery" servers:
Server1
and
Server2

Server3 is missing

I tried using TID https://support.microfocus.com/kb/doc.php?id=7001449

But nothing seems to jive/work.

Any ideas as to why this one server refuses to show up as a bindery server?
We're randomly getting "tree or server not found" which I think may be this one server (would have to find a hub to try to do a packet capture to see what's going on from the workstation perspective).

Restarting slpda has no effect.
  • On 06.06.2019 16:34, kjhurni wrote:

    Kevin...

    > net.slp.interfaces = 134.179.251.28


    ???

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • Massimo Rosen;2500630 wrote:
    On 06.06.2019 16:34, kjhurni wrote:

    Kevin...

    > net.slp.interfaces = 134.179.251.28


    ???

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de


    Yeah, was trying to change IP's and missed one.

    Sigh
    This is why I should've posted in the private forums but then everyone wants it posted publicly.

    Fixed the original post. Basically that = Server3
  • On 06.06.2019 17:06, kjhurni wrote:
    >
    > Massimo Rosen;2500630 Wrote:
    >> On 06.06.2019 16:34, kjhurni wrote:
    >>
    >> Kevin...
    >>
    >>> net.slp.interfaces = 134.179.251.28

    >>
    >> ???
    >>
    >> CU,
    >> --
    >> Massimo Rosen
    >> Micro Focus Knowledge Partner
    >> No emails please!
    >> http://www.cfc-it.de

    >
    > Yeah, was trying to change IP's and missed one.
    >
    > Sigh
    > This is why I should've posted in the private forums but then everyone
    > wants it posted publicly.
    >
    > Fixed the original post. Basically that = Server3
    >
    >

    Ic.

    I would remove it nonetheless, aka the whole line. Why is it there? Same
    goes for the MTU line.

    Also note, that the fact that Server3 is da (or not) is totally
    irrelevant for it's registration of eDirectory with SLP. That you don't
    see it in bindery.novell is either a problem of the local eDir instance
    failing to (re)registering itself with any of the configured DAs, or a
    completely malfucntioning local SLP stack.

    Do you see any other service of server3 in all the SLP services? Say
    smdr.novell or something?

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • On 06.06.2019 17:06, kjhurni wrote:
    >
    > Massimo Rosen;2500630 Wrote:
    >> On 06.06.2019 16:34, kjhurni wrote:
    >>
    >> Kevin...
    >>
    >>> net.slp.interfaces = 134.179.251.28

    >>
    >> ???
    >>
    >> CU,
    >> --
    >> Massimo Rosen
    >> Micro Focus Knowledge Partner
    >> No emails please!
    >> http://www.cfc-it.de

    >
    > Yeah, was trying to change IP's and missed one.
    >
    > Sigh
    > This is why I should've posted in the private forums but then everyone
    > wants it posted publicly.
    >
    > Fixed the original post. Basically that = Server3
    >
    >

    Ic.

    I would remove it nonetheless, aka the whole line. Why is it there? Same
    goes for the MTU line.

    Also note, that the fact that Server3 is da (or not) is totally
    irrelevant for it's registration of eDirectory with SLP. That you don't
    see it in bindery.novell is either a problem of the local eDir instance
    failing to (re)registering itself with any of the configured DAs, or a
    completely malfucntioning local SLP stack.

    Do you see any other service of server3 in all the SLP services? Say
    smdr.novell or something?

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • To get a real view of what an given DA knows about use something like
    slptool unicastfindsrvs xx.xx.xx.xx service:bindery.novell
    with the X-rays being the DA's ip address (DNS does not work).
    If there's only one address bound on Server3 leave out the
    net.slp.interfaces
    statement. Leave the MTU at 1400 unless there's a really valid reason for something else. And please check the
    n4u.nds.advertise-life-time=
    setting with ndsconfig get.
    ndsd registers bindery.novell and ndap.novell at loadtime and after the given interval.
  • Massimo Rosen;2500632 wrote:
    On 06.06.2019 17:06, kjhurni wrote:
    >
    > Massimo Rosen;2500630 Wrote:
    >> On 06.06.2019 16:34, kjhurni wrote:
    >>
    >> Kevin...
    >>
    >>> net.slp.interfaces = 134.179.251.28

    >>
    >> ???
    >>
    >> CU,
    >> --
    >> Massimo Rosen
    >> Micro Focus Knowledge Partner
    >> No emails please!
    >> http://www.cfc-it.de

    >
    > Yeah, was trying to change IP's and missed one.
    >
    > Sigh
    > This is why I should've posted in the private forums but then everyone
    > wants it posted publicly.
    >
    > Fixed the original post. Basically that = Server3
    >
    >

    Ic.

    I would remove it nonetheless, aka the whole line. Why is it there? Same
    goes for the MTU line.

    Also note, that the fact that Server3 is da (or not) is totally
    irrelevant for it's registration of eDirectory with SLP. That you don't
    see it in bindery.novell is either a problem of the local eDir instance
    failing to (re)registering itself with any of the configured DAs, or a
    completely malfucntioning local SLP stack.

    Do you see any other service of server3 in all the SLP services? Say
    smdr.novell or something?

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de


    Ah, so you jogged my memory.

    The Server1 and Server3 have two NIC
    But multiple IP's (two actually) one for each NIC.

    One IP is used STRICTLY for LDAP behind a hardware load balancer, so that's why we restricted the SLP/NCP traffic to the one IP, because we found that the server would reply from the "LDAP" NIC but the load balancer would toss the traffic, thus resulting in errors from the client-side.

    Now that I've remembered that, ironically Server1 doesn't have the restriction line, so possibly that's where the tree or server not found it coming from?

    Server3 is supposed to be a DA (ha)

    I'm not seeing smdr.novell for Server3
    But I see like:
    service:ntp
    service:ldap
  • mathiasbraun;2500633 wrote:
    To get a real view of what an given DA knows about use something like
    slptool unicastfindsrvs xx.xx.xx.xx service:bindery.novell
    with the X-rays being the DA's ip address (DNS does not work).
    If there's only one address bound on Server3 leave out the
    net.slp.interfaces
    statement. Leave the MTU at 1400 unless there's a really valid reason for something else. And please check the
    n4u.nds.advertise-life-time=
    setting with ndsconfig get.
    ndsd registers bindery.novell and ndap.novell at loadtime and after the given interval.


    thanks.
    the unicastfindsrvs shows all 3 servers.
    I set the lifetime to 600 (10 min) from the default of 3600 (via ndsconfig get) and reloaded slpda, but that didnt' seem to actually take/kick in.
    iManager still showed 0:13:something for the "waiting" which would imply it did not read/take the 10 minutes setting.

    Even if it was the hour, the server should've shown itself in the bindery since it was restarted 2 weeks ago.

    I think the MTU was 1450 for some networking reason (but can't remember). Will have to try to dig up some old notes.
  • Kevin,

    On 06.06.2019 18:06, kjhurni wrote:
    > the unicastfindsrvs shows all 3 servers.


    Using which IP? WHat is the result for each of the three servers?

    > I set the lifetime to 600 (10 min) from the default of 3600 (via
    > ndsconfig get) and reloaded slpda, but that didnt' seem to actually
    > take/kick in.


    No, as it's a setting for NDSD, not for SLPDA. To have it take, you need
    to restart ndsd of course. But it's really not that important, the
    default is ok these days.


    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • Kevin,

    On 06.06.2019 18:06, kjhurni wrote:
    > the unicastfindsrvs shows all 3 servers.


    Using which IP? WHat is the result for each of the three servers?

    > I set the lifetime to 600 (10 min) from the default of 3600 (via
    > ndsconfig get) and reloaded slpda, but that didnt' seem to actually
    > take/kick in.


    No, as it's a setting for NDSD, not for SLPDA. To have it take, you need
    to restart ndsd of course. But it's really not that important, the
    default is ok these days.


    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • If "unicastfindsrvs", pointing TO both DAs from ANY box, shows all servers, then all registrations seem to be ok. You might want to verify the
    /etc/slp.reg.d/slpd/DABackup
    file.