One of my readers asked me what platform I use for my docker containers in the lab. He assumed it is one of the public cloud platform providing such service. This is not true. I run few containers in public cloud, but this is not cost-optimal for lab tests. Especially in the way I sometimes work, when there might be few hours gap between the tests. I run all the containers locally on my own infrastructure which does not consist of few racks in mine basement. Actually, it is very small, so it has to be resource-optimal. I decided that for now, VMware Photon OS Project is the best solution for me.
You learn new things every day. Quite often by accident because something is not working as you expect or it just stopped working. This is one of those situations where I learned to be careful how to use container names using docker-compose and how containers refer to each other names. This is very important if they share the same network.
To perform some tests I created a lab where I run Ansible AWX (the free Ansible Tower version) and Netbox IPAM. I decided to use docker-compose because it gave me an easy way to manage the lab. By default, both AWX and Netbox is put in dedicated Network just for the containers of each installation. This means the isolation – the desired way you want to run containers. But in my lab, AWX need to talk to Netbox API to pull inventory. Because it is my lab I did the simplest thing.
Best way to learn Ansible and the whole idea of automation is to start from the small playbooks and then grow big. If you first automate simple tasks, even those that may be easier and quicker to perform from the command line, you will learn how Ansible is working. Let’s say, we want to test if SNMP is responding on the remote host (we name it HostA). We will use SNMPv3 and authPriv security model. And of course, we want to write the Ansible playbook and run it on server HostNOC.
Sometimes you want to add a new interface to existing virtual router. I am sure everyone will agree with me that creating new virtual router from scratch and then moving the running configuration on it is far away from flexible approach – you want to modify existing instance. Adding new interface on vSRX on VMWare Workstation should be as simple as adding new PIC card on the physical device. There is just one thing you need to remember about.
First, you need to power off your virtual machine. At such point, I usually also make a snapshot of the VM in case of any problems. Then add new Network Interface in VM settings like for any other virtual device running on VMWare Workstation hypervisor, and assign all parameters as required. If you boot the vSRX now, you will get stuck at Wind River Linux login prompt
It is hard to guess at this point why it is not booting into JunOS. The only thing we changes is the new NIC we add. Indeed this is the source of the problem. vSRX requires NIC type defined as vmxnet3 device type, while for VMWare Workstation it does not default.
To fix this go to the folder where you store your virtual machine and find the file with .vmx extension. That is configuration file of the VM. In the end, you will see latest entries which cover newly added NIC. The index will differ depending on how many NICs you already have.
ethernet3.pciSlotNumber = "256" ethernet3.connectionType = "custom" ethernet3.addressType = "generated" ethernet3.vnet = "VMnet19" ethernet3.displayName = "VMnet19" ethernet3.present = "TRUE" ethernet3.generatedAddress = "00:0c:29:b1:f5:c4" ethernet3.generatedAddressOffset = "30"
To define NIC type, you need to add one line to the configuration file
ethernet3.virtualDev = "vmxnet3"
Now vSRX will boot as expected and you will find the new interface in show interface terse output.
You can use Synology NAS products not only as file storage. The DSM system provides a broad spectrum of additional services via packages – either signed by Synology or provided by third-party communities – the SynoCommunity repository is the most known. The only limitation you have is your NAS hardware platform and its performance. I own DS211 model which reached its End of Sale status already. I run several network services like DNS server there, and I use it as remote storage for SMB and AFP shares as well as for iSCSI LUNs. It also provides some services for my home network and lab. One of them is RADIUS server.
I want to show you how you can use the Synology products as RADIUS server which will use LDAP database for user authentication. This way local accounts that I use for network shares authentication remains separated from any additional accounts dedicated to RADIUS service. Both RADIUS and LDAP runs on the NAS itself.
So you have your brand new shiny lightweight AP from Cisco and wireless controller. The beauty of the managed wireless solution is that it requires almost no effort to add a new access point to existing local network. There are multiple ways how lightweight AP can discover the WLC – I will show you, in my opinion, the easiest one.
Access Point registration
The WLC has two essential ports – management and service. The second one we use mostly for recovery procedure on physical appliances and is not that important when you use vWLC. The Management Port is the one you use to connect to WLC GUI. But by default, it is also used to register access point. You can always change this by selecting the “Enable Dynamic AP Management” option in other port configuration.
There are multiple options how lightweight access point can discover the controller. I think one of the most known is by using DHCP option 43, but that usually requires quite a lot of work and may not be supported by all DHCP server software. In my opinion, the easiest way to let AP discover the controller is via DNS discovery. There are two requirements for this solution to work:
- The DHCP server must provide DNS servers IP addresses and the domain name in response
- You need to configure CISCO-LWAPP-CONTROLLER.localdomain or CISCO-CAPWAP-CONTROLLER.localdomain where the ‘localdomain’ is the access point domain provided by DHCP.
So the whole required configuration is limited to setting up DHCP like for any other host you have in a network (no unique attributes), adding DNS entry and configure switch port in proper VLAN.
Before AP can register at WLC, we must configure the WLC itself as the master controller for the wireless network. To do that go to Controller -> Advanced -> Master Controller Mode, click the checkbox and apply the change.
When you boot up the AP, it should obtain its IP address from DHCP server. You should also see logs as below on AP console which means access point is trying to join the controller provided in DNS configuration.
*Dec 16 23:19:42.015: AP has SHA2 MIC certificate - Using SHA2 MIC certificate for DTLS. *Dec 16 23:19:42.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 172.16.1.205 peer_port: 5246 *Dec 16 23:19:42.223: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 172.16.1.205 peer_port: 5246 *Dec 16 23:19:42.223: %CAPWAP-5-SENDJOIN: sending Join Request to 172.16.1.205 *Dec 16 23:19:47.223: %CAPWAP-5-SENDJOIN: sending Join Request to 172.16.1.205
It takes 1-2 minute for AP to join the controller, even more, to be operational. Usually new AP first require firmware upgrade which takes time (unless you are needed do to it manually because it is too old compared to WLC firmware which I explained in Manual firmware upgrade of lightweight access point post). When registration process completes, you will see the access point on the list in the Wireless section.
Those are not my first steps with wireless controllers or wireless networking. I had my first touch of enterprise-class wireless networks like 7-8 years ago when Cisco WLC controllers hit the market and lead the evolving world of wireless networking. Working for Cisco Gold Partner back then gave me the opportunity to configure few both autonomous and centrally managed wireless networks at different scale. I also performed a security audit of one quite big installation. Back then there was no virtual vWLC controller back then.
Why am I getting back to the Cisco wireless solutions now? I got Cisco AIR-CAP3702 access point lately, so it was excellent opportunity to refresh my knowledge and look at the past few years changes. It is a popular enterprise model that can work either as an autonomous access point or managed via a controller. So this model is for tests and PoC labs for me, so I decided to check what has changed in Cisco wireless world.
The Cisco lightweight access point managed by the wireless controller is not a new product. It has been on the market for years, evolved from LWAPP to CAPWAP model, is supporting a wide range of access point models. The idea is that access point upgrades its firmware when it registers to WLC. Sounds easy? Yes. Is it working? Yes, usually, but not always. Sometimes you need to perform a manual lightweight access point firmware upgrade procedure which is not well documented. And you need to know a hidden command. I will show you how.
On March 1, 2018, Microsoft will disable support for TLS 1.0 and TLS 1.1 protocols in many of its online services. That means TLS 1.2 or later version will be only allowed in browser-server and client-server connections. It is a good move and security enhancement. You should not even see this change unless you use the old legacy software.
During the past few weeks, I have been working on the project related to the implementation of the GDPR law for one of my customers. One of the milestone tasks was a migration to Office365 and Exchange Online. They were using external email service from one of the national providers so far. One of the applications they are still using is the on-premise CRM – I cannot name the product, but it has support from the vendor and every few months users get a new release. However, this CRM does not support TLS at all in deployed version, only the SSL, for connection to the SMTP server. It was not a problem for previous email service provider, but Microsoft is not going to enable SSL for you just because you need it.
Even in small company changing or upgrading the CRM is not a quick and easy task, so it was not an option in this case. So I had to make changes to SMTP service. My choice was to install SMTP Relay.
Ansible is one of the powerful tools providing us an automation of recurring tasks. In the current world, it is impossible to manage infrastructure manually efficiently. Many people still do this but the world has already changed and we need to progress otherwise our business will be cost ineffective. You can provide static inventory – list of the devices where you want to execute the playbook. But in dynamic environments, such as Cisco VIRL simulations you don’t want to edit inventory file manually. That is why I use Python script that will generate Dynamic VIRL inventory for Ansible playbook for me.