Don’t Forget Overlay MTU Requirements!

There are several benefits to overlay networking, such as providing a larger number of segments to consume, for example over 16m for VXLAN and Geneve (both provide 24-bits for the VNI) or removing the reliance on physical network config to spin up a new subnet.

To make use of these benefits and more, the overlay doesn’t ask for much of the underlay, just a few basic things:

• IP connectvity between tunnel endpoints
• Any firewalls in the path allows UDP6081 for Geneve or UDP4789 for VXLAN
• Jumbo frames with an MTU size of at least 1600 bytes
• Optionally, multicast if you wish to optimise flooding

This article is about what happens when you don’t obey rule #3 above with NSX-T…

Topology

A basic 3-tier app has been deployed as above, with each tier on it’s own segment and connected to a T1 gateway. Routing between segments will be completely distributed in the kernel of each hypervisor that the workloads are on.

Problem

When connected to one of the WEB servers and attempting to access the APP, the connection was getting reset:

As the WEB and APP workloads were on separate hosts the traffic was being encapsulated into a Geneve packet (which cannot be fragmented) and sent over the transport network from TEP to TEP:

A ping test confirmed that connectivity was ok up to 1414 bytes, anything larger was being dropped:

root@NWATCH-WEB01 [ ~ ]# ping 10.250.70.1 -s 1414

PING 10.250.70.1 (10.250.70.1) 1414(1442) bytes of data.

1422 bytes from 10.250.70.1: icmp_seq=1 ttl=61 time=1.33 ms

^C

— 10.250.70.1 ping statistics —

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 1.326/1.326/1.326/0.000 ms

root@NWATCH-WEB01 [ ~ ]# ping 10.250.70.1 -s 1415

PING 10.250.70.1 (10.250.70.1) 1415(1443) bytes of data.

^C

— 10.250.70.1 ping statistics —

1 packets transmitted, 0 received, 100% packet loss, time 0ms

To prove the app layer was ok, a small page returning just one word was tested and worked fine:

Solved

As soon as the MTU size was increased on the underlay transport network to 1600 bytes the full webpage loaded fine:

And a ping for good measure:

root@NWATCH-WEB01 [ ~ ]# ping 10.250.70.1 -s 1415

PING 10.250.70.1 (10.250.70.1) 1415(1443) bytes of data.

1423 bytes from 10.250.70.1: icmp_seq=1 ttl=61 time=1.76 ms

1423 bytes from 10.250.70.1: icmp_seq=2 ttl=61 time=1.69 ms

^C

— 10.250.70.1 ping statistics —

2 packets transmitted, 2 received, 0% packet loss, time 2ms

rtt min/avg/max/mdev = 1.686/1.723/1.760/0.037 ms

Advertisement

Deploying NSX-T 2.5 with VMware’s Ansible Examples

I try to use IaC to build my labs, so that when I inevitably break something, I can always re-roll.

However, when I tried to build an NSX-T 2.5 lab, using Ansible playbooks based on the VMware examples that worked on 2.4, I received an error about the nsx role when deploying the manager OVA:

Error:\n - Invalid value 'nsx-manager nsx-controller' specified for property nsx_role.

After poking around the Manager OVF file I noticed that the value options had changed from previous versions from manager/controller/cloud options to just manager/cloud.

Here’s the values in NSX-T Manager 2.4:

And here’s the values in NSX-T Manager 2.5:

So a simple change of the nsx_role to “NSX Manager” in my playbook and everything deployed successfully!

I’ve raised an issue on the ansible-for-nsxt GitHub page for the example provided and I’ll hopefully submit a PR to resolve, by adding a version variable to make it compatible across versions.

vRealize Network Insight 5.0 Installation

The new release of vRNI adds a host of new features, you can see here, so let’s try it out in the lab…

The installation is the same as other versions, with the Platform VM installed first, followed by the Proxy VM. The basic setup is:

Platform VM

• Deploy the OVA, providing just the name, datastore and network portgroup
• Power up the VM and go through the CLI setup wizard from the Arkin days
• Enter the password settings for the SSH and CLI users.
• Enter networking details (IP, mask, gateway, DNS, NTP)
• Continue the configuration via the web UI:
  • Apply the license
  • Set the password for web admin user (admin@local)
  • Generate Shared Secret (for Proxy VM)

