CSR1000v - Extra line/carriage return in telnet

[jordan.wimberley]

I'm running into a weird issue with a few CSR1000v routers running on ESXi 5.1.  I've created 10 VMs and of those 10 instances, I have 1 router that seems to insert an extra line (or carriage return) in the CLI whenever I hit 'enter'.  This issue has followed between SecureCRT and PuTTY.  I am also unable to use the 'tab' key, up or down arrows for history, and the '?' does not generate output until I hit 'enter'.  A few examples follow:

Router>
Router>en
en
Router#
Router#

Up arrow:

Router#^[[A

Down arrow:

Router#^[[B

Tab key:

Router>^I

I am utilizing the "platform console serial" setup and telneting to my ESXi server address with port number, ie: 172.100.100.2:2003 for Router3.  If I telnet between my routers (R1 telnets to an IP on the CSR's interface), the issue does not follow.  However, now as I create my 11th and 12th VM, I am seeing the extra line in sessions when outputting the the console to serial.  

Anybody ever run into this before?

[kevin.szatkowski]

Jordan, I suspect that it has to do with your terminal setup.  Can you post your putty and secureCRT settings?  I'll try to replicate though I don't have a esxi sitting around but the csr should act the same.

Regards,

Kevin

[jordan.wimberley]

Hi Kevin,

I've attached a couple screenshots of my SecureCRT settings.  However, I have used the default settings for all sessions, except for troubleshooting due to posted issues.

I would expect the issue to follow to other sessions if there was a misconfigured setting.

I did come across this post -

https://s2-forums.vandyke.com/showthread.php?t=11113

which suggested the fix referenced here -

https://s2-forums.vandyke.com/showpost.php?p=11835&postcount=6

However, this has not resolved the problem.  I have rebooted the ESXi host to see if there was some transient issue, but no change - 9 out of the 10 original sessions work fine.  If the issue had not followed to PuTTY, I would have contacted support for SecureCRT.

[kevin.szatkowski]

Ok, I'll try tomorrow. The reason I think it's the terminal is because once you telnet from one router to the next, the issue doesn't follow.  So it seems to be a terminal emulation issue but who knows...

Kevin

[jordan.wimberley]

Thanks!  I would agree - and to narrow it a little bit further, maybe...

My ESXi host is 192.168.1.2/24.  I reach these routers via the "serial port", as indicated in the original post (telneting to 192.168.1.2:200x).  This is when I see the issue on the one problem router (plus new routers now).

If I put an IP address on Gi3 within the same subnet, place it in the same vSwitch, and telnet directly to that IP (via SecureCRT with same settings), the additional line return does not show up as it did with the console-to-serial session.  The routers that were previously unaffected still remain unaffected, utilizing the console-to-serial session.

I've also tried a slightly older code version for the CSR1000v and the issue followed there for new VM install, also hinting towards the terminal.

[kevin.szatkowski]

Jordan,

     I tried a CSRv1000 fresh (I don't have ESXi just player) with putty and messed with the "Terminal Settings"  "Implicit LF in every CR" and  "Implicit CR in every LF", which gives the same results as carriage returns is happening to you but it follows if you telnet/ssh to another device.  So I would check but I don't believe this is what is happening.

Based on you statement the if you telnet between CSRs the problem doesn't follow I would say it's a VMware ESXi issue in the way they implement serial ports.  Somehow between you typing and the vm getting the characters it's getting messed up.  In the vmx file for the CSR is there a "serial0.hardwareFlowControl = "TRUE"" statement? I couldn't really find much to make sure their doing the 8 none and 1.  This is my best guess.  When I google'd around I came across an example for a CSR ESXi install and it too contained the extra returns. 

I hope you have support with VMware or you can try opening a support discussion on VMware's site.  I would just setup SSH and use the network vs telnet.  Sorry I couldn't help you more.

Regards, Kevin

[jordan.wimberley]

Hi Kevin,

I believe I have found the solution after you pointed me in the right direction.  I went to the datastore and downloaded the relevant .vmx file to take a look.  I did not see the statement you listed, but I did see the following serial0 statements -

serial0.present = "TRUE"
serial0.yieldOnMsrRead = "TRUE"
serial0.fileType = "network"
serial0.fileName = "192.168.1.2:2007"

Compared to a working VM:

serial0.present = "TRUE"
serial0.yieldOnMsrRead = "TRUE"
serial0.fileType = "network"
serial0.fileName = "telnet://192.168.1.2:2001"

Not sure how the "telnet" portion was being left off during the setup, but I added it to the .vmx file and uploaded to the datastore.  Started the VM up and the extra return line is gone.  I repeated this process again for another new instance that was having the same issue - problem resolved again.

Now that I know the fix, I'll have to see if I can figure out why it's not being added to new machines.  Nonetheless, thanks for the vmx hint!

[kevin.szatkowski · Accepted solution]

Great news!  Mark it as solved for others to find.  Kevin

[rylynch]

FYI, this solved my issue as well.

[rikerrobert]

I had a similar issue. I checked the serial configuration of the serial port and realized I had omitted the "telnet://" from the 10.255.1.81:2301, added the telnet://10.255.1.81:2301 and the second carriage return went away! Thanks for the pointer!