Category Archives: labs

Vyos first impression

So just started playing with Vyos, a community fork of Vyatta. Vyatta, now owned by Brocade, is a Linux, Debian based firewall / router distro running on X86 hardware. Renamed to Vyatta, a Brocade company, Brocade sell subscription models and appliances, built round the system. Vyatta has a webgui but the command line structure is I gather based on Juniper Networks Junos. A popular rivle to Cisco’s IOS.

Vyos is freely available and like it’s commercial cousin, runs on X86 hardware and a variety of virtulisation platforms. For my purposes I’ve just installed it to a VM under VMware Workstation. It is apparently possible to install to compact flash card for use in single board PCs, such as the PC Engines Alix. However the usual problem of limitting writes to that media apply, so logs need to be redirected.

At time of writing I’m using Vyos Helium, the second major release. V1.1.0. There is no webgui implemented yet, which personly suits me fine. Command line tools have a higher learning curve but are so much faster once you know them. The on board CLI help, like Cisco IOS is very useful. With the usual “?” offering options for the given mode. Yes like Privileged Exec and Global Configure, the familiar dropping into modes to perform sets of tasks applies here. The “configure” command gets you to global config. Changes are only applied once the “commit” command is given and “save” stores to disk.

One of my reasons for wanting to try Vyos, aside curiosity, is that I’ll be working on some Ubiquiti routers shortly. Their Edge OS is another fork of Vyatta and shares the same command syntax, at least thus far.

I’d say I like Vyos a lot at this point except for one major nag. That is, I’m not currently abel to get my Vyos VM working with VMware Virtual Network Adapters in Workstation. So I can’t connect this VM to the rest of my internal virtual networks. This maybe a misunderstanding on my part, some setting I’ve missed or possibly only works on VMware VSphere. The bare metal hypervisor. This is a great shame. I’ve posted to the Vyos forums but not had a reply. Anyway, will continue nosing around this issue.

VMWare Virtual Network Lab Setup

Example virtual lab using VMWare. I’ll refer to this as Vlab 1 in case I mention it in latter posts.

The general objective is to set up a small virtual network on which I can build. The virtual machines on the network will access the real network and thus the internet through one of them acting as a gateway.

I’m using 4 headless VMs, all running the Debian based Voyage Linux distro, which is tailored for router applications.

One of these VMs will be bridged to my real LAN, the one simulating an internet gateway. It will perform NAT for the networks behind it on the virtual side.

As an aside, these are running single area OSPF with the Quagga router software but I’ll just talk about the basic interface setup in this post.

Let’s call the 4 Voyage routers alpha, beta, gamma, delta. For what it’s worth, they are all installed in 2GB virtual disks, have one processor core each and 256MB RAM.

Alpha will be the gateway. i.e. the one with a bridged interface to the real network. The 4 VMs are connected in a simple line. Alpha – beta – gamma – delta.

In VMWare’s Virtual Network editor, I’ve configured 3 Vnets for these links. For some reason, it seems you can’t use a /30 subnet for Vnets. Which would be the usual point to point link. Virtual Network Editor just won’t allow it. SO I’m using /29’s.

In my case, Vnets 11, 12, 13.

Vnet 11. 172.16.1.0/29
Link between alpha and beta.

Vnet 12. 172.16.1.8/29
Link between beta and gamma.

Vnet 13. 172.16.1.16/29
Link between gamma and delta.

Alpha has 2 interfaces, one on the real LAN.
192.168.1.2

And the Host Only Custom link to beta.
172.16.1.1

The rest are all Host Only Custom links in their respective Vnets.

Beta – alpha:
172.16.1.2

Beta – gamma:
172.16.1.9

Gamma – beta:
172.16.1.10

Gamma – delta:
172.16.1.17

Delta – gamma:
172.16.1.18

Notes:

I have to be organised in how I set these up, more so than perhaps most people. As they’re running headless, no desktop, they have no screenreader running. It may be possible to recompile Voyage with Speakup but that’s beyond me at the moment.

Normally when I’m experimenting with say a single virtual server, I’ll have one interface bridged to my real LAN so I can use my screenreader on the host and SSH in. In this case, I want to force all traffic through the virtual gateway and only have that machine appearing on the LAN. So to reach the others, I need to make sure the routing is setup as I’ll be SSHing to the gateway and hopping from there. As there’s no screenreader on the VMs I can’t just type at the consol.

How I’ve done this is initially set up all VMs with one bridged interface so I can connect and configure the other Host Only connections by editing /etc/network/interfaces. Once I know these are up and reachable from the other VMs, I shut down the bridged interface and comment it out.

As mentioned I am using OSPF and having alpha redistribute the default route that leads out on to the LAN. Were this not the case, I could have used a line in interfaces to set a static default route pointing to the Host Only interface. i.e. through the virtual network towards alpha and the real world.
Post-up route add default gw x.x.x.x

Whilst setting these up it might be worth noting, I did manage to mess up my SSH config file on one of the Vms after I’d already shutdown the bridged interface. Effectively locking myself out due to the no screen reader access on the consol. I fixed it by SSHing into another Voyage VM and counted down how many lines the errant line was. Then did this blind on the misconfigured machine. Cleverer people than I might have used Sed and Grep in some fancy way to fix it…

Links

VMware

Voyage Linux