My first Cisco router was a blade for a Cabletron modular hub (anyone remembers what hubs were or a company named Cabletron?). We plugged it in, I read the documentation, figured out I had to type conf t and was faced with a blinking cursor staring back at me from an empty line.

A few years later I was invited to beta test Cisco software release 9.21 (it wasn’t called IOS yet). The best feature it had was the awesome configuration CLI with context-sensitive prompts and on-demand help.

Read more ...

Have you ever wondered how many free ports you have on your stackable campus switches? I’m sure there must be a wonderful network management tool that creates that reports with a click of a button… but what if the tool your PHB purchased based on awesome PowerPoint and glitzy demo can’t do that?

Nadeem Lughmani decided to solve this challenge as a hands-on assignment in the Building Network Automation Solutions online course and created an Ansible playbook and a Python plugin that counts the total number of ports and number of free ports for each switch stack specified in the device inventory.

Wonder what else course attendees created in the past? Here’s a small sample.

Storing passwords in clear text is a bonanza for insider threats. Who knows what they got ?

The post Insider Threats and Facebook’s Poor Password Management appeared first on EtherealMind.

Because RSS is best way to get information

The post RSS and Medium blogs appeared first on EtherealMind.

JSNAPY is an open source tool released by Juniper Networks circa 2015 that is the Python version of the Juniper Snapshot Administrator. This tool in the most simplest sense gives us the ability to have unit-tests when working with Junos, much in the same way a developer would write tests against their code. JSNAPy creates snapshots of a device’s operational or configurational state, the content of which depends on tests. JSNAPy then can diff and check these snapshots, which when combined with your test logic, means you can detect when things change or don’t change as per your desire. It’s a simple but effective tool when working with Junos. In fact, if you have another system to take the snapshot, JSNAPy is really an XML snippet checking tool and thus, it can be used for multi-vendored environments!!!

JSNAPy is a great tool for not only dealing with operational changes, but also also for steady state change operations too through the use of both

pre

and

post

tests and the logical operators JSNAPy supports. It’s worth mentioning you can call the snaps and tests anything you want. Bob and Alice are both valid examples of a snap name, but the advice here is to use meaningful naming.

All tests and configuration are written in YAML and are quite simple providing you spend five minutes to get acquainted with the keywords.

Here are the installation instructions in case you haven’t installed it yet: https://github.com/Juniper/jsnapy/wiki/1.-Installation

Just in case you didn’t know, JSNAPy can also be used in Ansible directly, the gains of which need to be said. Here is a link to an Ansible example to help shortcut the ramp-up time! https://github.com/arsonistgopher/Juniper5StepDemos/tree/master/Ansible

Here are the logical test operators supported by JSNAPy at the time of writing.

- Execute Tests Over Elements with Numeric or String Values
    1. all-same: Check if all content values for the specified element are the same. It can also be used to compare 
                 all content values against another specified element.
           - all-same: flap-count
             checks if all values of node <flap-count> in given Xpath is same or not.

    2. is-equal: Check if the value (integer or string) of the specified element matches a given value.
           - is-equal: admin-status, down
             check if value of node <admin-status> in given Xpath is down or not.  

    3. not-equal: Check if the value (integer or string) of the specified element does not match a given value.
           - not-equal: oper-status, down
             check that value of node <oper-status> should not be equal to down.  

    4. exists:  verifies the existence of an XML element in the snapshot.
           - exists: no-active-alarm 
             checks if node </no-active-alarm> is present or not  
 
    5. not-exists: verifies xml element should not be present in snapshot
           -not-exists: no-active-alarm 
            checks </no-active-alarm> node should not be present in snapshot.  

    6. contains: determines if an XML element string value contains the provided test-string value.
           - contains: //package-information/name[1], jbase
           checks if jbase is present in given node or not. 

    7. not-contains: determines if an XML element string value does not contain the provided test-string value.
           - not-contains: //output, sync_alarm
           checks if sync_alarm is present in given node or not.

 - Execute Tests Over Elements with Numeric Values
    1. is-gt: Check if the value of a specified element is greater than a given numeric value.
            - is-gt: cpu-total, 2
              checks value of <cpu-total> should be greater than 2  

    2. is-lt: Check if the value of a specified element is lesser than a given numeric value.
            - is-lt temperature, 55
              checks value of <temperature> is 55 or not.  

    3. in-range: Check if the value of a specified element is in the given numeric range.
            - in-range memory-buffer-utilization, 20, 70 
              check if value of <memory-buffer-utilization> is in range of 20, 70  

    4. not-range: Check if the value of a specified element is outside of a given numeric range.
              - not-range: memory-heap-utilization, 5 , 40
                checks if value of <memory-heap-utilization> is not in range of 5 to 40

 - Execute Tests Over Elements with String Values: 
    1. contains: determines if an XML element string value contains the provided test-string value.
           - contains: //package-information/name[1], jbase
             checks if jbase is present in given node or not.

    2. not-contains: determines if an XML element string value does not contain the provided test-string value.
           - not-contains: //output, sync_alarm
           checks if sync_alarm is present in given node or not.

    3. is-in: Check if the specified element string value is included in a given list of strings.
           - is-in: oper-status, down, up
             check if value of <oper-status> in is list (down, up)  

    4. not-in: Check if the specified element string value is NOT included in a given list of strings.
           - not-in :oper-status, down, up
             check if value of <oper-status> in not in list (down, up)

