Hi,
HPE Networks^W^WHPE Aruba have been working on the OpenSwitch project for
a while. It was launched as a public, open-source project late last year,
and is in the process of becoming a Linux Foundation project. OpenSwitch
exists to build a Linux based, open-source operating system for L3
switches and routers.
OpenSwitch uses an OVSDB based architecture to tie together its
components. OVSDB is the embedded database from the OpenVSwitch (OVS)
project. The OVSDB core provides a JSON-encoded, Pub/Sub RPC protocol and
is described in IETF informational RFC. Additionally, there are ovsdb*
command-line tools to interact with and monitor changes to an OVSDB
instance. See the diagramme in:
http://openswitch.net/documents/user/architecture
This architecture allows functionality to be distributed across small
components, while still providing unified access to their state, and
allowing state and function to be kept separate.
OpenSwitch (OPS) is using Quagga for BGP and OSPF. Quagga in OPS has been
adapted to store and retrieve its configuration state to and from the
OVSDB, as well as its routing state. The vtysh CLI has been adapted to use
the OVSDB, and the modern and well-defined schemas and protocols it
provides, to provide the traditional UI. There is an additional JSON/HTTP
based ReST API, again going via the OVSDB.
The advantages of this architecture are:
* Modern, well-defined and general protocol to interact with Quagga
components, via the OVSDB JSON/PubSub RPC protocol (not HTTP).
* vtysh based on this architecture, along with other interfaces such as a
JSON/HTTP ReST API.
* The ability to configure Quagga components either via the traditional
CLI like configuration, or OVSDB, or the ReST API.
* The UI is *out* of the protocol daemons - e.g. the "show ip bgp"
table-walking command does /not/ cause bgpd to have do anything.
Instead, the UI just talks to the OVSDB.
* Separation of state and function makes things like graceful-restart of
daemons much easier (e.g. implemented for zebra).
- Separation of state from function also will make it easier to further
sub-divide existing daemons into different processes, e.g. this
infrastructure could be built to run the BGP LocRIB handling in a
seperate process to peer-facing BGP protocol IO.
* Tight integration with other open-source networking components via the
OVSDB, with a cohesive UI to all. E.g. OpenSwitch also has adapted
Vincent Bernat's LLDP, and HPE Aruba have contributed their own
technologies.
The code is available at:
http://git.openswitch.net/cgit/openswitch
The Quagga modifications are in:
http://git.openswitch.net/cgit/openswitch/ops-quagga
and come with design documents and extensive tests.
The OPS Quagga version is based on 0.99.24.1, and the diff to that version
of Quagga is:
http://git.openswitch.net/cgit/openswitch/ops-quagga/diff/?id=master&id2=vendor&context=6&ignorews=1&dt=0
HPE Aruba have a large team of people working on OpenSwitch generally. HPE
Aruba would be keen to get this technology upstreamed. In which event, HPE
Aruba engineering would be able to do further work on Quagga upstream
first.
The diff above may contain other changes. Some work is needed to separate
out the non-OVSDB stuff, to reconcile some work that was done by
copying-and-modifying existing files, and to move the old telnet UI to
seperate files and make it a compile time option for backward
compatibility.
Also, to try do the split-brain thing, [email protected] would probably want
the code split into a series of logical commits, and the interfaces
generalised a bit, along with other issues. However, based on the
discussion on the Quagga monthly call yesterday, it seems appropriate to
post this contribution now and ask to have it considered as it is now
(sans minor tidy-ups as in previous para).
regards,
--
Paul Jakma, HPE Aruba, Advanced Technology Group
Fortune:
Reality -- what a concept!
-- Robin Williams
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
