A while ago Azure announced a new feature allowing you to connect VNets together without express route or VPN.

VNet peering is a mechanism that connects two virtual networks (VNets) in the same region through the Azure backbone network. Once peered, the two virtual networks appear as one for all connectivity purposes. They are still managed as separate resources, but virtual machines in these virtual networks can communicate with each other directly by using private IP addresses.

The product page can be found here.

The Existing Architecture

Originally, your architecture may have consisted of several VNets and all of these would have had a gateway (a billable item) and a form of connectivity between them – either express route or VPN. There are some inefficiencies here as all traffic between VNets needs to be routed via your express route circuit. Bandwidth and the actual location of your express route termination points may be problems here. A 1000mb/s link may be plenty between your on-prem networks and Azure, but is it enough for your traffic between all of your VNets? With the below architecture we have 4 gateways for 4 VNets.

Legacy Azure Architecture - A gateway in each VNET

Legacy Azure Architecture – A gateway in each VNet

The New Architecture

VNet peering does away with the requirement to have a gateway on every VNet. We can create a VNet which serves as the link between your on-prem networks and have the rest connected via VNet peering. This is even supported between VNets that are in different subscriptions. To use the same reference architecture but changed to adopt VNet peering, we will have something like the below.

VNet Peering Azure Architecture - One more VNet but 3 fewer gateways. Profit!

VNet Peering Azure Architecture – One more VNet but 3 fewer gateways. Profit!

So we have one extra VNet, but 3 fewer gateways. The gateways are what cost money in this setup, so this will not only be a cheaper setup, but a more efficient one. All traffic between VNets will be via the (blazing fast!!!) azure backbone and not your express route link. At the moment VNet peering traffic is free of charge, so you will save some money on your ingress/egress express route charges.

As with everything Azure, please do your own research as pricing and features change regularily.

If you have provisioned an application gateway through the azure portal it’s not actually that easy to remove some components that get created automatically. As part of my testing, I ended up with a few Listeners that were surplus to requirement.

application gateway listeners - at the moment they cannot be deleted through the portal

application gateway listeners – at the moment they cannot be deleted through the portal

As a new service, the documentation isn’t that great yet. The following can be used to delete a listener from application gateway using powershell:

Remove Listeners

$AppGw = Get-AzureRmApplicationGateway -Name “application-gateway-name” -ResourceGroupName “application-gateway-resource”
Remove-AzureRmApplicationGatewayHttpListener -ApplicationGateway $AppGw -Name “name-of-listener-to-delete”
Set-AzureRmApplicationGateway -ApplicationGateway $AppGw

The process takes a wee while but will remove the listener. And for the following:

Remove HTTP Settings

$AppGw = Get-AzureRmApplicationGateway -Name “application-gateway-name” -ResourceGroupName “application-gateway-resource”
Remove-AzureRmApplicationGatewayBackendHttpSettings -ApplicationGateway $AppGw -Name “name-of-http-settings-to-delete”
Set-AzureRmApplicationGateway -ApplicationGateway $AppGw

Remove Back End Pools

$AppGw = Get-AzureRmApplicationGateway -Name “application-gateway-name” -ResourceGroupName “application-gateway-resource”
Remove-AzureRmApplicationGatewayBackendAddressPool -ApplicationGateway $AppGw -Name “name-of-back-end-pool-to-delete”
Set-AzureRmApplicationGateway -ApplicationGateway $AppGw

I’ll do a write up of the service once I have fully evaluated it. At this stage I’m not 100% sure what the difference is between this and Azure AD Application Proxy as the feature set overlaps a lot.

2960 Memory Leaks

Cisco 2960’s and their memory leaks have on more than one occasional left me without SSH/Telnet access, but still responding to SNMP requests. No matter which code base we have tried, the same pattern of memory usage over time can be seen. To be fair we ask a lot of these switches – we’re heavy uses of 802.1x, insist on using SSH rather than telnet, and have loads of smaller services such as DHCP snooping, RSTP, aaa accounting, ntp etc  – each one uses a little memory.

Cisco 2960 memory usage over time - leaking slowly we lose SSH access at around about 90%

Cisco 2960 memory usage over time – leaking slowly we lose SSH access at around about 90%

Time to Reload

A handy feature is a SNMP oid which, if you have the read/write community, allows you to reboot a switch remotely if it is still responding to SNMP (which they usually do – even when telnet/ssh/console access isn’t working).

Most Linux distributions will have snmpset installed, but there are Windows equivalents of course.

snmpset -v1 -c your-rw-community-her 1.1.1.1 .1.3.6.1.4.1.9.2.9.9.0 i 2

Change your community string, and the IP address and run this sucker. I suggest keeping a ping running to the device so you can see if this has had the desired result, and so you can see when it’s back up and running again.

Long term Solution

We are in the process of looking to replace these switches which are fully EOL July 2017. I’m tempted to script up something to reload these out of hours when the memory usage is approaching that lose-ssh-access threshold.

In the first of several posts about Skype for Business calling, I will be looking at a few ways that performance issues can be troubleshooted. As a new user of this service we have at times experienced issues with the quality of calls – usually this comes in the form of ‘squelchy’ sounding voice, or either one way or bidirectional silence on the calls (while the participants continue to talk). First up…

Network Assessment Tool

Published on the 14th of December, network assessment tool is a program which will make automated test calls using the clients Skype for Business client. On each call the following stats are output:

  • PacketLoss
  • Rate RoundTripLatencyInMs
  • PacketsSent
  • PacketsReceived
  • AverageJitterInMs
  • PacketReorderRatio
Network Assessment Tool Results

Network Assessment Tool Results

Additionally, an audio file is stored with the results that effectively plays back the call to the user. it’s a good way to see whether a small amount of packet loss created a perceivable drop in quality on the call.

The tool can be downloaded here.

The main configuration file ‘NetworkAssessmentTool.exe.config’ allows a number of changes to the way the tool behaves by default. I suggest removing the ‘Relay.TCPPort’ setting as skype for business should be using UDP for it’s calls. The ‘NumInterations’ is important as it allows you to specify how many times the tool should run before it quits.

configuration file options

Configuration file options

An issue I found with the tool was that although it was running several times, the output file ‘ReceivedAudioFile.wma’ was being overwritten every time. It was therefore impossible to correlate one line in the excel results file to a particular audio file as only the last one was being saved. I wrote a little powershell to run the program, rename and move the audio file, and export the results.

$repeat_count = 100000
$delay = 20
$i = 1

while($i -lt $repeat_count) {

sleep $delay
write-host “Starting call number $i”
$date = Get-Date -Format s
$file = $date + “.wma”
$file = $file -replace ‘:’,”

Set-Location -Path C:\Temp\NetworkAssessmentTool\
C:\Temp\NetworkAssessmentTool\NetworkAssessmentTool.exe
Move-Item ReceivedAudioFile.wma C:\Temp\NetworkAssessmentTool\Calls\$file
$new_resilts = Import-Csv results.tsv
$new_resilts | export-csv running-results.csv -NoTypeInformation -Append
$i++

}

Now you get a directory filled with audio files, and a excel file detailing the stats of every call. I have left this running for the last few weeks and it’s been very useful to see if call performance issues can be identified against network events (ie busy periods, backup jobs, internet problems etc).

Assessment tool script output

Assessment tool script output