# How to use vale-ctl?



## Farhan Khan (Nov 18, 2017)

I can't make heads or tales of the vale-ctl command. My goal is to create a virtual switch, and then attach epairs to them, then pass those epairs to jails and see if they can communicate without setting up routing.

Compiled as follows:
`cd /usr/src/tools/tools/netmap
make vale-ctl`

I (think) I am creating a virtual switch as follows:
./vale-ctl -n vswitch0

There are some kernel messages of the recently created switch. Then -l flag merely displays the help menu. I tried to attach an interface, but received an invalid argument as follows:

`root@fbsdnetwork:/usr/src/tools/tools/netmap # ./vale-ctl -d em0 
em0: Invalid argument
root@fbsdnetwork:/usr/src/tools/tools/netmap # ./vale-ctl -d em0 vswitch0
Usage:
(snippet)`

Any ideas? I have not been able to find _any_ documentation on this tool or how virtual switches work on FreeBSD.

Thank you


----------



## Farhan Khan (Mar 30, 2018)

Hi all,

Took me a while, but I figured it out. The syntax does not appear to be documented anywhere. In the below example, I am creating a switch called 'vale0' and adding the vnet interfaces epair7a and epair8a.

`[root@server /usr/src/tools/tools/netmap]# make vale-ctl
(snippet!)
[root@server /usr/src/tools/tools/netmap]# ./vale-ctl -h vale0:epair7a
[root@server /usr/src/tools/tools/netmap]# ./vale-ctl -h vale0:epair8a`

This creates a switch called 'vale0' and adds the interfaces epair7a and epair8a to it. After this, I had connectivity between them.

I have not been able to get tcpdump working in a jail, but based on how a bridge works, two jails on different bridges would be receive another jail's frames/packets, whereas a virtual switch should prevent that.


----------



## Phishfry (Feb 3, 2019)

When I ran `make` it placed the compiled program and its object file in another directory:
/usr/obj/usr/src/amd64.amd64/tools/tools/netmap/vale-ctl

I have also created the vale switch with bhyve:
https://gist.github.com/gonzopancho/f58516e98f6c8a5a3013

Shows up as a 10G interface in the client:

```
vtnet0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
        ether 00:a0:98:a2:2d:09
        media: Ethernet 10Gbase-T <full-duplex>
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
```


----------



## Phishfry (Feb 3, 2019)

I was expecting quicker times on a software switch.

```
ping 192.168.222.1
PING 192.168.222.1 (192.168.222.1): 56 data bytes
64 bytes from 192.168.222.1: icmp_seq=0 ttl=64 time=0.635 ms
64 bytes from 192.168.222.1: icmp_seq=1 ttl=64 time=0.280 ms
64 bytes from 192.168.222.1: icmp_seq=2 ttl=64 time=0.397 ms
64 bytes from 192.168.222.1: icmp_seq=3 ttl=64 time=0.317 ms
64 bytes from 192.168.222.1: icmp_seq=4 ttl=64 time=0.351 ms
64 bytes from 192.168.222.1: icmp_seq=5 ttl=64 time=0.364 ms
64 bytes from 192.168.222.1: icmp_seq=6 ttl=64 time=0.395 ms
64 bytes from 192.168.222.1: icmp_seq=7 ttl=64 time=0.286 ms
64 bytes from 192.168.222.1: icmp_seq=8 ttl=64 time=0.388 ms
```
350ms average is not very quick is it? I see that on my local hardware.


----------

