Cisco NL Strategic Innovation Tour 2019

Cisco NL Strategic Innovation Tour 2019

Fortunately, Cisco Netherlands organized another innovation tour for Cisco Partners in the week before Cisco Live US in San Diego. This time the innovation tour spanned two days and included visits to four tech companies in Sillicon Valley. In this blog I’d like to share my experiences of the tour.  

Apple Systems

Our first company visit was Apple Systems. And while many business visits happen at the 1 infinite loop building in Cupertino, we were honored to be invited to the new Apple Park campus building in Cupertino.

After a bit of a delayed start (well, Apple Park is huge!), we were welcomed by Apple in an environment quite beautiful .

There were a number of briefings, which were all very interesting. One was on how Apple is working with partners in its ecosystem, that not only includes Cisco on the networking side, but also a huge partnership with IBM on Swift and App developments. Another session was on how Apple sees the future, their role in the enterprise and they demo’ed several aspects of which were related to privacy, the announcements made at WWDC2019 earlier that week.

What really stood out for me was the way they demonstrated their new VoiceControl options for those that have disabilities. The video touched me, as I thought back to my father who died of A.L.S. in 2009, and how he might have used that (for a short period of time, as his speech deteriorated too). Besides this video, the capabilities of endpoint management that Apple can offer (both with and without supervised mode) were demonstrated, including a short briefing on the WWDC2019 announcement of having two distinct data-profiles on your iPhone. Of course, I already knew that a lot is possible for endpoint management on Apple devices, but the demo made clear that quite some nice new features have been introduced.

After the formal briefing sessions, we were invited to Apple’s visitor center, right across Apple Park. We got a tour through the visitor center, how it mirrors the new Apple Park Campus design and besides an awesome Augmented Reality app (see image below, thanks to Fred Spikker), the guide also explained how Apple park can already be so lush and green, while the building is only 2 years old! Steve Jobs and Jony Ive wanted to have employees working at Apple Park a full-grown experience, so they grew trees in other locations and moved them after the construction was finished!

But what really stood out to me was not the amazing design of the building itself, but the sustainability of the building. The building has zero CO2 footprint (even negative footprint, e.g. reducing) by large solar panels for power generation, but also the airflow of the cool San Francisco breeze is used to cool the building. They only need Airconditioning 3 months a year, the rest of the time, the wind is used for cooling. And yes, it was comfortable inside!


Our second visit on the first day was to Meraki HQ in San Francisco. And although we arrived late, we were welcomed at the Meraki office.

The session with Meraki and the tour around their office was interesting. Meraki still has a typical valley-startup vibe to it, which is acknowledged by the fact that personal packages can be delivered (or picked up) at the office, food provided by Meraki, dynamic office environments and not to forget, you can bring your dog along.

I don’t know what I can publicly share on the content of the sessions, but Meraki is really integrating more with Cisco Systems on several fields, such as integration with SDA and of course network programmability. Meraki of course already supported API’s, but they now have an API first strategy, so in time, everything you see in the web interface is effectively an API call to the backend. 

Cisco Systems

A visit to Cisco itself can of course not be forgotten. Day 2 started with a visit to Cisco’s Customer Experience Center in San Jose. And besides bumping into Chuck Robbins when walking through the center, we had some very interesting briefings.

The first briefing detailed the change that Cisco is foreseeing in the partnership. With Cisco profiling more as a software company, the partnership is changing. Don’t worry, Cisco still strongly believes and is committed to the partner model, but a different type of partners emerge besides just supplying the hardware boxes. It is part of the digital transformation and the journey a lot of organizations are on.

Image courtesy of Fred Spikker

The second briefing was very interesting. It was presented by Hugo Latapie, one of the experts on Artificial Intelligence and Machine Learning. What I truly loved about it is that he didn’t only demonstrate what can be done with deep fusion reasoning, but also the drawbacks on AI/ML. There are plenty of samples on the Internet where an image, used for learning, can be changed in such a way that a completely different object is recognized.


The last briefing was with Edwin Paalvast. As he is also Dutch, his briefing was in Dutch and he shared his vision on the challenges many enterprises face, and how Cisco can support them. And typical Dutch, we had a discussion on that vision and challenged one and another. I must say, I did recognise the problems he described and see them in my own environment too. And although the dot on the horizon is clear, the road to it is still a journey with a lot of hurdles to take in.


And well, we were at the customer experience center, so we also received a very nice demo on how Cisco’s security portfolio supports the enterprise and the world in a more secure environment.


The last company visit of this innovation tour was with Nvidia, in their brand new headquarters. What a beautiful building and what a difference with Meraki and the other companies too. 

