Bug 1105438
Summary: | ip tunnel help and ip-tunnel manpage have inconsistent list of modes | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | David Spurek <dspurek> |
Component: | iproute | Assignee: | Phil Sutter <psutter> |
Status: | CLOSED ERRATA | QA Contact: | Marek Marusic <mmarusic> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.0 | CC: | ebenes, jaster, mmarusic, rkhan |
Target Milestone: | rc | Keywords: | Documentation, Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | iproute-3.10.0-60.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-11-03 23:32:19 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David Spurek
2014-06-06 06:49:32 UTC
Using upstream iproute: # ip tunnel add help Usage: ip tunnel { add | change | del | show | prl | 6rd } [ NAME ] [ mode { ipip | gre | sit | isatap | vti } ] [ remote ADDR ] [ local ADDR ] ... # ip -6 tunnel add help Usage: ip -f inet6 tunnel { add | change | del | show } [ NAME ] [ mode { ip6ip6 | ipip6 | ip6gre | vti6 | any } ] ... This should fix the inconsistency. diff --git a/man/man8/ip-tunnel.8 b/man/man8/ip-tunnel.8 index fc2d6bd..d22d210 100644 --- a/man/man8/ip-tunnel.8 +++ b/man/man8/ip-tunnel.8 @@ -50,7 +50,7 @@ ip-tunnel - tunnel configuration .ti -8 .IR MODE " := " -.RB " { " ipip " | " gre " | " sit " | " isatap " | " ip6ip6 " | " ipip6 " | " ip6gre " | " any " }" +.RB " { " ipip " | " gre " | " sit " | " isatap " | " vti " | " ip6ip6 " | " ipip6 " | " ip6gre " | " vti6 " | " any " }" .ti -8 .IR ADDR " := { " IP_ADDRESS " |" @@ -107,10 +107,10 @@ select the tunnel device name. set the tunnel mode. Available modes depend on the encapsulating address family. .br Modes for IPv4 encapsulation available: -.BR ipip ", " sit ", " isatap " and " gre "." +.BR ipip ", " gre ", " sit ", " isatap " and " vti "." .br Modes for IPv6 encapsulation available: -.BR ip6ip6 ", " ipip6 ", " ip6gre ", and " any "." +.BR ip6ip6 ", " ipip6 ", " ip6gre ", " vti6 " and " any "." .TP .BI remote " ADDRESS" On the other hand, it doesn't seem to be very convenient to have to give '-6' for all IPv6 specific types. Instead, in my opinion, the ip command should accept all the types without '-6' and select the address family accordingly. This would be consistent with other ip subcommands that try to do their best in not requiring the user to set the address family when it is implied by other data on the command line. Let me know if you want to extend the bug report to also cover this. I'm also curious why ipip/ipip6/ip6ip6 are different modes at all and why ip6ip doesn't seem to be supported. I would think that a generic ipip with IPv4 transport addresses could serve as current ipip and ipip6, while a generic ipip with IPv6 transport addresses could serve as missing ip6ip as well as current ip6ip6. The concept of IP-in-IP encapsulation is fairly trivial and I don't see a reason to complicate it that much. I don't know the implementation details on the kernel side, though. Your fix looks good. I don't have a problem with 'extending' functionality where iproute will accept all types and will choose address family based on given type. I don't have so much information about ipip/ipip6/ip6ip6 modes. Maybe someone from kernel or previous maintainer can help us. Posted upstream with other docs changes. This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions The necessary man page enhancements to resolve this ticket have already been backported during my first attempt at resolving bug 1251186. Reopening this ticket so it can be tested for in QA. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-2162.html |