Proxy VM

• Deploy OVA, setting the Shared Secret from the Platform deployment
• Power up the VM and go through the CLI setup wizard from the Arkin days
• Enter the password settings for the SSH and CLI users.
• Enter networking details (IP, mask, gateway, DNS, NTP)

 

Final Steps

Once both appliances are fully deployed, the proxy/collecter will connect to the platform and the web UI will show the below:

Click finish and continue to login to vRNI, with the username admin@local and the password set during setup.

Now add your data sources like vCenter, NSX-v, NSX-T, physical network kit, clouds etc.) to start getting visibility into your network:

Next up is viewing and working with the plethora of data you’ll see from vRNI…

What’s New in vSphere 6.7 Update 2 and NSX 6.4.5

UI Changes

You can see the first UI change in vSphere 6.7U2 when you login to vCenter. Gone is the dark blue flash-based SSO login screen, which was the final reminder of the ‘old web client’, and in with the new Clarity UI login splash screen that was introduced on the VAMI a few versions ago:

Dark Theme

The most important feature for any app to be cool these days that was introduced in U1 has been improved in U2 to add a bit more colour to certain features that make them easier to view:

Not everything has caught up though, NSX for example still doesn’t go full night mode.

NSX Plugin Install

A nice subtle update in 6.7U2 is that you’re not longer required to logout when you install NSX. In previous versions the warning banner would say that the NSX plugin has been installed but you need to log out to activate, now it just needs a simple refresh!

 

NSX Dashboard

The NSX dashboard in the vCenter H5 UI could always be a bit slow to load, but at least now there’s some visibility of it actually doing something in the background. Activity bars are now shown on the dashboard tiles:

NSX HTML5 UI Updates

NSX 6.4.5 now provides more (Routing, Bridging, Load Balancing) configuration for ESGs into the HTML5 UI:

 

Hands On With NSX-T 2.4

In order to wrap my head around the changes from NSX-V (ok, NSX Data Center for vSphere) to NSX-T (Data Center) I’ve created a few labs with previous versions. With the latest release 2.4 though there’s a lot of simplification been done in terms of deployment and manageability that you can tell straight away from the UI.

After a few hours with NSX-T 2.4 I’d setup the following deployment:

Diagramming it all out helps me to understand how the pieces fit together (and there are a lot of pieces to NSX-T).

A few things I’ve noticed so far…

Logical Switches in vCenter

A nice feature in NSX-T is the way that Logical Switches are presented in vCenter, compared to the ugly ‘virtualwires’ from NSX-V, you now get full integration of the N-VDS (NSX-T Virtual Distributed Switches) so they look just like the old school VDS’s. Heres’ the view from H01:

And again from H03:

New Workflows

Creating segments, routers and other networking constructs had been a little complicated in previous releases, but now the new wizards makes these tasks easy. Once created the show up in, adding some much needed visibility in to what’s been created:

For my first deployment I went straight in with the Advanced Networking & Security screen, not knowing that none of these objects are shown in the fancy new dashboards… so I recreated them. Objects created through the new workflows do show up in the Advanced tab though and can be identified with the ‘Protected Object’ icon as below:

 

Working with NSX API: Adding an IP to an ESG (Edge Services Gateway)

Whilst setting up an NSX load balancer (post to follow) I found the need to add a secondary IP to an ESG. Because of this (KB2151309) handy bug feature I had to either delete the ESG and re-create it, or set a secondary IP via the API, so here goes…

This post assume basic knowledge of NSX components and uses the following:

• NSX 6.3.2 with a fully deployed ESG
• Postman

The Before

A quick look at the ‘before’ setup of the ESG interface configuration (IPs and names have been changed to protect the innocent):

And here’s a closer look at the vNIC 0 that we’ll be adding a secondary IP to, to prove there’s not already one set:

API Call 1 – Get the config of the vNIC we want to change

So we know we need to edit vNIC 0, but to get all of its current config we need to call on the API. This will help to see the structure of the config required and confirm all of the settings.

The NSX API Guide tells us how the API request should look…

So fire up Postman (or other API consumer) and structure the request:

• Method: GET
• URL: https://NSX-MANAGER.FQDN/api/4.0/edges/edge-1/vnics/0
  • This is from the NSX API Guide as above, with the index of 0 at the end to represent the vNIC 0 we’re working with
  • Remember that in NSX world that the NSX Manager presents the Northbound API, so you’re always interacting with the Manager
