Ubuntu netplan static IP address

It has been a few years since I last touched a Linux box. Tonight I decided to install an Ubuntu Server and wanted to give it a static IP address. As I went to /etc/network and wanted to edit the interfaces file, I realised that things have changed. Now you configure the NICs using netplan.

So I fired up putty after reading some examples on how to do this and got hit by this error when trying to apply the configuration:

Invalid YAML at /etc/netplan/eth.yaml line 10 column 0: found character that cannot start any token

Turns out that I had used tab to do indents of the config. I change my tabs to spaces and it all worked out. My config is this now:

network:
    version: 2
    ethernets:
        ens160:
          addresses: [ "10.10.10.22/22" ]
          gateway4: 10.10.10.1
          nameservers:
            addresses: [8.8.8.8, 9.9.9.9]

It is applied using:

sudo netplan apply

If you do not receive any errors verify with

ifconfig

Deploy ASAv using Ovftool

If you ever get stuck with the “A required disk image was missing” error when deploying an OVA directly on an ESXi host, you might want to check this out – ASAv specific, but should work for other OVAs like I wrote about regarding Deploy ISE PoV 2.3 OVA using ovftool

First of all you download the ASAv from CCO and unzip it. Second you create a text file with the command to deploy the OVA on the ESXi host. My file looks like this:

ovftool \
--name="ASAv_FW" \
--deploymentOption=ASAv5 \
--diskMode=thin \
--datastore=DS-Data-LUN \
--acceptAllEulas \
--noSSLVerify \
--allowExtraConfig \
--net:Management0-0="mgmt-net" \
--net:GigabitEthernet0-0="lab-net" \
--net:GigabitEthernet0-1="lab-net" \
--net:GigabitEthernet0-2="lab-net" \
--net:GigabitEthernet0-3="lab-net" \
--net:GigabitEthernet0-4="lab-net" \
--net:GigabitEthernet0-5="lab-net" \
--net:GigabitEthernet0-6="lab-net" \
--net:GigabitEthernet0-7="lab-net" \
--net:GigabitEthernet0-8="lab-net" \
asav-esxi.ovf \
vi://root@ip-of-esxi-host/

I placed it in the unzipped directory of ASAv to avoid struggling with full paths.

I’m a mac user, so I’ll need to first edit the PATH variable to include the path to the ovftool executable. Again to avoid using a full path to the file. To do this edit the file ~/.bash_profile to look something like this:

# Add path to VMware Ovftool
PATH="/Applications/VMware OVF Tool:${PATH}"
export PATH

Close the Terminal and reopen it.

Now the text file above needs to be executable:

# chmod 744 deploy_asav.cmd

Now all you need to do is run the file:

# ./deploy_asav.cmd

You’ll get prompted for the root password of the ESXi host and deployment will begin. It looks like this:After deployment you’ll need to change the Memory of the ASAv to 2GB or you’ll receive an error about starting webvpn when configuring ASDM (http ip mask interface).

Also you might want to configure serial access to the VM. This is done like this:

ciscoasa# cd coredumpinfo
ciscoasa# copy coredump.cfg disk0:/use_ttyS0

Shutdown the ASA and add a serial port to the VM for network, server with telnet://ip-of-esxi-host:port

You must enable the firewall rule on the ESXi host:

That’s it! Enjoy!

 

DNAC HA

The DNAC is currently sold as an appliance (part number DN1-HW-APL). It costs a whopping $80k list per box! So why do you need three of them when doing a HA setup?

It is because of Quorum. The definition of quorum is:

"The number of members of a group or organization required to be present to transact business legally, usually a majority."

 - source: dictionary.com

Say you only have two hosts in a cluster. If they get partitioned, who should take the role of servicing the network and maintaining the database? This is where quorum comes into play. When you have a three node cluster and one of them loses network connectivity to the other two nodes, the “majority” of nodes lies with the two nodes that can see each other. Quorum is obtained and DNAC continues to function. Now data consistency is also ensured when the network to the isolated single host is restored. This is also the reason why you can only survive losing a single DNAC host. If all three gets cut off from each other, you will need to isolate one of them and reinitialize the other two – one at a time.

This fact about quorum is very important when deciding where to place the nodes. First of all they must be layer 2 adjacent. Second they should be physically close to each other. At least two of them. If you have a data center with two sites, perhaps it would be a good idea to place one of the DNAC boxes at one site and two of them together at the other site.

For more information, see:
Split Brain and Network Partition
Recover Failed Hosts in a Cluster

DNAC Integration with ISE using a self-signed Certificate

NOTE! Using ISE 2.3p3 is not an option due to CSCvi94778

If you’re deploying a DNAC and you want to integrate with ISE, you might have read the following documents:

Perform Post-Installation Tasks
Cisco ISE Integration Limitations

I did and ended up with this error in DNAC when adding ISE:

Clearly this is a certificate error. The thing is that Cisco mentions that SAN (Subject Alternate Name) is essential for the trust between DNAC and ISE. They state this:

The IP address or FQDN of both Cisco ISE and DNA Center should be present in either the Subject Name field or the Subject Alt Name field of the corresponding certificates.

So I decided to use DNS for my SAN and got the above error! A colleague of mine decided to go with IPs instead which worked! Here is how you do it.

