[j-nsp] Change in host-name / domain-name behaviour - LLDP System Name / SNMP sysName

[James Stapley]

Not sure if we're the first people to notice this, but there seems to be a
change in the way Junos deals with FQDN, host-name and domain-name with our
latest kit.

tl;dr:
On MX204, running 18.1R3-S2.5, LLDP System Name and SNMP sysName are not
consistent, with LLDP System name having the domain-name appended to the
configured host-name, but SNMP sysName not doing so.

On all our other Juniper gear (MX10, EX4200/4300/4550) - apart from
recently commissioned MX204s, which just replaced the MX10s -  we have
host-name set as the relevant FQDN (my longtime FreeBSD sysadmin colleagues
tell me that's normal for FreeBSD systems, but not Linux ones, which
normally have a "naked" hostname).

The other older Junipers all run Junos 15.X versions, and the equally
recently installed EX4600s running on 17.X also behave "as expected".

The MX204 routers that are behaving "strangely" are running 18.1R3-S2.5.

I first noticed this on LLDP neighbours, where the MX204s are showing up as
something along the lines of:<FQDN>.<domain-name> ... which is odd.
In other words, it's taking the FQDN host-name we've set and appending
domain-name to generate its LLDP System Name:

 user at ammedge> show lldp neighbors
Local Interface    Parent Interface    Chassis Id          Port info
  System Name
xe-0/1/1           -                   44:xx:xx:xx:xx:xx   534
  strubenedge.net.ru.ac.za.net.ru.ac.za
xe-0/1/0           -                    44:xx:xx:xx:xx:xx     541
      strubenedge.net.ru.ac.za.net.ru.ac.za

<snip>

In the above example, the FQDN host-name is set as strubenedge.net.ru.ac.za,
and the domain-name is configured as strubenedge.net.ru.ac.za. (this
domain-name appending behaviour does not extend to SNMP sysName).

Configuring host-name as a "naked" (non-FQDN) hostname [which the Junos
documentation around host-name strongly hints is expected] shows then the
expected behaviour in LLDP on the MX204 platform:

user at strubenedge> show lldp neighbors
Local Interface    Parent Interface    Chassis Id          Port info
  System Name
xe-0/1/0           -                   44:xx:xx:xx:xx:xx     534
    ammedge.net.ru.ac.za
xe-0/1/1           -                   44:xx:xx:xx:xx:xx     535
    ammedge.net.ru.ac.za
<snip>


But then in SNMP, it is not appending the domain-name:

snmpget -Pu -v2c -c<secret> ammedge.net sysName.0
SNMPv2-MIB::sysName.0 = STRING: ammedge


My understanding of snmp sysNAME is that it should be displayed as a FQDN:

sysName OBJECT-TYPE
     SYNTAX      DisplayString (SIZE (0..255))
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
             "An administratively-assigned name for this managed
             node.  By convention, this is the node's fully-qualified
             domain name.  If the name is unknown, the value is
             the zero-length string."
     ::= { system 5 }


So  in 18.x, it seems you can either "break" SNMP sysNAME or LLDP System
Name.

In previous versions/platforms, having host-name configured as a FQDN and
domain-name set worked as expected (FQDN reported on LLDP and SNMP
correctly).

This seems a significant change in behaviour (albeit one that is probably
minor in scope/impact for the average person), which we didn't see
mentioned in release notes. I suspect in a era of increasing automation,
predictable (and consistent) answers to LLDP and SNMP queries might be
important. :)

In the older versions/platforms, it seems to report whatever you set as
host-name for both those fields, and seems not to append the domain-name.
I've not spent a huge amount of time testing the older ones that work "as
expected".

I suspect both these fields ought to report whatever is configured as
host-name, without any mucking about with appending whatever is configured
as domain-name for the most "predictable" behaviour - and this seems to be
what used to be the case in the past.

Not sure I'll get anywhere reporting this through our support partner (or
manage for them to pierce Tier 1 in turn...), so I thought this might be a
good place to post this info.

Thank you!

-- 
James Stapley
Network Architect
Information & Technology Services, Rhodes University
t: +27 (0) 46 603 8849
PO Box 94, Grahamstown, 6140, South Africa
www.ru.ac.za