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 <[email protected]> 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@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@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 _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
