Underscore in the node name leads to "Invalid name detected" message

[andrei-korshikov]

Describe the bug This issue is a bit intermittent. When you put underscore in the node name, you get "Invalid name detected for this device" (or "Invalid name detected for IOU node" in case of IOU) message. But, sometimes, you can rename. QEMU node can be renamed via "Node properties" dialog (Right Click - Configure), but can't be renamed via Right Click - Change hostname or label editing. IOU node can't be renamed by any means.

GNS3 version and operating system:

• OS: Linux
• GNS3 version: 2.2.43
• No use of the GNS3 VM or remote server (GNS3 installed in venv via pip)

To Reproduce

• Put underscore in the node name (especially via "Change hostname" or label editing).
• Try to save.
• See "Invalid name detected" message.

Screenshots

Additional context Indeed, some devices don't allow to put underscores in their hostnames. From my experience, if I remember correctly, there are Cisco PIX, Cisco ASA, APC/Schneider Network Management Cards, and so on. But there are plenty of underscore-friendly devices)

At least, I would like to emphasize two cases:

1. Underscores in Cisco IOS are perfectly valid (see screenshots above). So IOU nodes must accept underscores in their names.
2. Disallowing underscores in QEMU node names is senseless. We don't know if guest system allows underscores, and we can't change configuration inside VM anyway, so the user has to alter the hostname inside VM manually, so why don't allow them to put AWESOME_NODE_NAME in GNS3 GUI:)

[grossmj]

For IOS and IOU, we follow the rules for ARPANET hostnames:

They must start with a letter, end with a letter or digit, and have only letters, digits, and hyphens as interior characters. Names must be 63 characters or fewer.

For Qemu and Docker, we follow the rules in RFC 1123:

Each element of the hostname must be from 1 to 63 characters long and the entire hostname, including the dots, can be at most 253 characters long. Valid characters for hostnames are ASCII letters from a to z, the digits from 0 to 9, and the hyphen (-). A hostname may not start with a hyphen.

Many websites tell us the underscore aren't supported however I found this:

The use of underscores in hostnames violates RFC 1123's valid defined characters for a domain name. However, in practice, the global DNS system allows underscores to be used in hostnames.

Also, I found this warning while looking if we should accept underscore:

Don’t use underscores ( _ ) in router names. They are hard to type, often lead to confusion, and aren’t legal in Domain Name System (DNS) names. Use a hyphen (-) instead. Similarly, avoid mixing upper- and lowercase. Instead of “routerOneNewYork”, use “router-one-newyork”. The router won’t care, but your users will!

It sounds like we would be asking for problems if we allow users to have underscores in device names.

[andrei-korshikov]

Long story short:

• the standard for hostname (RFC 1123) clearly doesn't allow _ (because teletype keyboards back in the day often did not have this symbol)
• some popular software (notably Windows) does allow _
• it is impossible to copy real-world network with illegal (but perfectly working in that environment) names onto GNS3 canvas

My main idea is not about breaking the rules (I personally strongly prefer to follow the standards), but about impossibility to mimic the real world. Imagine, you know that your favorite router has the name "router_a". You've seen this name for years in the CLI. You've get accustomed to it. And now you decide to lab some aspects of your network in GNS3, and see that "router-a" O-O so awkward... so imperfect... so irritating... Unfortunately, that's all about perception, which is illogical by the nature of human beings:D

@grossmj I see your points, and now I do agree that just enabling _ might (and certainly will) create some chaos. So, if it is possible, I would suggest to add per-project (or even per-node) option for disabling hostname checking (with big red warningD), so experienced users can shoot in their feet.

Also, such option would open very attractive possibility: disjoint the ideas of hostname and label. What we see on the canvas above the node picture is the label. And it can be any UTF-8 string. And hostname is just node property, it is somewhere in node's configuration. For example, I can create a bunch of virtual routers (logical systems and routing instances) inside my Juniper vMX QEMU node, and imagine it is the ISP. I don't care about the hostname of main QEMU node, and it would be nice to have label "My Favorite Service Provider" on the GNS3 canvas.

