Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Summary: this is initial work to add GUE encapsulation option for katran. Reason behind this is that currently we are using IPIP. but for IPIP to play nice w/ ECMP and RSS we are "faking" src ip of outer IP header. that makes debuging anything related to "from which load balancer i have recved this flow" hard. GUE would allow us to have benefit of preserving (or setting to whatever we want) source IP and at the same time allow for ECMP/RSS to works (as network or NICs are going to use src port for hashing. which is going to be unique per flow). the price for this is 8 bytes of UDP header. This diff adds gue encapsulation in forwarding plane. we are adding variant 1 from https://tools.ietf.org/html/draft-ietf-intarea-gue-07 (aka no additional headers w/ metadata) what is missing for now is: - gue based encap for healthchecks - gue decapsulation. to build katran w/ GUE encapsulation it must be compile w/ -DGUE_ENCAP option. Also as a part of this diff dissector for wireshark was added (so encapsulated packets would be visible in wireshark). Tests: katran_tester: added new test fixtures for GUE encap + "-gue" option to use em. to see the output of the test (and to make sure that everything looks sane) you can run em with -gue and -pcap_output=/tmp/test.pcap in that case test.pcap would contain all the input and output packets of the test. for GUE we are forcing udp checksum to be 0 for outer packet so some "csum failed" output in wireshark is expected. example of pcap output: https://gist.github.com/tehnerd/50a8ee7c47000941c3e41872d2fa6136 actual tests w/ katran + test host: (w/ modifications in example grpc server (which are not in this diff): ``` diff --git a/example_grpc/katran_server.cpp b/example_grpc/katran_server.cpp index b3c17ad..8b17118 100644 --- a/example_grpc/katran_server.cpp +++ b/example_grpc/katran_server.cpp @@ -129,6 +129,8 @@ int main(int argc, char** argv) { config.forwardingCores = forwardingCores; config.numaNodes = numaNodes; config.hcInterface = FLAGS_hc_intf; + config.katranSrcV4 = "10.0.13.37"; + config.katranSrcV6 = "fc00:2307::1337"; ``` katran's config: ``` 2019/10/03 17:06:23 vips len 2 VIP: fc00:1::1 Port: 22 Protocol: tcp Vip's flags: ->fc00::1 weight: 1 VIP: 10.0.0.1 Port: 22 Protocol: tcp Vip's flags: ->fc00::1 weight: 1 ->192.168.102.129 weight: 1 exiting ``` reals configuration (to support gue): ``` modprobe fou ip fou add port 6080 gue ip link add name gue_v4 type ipip external encap gue encap-sport auto encap dport 6080 ip link set gue_v4 up sudo net.ipv4.conf.gue_v4.rp_filter=0 net.ipv4.conf.default.rp_filter=0 ip fou add porto 6080 gue -6 ip link add name gue_v6 type ip6tnl external encap gue encap-sport auto encap-dport 6080 ip link set up dev gue_v6 some outputs: tehnerd@tbox1:~$ ip fou show port 6080 gue -6 port 6080 gue tehnerd@tbox1:~$ ip -json link show dev gue_v4 [{ "ifindex": 7, "ifname": "gue_v4", "link": null, "flags": ["NOARP","UP","LOWER_UP"], "mtu": 1480, "qdisc": "noqueue", "operstate": "UNKNOWN", "linkmode": "DEFAULT", "group": "default", "txqlen": 1000, "link_type": "ipip", "address": "0.0.0.0", "broadcast": "0.0.0.0" } ] tehnerd@tbox1:~$ ip -json link show dev gue_v6 [{ "ifindex": 9, "ifname": "gue_v6", "link": null, "flags": ["NOARP","UP","LOWER_UP"], "mtu": 1452, "qdisc": "noqueue", "operstate": "UNKNOWN", "linkmode": "DEFAULT", "group": "default", "txqlen": 1000, "link_type": "tunnel6", "address": "::", "broadcast": "::" } ] ``` v4 in v4: vip is 10.0.0.1 in dump we are see packets which goes to load balancer (first one) then gue from load balancer to local server and then reply from local server to the client. this convo basically means that local server was able to decap v4inv4 gue (it passed all the checks, encapsulated packet was delivered to application and application replied). ``` 16:58:51.008903 IP 192.168.102.140.60000 > 10.0.0.1.22: Flags [S], seq 1298498081, win 32768, length 0 16:58:51.010958 IP 10.0.13.37.1638 > 192.168.102.129.6080: UDP, length 40 16:58:51.010995 IP 10.0.0.1.22 > 192.168.102.140.60000: Flags [S.], seq 122077391, ack 1298498082, win 29200, options [mss 1460], length 0 ``` v6inv6: same as above. ``` 17:02:55.576750 IP6 fc00::10.60000 > fc00:1::1.22: Flags [S], seq 1298498081, win 32768, length 0 17:02:55.578319 IP6 fc00:2307::1337.60000 > fc00::1.6080: UDP, length 60 17:02:55.578498 IP6 fc00:1::1.22 > fc00::10.60000: Flags [S.], seq 3064362547, ack 1298498082, win 28800, options [mss 1440], length 0 ``` v4inv6: 17:05:15.541911 IP 192.168.102.140.60004 > 10.0.0.1.22: Flags [S], seq 1298498081, win 32768, length 0 17:05:15.543775 IP6 fc00:2307::1337.36072 > fc00::1.6080: UDP, length 40 17:05:15.543812 IP 10.0.0.1.22 > 192.168.102.140.60004: Flags [S.], seq 173938774, ack 1298498082, win 29200, options [mss 1460], length 0 Pull Request resolved: #60 Test Plan: Imported from GitHub, without a `Test Plan:` line. canary https://our.intern.facebook.com/intern/tupperware/canary/view/?experiment_id=4836154 Reviewed By: mjoras Differential Revision: D17741225 Pulled By: udippant fbshipit-source-id: 539917985f47f688b8b255f78841045843f24743
- Loading branch information