*Taken from https://github.com/Juniper/jsnapy/wiki*

JSNAPy is great for use in upgrade & update scenarios. The aim is to ‘finger print’ the pre change state and then take another fingerprint of the post state for comparison.

Junos Upgrade

You want to update Junos on a production device in the quickest and most reliable way possible. JSNAPy can be used to snapshot the state of interfaces, routing protocols and general health from both an operational and configuration perspective. Anywhere we can access XML data (everywhere on Junos), we can use JSNAPy to snapshot and run checks!

1. Take

   pre

   snapshots of test hotspot areas, for example:
   -Number of routes in

   inet.0

   routing table
   -Number of interfaces in physical up state
   -Number of BGP peers in the established state

2. Upgrade Junos

3. Take new post snapshots after some settling¹ time

4. Run JSNAPy checks to ensure the

   post

   state is the same as the

   pre

   state

This is a pretty straight forward example and the

is-equal

test operator will suffice here. The trickiest thing will be to find the correct XML xpath statement with regards to pinning the data described in the short list.

Addition of an Interface

This one isn’t so straight forward as ensuring the pre state matches the post state and so examples are included! Also the pre test is being used as a collision check to make sure that the network attribute isn’t being used before we intend to use it! If you’re familiar with Junos, you’ll also understand that if an interface isn’t configured, you just won’t see it in the configuration XML. If it’s an SFP based line card or fixed-form device, chances are you also won’t see it in the operational XML if the SFP is missing. All the fun of the circus with this example and exactly why I chose to write about it.

The way to deal with JSNAPy in this scenario is based on the logic of XML elements missing for pre-tests and on the logic of XML elements being present and correct for the post checks.

First of all, we need device configuration files for JSNAPy which are here:

Pre configuration

# Pre-Test for basic automation
hosts:
  - device: demo01
    username: tf
    passwd: Passw0rd
tests:
  - ./tests/pre.yml

Post configuration

# Post-Test for basic automation
hosts:
  - device: demo01
    username: tf
    passwd: Passw0rd
tests:
  - ./tests/post.yml

Github link for pre config here
Github link for post config here

The workflow for the set of pre tests looks like below:
1. Check that interface

ge-0/0/42

isn’t configured
2. Check that

irb.42

isn’t configured
3. Check that the VLAN

DT

isn’t configured – DT for DeepThought, a large and beefy server that likes watching TV

We could take this further and ensure that the VLAN number isn’t in use, so let’s assume we have one source-of-truth and name/number is tightly coupled.
Also, we could add another test in the style of the existing ones if you’re paranoid!

Here are the actual pre tests. Note we iterate through the list of interfaces and check that all of them are not equal. Take the

test_phy

test as an example, here we check that each name of the interface in the interface list is NOT equal to

ge-0/0/42

. Simple but effective logic.

test_phy:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/interfaces
  - iterate:
      id: ./name
      xpath: 'interfaces/interface'
      tests:
        - not-equal: name, ge-0/0/42
          info: "Interface does not exist"
          err: "-"