NVidia welcomed us with a reference to an article that states that businesses in The Netherlands are, according to research, leading the way in applying Artificial Intelligence. And that not only the large corporations use them. 


After this quick intro, the four technology pillars of NVidia (Gaming, Professional Visualization, Artificial Intelligence, and Self-Driving Cars) were explained.


All these four pillars are driven by the same common technology, also known as GPU and how the innovation and evolution of the GPU have brought enormous computational power to different sectors.

The briefing also detailed on how AI has changed the world around us already, with AI driving suggestions within Search Engines, Image Recognition and other industrial fields. After a short explanation on the Cisco-NVIDIA partnership (where you can get these amazing GPU’s in an UCS appliance for VDI deployments or GPU-based machine learning), the power of GPU’s for AI were demonstrated along a number of verticals.

What I really liked about the story of Nvidia is their single platform strategy on GPU’s. Nvidia has a Deep Learning Institute that teaches organizations (and individuals) on how you use deep learning to solve complex problems. Everybody can take sessions within this institute and get started on GPU-based AI/Machine learning. And the single platform strategy means that you can start coding solutions yourself on a developer board, such as the Jetson Nano ($99) or Jetson TX2 (twice the power) and you can then scale that up to GPU-based cloud services or an on-prem solution without changing your code.
And yes, within the networking industry, we are only just getting started programming the network, imagine what you can do with your programming skills on these GPU’s. There is a whole new world out there. I bought one of these developer kits to see how I can use GPU computational power to solve networking problems…

After the briefing itself, we were showed around NVidia’s Customer Experience Center. In that center, they have demonstrations on all the things you can do with GPU’s, from image-learning at a much larger pace, to a visualized photo of a woman, which is not a real person (freaky), to the possibilities of creating a 3D cut of x-ray visions in the medical industry, or a short trailer of a completely computer-rendered movie, very realistic.


It is quite difficult to provide a summary of this year’s innovation tour. It was jam-packed and although each visited company is technology-focused, they have their own culture, vision, and strategy.

And throughout these differences, there is a thin red lining that touches all these companies, whether they are one of the thought leaders or applying them. And that is that technology is changing our lives in ways that we could not fathom five years ago. AI and ML are technologies that are here to stay, there are some drawbacks (like telling what is real and what is not, or that the quality of learning is poor, and some philosophical and social discussions that really need to take place). The general goal of this technology is for the good and to improve the quality of life. 

If I had to summarize the tour and things I saw and learned, I would use the following word.


(I really hope that 2020 will also have an Innovation Tour!)

Hitting 100% CPU after restore on Firepower Management Center

I recently purchased a new microserver to reduce my power footprint at home. And I had to move the FMC (Firepower Management Center) from the OpenStack deployment that I previously ran at home. However, I ran into several bugs in OpenStack that were fixed in later versions, but I couldn’t upgrade because of another bug. Essentially I hit a catch-22 and had to deploy a new FMC on that new microserver and use a restore to move the data and policies. In that process I did hit a bug for which I’d like to share some info on. (more…)

Swift & Network programmability, a good combo? An introduction.

Swift & Network programmability, a good combo? An introduction.

Swift is commonly known by iOS and MacOSX Software developers as Apple introduced the language in 2014 for MacOSX, iOS and Linux application development.
In my role as software engineer I’ve used different programming languages to build small tools, solutions or prototypes. For network programmability I’ve used Java as my primary language. I have my reasons, which I might share later in another post.

Network Programmability on the web pretty much evolves around Python. Is Swift mature enough and powerfull enough to be used for programming the network? Time to write up my experiences in a blog series. The first post is an introduction to Swift. (more…)

FTD 6.2 and Remote Access VPN (anyconnect) configuration

FTD 6.2 and Remote Access VPN (anyconnect) configuration

With Firepower Threat Defense (FTD) version 6.2 Cisco has introduced the remote access VPN functionality from the ASA firewall software. For an overview of the differences, you could read a previous post. With FTD 6.2.2 (released in september) this feature is now also avaialble on the ASA platforms. With a week of PTO planned, it was time to configure and test RA VPN on my home environment. (more…)

FTD access policy behaviour

FTD access policy behaviour

In a previous blog, I’ve written about the differences between Firepower Threat Defense and ASA software. And although the basic OS appears to be ASA with Snort set in between ASA ingress and egress, some basic concepts of the ASA (or actually the PIX) have disappeared in FTD. And it will have an impact once you migrate from ASA (with or without firepower) to FTD devices..
The Cisco ASA firewall has implemented the concept of security levels on interfaces. Each interface must have an interface name and interface level (IP-address is only necessary if you use routed or IRB interfaces). The concept for this is quite easy, let’s take the basic ASA edge deployment into mind.

