{ "mode": "man", "parameter": "tc-tunnel_key", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc-tunnel_key/8/json", "generated": "2026-06-15T16:01:39Z", "synopsis": "tc ... action tunnelkey { unset | SET }\nSET := set srcip ADDRESS dstip ADDRESS id KEYID dstport UDPPORT tos TOS ttl TTL [ csum |\nnocsum ]", "sections": { "Tunnel metadata manipulation action in tc(8) Linux Tunnel metadata manipulation action in tc(8)": { "content": "", "subsections": [] }, "NAME": { "content": "tunnelkey - Tunnel metadata manipulation\n", "subsections": [] }, "SYNOPSIS": { "content": "tc ... action tunnelkey { unset | SET }\n\nSET := set srcip ADDRESS dstip ADDRESS id KEYID dstport UDPPORT tos TOS ttl TTL [ csum |\nnocsum ]\n\n", "subsections": [] }, "DESCRIPTION": { "content": "The tunnelkey action combined with a shared IP tunnel device, allows to perform IP tunnel\nen- or decapsulation on a packet, reflected by the operation modes UNSET and SET. The UNSET\nmode is optional - even without using it, the metadata information will be released automati‐\ncally when packet processing will be finished. UNSET function could be used in cases when\ntraffic is forwarded between two tunnels, where the metadata from the first tunnel will be\nused for encapsulation done by the second tunnel. SET mode requires the source and destina‐\ntion ip ADDRESS and the tunnel key id KEYID which will be used by the ip tunnel shared de‐\nvice to create the tunnel header. The tunnelkey action is useful only in combination with a\nmirred redirect action to a shared IP tunnel device which will use the metadata (for SET )\nand unset the metadata created by it (for UNSET ).\n\n", "subsections": [] }, "OPTIONS": { "content": "unset Unset the tunnel metadata created by the IP tunnel device. This function is not\nmandatory and might be used only in some specific use cases (as explained above).\n\nset Set tunnel metadata to be used by the IP tunnel device. Requires srcip and dstip op‐\ntions. id , dstport , geneveopts , vxlanopts and erspanopts are optional.\n\nid Tunnel ID (for example VNI in VXLAN tunnel)\n\nsrcip Outer header source IP address (IPv4 or IPv6)\n\ndstip Outer header destination IP address (IPv4 or IPv6)\n\ndstport\nOuter header destination UDP port\n\ngeneveopts\nGeneve variable length options. geneveopts is specified in the form\nCLASS:TYPE:DATA, where CLASS is represented as a 16bit hexadecimal value, TYPE\nas an 8bit hexadecimal value and DATA as a variable length hexadecimal value.\nAdditionally multiple options may be listed using a comma delimiter.\n\nvxlanopts\nVxlan metadata options. vxlanopts is specified in the form GBP, as a 32bit\nnumber. Multiple options is not supported.\n\nerspanopts\nErspan metadata options. erspanopts is specified in the form VERSION:IN‐\nDEX:DIR:HWID, where VERSION is represented as a 8bit number, INDEX as an 32bit\nnumber, DIR and HWID as a 8bit number. Multiple options is not supported. Note\nINDEX is used when VERSION is 1, and DIR and HWID are used when VERSION is 2.\n\ntos Outer header TOS\n\nttl Outer header TTL\n\n[no]csum\nControls outer UDP checksum. When set to csum (which is default), the outer UDP\nchecksum is calculated and included in the packets. When set to nocsum, outer\nUDP checksum is zero. Note that when using zero UDP checksums with IPv6, the\nother tunnel endpoint must be configured to accept such packets. In Linux,\nthis would be the udp6zerocsumrx option for the VXLAN tunnel interface.\n\nIf using nocsum with IPv6, be sure you know what you are doing. Zero UDP check‐\nsums provide weaker protection against corrupted packets. See RFC6935 for de‐\ntails.\n", "subsections": [] }, "EXAMPLES": { "content": "The following example encapsulates incoming ICMP packets on eth0 into a vxlan tunnel, by set‐\nting metadata to VNI 11, source IP 11.11.0.1 and destination IP 11.11.0.2, and by redirecting\nthe packet with the metadata to device vxlan0, which will do the actual encapsulation using\nthe metadata:\n\n#tc qdisc add dev eth0 handle ffff: ingress\n#tc filter add dev eth0 protocol ip parent ffff: \\\nflower \\\nipproto icmp \\\naction tunnelkey set \\\nsrcip 11.11.0.1 \\\ndstip 11.11.0.2 \\\nid 11 \\\naction mirred egress redirect dev vxlan0\n\nHere is an example of the unset function: Incoming VXLAN traffic with outer IP's and VNI 11\nis decapsulated by vxlan0 and metadata is unset before redirecting to tunl1 device:\n\n#tc qdisc add dev eth0 handle ffff: ingress\n#tc filter add dev vxlan0 protocol ip parent ffff: flower \\\nencsrcip 11.11.0.2 encdstip 11.11.0.1 enckeyid 11 action tunnelkey unset action mirred egress redirect dev tunl1\n\n", "subsections": [] }, "SEE ALSO": { "content": "tc(8)\n\n\n\niproute2 10 Nov 2016Tunnel metadata manipulation action in tc(8)", "subsections": [] } }, "summary": "tunnelkey - Tunnel metadata manipulation", "flags": [], "examples": [ "The following example encapsulates incoming ICMP packets on eth0 into a vxlan tunnel, by set‐", "ting metadata to VNI 11, source IP 11.11.0.1 and destination IP 11.11.0.2, and by redirecting", "the packet with the metadata to device vxlan0, which will do the actual encapsulation using", "the metadata:", "#tc qdisc add dev eth0 handle ffff: ingress", "#tc filter add dev eth0 protocol ip parent ffff: \\", "flower \\", "ipproto icmp \\", "action tunnelkey set \\", "srcip 11.11.0.1 \\", "dstip 11.11.0.2 \\", "id 11 \\", "action mirred egress redirect dev vxlan0", "Here is an example of the unset function: Incoming VXLAN traffic with outer IP's and VNI 11", "is decapsulated by vxlan0 and metadata is unset before redirecting to tunl1 device:", "#tc qdisc add dev eth0 handle ffff: ingress", "#tc filter add dev vxlan0 protocol ip parent ffff: flower \\", "encsrcip 11.11.0.2 encdstip 11.11.0.1 enckeyid 11 action tunnelkey unset action mirred egress redirect dev tunl1" ], "see_also": [ { "name": "tc", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc/8/json" }, { "name": "tc", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc/8/json" } ] }