On Sun, Sep 07, 2025 at 07:55:02PM +0300, Martin Tonusoo wrote:
Older versions of Junos incorrectly interpret the first byte of the Shutdown Communication as a character in the message, instead as the length field.
Thanks, I can confirm this.
Cheers.
However, I also noticed that one can deliberately/accidentally inject control characters to Shutdown Communication field and Junos would return those control characters in its NETCONF response. For example, let's say that I send a following valid cease NOTIFICATION message to a Juniper router running Junos version 25.2R1.9:
Border Gateway Protocol - NOTIFICATION Message Marker: ffffffffffffffffffffffffffffffff Length: 34 Type: NOTIFICATION Message (3) Major error Code: Cease (6) Minor error Code (Cease): Administratively Shutdown (2) BGP Shutdown Communication Length: 12 Shutdown Communication: \vmaintenance
ff ff ff ff ff ff ff ff ff ff ff ff ff ff .............. ff ff 00 22 03 06 02 0c 0b 6d 61 69 6e 74 65 6e ...".....mainten 61 6e 63 65 ance
As seen above, the 0x0c is the length of the Shutdown Communication field in octets and the "0b 6d 61 69 6e 74 65 6e 61 6e 63 65" is the message. Calling the "get-bgp-neighbor-information" or "get-bgp-summary-information" RPC on that router would include the character 0x0b, which is invalid in XML 1.0.
The Shutdown Communication is _supposed_ to only contain valid UTF-8, but of course neighbors can put any bytes they want on the wire (as you noticed!). If I worked at Juniper/HPE ... I'd use something like strnvis() to sanitize the (untrusted) network input contained within a Shutdown Communication. See the documentation here https://man.openbsd.org/vis.3 This is what OpenBGPD uses in order to avoid logging raw control character sequences into the router's syslog facility. Running the sequence you provided through a command line utility that calls vis(), one can see that the non-printable character is replaced by an encoding which uses a backslash ‘\’ character to introduce special sequences. Vis encoding is a unique, invertible representation composed entirely of graphic characters. Perfect for stuff like this! $ echo 0b6d61696e74656e616e6365 | xxd -r -ps | hexdump -C 00000000 0b 6d 61 69 6e 74 65 6e 61 6e 63 65 |.maintenance| 0000000c $ echo 0b6d61696e74656e616e6365 | xxd -r -ps | vis \^Kmaintenance $ echo 0b6d61696e74656e616e6365 | xxd -r -ps | vis | hexdump -C 00000000 5c 5e 4b 6d 61 69 6e 74 65 6e 61 6e 63 65 |\^Kmaintenance| 0000000e In any case, it is the vendor duty to not emit invalid XML... I recomend you reach out to JTAC-- because from what you shared it seems there is more work to be done in the Junos implementation. Kind regards, Job