test_irb:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/interfaces
  - iterate:
      id: ./name
      xpath: 'interfaces/interface[name="irb"]/unit'
      tests:
        - not-equal: name, 42
          info: "Interface does not exist"
          err: "-"

test_vlan:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/vlans
  - iterate:
      id: ./vlan
      xpath: 'vlans/vlan'
      tests:
        - not-equal: name, DT
          info: "VLAN does not exist"
          err: "-"

GitHub link for pre test here

The workflow for the post test is a little different to the pre. We’ll check for direct matches and do not iterate through the list.

1. Check that interface

   ge-0/0/42

   exists
2. Check that

   irb.42

   exists
3. Check that VLAN

   DT

   exists

test_phy:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/interfaces
  - item:
      id: ./name
      xpath: 'interfaces/interface[name="ge-0/0/42"]'
      tests:
        - is-equal: name, ge-0/0/42
          info: "Interface exists"
          err: "-"

test_irb:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/interfaces
  - item:
      id: ./name
      xpath: 'interfaces/interface[name="irb"]/unit[name="42"]'
      tests:
        - is-equal: name, 42
          info: "Interface exists"
          err: "-"

test_vlan:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/vlans
  - item:
      id: ./vlan
      xpath: 'vlans/vlan[name="DT"]'
      tests:
        - is-equal: name, DT
          info: "VLAN exists"
          err: "-"

GitHub link for post test here

Executing Tests

JSNAPy tests are super easy to run providing you have it installed and the credentials to the device under test are correct.

The below example shows running both the

pre

and

post

tests using the

--snapcheck

switch. This switch makes JSNAPy do a

snapshot

and also perform a check against the tests referenced by the

x.yml

file the command line call references.

JSNAPy --snapcheck pre -f pre.yml
JSNAPy --snapcheck post -f post.yml

Close

Whilst this post doesn’t serve as a full blown guide with install, it does deliver some “how-to” logic if you’re wondering about the tool.

Hopefully this post has proved to be a useful view into a use of JSNAPy and has delivered some value in payment for your time.

You may want to trigger these tests within a CI/CD pipeline as separate stages to really get the value out of the tool and tests. This way, tests that fail can prevent the pipeline from progressing any further in the case of pre tests and failed post tests can be used to trigger revert workflows.

Useful Links
– Matt Oswalt wrote about JSNAPy here.
– NRELabs has a JSNAPy lesson which means you can use it for free and extremely quickly in a browser session. That can be found here
– https://github.com/Juniper/jsnapy/blob/master/README
– https://github.com/Juniper/jsnapy/wiki/2.-Writing-test-and-config-file
– https://github.com/Juniper/jsnapy/wiki/3.-Command-Line-Tool

The post IaC – unit tests with jSNAPy and Ansible appeared first on ipengineer.net.

We all know about catastrophic headline-generating failures like AWS East-1 region falling apart or a major provider being down for a day or two. Then there are failures known only to those who care, like losing a major exchange point. However, I’m becoming more and more certain that the known failures are not even the tip of the iceberg - they seem to be the climber at the iceberg summit.

Read more ...

A terminal UI for tshark, inspired by Wireshark

The post Termshark appeared first on EtherealMind.

Don't bet on products, bet on skills and knowledge

The post Your Job and EOL Products appeared first on EtherealMind.

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

One of the common questions I get once the networking engineers progress from Ansible 101 to large-scale deployments (example: generating configurations for 1000 devices) is “Can Ansible use a relational database? Text files don’t scale…”

TL&DR answer: Not directly, but there are tons of database Ansible plugins or custom Jinja2 filters out there.

Read more ...

The root zone of the DNS has been the focal point of many DNS conversations for decades. One set of conversations, which is a major preoccupation of ICANN meetings, concerns what labels are contained in the root zone. A separate set of conversations concern how this root zone is served in the context of the DNS resolution protocol. In this article I'd like to look at the second topic, and, in particular, look at two proposals to augment the way the root zone is served to the DNS.

Live in New York on May 14

The post Gluware and Packet Pushers Live Event In New York – Please Join Us appeared first on EtherealMind.

Like most business management truths, its plain wrong.

The post Boiling the Frog is a Falsehood appeared first on EtherealMind.

Remember how Nick Buraglio tried to use OpenDaylight to build a small part of SuperComputing conference network… and ended up with a programmable patch panel?

