Bug 887594 - within /sbin/ip, the nexthop clause does not accept IPv6 addresses, only IPv4 addresses
Summary: within /sbin/ip, the nexthop clause does not accept IPv6 addresses, only IPv4...
Keywords:
Status: CLOSED DUPLICATE of bug 734697
Alias: None
Product: Fedora
Classification: Fedora
Component: iproute
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Šabata
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-16 17:47 UTC by Wendell Baker
Modified: 2012-12-20 16:01 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-20 16:01:36 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Wendell Baker 2012-12-16 17:47:14 UTC
Description of problem:

The notion is that only an IPv4 address can appear within a 'nexthop' clause

sudo /sbin/ip -6 route add table mytable to default scope global nexthop via fdd3:1234:1234:0:1:1:2:8002 dev em1 weight 1 nexthop via fdd3:1234:1234:0:1:1:2:8007 dev em1 weight 1
Error: an IP address is expected rather than "fdd3:1234:1234:0:1:1:2:8002"

Not sure there's a workaround here.  I have IPv6 hosts A, B C, D connected as follows

  /---+B+---\
A-+         +-D
  \---+C+---/

I think this utterance is what I need to say.  I have two possibilities
to get from A to D and I want to use both equally.  I utter this route
declaration on A to get traffic back to D via B or C.

[pointless and wrong, but it illustrates that "nexthop via" parsing occurs for IPv4 addresses]
sudo /sbin/ip -6 route add table linode-fremont to default scope global nexthop via 1.2.3.4 dev em1 weight 1 nexthop via 2.3.4.5 dev em1 weight 1
RTNETLINK answers: No such device


Version-Release number of selected component (if applicable):

iproute-3.3.0-2.fc17.i686

How reproducible:

very

Steps to Reproduce:
1. (as above)
2.
3.
  
Actual results:

Error: an IP address is expected rather than "fdd3:1234:1234:0:1:1:2:8002/64"

Expected results:

the IPv6 route was added

Additional info:

Somewhere out there, upstream somewhere, someone has put some work
into this.  There is code on github that seems to have IPv6 built
into iproute2.  This is just advice that a solution already exists;
I found it by looking at the Fedora 17 src rpm and then searching for
'parse_one_nh' to see if anyone had coded changes to that function.


To wit:

https://github.com/SamB/iproute2/blob/0ddcf76dfd1f916846c81fbb5891c61997d52c3f/ip/iproute.c

The function of interest is (at least) parse_one_nh

$ diff $FEDORA17_SRC/iproute-3.3.0-2/ip/iproute.c $WORKAREA/com.github/SamB/iproute2/iproute2/ip/iproute.c 
<snip/>
628c628
< int parse_one_nh(struct rtattr *rta, struct rtnexthop *rtnh, int *argcp, char ***argvp)
---
> int parse_one_nh(struct rtmsg *r, struct rtattr *rta, struct rtnexthop *rtnh, int *argcp, char ***argvp)
634a635
> 			inet_prefix addr;
636,637c637,641
< 			rta_addattr32(rta, 4096, RTA_GATEWAY, get_addr32(*argv));
< 			rtnh->rtnh_len += sizeof(struct rtattr) + 4;
---
> 			get_addr(&addr, *argv, r->rtm_family);
> 			if (r->rtm_family == AF_UNSPEC)
> 				r->rtm_family = addr.family;
> 			rta_addattr_l(rta, 4096, RTA_GATEWAY, &addr.data, addr.bytelen);
> 			rtnh->rtnh_len += sizeof(struct rtattr) + addr.bytelen;
689c693
< 		parse_one_nh(rta, rtnh, &argc, &argv);
---
> 		parse_one_nh(r, rta, rtnh, &argc, &argv);
<snip/>

Comment 1 Petr Šabata 2012-12-20 16:01:36 UTC

*** This bug has been marked as a duplicate of bug 734697 ***


Note You need to log in before you can comment on or make changes to this bug.