As a part of course CSC 791 - Linux Networking, we decided to create a SaaS project, Transit Routing as a Service.
Why did we build it?
In order to have high availability, companies generally choose to have a multi-cloud deployment and would require services to connect instances over L2 or L3 network.
Cloud providers, having a strong backbone network and presence all over around the globe, can monopolize the routing service. We decided to build an opensource SaaS product, extending Linux virtualization, to provide such services to achieve required custom connectivity for the clients' sites.
How did we build it?
Stack
- Python (Logic)
- Ansible (Orchestration)
- Bash (Low level linux API interaction)
- Linux Network Namespace utility (Custom Virtual Network Devices)
- Quagga (BGP Implementation)
- VxLAN (L2 Connectivity)
- GRE (L3 Connectivity)
- Docker (Infrastructure)
We took leverage of Linux virtualization technology to create a custom topology over the internet which could give L2 and L3 connectivity.
Architecture
Link to the repo
ke2ulpatani
/
Transit-RaaS
Routing as a service between different public cloud
Multi Cloud Transit VPC based Routing as a Service
/etc :
This directory is where tenants place their config files (We have populated this directory for demo purposes)
/var :
This directory is where any run time information and logs are placed
/logic :
This directory is where all the core processing logic and Ansible playbooks
execute.sh that is used to run as the driver code in order to create VPCs, Spines, Leaves, L1 Transits or L2 Transit Nodes.
constants.py :
Has a set of pre defined constants and paths
create-vms.yml :
Define, Start and Attach interface to VMs
create_leaf.py :
Used to create leaf nodes that hosts a subnet with one or more multiple PCs
create_spine.py :
Used to create spines, L1 transits and L2 transits nodes
create_vpc.py :
Used to create a VPC
hyp_utils.py :
Utitlity functions that are built to work on the JSON file stored on…
Top comments (0)