This time he repeated the experiment using Faucet SDN Controller – an OpenFlow controller focused on getting the job done – and described his experience in Episode 101 of Software Gone Wild.

We started with the usual “what problem were you trying to solve” and quickly started teasing apart the architecture and got geekily focused on interesting things like:

Read more ...

This is a guest blog post by Dave Crown, Lead Data Center Engineer at the State of Delaware. He can be found automating things when he's not in meetings or fighting technical debt.

---

In a recent blog post, Ivan postulated “You’d execute a REST API call. Any one of those calls might fail. Now what? ... You’ll have absolutely no help from the orchestration system because REST API is not transactional so there’s no rollback.” Well, that depends on the orchestration system in use.

The promise of controller-based solutions (ACI, NSX, etc.) is that your unicorn powered network controller should be an all seeing, all knowing platform managing your network. We all have hopefully learned about the importance of backups very early on our careers. Backup and, more importantly, restore should be table stakes; a fundamental feature of any network device, let alone a networking system managed by a controller imbued with magical powers (if the vendor is to be believed).

Read more ...

If you had to pick two really hot topics in the networking space right now, you’d be hard-pressed to find two more discussed than SD-WAN and microsegmentation. SD-WAN is the former “king of the hill” in the network engineering. I can remember having more conversations about SD-WAN in the last couple of years than anything else. But as the SD-WAN market has started to consolidate and iterate, a new challenger has arrived. Microsegmentation is the word of the day.

However, I think that SD-WAN and microsegmentation are quickly heading toward a merger of ideas and solutions. There are a lot of commonalities between the two technologies that make a lot of sense running together.

SD-WAN isn’t just about packet switching and routing any longer. That’s because networking people have quickly learned that packet-by-packet processing of traffic is inefficient. All of our older network analysis devices could only see things one IP packet at a time. But the new wave of devices think in terms of flows. They can analyze a stream of packets to figure out what’s going on. And what generates those flows?

Applications.

The key to the new wave of SD-WAN technology isn’t some kind of magic method of nailing up VPNs between branch offices. It’s not about adding new connectivity types. Instead, it’s about application identification. App identification is how SD-WAN does QoS now. The move to using app markers means a more holistic method of treating application traffic properly.

SD-WAN has significant value in application handling. I recently chatted with Kumar Ramachandran of CloudGenix and he echoed that part of the reason why they’ve been seeing growth and recently received a Series C funding round was because of what they’re doing with applications. The battle of MPLS versus broadband has already been fought. The value isn’t going to come from edge boxes unless there is software that can help differentiate the solutions.

Segmenting Your Traffic

So, what does this have to do with microsegmentation? If you’ve been following that market, you already know that the answer is the application. Microsegmentation doesn’t work on a packet-by-packet basis either. It needs to see all the traffic flows from an application to figure out what is needed and what isn’t. Platforms that do this kind of work are big on figuring out which protocols should be talking to which hosts and shutting everything else down to secure that communication.

Microsegmentation is growing in the cloud world for sure. I’ve seen and talked to people from companies like Guardicore, Illumio, ShieldX, and Edgewise in recent months. Each of them has a slightly different approach to doing microsegmentation. But they all look at the same basic approach form the start. The application is the basic building block of their technology.

With the growth of microsegmentation in the cloud market to help ensure traffic flows between hosts and sites is secured, it’s a no-brainer that the next big SD-WAN platform needs to add this functionality to their solution. I say this because it’s not that big of a leap to take the existing SD-WAN application analytics software that optimizes traffic flows over links and change it to restrict traffic flow with policy support.

For SD-WAN vendors, it’s another hedge against the inexorable march of traffic into the cloud. There are only so many Direct Connect analogs that you can build before Amazon decides to put you out of business. But, if you can integrate the security aspect of application analytics into your platform you can make your solution very sticky. Because that functionality is critical to meeting audit goals and ensuring compliance. And you’re going to wish you had it when the auditors come calling.

---

Tom’s Take

I don’t think the current generation of SD-WAN providers are quite ready to implement microsegmentation in their platforms. But I really wouldn’t be surprised to see it in the next revision of solutions. I also wonder if that means that some of the companies that have already purchased SD-WAN companies are going to look at that functionality. Perhaps it will be VMware building NSX microsegmentaiton on top of VeloCloud. Or maybe Cisco will include some of their microsegmentation from ACI in Viptela. They’re going to need to look at that strongly because once companies that are still on their own figure it out they’re going to be the go-to solution for companies looking to provide a good, secure migration path to the cloud. And all those roads lead to an SD-WAN device with microsegmentation capabilities.

