Date: Thu, 28 Mar 2024 23:58:36 +0000 (UTC) Message-ID: <1225982804.915.1711670316958@ip-10-30-146-46.us-west-2.compute.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_914_495099369.1711670316957" ------=_Part_914_495099369.1711670316957 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The interface configuration is part of the network configuration= . It allows users to configure information about ports and logical ports of= devices connected to the system. The information is used by ONOS and its a= pplications to decide how to select and forward the network traffic. The in= terface configuration is probably the most similar to the "legacy" network = devices configuration. Examples of common patterns are "select traffic tagg= ed with VLAN X on port Y", "Select all the traffic coming with IP A and sen= d it out through port B".
The configuration contains a list of physical ports, an= d logical interfaces. A more detailed explanation is repor= ted below.
As the rest of the network configuration, also the interface configurati= on is expressed in JSON format. Below, you can find a the structure of a ve= ry generic interface configuration
{ "ports" : { "of:DPID__WITH_NO_COLUMNS/PORT" : { "interfaces" : [ { "KEY_1" : "VALUE_1", =09=09=09=09 "KEY_2" : [ "VALUE_2A", "VALUE_2B" ], "KEY_3" : "VALUE_3" } ] }, "of:ANOTHER_DPID_WITH_NO_COLUMNS/PORT" : { "interfaces" : [ { "KEY_1" : "VALUE_1", =09=09=09=09 "KEY_2" : [ "VALUE_2A", "VALUE_2B" ], "KEY_3" : "VALUE_3" }, =09=09=09=09{ "KEY_10" : "VALUE_10", =09=09=09=09 "KEY_4" : [ "VALUE_4A", "VALUE_4B" ], "KEY_3" : "VALUE_3" } ] } }
What's reported above is a sample configuration, used in SDN-IP.
Configuration you may find are usually very specific to the application = that parses them.
While the configuration syntax and the general structure is globally enf= orced by the interface configuration subsystem itself, It's up to each ONOS= application how to interpret the values provided. For example, some applic= ations might request just one parameter per interface (it might be the case= of some L2 applications with VLAN); some others might reques more (for exa= mple IPs for L3 applications). Also, applications might use the values as t= hey like, so giving them any meaning.
Even if different applications might interpret the configuration in diff= erent ways, there's an agreement about how parameters should be read. Follo= wing is a list of "best-practices" we generally follow:
As an example, the ARP handler of SDN-IP uses the combination of IP addr= esses and MAC address to emulate routers behavior.
{ "ports" : { "of:0000000000000001/1" : { "interfaces" : [ { "name" : "Interface 1 sw 1", =09=09=09=09 "ips" : [ "1.1.1.1/24", "10.10.10.1/24" ], "mac" : "00:00:00:00:00:01" } ] } =09} }
The configuration above means "...ARP request packets coming in from DPI= D 00:00:00:00:00:00:00:01, port 1, having destination IPs 1.1.1.1/24 or 10.= 10.10.1/24, should be replied with ARP replies with MAC address 00:00:00:00= :00:01..."
Sometimes you may want to express parameters related to an entire physic= al port, rather than an interface. Configurations attributes written direct= ly under a physical port won't be parsed. Anyway, there's a work-around to = it: just add one interface to the physical port it and specify inside its p= arameters.
Following is a list of known applications (including the link to their c= onfiguration guide) that use the interface configuration. If you like, you = may look at their configuration guides and at their code, taking them as ex= ample.