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

[James Stapley]

A dirty hack to move behaviour back to expected is to put the host-name in
as a FQDN and delete domain-name.
Seems not to affect anything else (domain-search helps resolution of naked
hostnames in commands), and both LLDP and SNMP report the same value.

On Mon, 14 Jan 2019 at 12:56, James Stapley <j.stapley at ru.ac.za> wrote:

> 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
>


-- 
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