Tweet This: Tweet
Share on LinkedIn:
By Omid Moheb, Kovarus Sr. Solution Architect
I joined Kovarus in 2019 from the other side of the table — as a former Global Director it was past-me who was meeting with the likes of current-me to discuss partnerships and strategic solutions. There are a lot of important points that need to be considered for building and maintaining a partnership — the following three top priorities were important to me to warrant at least a second meeting:
- Does the potential partner understand my business — not that of other, similar or competing companies — but MY business?
- If they do, are the solutions they are proposing strategic and integrate well in either my current or planned ecosystem?
- Do the proposed solutions work in real life?
The last item is obviously very critical — and the best way to answer that question is to demonstrate the proposed solution working — not on paper, but in practical life. Seeing is believing and a picture speaks more than 1,000 words — and so on.
However, not every customer has the possibility or means to go through a proof of concept or pilot implementation, for many different reasons, including but not limited to: resource constraints (people, time, budget); day to day business impact; control; experience; and skillset. That’s where a lab or mock environment comes in handy. At Kovarus, we call it the Kovarus Proven Solution Center.
Our KPSC is not only a room full of equipment — it is an experience for our customers. Imagine an EBC coupled with the technical depth to satisfy all levels of customer engagements — from conversations with C-level executives all the way to having engineers poke and probe technical solutions, even allowing for our customers to get their own feet wet and hands on the technology they are interested in.
The KPSC is however not a training facility, or for an isolated product showcase — there are much better resources available by the OEMs which are tailored for those purposes. For example the Cisco dCloud (https://dcloud.cisco.com/).
The advantages the KPSC offers over the OEM platforms and self-service demo portals are:
- Ability to mock up our customer’s environments and showcase how the new technology or solution would work in tandem with the existing ecosystem
- Customization of demos and POCs to meet the specific needs of our customers
- Integrated and turnkey solution demos
- Multi-vendor product interaction demos
While we represent many different OEMs and solutions in our KPSC, the scope of this document is our latest network environment addition, which we’ve built in close collaboration with our partner Cisco. To do that, I’ll follow my all-time favorite OSI model (https://en.wikipedia.org/wiki/OSI_model).
Layer 1 Overview
The goal was to imitate a typical enterprise environment — with various branch sites, a data center and a public cloud footprint. At each branch site, we assume we have a need for corporate, bring-your-own-device (BYOD) and guest network access — each segment having different connectivity characteristics and security requirements. At the data center we have the centralized workloads as well as shared network services as well as management and monitoring tools.
We’ve been able to compile a quite comprehensive suite of products for Enterprise Networking:
- Wireless: Catalyst 9120 Wi-Fi 6 Access Points, as well as Wi-Fi 5 (802.11ac Wave 2) Cisco Wireless APs (3800 and 4800) — and the latest Cisco Catalyst 9800 Wireless LAN Controller
- LAN switching: Catalyst 9300 POE and MultiGig models
- WAN Routing: Cisco SDWAN (former Viptela) with the cloud-based controllers as well as various edge routers: vEdge 100 and 1000, cEdge 1111 and 4331 (ISR 4K) running the SDWAN code.
- DNA Center
- Virtual WAN with the ability to influence various WAN link parameters such as bandwidth, delay, loss and jitter
- Wired and Wireless Clients: We use an array of Raspberry Pi’s to simulate the clients and generate load on the network.
And we were able to mount all of this into a single rack and make it look great!
Layer 2-4 Overview
To accommodate the different connectivity and security requirements for each user group, I’ve defined three different VLANs which are in three different SSIDs and end up in three different Cisco SDWAN VPNs (a.k.a. VRFs = Virtual Routing and Forwarding).
Per default, there’s no connectivity policies between the three segments, but there’s access to common services and targets. Corporate subnets typically gain access to resources residing in private IP space (“RFC1918”) which are typically internal to the corporation and only allowed to corporate-issued devices with tightly controlled security software on them, which are usually issued to employees that have been onboarded and vetted by HR.
BYOD and guest networks can usually only access internet resources, often restricted to business-critical services and apps using methods like content filtering and bandwidth quotas.
I’ve seen the legal requirements be completely different depending on the legal team and the company and their nature of the business — as well as geographical location of each site. I’ve came across zero liability stance for courtesy guest internet services, where there’s no Acceptable Use Policy (AUP) or security measures that would limit the level of access BYOD and guest users would get access to.
As for the IP schema and addressing, we use an open source tool called Netbox as a standard at Kovarus. Having an up-to-date IP Address Management (IPAM) tool is crucial for successful and efficient day-to-day operations including change management and network planning, and a cornerstone for any type of network automation and orchestration.
Layer 5-7 Overview
What’s a network without any workloads, apps, services and clients using it? Not worth much if you ask me — so I’ve decided to add a few Raspberry Pi’s to the mix to simulate wired and wireless connectivity, as well as running load generators which will make graphs and stats better looking for the monitoring and management tools we have setup for the environment. The setup still needs to look professional, which is made possible by some neat rack mount kits for the Raspberry Pi boards. The OS running on them is Kali Linux — chosen for two reasons:
- Linux allows for more flexibility and control over the network configuration.
- The Kali distribution because it’s well known among network and security communities and comes pre-loaded with network and security tools that will come in handy for the planned demos and POCs.
In order not to lose connectivity to the Raspberry Pi’s when connecting/disconnecting from the various network segments and switching between wireless and wired networks, an additional Ethernet dongle was added, and some modifications were necessary to the routing table of Linux.
The following diagram shows how it all comes together — indicating what’s ready today and what’s planned:
Some highlights I wanted to point out are:
- Single policy definition, visibility and control across enterprise and cloud / data center networks
- Telemetry-based, real-time fault isolation and remediation (“Self-healing networks”)
- End-to-end process automation for daily network operations tasks such as troubleshooting, change management as well as new request fulfillments and deployments
- Simplified workload migration for hybrid cloud infrastructure
Once the full lab is built out, the use cases that could be demonstrated and explored are endless. The goal is also to keep the spectrum of the targeted audience fairly wide: whether you’re coming in as a C-level executive, manager of an app developer team, CLI network engineer or a DevOps Unicorn — we want to capture and wow you all!
Looking to learn more about modernizing and automating IT? We created the Kovarus Proven Solutions Center (KPSC) to let you see what’s possible and learn how we can help you succeed. To learn more about the KPSC go to the KPSC page.
Also, follow Kovarus on LinkedIn for technology updates from our experts along with updates on Kovarus news and events.