Every time I’m running a data center-related workshop I inevitably get pulled into stretched VLAN and stretched clusters discussion. While I always tell the attendees what the right way of doing this is, and explain the challenges of stretched VLANs from all perspectives (application, database, storage, routing, and broadcast domains) the sad truth is that sometimes there’s nothing you can do.

In those sad cases, I can give the workshop attendees only one advice: face the reality, and figure out how badly you might fail. It’s useless pretending that you won’t get into a split-brain scenario - redundant equipment just makes it less likely unless you over-complicated it in which case adding redundancy reduces availability. It’s also useless pretending you won’t be facing a forwarding loop.

Read more ...

his thread on Reddit/r/networking about building your own branch NFV caught my interest

The post Response: BYO Branch NFV appeared first on EtherealMind.

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

I was walking down the infinite hallways of Cisco Live Europe chatting with the fellow Tech Field Day Extra delegates when I probably blanked out for a minute as the weirdest of thoughts hit me: “REST API is not transactional”

TL&DR: Apart from using structured data and having error codes REST API is functionally equivalent to Cisco IOS CLI from 1995

Read more ...

DOH is not going away. It seems that the previous article on DOH has generated some reaction, and also there is some further development that should be reported, all of which I'll cover here.

Cred to dark_15

Presentation on Google's internal network from the show floor

The post The High-Performance Network (Cloud Next ’19) – YouTube appeared first on EtherealMind.

This is a guest blog post by Albert Siersema, senior network and cloud engineer at Mediacaster.nl. He’s always busy broadening his horizons and helping his customers in (re)designing and automating their infrastructure deployment and management.

---

We’d like to be able to automate our network deployment and management from a single source of truth, but before we get there from a running (enterprise, campus!) network, we’ll have to take some small steps first.

These posts are not focused on 802.1x, but it serves as a nice use case in which I’ll show you how automation can save time and bring some consistency and uniformity to the network (device) configuration.

Read more ...

I’m not the only one telling people not to bet the farm on Santa Claus and dancing unicorns. Pete Welcher wrote a nice blog post describing the implications of laws of physics and data gravity (I described the gory details in Designing Active-Active Data Centers and AWS Networking Deep Dive webinars).

Meanwhile, Russ White reviewed an article that (without admitting it) discovered that serverless is just software running on other people’s servers.

Enjoy!

Every now and then I get a question along the lines of I’m your subscriber and would like to know more about X, so I decided to start creating technology-specific pages on www.ipSpace.net that would include links to most relevant ipSpace.net blog posts, webinars, sections in our online courses, and interesting third-party resources.

The subscriber triggering this process asked me about Intent-Based Networking, so here’s the relevant resources page.

802.11ax is fast approaching. Though not 100% ratified by the IEEE, the spec is at the point where most manufacturers and vendors are going to support what’s current as the “final” version for now. While the spec for what marketing people like to call Wi-Fi 6 is not likely to change, that doesn’t mean that the ramp up to get people to buy it is showing any signs of starting off slow. One of the biggest problems I see right now is the decision by some major AP manufacturers to call 802.11ax a “wireless switch”.

Complex Duplex

In case you had any doubts, 802.11ax is NOT a switch.¹ But the answer to why that is takes some explanation. It all starts with the network. More specifically, with Ethernet.

Ethernet is a broadcast medium. Packets are launched into the network and it is hoped that the packet finds the destination. All nodes on the network listen and, if the packet isn’t destined for them they discard it. This is the nature of the broadcast. If multiple stations try to talk at once, the packets collide and no one hears anything. That’s why Ethernet developed a collision detection  system called CSMA/CD.

Switches solved this problem by segmenting the collision domain to a single port. Now, the only communications between the stations would be in the event that the switch couldn’t find the proper port to forward a packet. In every other case, the switch finds where the packet is meant to be sent and forwards it to that location. It prevents collisions by ensuring that no two stations can transmit at any one time except to the switch in the middle. This also allows communications to be full-duplex, meaning the stations can send and receive at the same time.