Create a file named req.conf with the following content:

[ ca ]
default_ca = CA_default

[ req ]
prompt = no
distinguished_name = req_distinguished_name
x509_extensions = v3_ca

[req_distinguished_name]
C = DK
O = MyCompany
CN = dnac.sda.domain.lab

[alternate_names]
IP.1 = 10.0.0.101
IP.2 = 10.0.0.201
DNS.1 = dnac.sda.domain.lab

[v3_ca]
basicConstraints = CA:TRUE
subjectAltName = @alternate_names
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment

[CA_default]
copy_extensions = copy

This serves as a configuration file for openssl. Specify both the real IP of the DNAC(s) and the VIP.

Next, use openssl to generate a self-signed certificate like this:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 1825 -config req.conf

The only thing needed is to upload the new certificate to DNAC. Browse to Settings -> Certificate and click Replace Certificate.

Click Upload/Activate and wait for 5-10 minutes. Refresh the page and you should be prompte to accept the newly (untrusted) certificate in your browser.

Now you can add ISE under Settings -> Authentication and Policy Servers

If it works, you should see this:

Now you must approve DNAC in ISE. Go to your ISE Web UI under Administration -> pxGrid Services

Here you’ll see this:

Select Total Pending Approval and select Approve all (click OK to confirm).

Now back to DNAC and you’ll see this:

All done. Success!

Deploy ISE PoV 2.3 OVA using ovftool

When you want to deploy the ISE Proof of Value OVA in a ESXi 6.5 this happens:

We create a new VM, specify the name and select the ova:

In the last step, you’ll receive an error that “A required disk image was missing.”

Most likely due to CSCvf26967

Instead of combining the 5 zip files you downloaded from box.cisco.com (.001-.005), you should extract them and use ovftool to deploy the vm.

You now have these files:

Deploy using ovftool:

ovftool --noSSLVerify --acceptAllEulas -ds="datastore-name" --network=network-for-vm -n=ISE-PoV-2.3 "e:\ISE 2.3-POV.ovf" vi://root:passw0rd!@ip-of-esxi-host/

This is what you’ll see:

After the deployment has completed successfully use the Web UI to change these values:

  • VM Compatibility
  • Guest OS to RHEL 7 (64-bit)
  • CPUs
  • Memory
  • NIC to E1000

Enjoy!

ISR4321 Switch Module Not Working – CPLD Incompatibility

I recently had the pleasure of upgrading a ISR4321 router to Denali (16.3.5). If you have a NIM-ES2-8 for example you might want to be careful and check the CPLD version before doing the upgrade! Here is why.

Here the CPLD version is 14101324

The Firmware Version is the ROMMON version.

As of writing there is no way of correlating the CPLD version show in the output of show platform and the one you can download on CCO. And for ISR4321 there is only one version on CCO.

Why is this important? Well, if you upgrade to Denali this will show up in the log after the upgrade:

*Jan 17 2018 10:07:34.633 CET: %SPA_OIR-3-RECOVERY_RELOAD: subslot 0/1: Attempting recovery by reloading SPA
*Jan 17 2018 10:07:34.637 CET: %SPA_OIR-6-OFFLINECARD: SPA (NIM-ES2-8) offline in subslot 0/1

Router#sh hw-module subslot 0/1 oir
Module        Model                Operational Status
------------- -------------------- ------------------------
subslot 0/1   NIM-ES2-8            out of service(failed too many times)

After you upgrade the CPLD version the module will work again.

Router#show hw-module subslot 0/1 oir
Module        Model                Operational Status
------------- -------------------- ------------------------
subslot 0/1   NIM-ES2-8            ok

And as of writing this was not documented in the release notes or anywhere else in Cisco Documentation!

ISR4321 Software Upgrade – Signature Verification Failed

If you try to upgarde to Everest (16.6.2) you will probably hit a ROMMON bug due to the image footprint (being larger than 512MB). Specifically you will see this:

Turns out the bug is reported as CSCvg89038

If your router has a switch module installed, you might want to check out this post.

Cisco 4321 – Boot Loop

I had the opportunity to configure a new Cisco 4321 router the other day.

Opened the box and plugged in the power which by the way is via an external power supply that has a Mickey Mouse (C5) connector!

Waiting in excitement for the router to boot… After some time I realised the router wasn’t booting. The error was:

unable to open bootflash:xdsl/packages.conf (14)

My output from SecureCRT:

Great! Brand new out of box router from Cisco that doesn’t boot!

I put the router into rommon and looked at the flash. The image was there so I tried to issue the boot command and the router booted. After bootup I discovered that the Gi0 management port had an IP address assigned! Never seen that before. I did a wr erase and reload. Boot loop again!

I stumbled upon a Troubleshoot Cisco 4000 Series ISR Stuck in ROMMON article and tried the solution they suggested. And it worked! In short I did this:

Set configuration register to 0x0 which makes the router ignore the boot variable configured in startup-config.

rommon 1 > confreg 0x0
rommon 2 > reset

Next set the configuration register back to 0x2102.

rommon 1 > confreg 0x2102
rommon 2 > boot bootflash:isr4400-universalk9.03.15.01.S.155-2.S1-std.SPA.bin

The router boots and is able to boot again when reloaded!