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 _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/NVTJ3N34FYGE6JH6N2AKGEEPJDUPVYU6/