With interface security levels the ASA keeps two principles into mind when a packet comes into the firewall for a new connection:

  • Traffic is always allowed from a higher security level to a lower security level, unless an access-list prohibts this
  • Traffic is never allowed from a lower security level to a higher security level, unless there is an access-list explicitly permitting the traffic and a static translation is created

So, in this example, the client with internal IP is allowed to go outbound to the webserver on the Internet, but unless you configure a specific access-list, traffic is not allowed from the Internet to the inside mail server.
If you then take into account that IOS/PIX/ASA access-lists always have an implicit deny ip any any statement in the access-list, so even if you configure an access-list (except of course permit ip any any), traffic will be blocked by that implicit match. So it’s relatively easy to tie down the traffic flows, right?

In FTD things are working quite differently.. In FTD there is not really the concept of an access list with an implicitly deny any any. Within FTD, an access policy is used to define the policies that need to be applied to one or more FTD devices. One or more rules, which are run sequentially, combined define the access policy. Each rule in itself contains several elements that can be combined to define the policy rule. Each rule consists following elements:

Element Description
source zone(s) Within FTD it is possible to logically combine different interfaces into a single zone. One or more zones can be used as selection criteria
destination zone(s) Also one or more destination zones can be used as selection criteria, for example the “outside” zone
source network(s) This is the classic selection criteria for a layer3 firewall, based on one or more source IP networks.
destination network(s) This is the classic selection criteria for a layer3 firewall, based on one or more destination IP networks.
VLAN’s It is possible to match traffic based on the vlan tag
Users This is part of the next generation firewall that is inside FTD, per user (or group) policy rules can be matched
Applications Also part of the next generation firewall, in which a lot of applications are already defined. It is also possible to define custom applications using openAppID as well
Source port(s) Classic criteria for the source ports. Within FTD there is a default group called “high ports” that you can use for client connections
Destination port(s) Classic match criteria for the destination ports. It is possible to use one or more ports to match on, or use a port group.It is possible to mix and match UDP, ICMP, ICMP6, TCP, etc in a single match statement
ISE/SGT attributes This is used if you have a pxGrid ISE integration with FirePower and wish to match on scalabale group tags
URL Categories This is also part of the next generation firewall feature set, in which you can use URL categories (like advertisment, Phishing, etc) to match traffic on. It is a recommended from Cisco not to combine these URL categories together with the application matching statement.
File Policy This option (within the rule details) specifies which file detection policy is to be used in AMP for networks.
IPS Policy (with variable set) It is possible to define different Intrusion Policies within FMC. Within a specific rule it is possible to set a custom IPS signature policy.
Action The resulting action that FTD will take when the packet is matching this rule.


FTD Policy actions

There are different actions that FTD can take once a packet has matched the access rule, being

Action Description
Allow This traffic
Trust Trust this traffic and do not send it to Snort for inspection.
Monitor Monitor this traffic, apply inspection, but do not discard packets (drop)
Block Block this packet. Be aware, if used on a TCP connection,  the client will do retries
Block with reset Block this packet and send TCP resets to client and server to reset this packet
Interactive Block This is similar as the block action, but FTD will respond back with a web page that provides feedback to the block
Interactive Block with Reset This is similar as the block with reset action, but FTD will respond back with a web page that provides feedback to the block

For grouping purposes it is possible to group access rules together. Using this approach, it is a very flexible and powerfull mechanism to define the policy. It is a single policy for both ingress and egress traffic, so double access list policies are not required anymore, which is a great benefit. Also, rules are run through sequentially, so after a packet matches the rule, the specific actions are executed.

But what happens if no rule inside the policy is matched? Well, then the default Action comes into play. As soon as you create a new access policy, FMC asks what the default action will be of the new policy

Block all traffic Just block all traffic, similar to the implicit deny any any
Intrusion prevention Allow traffic, but do run it through Snort for inspection
Network discovery Allow traffic for discovery of users, applications and hosts on the network

Within a Firepower on ASA rule, I usually choose the “Intrusion Prevention” or “network discovery” rule, as there is still a firewall outside the FirePower module that has access-lists as well.

But in FTD that is not true!! If you choose “network discovery” or “intrusion prevention“, you will basically allow alltraffic to traverse through the firewall as the interface security levels are in essence equal. So it is then basically a router with some security power! I ran into this issue when I converted a Firepower on ASA device to FTD recently. This is something you have to be aware off.

If you want to change this behaviour in an access policy at a later stage, just go into the access policy and click the pull down menu at the bottom of the policy and select “Access control: Block All Traffic”

So in summary, if you start working with FTD and come from an ASA background, make sure your that you define the access rules both ways and have explicit block rules in your access policy. Either via the default action or per traffic-flow in a category.