Wireless is a different medium. The AP still speaks Ethernet, and there is a bridge between the Ethernet interface and the radios on the other side. But the radio interfaces work differently than Ethernet. Firstly, they are half-duplex only. That means that they have to send traffic or listen to receive traffic but they can’t do both at the same time. Wireless also uses a different version of collision detection called CSMA/CA, where the last A stands for “avoidance”. Because of the half-duplex nature of wireless, clients have a complex process to make sure the frequency is clear before transmitting. They have to check whether or not other wireless clients are talking and if the ambient RF is within the proper thresholds. After all those checks are confirmed, then the client transmits.

Because of the half-duplex wireless connection and the need for stations to have permission to send, some people have said that wireless is a lot like an Ethernet hub, which is pretty accurate. All stations and APs exist in the contention (collision) domain. Aside from the contention algorithm, there’s nothing to stop the stations from talking all at once. And for the entire life of 802.11 so far, it’s worked. 802.11ac started to introduce more features designed to let APs send frames to multiple stations at the same time. That’s what’s called Multi-user Multi-In, Multi-out (MU-MIMO).In theory, it could allow for full-duplex transmissions by allowing a client to send on one antenna and receive on another, but utilizing client radios in this way has impacts on other things.

Switching It Up

Enter 802.11ax. The Wi-Fi 6 feature that has most people excited is Orthogonal Frequency-Division Multiple Access (OFDMA). Simply put, OFDMA allows the clients and APs to not use the entire transmission channel for sending data. It can be sliced up into sub-channels that can be used for low-bandwidth applications to reserve time to talk to the AP. Combined with enhanced MU-MIMO support in 802.11ax, the idea is that clients can talk directly to the AP and allocate a specific sub-channel resource unit all to themselves.

To the marketing people in the room, this sounds just like a switch. Reserved channels, single station access, right? Except it is still not a switch. The AP is still a bridge between two media types for one thing, but more importantly the transmission medium still hasn’t magically become full-duplex. Stations may get around this with some kind of trickery, but they still need to wait for the all-clear to send data. Remember that all stations and APs still hear all the transmissions. It’s still a broadcast medium at the most basic. No amount of software configuration is going to fix that. And for the networking people in the room that might be saying “so what?”, remember when Cisco tried to sell us on the idea that StackWise was capable of 40Gbps of throughput because it could send in both directions on the StackWise ring at once? Remember when you started screaming “THAT’S NOT HOW BANDWIDTH WORKS!!!” That’s what this is, basically. Smoke and mirrors and ignoring the underlying physical layer constraints.

In fact, if you read the above resources, you’re going to find a lot of caveats at the end about support for protocols coming up and not being in the first version of the spec. That’s exactly what happened with 802.11ac. The promise of “gigabit Wi-Fi” took a couple of years and the MU-MIMO enhancements everyone was trumpeting never fully materialized. Just like all technology, the really good stuff was deferred to the next release.

To make sure that both sides are heard, it is rightly pointed out by wireless professionals like Sam Clements (@Samuel_Clements) that 802.11ax is the most “switch-like” so far, with multiple dynamic collision domains. However, in the immortal words of Tyler Durden, “Sticking feathers up your butt doesn’t make you a chicken.” The switch moniker is still a marketing construct and doesn’t hold any water in reality aside from a comparison to a somewhat similar technology. The operation of wireless APs may be hub-like or switch-like, but these devices are not either of those types of devices.

CPU Bound and Determined

The other issue that I see that prevents this from becoming a switch is the CPU on the AP becoming a point of contention. In a traditional Ethernet switch, the forwarding hardware is a specialized ASIC that is optimized to forward packets super fast. It does this with some trickery, including cut through for packets and trusting the incoming CRC. When packets bounce up to the CPU to be process-switched, it bogs the entire system down terribly. That’s why most networking texts will tell you to avoid process switching at all costs.

Now apply those lessons to wireless. All this protocol enhancement is now causing the CPU to have to do extra duty to work on time-slicing and sub-channel optimization. And remember that those CPUs are operating on 18-28 watts of power right now. Maybe the newer APs will get over 30 watts with new PoE options, but that means those CPUs are still going to be eating a lot of power to process all this extra software work. Even adding dedicated processing power to the AP isn’t going to fix things in the long run. That might be one of the reasons why Cisco has been pushing enhanced PoE in the run-up to their big 802.11ax launch at the end of April.

