<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Automation on Problem of Network</title>
    <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/tags/automation/</link>
    <description>Recent content in Automation on Problem of Network</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <lastBuildDate>Thu, 06 Jun 2024 09:13:06 +0200</lastBuildDate>
    <atom:link href="https://6364c9bf.problemofnetworkdotcom.pages.dev/tags/automation/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Untangling My Brain From Autocon1</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/untangling-my-brain-from-autocon1/</link>
      <pubDate>Thu, 06 Jun 2024 09:13:06 +0200</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/untangling-my-brain-from-autocon1/</guid>
      <description>&lt;p&gt;Last week I had some fun in Amsterdam, and at no point was there any debauchery.&lt;/p&gt;&#xA;&lt;p&gt;For those who are unaware, Autocon is a conference put together by the Network Automation Forum. Autocon1 was the second event ever, and the first in Europe. They ran autocon0 in Denver in the Autumn of 2023.&lt;/p&gt;&#xA;&lt;p&gt;TL:DR - if you are in the network automation space, you have to try and get yourself there. It&amp;rsquo;s a &lt;em&gt;very&lt;/em&gt; valuable event.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Software Defined Waffle with a gitops topping</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/software-defined-waffle/</link>
      <pubDate>Mon, 22 Jun 2020 12:51:00 +0000</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/software-defined-waffle/</guid>
      <description>&lt;p&gt;Over the last two years or so, I have been on adventure with Data Centre Infrastructure renewal. As past posts may allude to, ACI was a big part of what we did, but before anyone gets all dogmatic about it, know that we didn&amp;rsquo;t go &amp;ldquo;All in&amp;rdquo; with that one product, since I personally don&amp;rsquo;t subscribe to the &amp;ldquo;DC Fabrics cure all ills&amp;rdquo; mantra.&lt;/p&gt;&#xA;&lt;p&gt;CLOS fabrics and the various approaches to overlays within them are great at providing stable platforms with predictable properties for speed, latency and scale. Unsurprisingly, they go on to do a great job in server farms that can make the best use of that flexibility. During recent conversations on DC refresh, our Arista friends have been extremely keen to try and get us to run our Internet BGP border on the fabric as well. The 7280SR2K can handle 2M routes in FIB they say, just lob stuff into a VRF, bit of policy and voila. Yeah.&lt;/p&gt;</description>
    </item>
    <item>
      <title>ACI: Controller Upgrades with Python</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/aci-controller-upgrades-python/</link>
      <pubDate>Thu, 28 Jan 2016 01:42:00 +0000</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/aci-controller-upgrades-python/</guid>
      <description>&lt;p&gt;So I bought my ACI bundles so long ago that they&amp;rsquo;re still running 1.0(3f). Right now mainline is 1.2(1k), so i&amp;rsquo;m a bit behind.&lt;/p&gt;&#xA;&lt;p&gt;Using the official Cisco doc I did the first staged upgrade from 1.0 to 1.1 using the Web GUI. I wanted to see what happened in a visual sense.&lt;/p&gt;&#xA;&lt;p&gt;Basically you setup a connection between the APIC and a host that has staged the firmware files, then you setup a policy defining what versions the fabric should be on, and when that should be made active. For me it was 1.1(4f) and now basically.&lt;/p&gt;</description>
    </item>
    <item>
      <title>ACI: Initial Design Considerations</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/aci-initial-design-considerations/index.md/</link>
      <pubDate>Mon, 18 Jan 2016 11:49:00 +0000</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/aci-initial-design-considerations/index.md/</guid>
      <description>&lt;p&gt;ACI brings with it many different constructs for operating networks, some of which have analogous equivalence with classical networking, some of which are literally bat-poop crazy.&lt;/p&gt;&#xA;&lt;p&gt;As per usual, you can find lots of resources on how to structure ACI fabrics elsewhere, i&amp;rsquo;m not going to waste time on what you &lt;em&gt;can&lt;/em&gt; do and focus on what I am going to do (roughly).&lt;/p&gt;&#xA;&lt;p&gt;The below Image was unceremoniously stolen from Cisco themselves, in the critical read &lt;a href=&#34;http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI-Fundamentals_chapter_010001.html&#34;&gt;ACI Fundamentals&lt;/a&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>The ACI Adventure Begins</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/aci-adventure-begins/</link>
      <pubDate>Sat, 09 Jan 2016 18:21:00 +0000</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/aci-adventure-begins/</guid>
      <description>&lt;p&gt;Starting yesterday I began to deploy our Nexus 9000 ACI solution into our Datacentre. Scary yet fun times are ahead.&lt;/p&gt;&#xA;&lt;p&gt;Over the course of the project I will do my best to chronicle anonymised info that talks about what we did and how we did it.  Some of that may be of use to another ACI hopeful, whereas some will be pretty specific to my environment.  One thing I won&amp;rsquo;t be doing is reinventing the blogging wheel, and I will chose to refer to others that helped me, rather than rehash the same subjects over and over again.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Using CallManager APIs for fun and profit: Part 4 - Python End to End</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/call-manager-api-part4/</link>
      <pubDate>Mon, 29 Jun 2015 00:41:00 +0000</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/call-manager-api-part4/</guid>
      <description>&lt;p&gt;So by now you can use SoapUI and Python to read info out, and can utilise SoapUI Test Cases to validate, and deliver changes to the CallManager system.  Again, please do ensure you have reviewed parts 1-3 before entering into this post.  Its entirely contextualised within the series.&lt;/p&gt;&#xA;&lt;p&gt;Up until now what we have been doing is quite focused on a single object being added or sense checked.  In this, the final post in this mini series we will be looking at an end to end python script that can be used to add a new end user to the system, with pre and post validation.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cisco Live 2015</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/cisco-live-2015/</link>
      <pubDate>Thu, 11 Jun 2015 19:55:00 +0000</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/cisco-live-2015/</guid>
      <description>&lt;p&gt;This week is a first for me.  I&amp;rsquo;m at Cisco Live in San Diego.  It&amp;rsquo;s been pretty awesome so far I have to say!&lt;/p&gt;&#xA;&lt;p&gt;&lt;em&gt;Full Disclosure, I was brought here by Cisco to talk to Analysts about ACI. However, I should also point out my only session was closed door feedback on why we chose the solution, and how its helped us to date.  Since we are only at the early stages, it was a short conversation.  I thank Cisco for their hospitality, and for allowing me to access Conference Level sessions that my explorer level pass would not normally allow.&lt;/em&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Using CallManager APIs for fun and profit: Part 3 - Changes</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/call-manager-api-part3/</link>
      <pubDate>Mon, 01 Jun 2015 10:41:00 +0000</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/call-manager-api-part3/</guid>
      <description>&lt;p&gt;In this the third part of my mini series on using the CUCM API, we start to get further into the Ju-Ju, and check web app changes via the API, before then going on to make a change via the API itself.&lt;/p&gt;&#xA;&lt;p&gt;As before if you haven&amp;rsquo;t gone through the previous two posts then please, head back to the start and we will see you back here shortly.&lt;/p&gt;&#xA;&lt;h2 id=&#34;whats-your-motivation-today&#34;&gt;Whats your motivation today?&lt;/h2&gt;&#xA;&lt;p&gt;There are two reasons why you might want to use an API in your day to day changes.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Using CallManager APIs for fun and profit: Part 2 - Python</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/call-manager-api-part2/</link>
      <pubDate>Sun, 31 May 2015 18:33:00 +0000</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/call-manager-api-part2/</guid>
      <description>&lt;p&gt;In this part 2 of my API adventure, I will be looking at repeating what we did Part 1 via SoapUI, but this time in python using the suds library.  If you haven&amp;rsquo;t read that yet, then really, please go back and do that. This will not be wildly useful otherwise.&lt;/p&gt;&#xA;&lt;h2 id=&#34;getting-soap-y-with-python-suds&#34;&gt;Getting SOAP-y with Python suds&lt;/h2&gt;&#xA;&lt;p&gt;Yeah I went there&amp;hellip;&lt;/p&gt;&#xA;&lt;p&gt;So, we have a process that allows us to programatically look stuff up. Only its not very repeatable, and therefore not much use yet.  With this post I will take you through the creation of a python script that mimics what we did previously - finding things, and showing them to you.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Ciscoconfparse Wetdream</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/ciscoconfparse-wetdream/</link>
      <pubDate>Sat, 30 May 2015 03:07:00 +0000</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/ciscoconfparse-wetdream/</guid>
      <description>&lt;p&gt;Ick,  I know.&lt;/p&gt;&#xA;&lt;p&gt;Python has long been the language of choice for engineers looking to make their day go that little bit quicker or easier.  With deepening skill levels, more and more complex repetitive tasks can be disected and segmented into functions and reuable code, such that a competent scripting engineer can go from blank page to automated process in a matter of hours in most cases.  It is for this reason that I sit here to write this - an advocacy for ALL Cisco engineers to down tools and spend however long you need to get good at this.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Using CallManager APIs for fun and profit: Part 1 - SoapUI</title>
      <link>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/call-manager-api-part1/</link>
      <pubDate>Fri, 29 May 2015 16:13:00 +0000</pubDate>
      <guid>https://6364c9bf.problemofnetworkdotcom.pages.dev/posts/call-manager-api-part1/</guid>
      <description>&lt;p&gt;This is one of those posts that I will constantly refer back to&amp;hellip; ;)&lt;/p&gt;&#xA;&lt;p&gt;In my day job it&amp;rsquo;s clear to me that we need to automate more and more of the dumb day to day stuff.  One of those things is Leavers and Starters on our phone system.&lt;/p&gt;&#xA;&lt;p&gt;We employ Cisco CallManager, much like the rest of the world, and if you have ever spent any time with it, you will know that its VASTLY over-complicated to manage.  A single extension on someones&amp;rsquo; desk requires (at least):&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
