Decnet Over IP (Phase V question). - VMS

This is a discussion on Decnet Over IP (Phase V question). - VMS ; I am using TCPIP services with DECnet Phase V on 2 x Itanium Blades running OVMS 8.3-1H1. Here is the situation. Node 1 SCSNode = OESTST DNS Host name OESTST-TAB In DECNET I have it set up as NodeName = ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Decnet Over IP (Phase V question).

  1. Decnet Over IP (Phase V question).

    I am using TCPIP services with DECnet Phase V on 2 x Itanium Blades
    running OVMS 8.3-1H1.

    Here is the situation.

    Node 1

    SCSNode = OESTST
    DNS Host name OESTST-TAB

    In DECNET I have it set up as
    NodeName = oestst-tab
    Synonym = oestst
    -------------------------------------
    Node 2

    SCSNODE = TABTST
    DNS Host Name = TABTST

    In DECNET it is set up as
    NodeName = tabtst
    Synonym = tabtst

    I have 2 DNS servers
    tab-dns1.myplace.com
    glc-dns2.myplace.com

    -----------------------------
    I would primarily like the DNS servers to provide the name resolution.
    However the
    DNS host names are currently set up in the local tables on each node,
    (they are also defined in the DNS Servers coincidentally).

    how should I set up the naming information in DECNet Phase V.?

    i.e. "local,domain" or "domain", and how would I format the entries???

    Dave.

  2. Re: Decnet Over IP (Phase V question).

    On 7 Oct, 13:34, Baxt...@tessco.com wrote:
    > I am using TCPIP services with DECnet Phase V on 2 x Itanium Blades
    > running OVMS 8.3-1H1.
    >
    > Here is the situation.
    >
    > Node 1
    >
    > SCSNode = OESTST
    > DNS Host name OESTST-TAB
    >
    > In DECNET I have it set up as
    > NodeName = oestst-tab
    > Synonym = oestst
    > -------------------------------------
    > Node 2
    >
    > SCSNODE = TABTST
    > DNS Host Name = TABTST
    >
    > In DECNET it is set up as
    > NodeName = tabtst
    > Synonym = tabtst
    >
    > I have 2 DNS servers
    > tab-dns1.myplace.com
    > glc-dns2.myplace.com
    >
    > -----------------------------
    > I would primarily like the DNS servers to provide the name resolution.
    > However the
    > DNS host names are currently set up in the local tables on each node,
    > (they are also defined in the DNS Servers coincidentally).
    >
    > how should I set up the naming information in DECNet Phase V.?
    >
    > i.e. "local,domain" or "domain", and how would I format the entries???
    >
    > Dave.


    My understanding is that you need LOCAL, no matter what.

    I would suggest that you use LOCAL,DOMAIN as this will then dive off
    into the TCP/IP transport if you can't resolve the name through the
    LOCAL address towers. I'm not certain that the TCP/IP naming will
    actually go off through DNS or whether it will return remote node is
    unknown if the address is neither in the local DECnet database nor in
    the local host table. I suspect it'll return remote node is unknown
    because DECnet doesn't use DNS lookup for the IP stack.

    Steve

  3. Re: Decnet Over IP (Phase V question).

    @net$configure in advanced mode

    Answer "local,domain" to the naming service question.

    Answer "127.0.0.1" for the name / address of the name server - actually they
    really mean "BIND resolver". "127.0.0.1" equates to "localhost", so you
    always query your local HOSTS database first, then it will use whatever DNS
    nameserver list you have set up in your local IP stack. It's a useful trick
    that doesn't seem to be documented anywhere.

    All you then do is delete the 'old' DECnet style name from the local naming
    service (using DECNET_REGISTER) and insert the new name into the local HOSTS
    database, then move it out to your DNS if you ever need to.

    You might find the article I wrote some time ago for the VMS technical
    update useful, plus some of the slide sets available at
    www.xdelta.co.uk/seminars

    Don't forget that you can test the connectivity without relying on the
    naming by using things like set host ip$. You can check the
    naming at each end by looking at the SYS$*NODE* logical names. Beware that
    proxies work by node fullname, so expect to have to re-add your proxies.

    --
    Cheers, Colin.
    Legacy = Stuff that works properly!



  4. Re: Decnet Over IP (Phase V question).

    On 7 Oct, 13:34, Baxt...@tessco.com wrote:
    > I am using TCPIP services with DECnet Phase V on 2 x Itanium Blades
    > running OVMS 8.3-1H1.
    >
    > Here is the situation.
    >
    > Node 1
    >
    > SCSNode = OESTST
    > DNS Host name OESTST-TAB
    >
    > In DECNET I have it set up as
    > NodeName = oestst-tab
    > Synonym = oestst
    > -------------------------------------
    > Node 2
    >
    > SCSNODE = TABTST
    > DNS Host Name = TABTST
    >
    > In DECNET it is set up as
    > NodeName = tabtst
    > Synonym = tabtst
    >
    > I have 2 DNS servers
    > tab-dns1.myplace.com
    > glc-dns2.myplace.com
    >
    > -----------------------------
    > I would primarily like the DNS servers to provide the name resolution.
    > However the
    > DNS host names are currently set up in the local tables on each node,
    > (they are also defined in the DNS Servers coincidentally).
    >
    > how should I set up the naming information in DECNet Phase V.?
    >
    > i.e. "local,domain" or "domain", and how would I format the entries???
    >
    > Dave.



    LOCAL, DOMAIN

    LOCAL means DECnet local host file
    DOMAIN means whatever the DNS Name resolver is setup to do. Currently
    that would be the local host file but could be the DNS servers if you
    configured it like that.

  5. Re: Decnet Over IP (Phase V question).

    On Oct 7, 10:03*am, "Colin Butcher"
    wrote:
    > @net$configure in advanced mode
    >
    > Answer "local,domain" to the naming service question.
    >
    > Answer "127.0.0.1" for the name / address of the name server - actually they
    > really mean "BIND resolver". "127.0.0.1" equates to "localhost", so you
    > always query your local HOSTS database first, then it will use whatever DNS
    > nameserver list you have set up in your local IP stack. It's a useful trick
    > that doesn't seem to be documented anywhere.
    >
    > All you then do is delete the 'old' DECnet style name from the local naming
    > service (using DECNET_REGISTER) and insert the new name into the local HOSTS
    > database, then move it out to your DNS if you ever need to.
    >
    > You might find the article I wrote some time ago for the VMS technical
    > update useful, plus some of the slide sets available atwww.xdelta.co.uk/seminars
    >
    > Don't forget that you can test the connectivity without relying on the
    > naming by using things like set host ip$. You can check the
    > naming at each end by looking at the SYS$*NODE* logical names. Beware that
    > proxies work by node fullname, so expect to have to re-add your proxies.
    >
    > --
    > Cheers, Colin.
    > Legacy = Stuff that works properly!


    Hi guys,
    thanks for your replies. I appreciate your "undocumented"
    solution, however as a newbe to this I think I have to stick to the
    "proper" stuff. Anyway, here is what I have concluded from your
    joint comments,

    SCSNODE = TABTST
    DNS Host Name = TABTST
    DNS Server Name = TAB-DNS1.myplace.com


    1. @net$configure.
    2. Select option 2 (Change naming information)
    3. * Enter the directory services to use on the system [LOCAL] :
    local,domain
    4. * Enter the full name for directory service LOCAL
    [LOCAL:.TABTST] :
    5. * Enter the fully qualified host name for DNS/BIND :
    tab-dns1.myplace.com
    6. * What is the synonym name for this node? [TABTST] :


    will this do the job?? And does this have to be set up on both
    originator and destination in order to work??

    Also, once this is set up, should it work immediately, or do I have to
    wait, or flush cache, or anything?

    thanks

    Dave.



  6. Re: Decnet Over IP (Phase V question).

    Using "127.0.0.1" as the local IP name BIND resolver is not an
    "undocumented" solution in that you can enter whatever you like as the DNS
    nameserver. I'm just surprised that it's not the standard recommendation,
    because it's so easy and flexible in terms of setting up the name service
    lookup precedence order once you've jumped sideways into the IP stack.

    So, put "127.0.0.1" in as the name server, then set up the list of DNS name
    servers you wish to use in your IP stack in the usual manner. That way you
    get the HOSTS file first, followed by whatever name servers you choose to
    use. Means you don't have to go back to your DECnet configuration if you
    ever change your name servers. Easy.

    You should make consistent naming changes everywhere. In practice a
    destination node will accept inbound DECnet-over-IP connections without
    having all the naming in place, but you'll see "back translate" failures
    from the naming service until you have the naming consistent.

    You'll also need to flush the naming caches everywhere too. NCL> FLUSH
    SESSION CONTROL NAMING CACHE ENTRY "*" is what you need.

    Don't forget to enable the PWIP driver and allow ports 102 and 399 through
    the firewalls. You can also control which IP subnets you accept inbound
    connections from if you're on a recent version (can't remember which right
    now) - look at the NCL help for the rfc 1006 and rfc 1006-plus (aka rfc
    1869) OSI transport templates.

    --
    Cheers, Colin.
    Legacy = Stuff that works properly!



  7. Re: Decnet Over IP (Phase V question).

    On Oct 7, 1:17*pm, "Colin Butcher"
    wrote:
    > Using "127.0.0.1" as the local IP name BIND resolver is not an
    > "undocumented" solution in that you can enter whatever you like as the DNS
    > nameserver. I'm just surprised that it's not the standard recommendation,
    > because it's so easy and flexible in terms of setting up the name service
    > lookup precedence order once you've jumped sideways into the IP stack.
    >
    > So, put "127.0.0.1" in as the name server, then set up the list of DNS name
    > servers you wish to use in your IP stack in the usual manner. That way you
    > get the HOSTS file first, followed by whatever name servers you choose to
    > use. Means you don't have to go back to your DECnet configuration if you
    > ever change your name servers. Easy.
    >
    > You should make consistent naming changes everywhere. In practice a
    > destination node will accept inbound DECnet-over-IP connections without
    > having all the naming in place, but you'll see "back translate" failures
    > from the naming service until you have the naming consistent.
    >
    > You'll also need to flush the naming caches everywhere too. NCL> FLUSH
    > SESSION CONTROL NAMING CACHE ENTRY "*" is what you need.
    >
    > Don't forget to enable the PWIP driver and allow ports 102 and 399 through
    > the firewalls. You can also control which IP subnets you accept inbound
    > connections from if you're on a recent version (can't remember which right
    > now) - look at the NCL help for the rfc 1006 and rfc 1006-plus (aka rfc
    > 1869) OSI transport templates.
    >
    > --
    > Cheers, Colin.
    > Legacy = Stuff that works properly!


    Thanks Colin,

    One more question before I try this out. Just for testing
    purposes, I would like to stop the NAME_Service under TCPIP
    services. If I have all of my test nodes defined in the local host
    table, will this definition (i.e. 127.0.0.1) still work??? Or do I
    need the name service running to be able to query the local table.

    Dave

  8. Re: Decnet Over IP (Phase V question).

    Haven't tried it myself, so I don't know. Why would you want to stop the
    NAME service? There's only one way to find out for real...

    --
    Cheers, Colin.
    Legacy = Stuff that works properly!



+ Reply to Thread