---

Tom’s Take

Let me say it again for the cheap seats: 802.11ax is NOT a wireless switch! The physical layer technology that 802.11 is built on won’t be switchable any time soon. 802.11ax has given us a lot of enhancements in the protocol and there is a lot to be excited about, like OFDMA, BSS coloring, and TWT. But, like the decision to over-simplify the marketing name, the idea of calling it a wireless switch just to give people a frame of reference so they buy more of them is just silly. It’s disingenuous and sounds more like a snake oil salesman than honest technology marketing. Rather than trying to trick the users with cute sounding terms, how about we keep the discussion honest and discuss the pros and cons of the technology?

Special thanks to my friends in the wireless space for proofreading this post and correcting my errors in technology:

• Keith Parsons
• Sam Clements
• Blake Krone
• Ryan Adzima
• Tauni Odia
• Jonathan Davis

A long while ago I published a sample Ansible/NAPALM/Jinja2 solution that would take LLDP information and turn it into a network diagram (I described its details in a short video that’s accessible to anyone attending our network automation course or having an Expert subscription).

The trickiest part of that solution was detection of bidirectional links:

Read more ...

When I started working with Cisco routers in late 1980s all you could get were devices with a dozen or so ports, and CPU-based forwarding (marketers would call it software defined these days). Not surprisingly, many presentations in Cisco conferences (before they were called Networkers or Cisco Live) focused on good network design and split of functionality in core, aggregation (or distribution) and access layer.

What you got following those rules were stable and predictable networks. Not everyone would listen; some customers tried to be cheap and implement too many things on the same box… with predictable results (today they would be quick to blame vendor’s poor software quality).

Read more ...

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

One of my readers sent me this question:

Would you write about methods for reverting from expected new state to old state in the case automation went wrong due to (un)predictable events that left a node or network in a limbo state betwixt and between.

Like always, there’s the easy and the really hard part.

Read more ...

Last Thursday I started another experiment: a series of live webinar sessions focused on business aspects of networking technologies. The first session expanded on the idea of three paths of enterprise IT. It covered the commoditization of IT and networking in particular, vendor landscape, various attempts at segmenting customers, and potential long-term Enterprise IT paths. Recording is already online and currently available with standard subscription.

Although the attendance was lower than usual, attendees thoroughly enjoyed it – one of them sent me this: “the value of ipSpace.net is that you cut through the BS”. Mission accomplished ;)

From time to time the IETF seriously grapples with its role with respect to technology relating to users' privacy. Should the IETF publish standard specifications of technologies that facilitate third party eavesdropping on communications or should it refrain from working on such technologies? Should the IETF take further steps and publish standard specifications of technologies that directly impede various forms of third party eavesdropping on communications? Is a consistent position from the IETF on personal privacy preferred? Or should the IETF be as agnostic as possible and publish protocol specifications based solely on technical coherency and interoperability without particular regard to issues of personal privacy? This issue surfaced at IETF 104 in the context of discussions of DNS over HTTPS, or DOH.

If you're at least vaguely familiar with modern black hole theories, you'll totally enjoy the concept of email event horizon.

Wireless isn’t easy by any stretch of the imagination. Most people fixate on the spectrum analysis part of the equation when they think about how hard wireless is. But there are many other moving parts in the whole architecture that make it difficult to manage and maintain. Not the least of which is how the devices talk to each other.

This week at Aruba Atmosphere 2019, I had the opportunity to moderate a panel of wireless and security experts for Mobility Field Day Exclusive. It was a fun discussion, as you can see from the above video. As the moderator, I didn’t really get a change to explain my thoughts on OpenConfig, but I figured now would be a great time to jump in with some color on my side of the conversation.

Yin and YANG

One of the most exciting ideas behind OpenConfig for wireless people should be the common YANG data models. This means that you can use NETCONF to have a common programming language against specific YANG models. That means no more fumbling around to remember esoteric commands. You just tell the system what you want it to do and the rest is easy.