•  Authorization:
  • Type: Basic Auth
  • Username: (API-enabled user, could be the NSX default ‘admin’)
  • Password; ^^^
• Headers:
  • Content-Type: application/xml
  • Authorization: Basic (base64-added from the Authorization tab)

Hit Send and you should see some data similar to what was represented in the NSX web GUI:

<?xml version="1.0" encoding="UTF-8"?>
<vnic>
    <label>vNic_0</label>
    <name>EXTERNAL</name>
    <addressGroups>
        <addressGroup>
            <primaryAddress>10.1.1.1</primaryAddress>
            <subnetMask>255.255.255.248</subnetMask>
            <subnetPrefixLength>29</subnetPrefixLength>
        </addressGroup>
    </addressGroups>
 <mtu>1500</mtu>
 <type>uplink</type>
 <isConnected>true</isConnected>
 <index>0</index>
 <portgroupId>dvportgroup-6645</portgroupId>
 <portgroupName>EXTERNAL</portgroupName>
 <enableProxyArp>false</enableProxyArp>
 <enableSendRedirects>false</enableSendRedirects>
</vnic>

 

API Call 2 – Setting the Secondary IP Address

Note that in the output above from the vNIC it has no secondary addresses configured and there’s no stanza for one. So how do you know how to add one? And do you just guess and change the method from GET to POST? All is explained again in the NSX API Guide…

So we now know the syntax and method (PUT) to add a secondary address!

Back in Postman, update the request to change the method, then add a Body with the existing vNIC0 configuration (which was obtained earlier) along with the new secondary IP config (I’ve used 10.1.1.2) and hit Send:

Ok, it loaded for a bit then looks to have sent, but how do you know? Well in the bottom right corner of Postman we see Status: 204 No Content. Any HTTP 2XX message is a success and the fact that no content was sent back is fine, we didn’t expect anything.

The After

Time to check that the new config has worked. We can do this two ways, in the NSX web GUI or via the API…

Since we’re still in Postman, re-issue the GET from earlier to retrieve the new vNIC0 config:

And to be sure, confirm in the NSX web GUI:

 

Extension Mobility Remote Login/Logout without PIN in Python

Whilst trying to automate some mundane networking tasks in Python, I’ve started looking our UC environment. This lead me to a great post (thanks!) here:

https://ucnote.wordpress.com/2015/11/29/extension-mobility-remotely-login-user-to-phone/

I’m by no means a coder, but I’ve converted the PowerShell script from there into a Python version (feel free to suggest a more PEP8 improvement), that uses the Requests library.

Some uses for this is to make a web app to see who is logged in where and give the ability to log them out remotely. Alternatively, provide a Windows login/log off script that automatically logs a user into their handset (users with no roles can log themselves in/out, whilst users with the EM Authentication Proxy Rights role can login/logout any user).

Ingredients Used:

If you want to try this out it should work on most UCM versions and I think in Py3, but to rule out any incompatibilities, my environment was:

• Python 2.7
• Requests 2.9.1
• CUCM 10.5(1)
• Softphone

The Code:

Change the hard coded variables for your own and comment in/out the logout/in respectively:

#! /usr/bin/env python
import getpass
import requests

# YOUR DETAILS FROM HERE
cucm_server = "CUCM"
mac = "000000000002"
device = "SEP" + mac
emuser = "emuser"
appEmProxyUser = "appemadmin"
appPw = getpass.getpass(prompt="Enter the EMProxyUser password: ")
# TO HERE

uri = "http://" + cucm_server + ":8080/emservice/EMServiceServlet"
headers = {"Content-Type":
 "application/x-www-form-urlencoded"}

parameters = "<request>"
parameters += "<appInfo><appID>" + appEmProxyUser +\
 "</appID><appCertificate>" + appPw + "</appCertificate></appInfo>"

# parameters += "<logout><deviceName>" + device + "</deviceName></logout>"
parameters += "<login><deviceName>" + device + "</deviceName><userID>" +\
 emuser + "</userID></login>"

parameters += "</request>"

r = requests.post(uri,
 data={"xml":
 parameters},
 headers=headers)
print(r.text)