OpenSwitch Project

Kuntal Daftary OpenSwitch Engineering and Operations Management Hewlett Packard Enterprise Networking Open Switch

Open Switch Why OpenSwitch? Orchestration Control Plane Virtual Switch Physical Switch OS Physical Switch HW ? Disrupting data centers networking with open source and freedom of choice

Open Switch What is OpenSwitch? Community-based, Open-source, Full-featured, Network OS Launched in early Oct  home for developer and user innovation OpenSwitch.net community now:

Open Switch OpenSwitch: Technical Overview CLI, WebUI, Ansible, REST Consistency from temp mgmt. to BGP North Bound Interface Central Database Approach with OVSDB System Architecture Abstracted driver model OpenNSL, SAI or BYO SDK Hardware Underlay

Single OpenSwitch Instance ops-switchd Open Switch RFC 7047 protocol for integrations OpenSwitch: Architecture OVSDB-server Management daemons CLI, Rest,Chef,… Kernel Virtual L2/3 interfaces System daemons sysd, intfd, vland, … L2/3 protocol daemons bgpd, lldpd, lacpd, … Openflow controllers ASIC kernel SDK I 2 C and other drivers Derivation of ovs-vswitchd DB and Openflow layers ASIC specific driver ASIC user space SDK HW Support Daemons tempd, fand, powerd, pmd, … Monitoring daemons pmacct, hsflowd, broadview, … sFlow collectors OPS code OPS adapted External code Mgmt systems Collectors Legend

Single OpenSwitch Instance Open Switch OpenSwitch: North Bound Interfaces OVSDB-server Management daemons CLI, Rest, Ansible, WebUI, … Monitoring daemons pmacct, hsflowd, broadview, … Mgmt systems Collectors CLI – Cisco style, not keyword level compatible REST API – generated directly from OVSDB schema Full system declarative configuration – one big JSON that contains the entire desired state. Used to persist startup- config as well. Ansible, Chef, Puppet to follow - might be implemented on top of declarative configuration All configuration daemons talk to OVSDB only! The core system itself is declarative CLI/REST/etc. project the desired state of the system into OVSDB Daemons take care of bringing the system inline with the desired state Ordering is on the daemons and not the user

Open Switch OpenSwitch: North Bound Interfaces

Open Switch OpenSwitch: Hardware Underlay Single OpenSwitch Instance ops-switchd OVSDB-server Kernel Openflow controllers ASIC kernel SDK Platform independent part Sync to DB and Openflow ASIC specific driver ASIC user space SDK sFlow collectors ops-switchd Responsible for translating DB model to ASIC Responsible for handling Openflow and sFlow packet sampling All ASIC specific functionality is inside driver plugins Plugins are loaded dynamically Communication between platform independent part and plugin is over well defined API Specific platform carries appropriate plugin and kernel module

Open Switch OpenSwitch: Hardware Underlay Single OpenSwitch Instance OVSDB-server Kernel I 2 C and other drivers HW Support Daemons tempd, fand, powerd, pmd, … Platform Peripherals I2C drivers Described through YAML files Systemd reads and populates OVSDB Daemons read OVSDB and initialize hardware during bootup Interested to expand to other driver models

Open Switch OpenSwitch: Protocol Daemons Single OpenSwitch Instance OVSDB-server Kernel Virtual L2/3 interfaces L2/3 protocol daemons bgpd, lldpd, lacpd, … ASIC kernel SDK Packets are not going through the database! Every physical port, vlan, lag or tunnel will be represented in the kernel Control plane packets will be injected into those kernel interfaces L2/L3 protocol daemon pick up and transmit packets using regular Linux means – UDP, TCP, raw sockets. Ifconfig, tcpdump and other utilities may monitor the interfaces. However, configuration must go into the database!

Open Switch OpenSwitch: Development Process Code is modularized into separate repos Accessible from git.openswitch.net Build leverages Yocto-based custom distribution Each repo has a maintainer and bug czar, and multiple reviewers Extensive Test Framework White and black box tests Virtual and hardware testing Virtual test environment using simulator image Git-flavored Markdown for documentation OpenStack-like CIT infrastructure Gerrit for changeset review – code + tests + documentation Zuul for load-balancing jobs Jenkins for 3 tiers of CIT tests Allows 3 rd party CIT tests Defect + Feature tracking – Taiga Currently development infrastructure leverages GitHub ID Release planning and Feature proposals – to be announced soon

Open Switch OpenSwitch: Test Framework Tests are written in Python Full “multi-device” test can be executed by a developer on a laptop/VM Tests are fully isolated – may run in parallel Leveraging Mininet Python libraries and Docker Topologies take seconds to establish and erase CIT can be scaled in the cloud OPS Single Test OPS Ubuntu Mininet libraries extended for Docker support Development or CIT VM

Open Switch OpenSwitch: How To Participate Website Mailing List IRC Channel Regular IRC meetings on Wed 10am Pacific Time

Open Switch OpenSwitch: How To Participate

Open Switch OpenSwitch: How To Participate

Open Switch OpenSwitch: How To Participate

Open Switch OpenSwitch: Q&A Thank you !