Hide Forgot
Description of problem: When I add IPv4 server with ipvsadm for a IPv4 service I do not have to specify the port. When I switch to IPv6 the port is mandatory. This could be confusing when someone wants to migrate from IPv4 to IPv6. IPv4: # ipvsadm -A -t 1.2.3.4:80 -s rr # ipvsadm -a -t 1.2.3.4:80 -r 5.6.7.8 -g # ipvsadm IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 1.2.3.4:http rr -> 5.6.7.8:http Route 1 0 0 IPv6: # ipvsadm -A -t [fe01::5]:80 -s rr # ipvsadm -a -t [fe01::5]:80 -r [fe01::20] -g illegal real server address[:port] specified # ipvsadm IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP [fe01::5]:http rr # ipvsadm -a -t [fe01::5]:80 -r [fe01::20]:80 -g # ipvsadm IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP [fe01::5]:http rr -> [fe01::20]:http Route 1 0 0 Version-Release number of selected component (if applicable): ipvsadm-1.27-7.el7.x86_64 How reproducible: 100% Steps to Reproduce: see description Actual results: port is mandatory when adding real server Expected results: port should not be mandatory
To be clear, it is the port on the real server that is required for IPv6?
(In reply to Ryan O'Hara from comment #1) > To be clear, it is the port on the real server that is required for IPv6? Yes. In the command: ipvsadm -a -t [fe01::5]:80 -r [fe01::20] -g it is the part '-r [fe01::20]' Currently you have to specify the port otherwise you get an error.
I see the problem. When parsing an IPv6 address, the parse_service function never returns SERVICE_ADDR. I'll make some minor code changes and do some testing before sending this upstream. Would like to get any patch reviewed upstream before applying to RHEL packages.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.