Unless you plan to live by candle light and bathe in the canal you are going to need electrics and hot water. The two main players when it comes to boat electrics are Victron and Mastervolt, I went for victron as their whole eco-system seems a lot more advanced and customisable (are a lot more guides, examples and advise readily available online). In terms of hot water and heating a calorifier is the only real sensible option, for the diesel heater I chose Webasto over Eberspacher as I liked how they how they have incorporated the use of Heatmiser thermostat controllers.
You can only live for so long on laughing cow, pot noodles, soup and beans on toast, the boat diet is good for losing weight but not for your wellbeing. I got lucky with the weather as winter was pretty mild up until late October but when it turned you certainly did feel the cold on the boat. You would have to be crazy to try and survive on a boat in winter without a stove or some form of heating.
Now I had a design and a half empty shell it was time to get work. The biggest problem with working on a boat is space, you are forever moving things and constantly tidying up. All the materials had to be orderd to arrive just in time for when they were needed as there is no space on the boat to store them. The remoteness of the marina and not having a car didn’t help, I wasted a lot of hours getting local buses to go hire a van or waiting on deliveries.
I purposely bought a boat that needed work so that I could customise it to my needs and learn how everything works. The wooden interior was dated and gloomy, it only had 1 DC socket, no working AC (no fuse board or inverter), no hot water (water heater broken) and a rusted up stove with 1 radiator run off it. After 5 months of hardship and an ever decreasing bank balance whether that was a good idea is debatable…..
When it comes to working with steel it is a bit outside my comfort zone so I got the professionals in to do the blacking of the hull and a few different things to the cabin shell.
Oh a boat, how do you know it wont sink………..
The initial idea behind this blog was to have a medium to store and share notes on the different technologies I worked on in an searchable manner. I have decided to step back from work and take a year out so this new life tab of the blog will be for all things non-IT related. I still plan to write technology based blogs over this time (got a few automation projects and Azure tips to share), however this is unlikely to start happening until later into next year.
Information on running packet captures and debugging commands to follow traffic flows.
Useful commands to see general information on the firewall resources been used, interface and traffic statistics, and traffic counters.
Information on how applications are identified by App-ID and following sessions and traffic flows through the firewall using the CLI.
Palo Alto firewalls use the concept of a running config to hold the devices live configuration and the candidate config is copy of the running config where changes are made. A Commit operation causes the running config to be overwritten by the candidate config activating the changes.
A run through using the CLI to set up a Palo firewall at home covering the initial configuration, upgrading, BGP routing and a basic firewall policy.
The majority of Cisco SD-WAN guides and posts I have found use static routing rather than routing protocols on the transport-side. Static routes are all very well for SD-WAN tunnel traffic but I was wanting to understand how you equate for DIA traffic in a more real-life situation where address ranges are advertised via BGP.
The Cisco documentation about this call it Inter-AS Option B with the use case being to extend LSPs between sites over the one link. As Option B is the only MPLS-VPN method supported by Cisco SD-WAN I wanted to get a better understanding of how it works aswell as see if it could be used to extend multi-VRF prefixes between edge routers and a core switch within the same AS (rather than using Option C with LDP).
Recently whilst using pynetbox to create NetBox environment objects I had a need to use variables in the URL of the API calls to allow for reusable functions to perform API calls based on the URL and data fed in as arguments. The reason the URL needs to be fed in as an argument when calling the function is because each NetBox element uses a different API URL.
This post goes through how to configure MPLS VPN on the service-side of a Cisco SD-WAN edge device, so the south-side towards non-SD-WAN devices. What I am trying to achieve is to advertise the differing SD-WAN VPN (VRF, why Cisco have to call these VPNs beats me) prefixes to a core switch (using a ASR in the lab) directly connected to the SD-WAN router. This could be accomplished using per-VRF interfaces (or sub-interfaces) and BGP peerings, but a neater solution is to pass all the routing information over one the BGP MPLS VPNv4 peering.
As part of a POC I deployed a pair of HA F5 LTM/GTM at home to use for all things DNS based. It is an indulgent over the top DNS solution for a 1 bed flat, but hey-ho we are in a pandemic….. This guide does not go through the HA F5 or GTM (still cant stop calling it that) configuration, it is focussed around using ZoneRunner for DNS (bind) with these zones transferred into DNS express and serviced by a listener.
Nornir tasks are run against all or a subset of inventory members with the result formatted into a framework structured to show what was run against whom and the results. Tasks can be custom built python code or pre-built plugins that have been installed and imported.