Categories
Cloud Computing

Decentralized Network Security with Interstellars

We have heard about multifarious approaches to network security in the insecure times today with quite a few of them adding additional complexity and manageability to the already complex centralized cloud computing and data center setups.

Interstellars are a part of SynchroKnot Spatial Defined Networking and allow the creation of networks separated and secured directly at Ethernet layer 2. In Cloud Computing terminology, with Interstellars, the tenants have the ability to bifurcate and secure their network of virtual machines across decentralized hardware by simply assigning the virtual machines’ network interface card with a 28-bit Interstellar Identification.

By bifurcating and securing the decentralized network at layer 2, only the virtual machines that have the same Interstellar Identification can communicate with eachother, irrespective of their local or global location.

As an additional benefit, you can save a lot of time and energy by not having to carve separate layer 3 networks and setting up different gateways for them. Further, you may not have to configure the virtual machines to point the gateways you set up to have them communicate!

In this way you can substantially reduce the complexity, manageability and maintainence of networks and also further reduce the risks of misconfigurations which usually lead to security breaches.

Interstellars come built-in with the SynchroKnot software. The SynchroKnot software transforms any server, workstation, desktop or embedded device into a decentralized cloud or data center [data decenter].

You can use any commodity X86_64 Desktop/Workstation/Server/Embedded device and connect them to eachother in minutes.

Here are some of the highlights of how SynchroKnot Interstellar approaches network security by getting directly to the heart of layer 2 Ethernet:

■ Fully Flattens, Bifurcates and Secures the network at Layer 2. Works transparently, irrespective of stacked / unstacked vlans, and without deviating from standard Ethernet semantics.

■ Based on the design and architecture of Interstellar Identification, Interstellar Resonance Identification and Interstellar OUI [Organizationally Unique Identifier].

■ Each vNIC of the virtual machine MAC address has a 28-bit Interstellar Identification. Assign your own choice of Interstellar IDs.

■ Each virtual machine with the same Interstellar ID can communicate with eachother irrespective of their location. All other traffic from the virtual machine is not allowed to touch the network.

■ In the case where a virtual machine needs to resonate [ communicate ] across different Interstellars at the same time, additional Interstellar IDs can be accommodated in the form of Interstellar Resonance IDs. Both Interstellar and Interstellar Resonance IDs remain intact even when the virtual machines relocate to any other decentralized location.

■ Interstellar OUI allows direct interaction of the virtual machines with the existing physical data center infrastructure [ routers, switches, gateways, appliances & devices ]. Simply add the needed OUI(s) [ organizationally unique identifier – a 24-bit number that uniquely identifies a vendor or manufacturer ] and gain transparent access.

■ Interstellars [ in collaboration with other SynchroKnot features ] allow for flexible carving of the IP network(s) of the virtual machines by allowing the creation of large networks [ eg: /7, /8, /16 etc ] without having to set up routing and gateways to move across subnets or worry about broadcasts. The same flexibility is transparently possible with IPv6 and anything usually above layer 2.

More information is available at:
■ synchroknot.com

Categories
Cloud Computing

Flood Ping Fun with 24 Switches in a Ring Topology!

This demonstration video shows a total of 24 Ethernet switches in one large loop [ Ring Topology ] with Satellite Tree Protocol enabled and multiple switches being brought down and up every 10 seconds while Flood Pings are underway from multiple directions!

The SynchroKnot Satellite Tree Protocol an enhancement to the IEEE standard [ 802.1D (1998|2004), 802.1W ] while keeping the core semantics in place, and is a part of SynchroKnot Spatial Defined Networking.

Satellite Tree Protocol is the core networking component of the SynchroKnot Cloud Computing and Data Center Decentralization software which transforms any server, workstation, desktop or embedded device into a decentralized cloud or data center [data decenter].

The object is to ascertain the automatic and fast network resilience [root bridge failure, failover and failback], fault tolerance and intelligent path selection capabilities amidst very low hardware resources.

This demonstration setup has been purposefully done with an illogical setting so as to test how it can perform in extreme circumstances.

Mininet is used for actual network emulation.

You may also notice results of prior flood ping tests in the demonstration video before the current one gets underway.

We would like to assume that the outcome result with 0% [zero percent] packet loss with 24 switches is a bit much for our logical mind to digest and would love to blame the ping utility with a faulty flood ping option 🙂 ….. of course upon deeper contemplation you may develop an insight that differs.

■ In actual use case scenarios, with our unique cabling technique in a 5 X 5 2-D Torus topology, one may generally not have more than one or two hops! 24 nodes are used for purposes of extreme testing in difficult case scenarios.

■ Simple machine with 2 cores [4 threads] Intel Core i7-6500U Processor with 8 GB RAM. Alongside, a few running virtual machines not a part of this demo were used in the background to consume CPU and memory resources, leaving fewer CPU cycles and memory for Satellite Tree Protocol and the 24 nodes with Mininet. [This demonstration video was also recorded on the same machine and thus used additional CPU cycles and memory.]

■ Side Note : Spanning Tree Protocol and Rapid Spanning Tree Protocol generally respond to failures by recovering in about 40 to 300 seconds or more depending upon the timers and topology [ RSTP may recover faster in some scenarios ]. This is with the regular vendor / standards suggested timers found in most switches in standard setups today. One can increase the network diameter [ i.e number of switches between two endpoints ] to a maximum of about 18. This however will substantially increase the recovery time, alongside most likely put the timers of switches out of sync. Your mileage may vary. Please do your own research.

■ Caution : If you try a similar setup with standard physical Ethernet switches [Cisco, Juniper etc] then you are solely responsible if you brick your appliance(es). We cannot help you recover them.

In brief, the SynchroKnot software transforms any server, workstation, desktop or embedded device into a decentralized cloud or data center [data decenter]. You can use any commodity X86_64 Desktop/Workstation/Server/Embedded device and connect them to eachother. There is no need to purchase physical or virtual switches and routers or any of their licenses [Eg. Cisco, Juniper etc].

This demonstration video is available at the link below and also on synchroknot.com under the the demo section:

■ Spatial Satellite Tree Protocol showing Root Bridge failure, failover, failback with Flood Ping from multiple directions

More information is available at:
■ synchroknot.com