Crazy error message when SSH’ing from vManage to vEdge

Back story here is I did a factory reset on the software via the command line (#request reset configuration).  After the reload and new ZTP pull I tried to connect to the vEdge via SSH from the vManage command line.

I got the following error:

# request execute ssh username@x.x.x.x

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that a host key has just been changed.

 

This is caused by the SSH hash changing after the new config was applied.  This is to be expected.  I had to have support fix it.  I will update this post when I get a clear response on what they did to fix it.

You have to love the “SOMEONE IS DOING SOMETHING NASTY”.  Never in my wildest dreams did I think I’d see that in production code. 🙂

UPDATE:  To fix this error you need to delete the offending device information from the host file.

Cool power off command

Unlike Cisco routers, you power off your Viptela router via the command line.

Why would I not just pull the plug like with Cisco devices?  Excellent question.  It turns out that just pulling the plug “MAY CAUSE DISK CORRUPTION”.  Therefore use the poweroff command.

The shutdown will look like the following:

# poweroff
Are you sure you want to power off the system? [yes,NO] y
Stopping processes and shutting down
vEdge#
Broadcast message from root@vedge (Mon Nov  9 22:28:47 2015):

The system is going down for system halt NOW!
INIT: Switching to runlevel: 0
Stopping viptela daemon: sysmgr.
Deconfiguring network interfaces... done.
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Unmounting remote filesystems...
Deactivating swap...
Unmounting local filesystem...
System halted.

Read more about from Viptela documentation Power Off Command

 

 

How to capture traffic on an interface

Yes you are able to capture traffic on an interface of an Viptela router.

Just type the following command:
#tcpdump vpn 0 interface ge0/1 options “-v -n host 52.88.169.126”
tcpdump -i ge0_1 -s 128 -v -n host 52.88.169.126 in VPN 0
tcpdump: listening on ge0_1, link-type EN10MB (Ethernet), capture size 128 bytes
19:17:47.492894 IP (tos 0x0, ttl 44, id 22942, offset 0, flags [DF], proto TCP (6), length 52)

The above command will show you all the traffic from  and to the host with IP address 52.88.169.126

You can also change that above command slightly and you’ll be able to see different protocol traffic.  The following command will show protocol 17 traffic.

# tcpdump vpn 0 interface ge0/1 options “-v -n proto 17”
tcpdump -i ge0_1 -s 128 -v -n proto 17 in VPN 0
tcpdump: listening on ge0_1, link-type EN10MB (Ethernet), capture size 128 bytes
19:17:12.988857 IP (tos 0xc0, ttl 64, id 35275, offset 0, flags [DF], proto UDP (17), length 156)
10.60.6.50.12426 > 52.88.63.222.12346: UDP, length 128
19:17:12.988953 IP (tos 0x0, ttl 64, id 26577, offset 0, flags [DF], proto UDP (17), length 44)
10.60.6.50.12426 > 52.44.221.238.12346: UDP, length 16

 

How to configure vEdge via command line when attach to vManage

If you try and configure a Viptela device via the command line while a template is attached to it in vManage you get the following error:

Aborted: ‘system is-vmanaged’: This device is being managed by the vManage. Configuration through the CLI is not allowed.

To get around this you’ll need to call support because no one will give you the password needed.  But here are the commands that will let you over ride the vManage attached template.

# unhide viptela_internal
Password: ************   >>NOTE this password changes every time a new version of code is released

(config)# no system is_vmanaged

After this you can configure via the command line to your hearts content.

What ports are needed for Viptela to work

The ports needed for Viptela vEdge physical devices to make DTLS connections to the controller are:

• Port 12346
• Port 12366 – Delay of 1 minute
• Port 12386 – Delay of 2 minutes
• Port 12406 – Delay of 5 minutes
• Port 12426 – Delay of 6 minutes

If you are using the virtual machine vEdge then the ports needed are:

Core Number	Ports for DTLS (UDP)	Ports for TLS (TCP)
Core0	12346	23456
Core1	12446	23556
Core2	12546	23656
Core3	12646	23756
Core4	12746	23856
Core5	12846	23956
Core6	12946	24056
Core7	13046	24156

This is assuming that you do NOT have port-offset configured.  By default the physical devices jump 20 ports for every interval try.

source information:  Viptela documentation