Packet capture, built in to Windows


Sometimes when you are working in secure environments, you can’t just go installing software. But if you need a packet capture, and it’s a windows server, then what? If you can’t install Wireshark, then you can use Microsoft Network Monitor.

The capturing is done via a command-line tool. Once you export the file, then you have to use some Microsoft software to analyse it – it’s very similar to Wireshark in functionality, but uses a “.etl” file instead of a pcap.

To get the capture, launch a command prompt with admin rights, and enter the following sequence of commands:

start scenario=LAN capture=yes

Do whatever you need to capture, and enter:


It will give you the location of the .etl file. If you enter “show scenarios”, that will show you some other things you can trace against, but for everything I’ve ever needed, LAN has been sufficient.

Export the file over RDP shared folders or whatever means you like, and then open it on your machine using Microsoft Network Monitor – available at:

When I first installed this program, I had to change a setting to make it work properly: Go to Tools / Options / Parser Profiles, right click on “Windows” and select “Set as Active”.

I’d still much prefer a pcap, but in a pinch this has helped.

Palo Alto scheduled backups – without Panorama

Recently we deployed a Palo Alto VM-200 firewall. It was a stand-alone deployment on a remote site. We were going to deploy a pair, but we didn’t see how much value it added as the VM-series firewalls do support HA but not stateful HA.

As it was stand-alone, it wasn’t managed by Panorama. And without Panorama management, it is seemingly not very straightforward to enable scheduled automated backups. This seems odd to me – in my paranoid world of engineering, I want things backing up somewhere regularly. Maybe it’s just something to make you buy Panorama.

Anyway, there is a way to do it. We used a general purpose management Linux box, and set up a cron job to download the config using the XML API. Here are the details.

First, if you don’t use the API already, you need to generate an API key. This is basically your “password” for using the API. Go to the following URL:

Obviously swapping your IP, username and password in.

That should give you an XML response like this:

<response status="success">

Now you can get a full config backup via the API, by visiting the following URL:

This will dump out an XML configuration file.

So now we have a means to get the config file, we just need to schedule it. To do that, we set up a cron job on a linux server to run the following command:

curl -o /backups/`date +%Y%m%d`-my_firewall_backup.xml  -k -H "Accept: application/xml" -H "Content-Type: application/xml" -X GET ""

Set it to run whenever you like – I think we went for weekly as we don’t change it very much.

What is ARP?

A number of times in the last few weeks I have been asked by a number of people:

What is ARP?

There is the simple answer – which is simply a definition:

Address Resolution Protocol (ARP) is a mechanism to resolve IP addresses into MAC addresses.

However…that doesn’t really explain a lot. It probably doesn’t explain anything you didn’t already know. To really understand ARP, you probably need to understand the following:

  • Why do we need to ARP? Why do we care what MAC address is associated with what IP?
  • When do we ARP, and what do we ARP for?
  • How does ARP work? What does the conversation look like?
  • How often do we perform ARP?

In this post I’ll aim to go over some low level basic network stuff, to try and explain all of this. I’m going to generalise quite a lot – I’m specifically talking about ARP and IPv4. There are other protocols at the various layers, but I’m sticking to simple and relevant.

Why do we need ARP?

Right back at basics, we have the OSI 7 layer model (or the TCP/IP model – whichever you prefer):

OSI Models

Continue reading

Nexus 7000 Software Bug – Flash RAID Errors – Part 2

This is a continuation of a previous post: Nexus 7000 Software Bug – Flash RAID Errors – 7k Reboot and Failover.

The last post finished where we thought all was good, because the flash status code was reading 0xF0, which we were told means both flash drives are healthy. What we noticed though was that the diag tests were still failing for compact flash – test 7 – on some of the sups. Initially Cisco told us that this was cosmetic, and meant nothing.

However, we sent them some logs for review and confirmation and they came back and told use we still had dodgy flash on 2 sups. In the output of “slot [5/6] show system internal raid”, where the partitions are listed, you are looking for “[UU]”. UU means good. An underscore, like in the following output, means you have a bad disk:Continue reading

Why am I seeing packets on my server that aren’t for this server?

While troubleshooting a totally unrelated issue, one of my colleagues noticed that they were seeing packets in a tcpdump that were neither destined for nor sourced from the server. This is odd, when plugged into a switch, so we started digging.

The very over-simplified topology looked like this:



Server 1, was sending a stream of packets to Server 2 – in a different subnet somewhere. Sometimes, although rarely, these packets could be seen on Server 3.Continue reading

Nexus 7000 Software Bug – Flash RAID Errors – 7k Reboot and Failover

It’s been a mad couple of weeks with Nexus 7000’s. My client hit a software bug on their Nexus 7k, which turned out to be a most impressive bug. It basically causes the flash drives to be erroneously marked as faulty, which then causes them to be remounted in read only. The first symptom was that you could not save the running configuration by running “copy run start”. There were other symptoms in the logs, such as being unable to write to some SNMP and AAA files.

The bug reference is CSCus22805 (Cisco account needed).

So my clients site has a pair of Nexus 7k’s, connected as vPC peers. Each 7k has 2 N7K-SUP2 supervisor cards. Each supervisor card has 2 flash drives, configured in RAID 1 (mirrored). What could go wrong with this much redundancy? Well…a lot.Continue reading

Automate loading INE configs onto Cisco CSRs using Python

I haven’t posted for a while. Work has been hectic, I failed my CCIE written and lost all motivation, and many other excuses. Whilst I haven’t really been studying CCIE stuff, I have been productive. I have been learning Python. I decided to automate the process of loading the INE initial configs onto my CSR routers, using a Python script, and the power of pexpect.

I won’t go through the gory details, but I’ve learned a lot by doing this (including how to set up a github repo! –, thanks!).

It’s probably not perfect, but it works for me. I think I’d like to add threading, and maybe some error handling and logging of some description – but that’s for another day when I have some time to burn.

You can find it at – I’m not going to post the script here as it will get too messy.

Let me know if it’s useful (or not!).

Replacing a failed Cisco Ironport Web Security Appliance Proxy

Recently we had a Cisco Web Security Appliance (WSA) Proxy fail. When I say fail, I mean a single stick of RAM failed after a reboot. Cisco said RAM isn’t replaceable so we had to RMA the whole box (odd for a device that is basically a rebadged server…maybe I have a money saving idea for you Cisco!)

There were a few steps to getting it going, so I thought I’d share.Continue reading

Checkpoint GAiA BGP Network Origination

I was recently involved in a project upgrading the core firewall pair from Checkpoint R71.40 SPLAT to R77.20 GAiA. While very different, a lot of the configuration is pretty straight forward, and well documented in various articles on the Checkpoint website.

This setup runs BGP on the firewalls, to learn routes from our internal VRF’s and also the WAN VRF where our MPLS is connected. The main routing configuration is quite well documented in the GAiA Advanced Routing R77 Administration Guide

We did this gateway replacement with no changes to the core switches…we matched the BGP config on the gateways to the existing setup to minimise changes – and hopefully the number of things that could go wrong!

The only thing that really stood out as being particularly different, and took a little figuring out, was the route origination. It is fairly simple to redistribute routes in, but we didn’t want that. We wanted the equivalent of a network statement – giving us granularity over which routes are originated and also maintaining the BGP origin code of “i”.Continue reading