CR vs. LF in Extreme configs

  • 0
  • 1
  • Question
  • Updated 4 years ago
  • Answered
When dealing with Extreme Summit configs (specifically, the 200 and x460), are carriage return (0x0D) and line feed (0x0A) characters functionally equivalent? It seems that the Summit devices typically end a line with CRLF (Windows-style). Are CR (only) and LF (only) functionally equivalent?

I monitor Summit configurations for a client as part of my job, and occasionally I'll see changes made to a config in which the line feed character is dropped from (or added to) a line, meaning the lines are separated only by a carriage return. Is this an important change? Secondly, how might such a change occur?
Photo of Bob

Bob

  • 130 Points 100 badge 2x thumb

Posted 4 years ago

  • 0
  • 1
Photo of Drew C.

Drew C., Community Manager

  • 40,846 Points 20k badge 2x thumb
Hi Bob,
When I "show all characters" in a config file uploaded directly from a switch (X460 on EXOS v15.4.2), Using Notepad++ in Windows, I only see the <LF>.  I don't see a <CR>.  The command I'm using is:
upload config x.x.x.x config.txt vr vr-default
EXOS is a Linux based OS, so only seeing<LF> is expected.  I'm not sure why you are seeing a <CR> in your config.  What text viewer are you using?  I noticed that Windows' Notepad seems to expect <CRLF> to drop text to the next line, otherwise it all runs together.

For more information than you probably care to know, I'd recommend taking a look at the wikipedia entry on this topic:  http://en.wikipedia.org/wiki/Newline

I think this will help answer your questions.  It doesn't answer why you're seeing <LF> being added or dropped from a line, unless your config comparison tools aren't handling the end-of-line operators correctly.

-Drew
Photo of Bob

Bob

  • 130 Points 100 badge 2x thumb
Notepad++ might be doing some smart conversion.

I am pulling config files via telnet from a Windows machine using PHP. Without any modification to the output, these files are then sent to a central server for storage over an HTTPS connection, where they are stored in a SQL Server database. The main takeaway from this is that I'm not changing or opening the configs in any GUI application; this is all CLI. While it's possible that the Windows machine or Telnet protocol is inserting CRs, this behavior would be puzzling for reasons that will become clear momentarily.

When parsing these configs, pulling them from a database where they are stored wholesale, the typical "newline" is CRLF. I know this, because rather than opening them in any sort of smart GUI application, I can read them in PHP, character by character, and print out the ASCII values of each character. Most of the time, they end in CRLF.

Now, whether they end in CRLF or just LF isn't entirely important, but what happens every now and then is that a line will end in simply CR. And occasionally, that will be the *only* change between one version of a config and the next. That is, a single line will be missing the LF character.

My ultimate question is, is this a functional change? I'm not at liberty to be playing with customer network equipment, but if I have the line:

configure vlan "SrCenter-Voice" add port 20 untagged<CR>configure vlan "SrCenter-Voice" add port 20 mac-limit no-limit

is it functionally equivalent to:

configure vlan "SrCenter-Voice" add port 20 untagged<CR><LF>
configure vlan "SrCenter-Voice" add port 20 mac-limit no-limit

If ExOS is Linux-based, I'm inclined to believe that the LF is necessary, and a CR by itself might not be considered a newline, making this a functional change. On the other hand, wouldn't the first example cause some kind of error? Doubly frustrating is the fact that this occurs in the middle of a config, with disable clipaging set, meaning that however the config is sent, the newline characters should be consistent throughout.

These switches are checked on a daily basis, and in one case, the LF character was dropped from a line on 12/10. It was added back on 1/1, and there were no other changes, so if there was some sort of mistake in the transmission and/or storage of the config, then the exact same mistake was made for 21 straight days and then randomly stopped happening.

Again, my main concern here is whether this is a functional change. If ExOS sees a <CR> and treats it as a newline, I am perfectly happy to take that into account. If we think the <CR> characters are being added elsewhere, does that mean that these lines randomly become one line and later split apart? Does that even matter? The configs are generated by the devices based on current settings, so I suppose I'm inclined to believe this entire thing is irrelevant, but I wouldn't want to make an assumption that turns out to be incorrect.


Oh, and for the record, the x460s I'm working with don't seem to be doing this. It's some – but not all of – the 200s that seem to be affected. Even curiouser, it's on the 10th of each month that the LF character disappears, and it reappears on or around the 1st.
(Edited)
Photo of Drew C.

Drew C., Community Manager

  • 40,846 Points 20k badge 2x thumb
Hi Bob,
Thanks for the detailed explanation!

It sounds like this is up to how the telnet session is handling the CR/LF characters - but that doesn't explain why it changes on the 10th and 1st.  You may want to do some replacement of these hidden characters as it's being read into PHP to ensure consistency.  Something like this?

I'll see if I can test the scenario in the lab to see if the switch interprets it properly.  Let me get back to you on this.

Regarding the S200... These aren't "EXOS" devices, they're ExtremeWare - a very different OS (though the configuration is similar).  Just so you know, the Summit 200 is also End-of-Life / End-of-Support.  You mention that some of the S200s are working fine.  Can you check if they're on the same EWare version as the ones that are not?  If you can login - use show version or show switch.  The latest version is v7.8.4b1-patch1-4.  I can try to see if there's one I can dig one up to test behavior if needed.

-Drew
(Edited)
Photo of Bob

Bob

  • 130 Points 100 badge 2x thumb
According to show configuration's output, both the working ones and the weird ones are running
Software Version 7.1e.2 (Build 1)   By Release_Master on Tue 07/13/2004

I'm aware this is not the latest version, and I thank you for the information regarding EOL support; I'm sure we're already trying to sell this client newer hardware, but... it is what it is. :)

If a <CR> line break is equivalent to <LF> or <CR><LF>, it'll be easy to filter out. I just want to make sure that, before I do, the two are functionally equivalent.
Photo of Drew C.

Drew C., Community Manager

  • 40,846 Points 20k badge 2x thumb
Hi Bob,
I did a quick test in the lab trying to load a few config commands as a script, with the EOL operator being adjusted in Notepad++.  I transferred the files to the switch with TFTP.  This is on an X440, running EXOS.
Using just <CR> as a separator did not work.  EXOS interprets it as a long single line:
* X440-8t.50 # load script eoltestCR.xsf
%% Unrecognized command: "create vlan "test1"create vlan "test2"configure vlan test1 add ports 1-2 untagged configure vlan test2 add ports 3-4 untagged "
<LF> and <CR><LF> both loaded fine.

I don't know how an EWare S200 will behave.  I may be able to test this tomorrow if you'd like.
Photo of Bob

Bob

  • 130 Points 100 badge 2x thumb
Would be much appreciated, thank you.
Photo of Drew C.

Drew C., Community Manager

  • 40,846 Points 20k badge 2x thumb
Hi Bob,
Sorry to have kept you waiting.  When I tested with the S200, I saw that the default EoL Operator is <LF>, just like in EXOS.

The switch wasn't very happy with me loading the full config with the EoL Operator changed to just <CR>.  ExtremeWare loads new configurations at bootup (there's no "load script" option) and there were lots of errors thrown due to the configuration appearing as one very long line.

<CR><LF> worked fine.

Hopefully this helps answer your questions.  If not, just let me know!

-Drew
Photo of Bob

Bob

  • 130 Points 100 badge 2x thumb
I believe so, thank you!