{"id":13642626,"url":"https://github.com/Orange-OpenSource/oko","last_synced_at":"2025-04-20T20:32:28.335Z","repository":{"id":143061055,"uuid":"122633179","full_name":"Orange-OpenSource/oko","owner":"Orange-OpenSource","description":"Extend Open vSwitch with BPF programs at runtime","archived":true,"fork":false,"pushed_at":"2020-01-29T10:59:18.000Z","size":50351,"stargazers_count":32,"open_issues_count":1,"forks_count":10,"subscribers_count":18,"default_branch":"master","last_synced_at":"2024-11-09T14:38:00.708Z","etag":null,"topics":["bpf","dpdk","openflow","openvswitch","ovs"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Orange-OpenSource.png","metadata":{"files":{"readme":"README-lisp.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null}},"created_at":"2018-02-23T14:42:29.000Z","updated_at":"2024-08-21T09:38:11.000Z","dependencies_parsed_at":"2023-06-18T23:07:44.606Z","dependency_job_id":null,"html_url":"https://github.com/Orange-OpenSource/oko","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Orange-OpenSource%2Foko","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Orange-OpenSource%2Foko/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Orange-OpenSource%2Foko/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Orange-OpenSource%2Foko/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Orange-OpenSource","download_url":"https://codeload.github.com/Orange-OpenSource/oko/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":249958847,"owners_count":21351725,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["bpf","dpdk","openflow","openvswitch","ovs"],"created_at":"2024-08-02T01:01:34.110Z","updated_at":"2025-04-20T20:32:24.140Z","avatar_url":"https://github.com/Orange-OpenSource.png","language":"C","funding_links":[],"categories":["C"],"sub_categories":[],"readme":"Using LISP tunneling\n====================\n\nLISP is a layer 3 tunneling mechanism, meaning that encapsulated packets do\nnot carry Ethernet headers, and ARP requests shouldn't be sent over the\ntunnel.  Because of this, there are some additional steps required for setting\nup LISP tunnels in Open vSwitch, until support for L3 tunnels will improve.\n\nThis guide assumes tunneling between two VMs connected to OVS bridges on\ndifferent hypervisors reachable over IPv4.  Of course, more than one VM may be\nconnected to any of the hypervisors, and a hypervisor may communicate with\nseveral different hypervisors over the same lisp tunneling interface.  A LISP\n\"map-cache\" can be implemented using flows, see example at the bottom of this\nfile.\n\nThere are several scenarios:\n\n  1) the VMs have IP addresses in the same subnet and the hypervisors are also\n     in a single subnet (although one different from the VM's);\n  2) the VMs have IP addresses in the same subnet but the hypervisors are\n     separated by a router;\n  3) the VMs are in different subnets.\n\nIn cases 1) and 3) ARP resolution can work as normal: ARP traffic is\nconfigured not to go through the LISP tunnel.  For case 1) ARP is able to\nreach the other VM, if both OVS instances default to MAC address learning.\nCase 3) requires the hypervisor be configured as the default router for the\nVMs.\n\nIn case 2) the VMs expect ARP replies from each other, but this is not\npossible over a layer 3 tunnel.  One solution is to have static MAC address\nentries preconfigured on the VMs (e.g., `arp -f /etc/ethers` on startup on\nUnix based VMs), or have the hypervisor do proxy ARP.  In this scenario, the\neth0 interfaces need not be added to the br0 bridge in the examples below.\n\nOn the receiving side, the packet arrives without the original MAC header.\nThe LISP tunneling code attaches a header with harcoded source and destination\nMAC address 02:00:00:00:00:00.  This address has all bits set to 0, except the\nlocally administered bit, in order to avoid potential collisions with existing\nallocations.  In order for packets to reach their intended destination, the\ndestination MAC address needs to be rewritten.  This can be done using the\nflow table.\n\nSee below for an example setup, and the associated flow rules to enable LISP\ntunneling.\n\n               +---+                               +---+\n               |VM1|                               |VM2|\n               +---+                               +---+\n                 |                                   |\n            +--[tap0]--+                       +--[tap0]---+\n            |          |                       |           |\n        [lisp0] OVS1 [eth0]-----------------[eth0] OVS2 [lisp0]\n            |          |                       |           |\n            +----------+                       +-----------+\n\nOn each hypervisor, interfaces tap0, eth0, and lisp0 are added to a single\nbridge instance, and become numbered 1, 2, and 3 respectively:\n\n    ovs-vsctl add-br br0\n    ovs-vsctl add-port br0 tap0\n    ovs-vsctl add-port br0 eth0\n    ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip=flow options:key=flow\n\nThe last command sets up flow based tunneling on the lisp0 interface.  From\nthe LISP point of view, this is like having the Tunnel Router map cache\nimplemented as flow rules.\n\nFlows on br0 should be configured as follows:\n\n    priority=3,dl_dst=02:00:00:00:00:00,action=mod_dl_dst:\u003cVMx_MAC\u003e,output:1\n    priority=2,in_port=1,dl_type=0x0806,action=NORMAL\n    priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=\u003cEID_prefix\u003e,action=set_field:\u003cOVSx_IP\u003e-\u003etun_dst,output:3\n    priority=0,action=NORMAL\n\nThe third rule is like a map cache entry:  the \u003cEID_prefix\u003e specified by the\nnw_src match field is mapped to the RLOC \u003cOVSx_IP\u003e, which is set as the tunnel\ndestination for this particular flow.\n\nOptionally, if you want to use Instance ID in a flow, you can add\n\"set_tunnel:\u003cIID\u003e\" to the action list.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FOrange-OpenSource%2Foko","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FOrange-OpenSource%2Foko","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FOrange-OpenSource%2Foko/lists"}