{"action":"opened","issue":{"url":"https://api.github.com/repos/Igalia/snabb/issues/1176","repository_url":"https://api.github.com/repos/Igalia/snabb","labels_url":"https://api.github.com/repos/Igalia/snabb/issues/1176/labels{/name}","comments_url":"https://api.github.com/repos/Igalia/snabb/issues/1176/comments","events_url":"https://api.github.com/repos/Igalia/snabb/issues/1176/events","html_url":"https://github.com/Igalia/snabb/issues/1176","id":356700001,"node_id":"MDU6SXNzdWUzNTY3MDAwMDE=","number":1176,"title":"[wip] passthru-interface support","user":{"login":"mwiget","id":3111088,"node_id":"MDQ6VXNlcjMxMTEwODg=","avatar_url":"https://avatars1.githubusercontent.com/u/3111088?v=4","gravatar_id":"","url":"https://api.github.com/users/mwiget","html_url":"https://github.com/mwiget","followers_url":"https://api.github.com/users/mwiget/followers","following_url":"https://api.github.com/users/mwiget/following{/other_user}","gists_url":"https://api.github.com/users/mwiget/gists{/gist_id}","starred_url":"https://api.github.com/users/mwiget/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mwiget/subscriptions","organizations_url":"https://api.github.com/users/mwiget/orgs","repos_url":"https://api.github.com/users/mwiget/repos","events_url":"https://api.github.com/users/mwiget/events{/privacy}","received_events_url":"https://api.github.com/users/mwiget/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-09-04T08:16:55Z","updated_at":"2018-09-04T08:16:55Z","closed_at":null,"author_association":"NONE","body":"I'm sharing this brain dump to collect feedback while working on a prototype. \r\n\r\nSnabbvmx offered a unique way to pass control traffic to an attached VM (e.g. Juniper vMX) to handle all network control traffic, from ARP, IPv6 NDP, BFD, LLDP and routing protocols like ISIS, OSPF and BGP. Snabbvmx also offered next-hop resolution for processed packets by periodically sending a copy of the packet to the VM via the VhostUser interface. [vmx-docker-lwaftr](https://github.com/juniper/vmx-docker-lwaftr) uses snabbvmx. \r\n\r\nlwAFTR evolved dramatically since snabbvmx was introduced. A YANG file is now configuring more than one instances serving network interfaces and more and more basic network functions like ARP and ICMP have been implemented. This allows for alternate deployment options, where multiple interfaces can be served as slaves \"on a stick\" from a master snabb instance. Availability and routing of traffic towards each snabb instance can be handled via an \"out-of-band\" BGP session between the connecting L2/L3 switch and a route server, e.g. ExaBGP or Junos RR. (See [Video of crr-snabb-lwaftr prototype](https://youtu.be/VqWehwnJNd8)).\r\n\r\n<img width=\"747\" alt=\"crr-snabb-lwaftr\" src=\"https://user-images.githubusercontent.com/3111088/45018638-bd8c3e80-b02a-11e8-8ccf-621de731aca3.png\">\r\n\r\nBut this design requires an additional interface for the BGP session between switch and the BGP process and something must monitor the health of each lwAFTR instance and update the routing table. Snabbvmx solved this by \"fate sharing\" of date and control plane thru each interface.\r\n\r\nThis brings me to the main idea: Pass control traffic (like BGP) thru one or more interfaces of lwAFTR to an auxiliary TAP interface. LwAFTR runs in hairpinning mode.\r\n\r\n<img width=\"708\" alt=\"lwaftr-passthru-example\" src=\"https://user-images.githubusercontent.com/3111088/45018702-e3194800-b02a-11e8-8b32-acee1bc1d3f8.png\">\r\n\r\nThese auxiliary interfaces are passing thru traffic between the L2/L3 switch and an attached route reflector. The L2/L3 switch, lwAFTR and the route reflector all have unique IPv4 and IPv6 addresses and MAC addresses per link. IMHO LwAFTR doesn't need to know the route reflectors IP address. \r\n\r\nDiscussion: It is probably sufficient to know its MAC address. Though it is tempting to ignore the MAC address by simply passing BUM (Broadcast & Unknown Multicast) traffic thru, together with packets on the same subnet. But that would make it impossible to use loopback IP addresses. I'll most likely stick to telling lwAFTR the MAC address of the connected route reflector via configuration.\r\n\r\nConfiguration\r\n\r\n The YANG software-config has already containers for internal-interface and external-interface. This shall be extended with a passthru-interface container. The following example illustrates the idea:\r\n\r\n```\r\n    softwire-config {\r\n      instance {\r\n        device \"00:05.0\"\r\n        queue {\r\n          id 0;\r\n          external-interface {\r\n            ip 10.10.10.10;\r\n            mac 12:12:12:12:12:12;\r\n            // vlan-tag 42;\r\n            next-hop {\r\n              ip 1.2.3.4;\r\n            }\r\n          }\r\n          internal-interface {\r\n            ip 8:9:a:b:c:d:e:f;\r\n            mac 22:22:22:22:22:22;\r\n            // vlan-tag 64;\r\n            next-hop {\r\n              ip 7:8:9:a:b:c:d:e;\r\n            }\r\n          }\r\n          passthru-interface {\r\n          \tname \"xe0\";\r\n            mac 44:44:44:44:44:44;\r\n            // vlan-tag 64;\r\n            // promiscuous false;\r\n            // sample-rate 1000;\r\n          }\r\n        }\r\n      }\r\n    }\r\n```\r\n\r\nThere is no need to specify an IP address for the passhtru-interface; forwarding decisions are made at L2 based on the MAC address and optional VLAN towards the TAP interface. The optional leaf's promiscuous and sample-rate are an idea to use the same tap interface for monitoring purposes and merits further investigation. \r\n\r\nNext-hop resolution: snabbvmx uses the nh_fwd app to periodically pass a copy of an egress packet to the connected vMX VM. IMHO it is sufficient to specify the IPv4 and IPv6 next-hop address in the lwAFTR config and have the route reflector interact with Snabb config to learn about the active binding table entries and combine them with the internal- and external-interface IP addresses to create routing entries. By having multiple instances, each connected to a separate interface of the L2/L3 switch offers redundancy. "}}
{"actor":{"display_login":"mwiget"}}