The “tcp:" syntax means that OVS proactively reaches out to a controller at that address to establish the relationship.This blog post is part of our data centre networking series: “Controller” refers to an OpenFlow controller. The “ptcp::" syntax means that OVS is passively listening on that port and local address for incoming JSON-RPC data.
I have wondered about the 'tcp' vs 'ptcp' syntax. This allows us to use well-understood wire protocols (namely JSON-RPC) to send commands to an OVS instance to do things like create tunnels, turn on/off certain features, get configuration data, and more. In the world of OVS, this role is filled by OVSDB. For that, we need a management plane protocol. OSPF cannot disable a router’s interface, or create a GRE tunnel, for instance. Like OSPF, OpenFlow directly influences the forwarding behavior of a networking devices (albeit way differently than OSPF) but isn’t able to actually change the configuration of that device. Some background info on OVSDB from Brent Salisbury's Blog: Getting Started with OVSDB As Introduction to Open vSwitch says: # ovs-appctl -t ovsdb-server ovsdb-server/add-remote ptcp:6640 It is possible to add a tcp connection to gain access to the database: But for a native open vswitch install, this is the default state: Twitter: ovsdb is a generic database tool, some one may have build other schemas.
* Database: Cassandra, PostgreSQL, Microsoft SQL
* Network Monitoring: SNMP, Netflow, Nagios, Check_MK * Cisco Routing, Switching, MPLS, VPLS, Firewall/VPN * C++ Libraries: Wt, Boost, wxWidgets, ChartDir, HDF5 * Networks: BGP, OSPF, Multicast, VXLAN, TC * Automation: PXEBoot, SaltStack, Vagrant * Routing/Switching: FRFouting, Pimd, OpenvSwitch * Virtualization: KVM, LXC, VirtualBox, libvirt, ProxMox VE an engineer who is not only competent at the analytics and technologies of engineering, but can bring value to clients, team well, design well, foster adoptions of new technologies, position for innovations, cope with accelerating change and mentor other engineers" - CACM 2014/12
0 kommentar(er)
