Golang fun

Made some progress on my little app today (code updates happening on the development branch). This week, I learned the importance of composing structs when working with JSON (at least for working with in-memory data structures). What does all that mean?

So in python you have dictionaries that easily convert to json and vice versa, it’s like a couple of lines of code. Go is statically typed, so you have to model out the structure of the json body to tell go what tyes the values should be. Ok so you figure that out no worries, not too hard.

Now let’s talk about nesting.

Say you have json body with lists in it. if you want to be able to access those lists and work with them programmatically, then you need to do composition.

In this example, there’s a response with a list of certificates (only one shown here for brevity). If you wanted to work with those certificates individually, you would need to define a certificate struct, then a response struct, then make the certificate a slice of certificates inside the response. The way I figured it out was to print out the type of the struct I was getting from json.unmashal, to see if it was a generic struct or one I had defined.

  "response": [
      "id": "8c75350b-ea1b-4a51-a2e7-d37118ac04ae",
      "friendlyName": "Default self-signed server certificate",
      "serialNumberDecimalFormat": "16801809625158750310575466749",
      "issuedTo": "ise1.pod1.abl.ninja",
      "issuedBy": "ise1.pod1.abl.ninja",
      "validFrom": "Thu Mar 30 12:56:02 UTC 2023",
      "expirationDate": "Sat Mar 29 12:56:02 UTC 2025",
      "usedBy": "EAP Authentication, Admin, Portal, RADIUS DTLS",
      "keySize": 4096,
      "groupTag": "Default Portal Certificate Group",
      "selfSigned": true,
      "signatureAlgorithm": "SHA384withRSA",
      "portalsUsingTheTag": '"BYOD Portal (default), Blocked List Portal...',
      "sha256Fingerprint": "20af57d758f156d33a7616a664c58d605e53e7a1f678ebf08561421d6571cad6",
      "link": {
        "rel": "self",
        "href": "",
        "type": "application/json"


Ok so here’s how I modeled this in Go:

type CertList struct {
	Response []Cert

type Cert struct {
	ID                        string `json:"id"`
	FriendlyName              string `json:"friendlyName"`
	SerialNumberDecimalFormat string `json:"serialNumberDecimalFormat"`
	IssuedTo                  string `json:"issuedTo"`
	IssuedBy                  string `json:"issuedBy"`
	ValidFrom                 string `json:"validFrom"`
	ExpirationDate            string `json:"expirationDate"`
	UsedBy                    string `json:"usedBy"`
	KeySize                   int    `json:"keySize"`
	GroupTag                  string `json:"groupTag"`
	SelfSigned                bool   `json:"selfSigned"`
	SignatureAlgorithm        string `json:"signatureAlgorithm"`
	PortalsUsingTheTag        string `json:"portalsUsingTheTag"`
	Sha256Fingerprint         string `json:"sha256Fingerprint"`
	Link                      struct {
		Rel  string `json:"rel"`
		Href string `json:"href"`
	} `json:"link"`

So why did I do that? Because I wanted to get the certificate list for each node and simply bolt on to the node struct. to do that I can add my certificate type to my node type like this:

type node struct {
	Id   string
	Name string
	Link struct {
		Rel  string
		Href string
	Certs []Cert

Time for bed.


Firepower Custom Security Intelligence Feeds

Greetings, Programs!

Today I made a brief video on how to set up custom Security Intelligence feeds. This isn’t anything new by any means. However, with the rise of the 3rd party SOC, it’s still quite relevant and a valuable solution for cases where you want allow updates to simple block (or allow) lists without giving administrative access to the firewalls.

Documentation: https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/730/management-center-device-config-73/objects-object-mgmt.html#ID-2243-00000291

Restarting work on ISE-T

Greetings programs,

Today I restarted work on my little go-based ISE utility after a long hiatus. It’s like going to the gym after a long absence. Some pain is involved. But I got something done! Just need to finish one task a day, and eventually, I’ll have a fully working tool. I’ll be rambling on about it here to give myself some accountability

The thing I was working on today (besides refamiliarizing myself with the code) was generalizing the API calls into one helper function. If you’re used to thinking like a Python programmer, the tricky part is you can’t just say, “Hey, give me back the JSON body, and I’ll dot into it to grab what I want”. This is because of Go’s strong typing. You have to model the JSON out as a struct ahead of time. Since each API call returns a different JSON data structure, you must have a separate function for each one. My solution was to split things up to have a generic function that will call an API endpoint, read the body into a byte slice, then pass that to another function that will unmarshal it into the struct that I can actually utilize.

It took a minute to figure all this out, but I got it to work.

Development branch: https://github.com/srmcnutt/ise-t/tree/development

Monday Morning notes – 03.02.2020

Greetings programs!

It’s been quite a ride for the last month or so, so much going on. Last Monday morning I passed the new Cisco DEVASC exam (200-901) on the first day to test, making me a member of the Devnet 500 club.

DEVNET 500 w00t!

Preparing for the exam really did a lot for sharpening up some relatively new skills I’ve acquired that haven’t had a lot of reinforcement. That’s the real value of IT certifications – having that performance-based focal point. When your learning is self-directed there is a real tendency to sort of wander from topic to topic and lose focus, and learning tracks are a great tool to combat that.

That said, I think the most important takeaway is that we’re rapidly transitioning to an API driven world and it’s important to get comfortable working with structured data and logical abstractions in general regardless of the job role.

Ok, about Terraform. What I’m working through is the approach I want to take. I want to bring a unique angle rather than join a chorus of people all saying and doing the same thing. If there are specific things you would like to see, let me know in the comments.

Thanks for reading and I’ll see you around.

Monday morning note 02.17.2020

Greetings Programs!

Just a quick check-in for this week.

Life has gotten a bit hectic recently, and will likely remain so for another couple of weeks. Small things are beginning to take conscious effort and focus which is a reliable indicator that I need to trim the sails a little. What this means for this space is the first Terraform post is delayed for a week, possibly two.

On a brighter note, the weather was wonderful for this morning’s walk, my dogs were well behaved, and coffee is always there for us and wants us to be happy.

Until next time, may you care for yourself with ease.


PKIFNE #12: Diffie Hellman Groups

Greetings programs!

Today’s post is an excerpt from my CCIE Security notes, and it has a useful table of Diffie Hellman groups, which you can use as a job aid in IPSEC VPN designs. I Hope you find it useful.

About Diffie Hellman

The key bit of magic that makes IKE (Internet Key Exchange) possible is Diffie-Hellman. Diffie-Hellman allows anonymous entities to calculate a shared secret that can’t be discovered by a third party listening to the exchange. What’s amazing about it is the peers are able to do this using two different passwords that they keep private and never exchange. DH is one of the earliest examples of Public Key Cryptography.

Key points

  • Diffie-Hellman does not provide authentication. It’s used to assist in creating a secure channel for authentication
  • Diffie-Hellman does not provide encryption. It provides the keying material for encryption.
  • Diffie-Hellman is used for control plane functions only.


At a high level it works like this:

If side a and side b use the same generator and modulus, resulting values from step 5 and 6 should be the same. This shared key is used as an input to the negotiated encryption algorithm.

In the case of Diffie-Hellman The generator and Prime (g,p) are predefined values (defined in a number of different RFCs) which are referenced as Diffie-hellman groups. The larger the Generator and Prime are, the more difficult it is to break. As computational power has increased substantially since the first DH groups were defined, the old groups are no longer safe to use.

The following Table lists the Diffie-Hellman Groups:

Diffie Hellman Groups

*NGE refers to Cisco Next Generation Encryption, which is the vendors set of recommended ciphersuites.

*NSA Suite B refers to the United States the National Security Agency’s published list of list of interoperable modern cryptographic standards.

Children of the Magenta Line

Greetings programs!

I believe it’s a safe assumption that the current crop of budding network engineers are being indoctrinated with the notion that if they don’t 100% automate all the things, their jobs and careers will be at risk. My friend Daniel Dibb deserves ample credit for repeatedly asking the question “What happens when we subsequently end up with a generation of automation engineers who don’t understand networking?”.

Yesterday morning I was drinking coffee, scrolling through my Twitter feed, when I came across a thread where Marko Milivojević posted a link to a youtube video of American Airlines Captain Warren Van Der Burgh, delivering a talk in 1997 called Children of the Magenta Line. The context is lessons learned from a rash of airline crashes caused by flight crews becoming too dependent on automation.

If you are an infrastructure engineer, or you manage infrastructure engineers, this video is worth 25 minutes of your time.

There are two quotes that stand out from this Video:

  • We are Pilots and Captains, not Automation Managers
  • You’ve got to pick the appropriate level of automation for the task at hand

In googling the name of the video, I came across this article which had a quote from William Langewiesche which also illustrates a fundamental problem with over reliance on automation:

“We appear to be locked into a cycle in which automation begets the erosion of skills or the lack of skills in the first place and this then begets more automation.”

Let’s learn from the Airline industry and not repeat their mistakes.

Flock of birds wheeling around a statue of the barefoot mailman

Have a good one, and I’ll see you around.


Quick hit: playing with Terraform & IOS-XE Day 0 automation

Greetings Programs!

Over the last week or so I’ve been working on an Infrastructure as code Azure Hybrid cloud deployment, based on the Azure Spoke and Hub reference topology.

The gateways connecting Azure to the On-Prem datacenter in my case are Cisco Cloud Services Router 1000v (CSR1kv), using day 0 automation to inject a configuration into the Azure Router.

Here’s a link to the Azure Deployment Guide for the CSR1kv, which has some really interesting tidbits. I’ll dive into those in future post.

To actually execute the infrastructure build, I’m using a tool called Terraform.

Terraform does an incredible job of abstracting away all the details you normally have to worry about when provisioning cloud provider infrastructure. It’s a joy to work with. The documentation and examples are easy to follow, and the error messages tell you exactly what you did wrong and where to look.

Terraform Description file example

If that wasn’t cool enough, the Terraform binary is actually built in to the Azure Cloud shell. The net of that is, once you have your deployment files built, you can work with them using just cloudshell, which is super convenient.

Azure Cloud Shell – Checking the Terraform Version

That’s it for today. Lot’s of neat stuff in this lab that I’m dying to talk about, can’t wait to share.

Best regards,


Blowing the dust off, redux

Greetings programs.

I took this photo just a few minutes ago on my Monday morning beach walk. I hope you find it relaxing.

Holy cow, been 8 months since my last dispatch.  Still studying and learning cool stuff, have not done a good job at stopping to document my learnings, going to make another attempt to rectify that.

Been an eventful year.  In addition to learning DevOps tools and techniques and studying cloud native software design, I’ve also changed jobs.  As of August I’ve been working at Cisco systems as a pre-sales Architect.  It’s a dream job and I absolutely love working with my customers. I learn as much from them as they learn from me.

So yeah, the new job thing; several months of getting the firehose and struggling to take everything in and find my stride.

I didn’t feel like that was enough new stuff, so I enrolled in WGU’s Cybersecurity Bachelor’s program starting in January.  I don’t **need** a degree, but I don’t think it would hurt to become a more well-rounded technologist.  I’ve historically used certifications for learning paths which is fine but they tend to be narrowly defined in scope which can lead to polarized thinking.

So here’s the plan for the blog:  I’m committing to posting something every Monday morning, even if it’s just a “hello, I’m drinking coffee and checking my twitter feed how about you”.  I have a sizable collection of study notes, so there’s no shortage of meaningful topics however. Hopefully I’ll dip into that more than the small talk  :).

Have a great week, talk to you next Monday morning.