As outlined in the video, this has a huge impact on trying to keep configurations standard across different types of APs. Imagine the nightmare of trying to configure power settings or radio thresholds with 3 or more AP manufacturers in your building. Now, imagine being able to do it across your building or dozens of others with a few simple commands and some programming know-how? Doesn’t seem quite as daunting now, does it? It’s easy because you’re speaking the same language across all those APs.

So, what if you don’t care, like Richard McIntosh (@802TopHat) points out? What if your vendor doesn’t support OpenConfig? Well, that’s fine. Not everyone has to support it today. But if you work on building a model system and setting up the automation and API interfaces, are you just going to throw it out the window during your refresh cycle because the new APs that you’re buying don’t support OpenConfig? Or is the need for OpenConfig going to be a huge driver for you and part of the selection process.

Companies are motived by their customers. If you tell them that they need to develop OpenConfig for their devices, they will do it because they run the risk of losing sales. And if the industry moves toward adopting a standard northbound API, what happens to those that get left out in the cold after a few missed refresh cycles? I bet they’ll quickly realize the lost opportunities more than cover the development costs of supporting OpenConfig.

Telemetry Short-Cuts

The other big piece of OpenConfig and wireless is telemetry. SNMP-based monitoring doesn’t work well in today’s wired networks and it’s downright broken in wireless. There are too many variables out there in the average deployment to be able to account for them with anything other than telemetry. Many vendors are starting to adopt the idea of streaming the data directly to collectors via a subscription model. OpenConfig makes this easy with the ability to subscribe to the data you want using OpenConfig models.

From a manufacturer perspective, this is a huge chance to get into telemetry and offer it as a differentiator. If you’re not tied to using an archaic platform with proprietary data models you can embrace OpenConfig and deliver a modern telemetry infrastructure that users will want to adopt. And if the radio performance is the same between all of the offerings, telemetry could be a the piece that tips the scales in your favor.

Single-Vendor Isn’t So Single

I remember doing a deployment for a wireless system once that was “state of the art” when we put it in. I had my challenges and made everything work well and the customer was happy. Until a month later when the supporting vendor announced they were buying a competing company and using that company as their offering going forward. My customer was upset, naturally, but so was I. I spent a lot of time working out how to build and deploy that system and now it was on the scrap heap.

It’s even worse when you keep buying from single vendors and suddenly find that the new products don’t quite conform to the same syntax or capabilities. Maybe the new model of router or AP has a new board that is 95% compatible with the old one, except of that one command you use all the time.

OpenConfig can change that. Because the capabilities of the device have to be outlined you can easily figure out if there are any missing parts and pieces. You can also be sure that your provisioning scripts and programs aren’t going to break or cause problems because a critical command was deprecated. And since you can keep the models around for old hardware as well as new you aren’t going to be duplicating efforts everywhere trying to keep things moving between the platforms.

---

Tom’s Take

OpenConfig is a great idea for any system that has distributed components. Even if it never takes off in Wi-Fi, it will force the manufacturers to do a bit better job of documenting their capabilities and making them easy to consume via API. And anything that exposes more functionality to be consumed by automation and programmability is a good thing indeed.

A while ago I made a statement along the lines of “MPLS segment routing is the best thing that happened to MPLS control plane in a decade”. Obviously some MPLS-focused engineers disagree with that and a few years ago I decided to write a lengthy blog post explaining the differences between using MPLS SR with IGP (or BGP) versus more traditional IGP+LDP approach.

Obviously, I wasn’t making any progress on that front, so the only way forward was to record a short video on the topic which didn’t work well either because the end-result was a set of three videos (available with free or paid ipSpace.net subscription).

• Principles of MPLS-based transport core;
• Drawbacks of MPLS label distribution with LDP;
• MPLS label distribution in Segment Routing

When I started working with Ansible networking modules they had a distinct science fair feel: everything was in flux, every new version of Ansible would break my playbooks, modules would disappear from one release to next, documentation was sketchy and describing the latest development code not a shipped release.

In the meantime, code, documentation, and release/deprecation management improved dramatically:

Read more ...

If you’ve been in networking long enough you’d probably noticed an interesting pattern:

• Some topic is hotly debated;
• No agreement is ever reached even though the issue is an important one;
• The debate dies after participants diverge enough to stop caring about the other group.

I was reminded of this pattern when I was explaining the traffic filtering measures available in private and public clouds during the Designing Infrastructure for Private Clouds workshop.

Read more ...