SSH Sessions Hang on various commands!


#1

Hello,
I’ve been running Vyatta then Vyos virtual routers for about 2 years now and upgraded an older 6.6 vyatta to Helium (Vyos) running ospf and BGP.
Im running the vyos image with 3 gig of ram and a single 64bit vm.
It runs fine until i pull in a full internet feed! It then starts hanging on various commands via ssh. I can run all these commands locally on the console with no problem. Below is a list of commands that cause the session to hang and not come back!
show ip bgp (this is a huge list of prefixes)
show config commands
show ip route | grep 1.1.1.1

I see that the ssh session is using vytsh -c “command” syntax by looking at the process task list. Is there a setting to possibly give vtysh more memory? Or is this another problem. Has anyone else see this type of problem.

When i disable bgp peering the problems go away!
Any ideas would be helpful!
Thanks,
Pat


#2

show ip bgp
show ip route | grep 1.1.1.1

Very, very bad idea to make route lookup. Why not use “show ip route 1.1.1.1”/“show ip bgp 1.1.1.1” instead?
Your command takes all routes from RIB, sends full output to grep, and then grep lookup for simple text pattern match, instead of LPM search done by quagga, which is much faster and safer.


#3

I understand that this is a memory intensive process but It works fine via the console and not via and ssh session. It also hangs on sho ip route | grep 1.1.1.1
as well and show ip bgp 1.1.1.1?


#4

I found the fix! I also noticed that I was getting intermitten pauses of traffic as well.
This was a famliar behavior to some other servers in my vm environment! This router is, after all a VM! I redeployed a new blank vm. I created it via a custom type.
I uses vmware configuration type of 7 i made sure that the interfaces were using the E1000 drivers instead of the vmx3 drivers. I also made sure it was using the buslogic basic lsi driver as well. the rest of the system is the same. I then configured the new router vm the same as the old one and its been running for about an hour so far with no issue! I suspect anyone having similiar issue should first identify if its a vm.
If so set it back to a vmware type 7 config and use the e1000 drivers instead and buslogic drivers for disk. The performance is quite a bit faster as well! [/b]