In my experience I've seen extensive usage of underscores in big corporate environment. Windows hosts, Microsoft DNS server, Catalyst switches - so, no visible problems (at least until they try to communicate with illegal named stuff from Linux boxes). Of course, in simple situation like "core-a", or "switch-021", or "region-location-number" there is no need for underscores. But what if you need to subdivide your hostname into visible, distinguishable groups, which are further divided into subgroups? Like REGION_SUBREGION-LOCATION_SUBLOCATION-NUMBER, or REGION_NAME-LOCATION_NAME-NUMBER. If you need several distinguishable words in a part, underscores seems quite natural (like in Python function/variables naming convention). Yes, I understand (and do agree), that if we are talking about parts and sub-location, the better idea is to use DNS subdomains. Unfortunately, the group who controls the DNS server might disapprove subdomain creation.

For IOS and IOU, we follow the rules for ARPANET hostnames

I've seen that comment in the source code:) And I know the roots) Now quote from Command Reference for IOS 15.0: "The name must also follow the rules for ARPANET hostnames. ... Creating an all numeric hostname is not recommended but the name will be accepted after an error is returned." They added support for numeric hostnames somewhere in 15. And, frankly, their words about ARPANET (RFC 952) rules are just misleading, they support RFC 1123 (leading digits, like "3com") for ages.

the global DNS system allows underscores to be used in hostnames underscores ... often lead to confusion, and aren’t legal in Domain Name System (DNS) names.

This rabbit hole is a bit deeper than we might think:) There are several controversial opinions:

• RFC 1034 Section 3.5 (Preferred name syntax) does allow _: "The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes."
• RFC 1034 Section 3.5 (Preferred name syntax) does NOT allow _: "However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. ... The labels must follow the rules for ARPANET host names."
• RFC 2181 Section 11 (Name syntax) allows _: "The DNS itself places only one restriction... the length of the label and the full name. ... Those restrictions aside, any binary string whatever can be used as the label of any resource record. ... If the client has ... restrictions, it is solely responsible for validating the data from the DNS."
• some people still believe that RFC 2181 Section 11 is not about A-records anyway

So DNS servers and DNS clients implementers have to choose their bandwagon. In the Internet and Unix-like systems world they usually prefer to disallow _. Microsoft created their own rules. Catalysts (IOS) support _ for at least 20 years, I think because of pressure from corporate (Microsoft DNS servers/clients) environment.

[grossmj]

So, if it is possible, I would suggest to add per-project (or even per-node) option for disabling hostname checking (with big red warningD)

I am going to implement this (per-project). Thanks 👍

[grossmj]

Also, such option would open very attractive possibility: disjoint the ideas of hostname and label. What we see on the canvas above the node picture is the label. And it can be any UTF-8 string. And hostname is just node property, it is somewhere in node's configuration. For example, I can create a bunch of virtual routers (logical systems and routing instances) inside my Juniper vMX QEMU node, and imagine it is the ISP. I don't care about the hostname of main QEMU node, and it would be nice to have label "My Favorite Service Provider" on the GNS3 canvas.

I realized I moved the node name checks to the controller side in version 3.0... So now I am thinking it would be a better long term solution to have the disjoint ideas of hostname and label as you suggested. I would keep the current node name as the label and add a hostname field to allow users to set a custom one. Does this sound good?

[andrei-korshikov]

keep the current node name as the label and add a hostname field to allow users to set a custom one

I had exactly the same thoughts. Yes, I think it sounds good.

[grossmj]

Given the amount of changes, I prefer to implement the disjoint ideas of hostname and label in version 3.x

However, in the meantime starting with version 2.2.48, you can tick the "Enable experimental features" option in the preferences, this will disable the hostname checks.