| Message ID | 1369821617-29098-4-git-send-email-mike.rapoport@ravellosystems.com |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | stephen hemminger |
| Headers | show |
On Wed, 29 May 2013 at 10:00 GMT, Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: > Signed-off-by: Mike Rapoport <mike.rapoport@ravellosystems.com> > --- > ip/iplink_vxlan.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 125 insertions(+) > > diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c > index 1025326..be6c0ac 100644 > --- a/ip/iplink_vxlan.c > +++ b/ip/iplink_vxlan.c > @@ -28,11 +28,87 @@ static void explain(void) > fprintf(stderr, " [ port MIN MAX ] [ [no]learning ]\n"); > fprintf(stderr, " [ [no]proxy ] [ [no]rsc ]\n"); > fprintf(stderr, " [ [no]l2miss ] [ [no]l3miss ]\n"); > + fprintf(stderr, " [ dstadd DST ]\n"); > + fprintf(stderr, " [ dstdel ADDR ]\n"); Excuse me, but this looks like a design failure as you manipulate remotes with `ip link` while creating vxlan devices, shouldn't this be in a standard alone tool if we can't reuse any existing tool? Or am I missing anything? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 29, 2013 at 1:13 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote: > On Wed, 29 May 2013 at 10:00 GMT, Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: >> Signed-off-by: Mike Rapoport <mike.rapoport@ravellosystems.com> >> --- >> ip/iplink_vxlan.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 125 insertions(+) >> >> diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c >> index 1025326..be6c0ac 100644 >> --- a/ip/iplink_vxlan.c >> +++ b/ip/iplink_vxlan.c >> @@ -28,11 +28,87 @@ static void explain(void) >> fprintf(stderr, " [ port MIN MAX ] [ [no]learning ]\n"); >> fprintf(stderr, " [ [no]proxy ] [ [no]rsc ]\n"); >> fprintf(stderr, " [ [no]l2miss ] [ [no]l3miss ]\n"); >> + fprintf(stderr, " [ dstadd DST ]\n"); >> + fprintf(stderr, " [ dstdel ADDR ]\n"); > > Excuse me, but this looks like a design failure as you manipulate > remotes with `ip link` while creating vxlan devices, shouldn't this be > in a standard alone tool if we can't reuse any existing tool? Or am I > missing anything? Frankly, I had a long hesitation about the userspace implementation. From one side it seems very logical to use ip/iplink_vxlan for vxlan device manipulations. Moreover, since the remotes are used pretty much the same way as the group address, adding the remotes management to ip/iplink_vxlan makes a lot of sense. Besides, creation of stand alone tool for remote list manipulation in vxlan seemed to me little bit far fetched. On the other hand, I quite agree with you that ip link add vxlan0 ... dstadd 192.168.1.1 or ip link set vxlan0 ... dstdel 192.168.1.1 looks weird at least. > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 29 May 2013 13:52:55 +0300 Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: > On Wed, May 29, 2013 at 1:13 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote: > > On Wed, 29 May 2013 at 10:00 GMT, Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: > >> Signed-off-by: Mike Rapoport <mike.rapoport@ravellosystems.com> > >> --- > >> ip/iplink_vxlan.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 125 insertions(+) > >> > >> diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c > >> index 1025326..be6c0ac 100644 > >> --- a/ip/iplink_vxlan.c > >> +++ b/ip/iplink_vxlan.c > >> @@ -28,11 +28,87 @@ static void explain(void) > >> fprintf(stderr, " [ port MIN MAX ] [ [no]learning ]\n"); > >> fprintf(stderr, " [ [no]proxy ] [ [no]rsc ]\n"); > >> fprintf(stderr, " [ [no]l2miss ] [ [no]l3miss ]\n"); > >> + fprintf(stderr, " [ dstadd DST ]\n"); > >> + fprintf(stderr, " [ dstdel ADDR ]\n"); > > > > Excuse me, but this looks like a design failure as you manipulate > > remotes with `ip link` while creating vxlan devices, shouldn't this be > > in a standard alone tool if we can't reuse any existing tool? Or am I > > missing anything? > > Frankly, I had a long hesitation about the userspace implementation. > From one side it seems very logical to use ip/iplink_vxlan for vxlan > device manipulations. Moreover, since the remotes are used pretty much > the same way as the group address, adding the remotes management to > ip/iplink_vxlan makes a lot of sense. Besides, creation of stand alone > tool for remote list manipulation in vxlan seemed to me little bit far > fetched. > > On the other hand, I quite agree with you that > ip link add vxlan0 ... dstadd 192.168.1.1 > or > ip link set vxlan0 ... dstdel 192.168.1.1 > looks weird at least. Don't like add/delete semantics here either. Maybe replace or modify, or has this grown enough that having its own command line tool "vxlan ..." makes sense? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 30, 2013 at 1:56 AM, Stephen Hemminger <stephen@networkplumber.org> wrote: > On Wed, 29 May 2013 13:52:55 +0300 > Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: > >> On Wed, May 29, 2013 at 1:13 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote: >> > On Wed, 29 May 2013 at 10:00 GMT, Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: >> >> Signed-off-by: Mike Rapoport <mike.rapoport@ravellosystems.com> >> >> --- >> >> ip/iplink_vxlan.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> 1 file changed, 125 insertions(+) >> >> >> >> diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c >> >> index 1025326..be6c0ac 100644 >> >> --- a/ip/iplink_vxlan.c >> >> +++ b/ip/iplink_vxlan.c >> >> @@ -28,11 +28,87 @@ static void explain(void) >> >> fprintf(stderr, " [ port MIN MAX ] [ [no]learning ]\n"); >> >> fprintf(stderr, " [ [no]proxy ] [ [no]rsc ]\n"); >> >> fprintf(stderr, " [ [no]l2miss ] [ [no]l3miss ]\n"); >> >> + fprintf(stderr, " [ dstadd DST ]\n"); >> >> + fprintf(stderr, " [ dstdel ADDR ]\n"); >> > >> > Excuse me, but this looks like a design failure as you manipulate >> > remotes with `ip link` while creating vxlan devices, shouldn't this be >> > in a standard alone tool if we can't reuse any existing tool? Or am I >> > missing anything? >> >> Frankly, I had a long hesitation about the userspace implementation. >> From one side it seems very logical to use ip/iplink_vxlan for vxlan >> device manipulations. Moreover, since the remotes are used pretty much >> the same way as the group address, adding the remotes management to >> ip/iplink_vxlan makes a lot of sense. Besides, creation of stand alone >> tool for remote list manipulation in vxlan seemed to me little bit far >> fetched. >> >> On the other hand, I quite agree with you that >> ip link add vxlan0 ... dstadd 192.168.1.1 >> or >> ip link set vxlan0 ... dstdel 192.168.1.1 >> looks weird at least. > > Don't like add/delete semantics here either. > Maybe replace or modify, I think that replace or modify do not express the actual operation meaning. My intention with dstadd was "add remote host X to pseudo-multicast group". Replace/modify maybe nice to have features to avoid doing delete+ add. > or has this grown enough that having its own > command line tool "vxlan ..." makes sense? Say, misc/vxlan that will handle remote destinations management? Or should it take care of some vxlan parameters currently implemented in ip/iplink_vxlan and bridge/fdb? -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/30/13 at 11:42am, Mike Rapoport wrote: > On Thu, May 30, 2013 at 1:56 AM, Stephen Hemminger > <stephen@networkplumber.org> wrote: > > On Wed, 29 May 2013 13:52:55 +0300 > > Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: > >> Frankly, I had a long hesitation about the userspace implementation. > >> From one side it seems very logical to use ip/iplink_vxlan for vxlan > >> device manipulations. Moreover, since the remotes are used pretty much > >> the same way as the group address, adding the remotes management to > >> ip/iplink_vxlan makes a lot of sense. Besides, creation of stand alone > >> tool for remote list manipulation in vxlan seemed to me little bit far > >> fetched. > >> > >> On the other hand, I quite agree with you that > >> ip link add vxlan0 ... dstadd 192.168.1.1 > >> or > >> ip link set vxlan0 ... dstdel 192.168.1.1 > >> looks weird at least. > > > > Don't like add/delete semantics here either. > > Maybe replace or modify, > > I think that replace or modify do not express the actual operation > meaning. My intention with dstadd was "add remote host X to > pseudo-multicast group". Replace/modify maybe nice to have features to > avoid doing delete+ add. The alternative would be to require iproute2 to always provide the full list of remote addresses like we do we route nexthops. I do like the add/del though and don't see a problem with requiring an ''ip link set [..] dstadd/dstdel'' > > or has this grown enough that having its own > > command line tool "vxlan ..." makes sense? > > Say, misc/vxlan that will handle remote destinations management? Or > should it take care of some vxlan parameters currently implemented in > ip/iplink_vxlan and bridge/fdb? What do we gain from a separate tool? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 30, 2013 at 12:44:24PM +0100, Thomas Graf wrote: > On 05/30/13 at 11:42am, Mike Rapoport wrote: > > On Thu, May 30, 2013 at 1:56 AM, Stephen Hemminger > > <stephen@networkplumber.org> wrote: > > > On Wed, 29 May 2013 13:52:55 +0300 > > > Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: > > >> Frankly, I had a long hesitation about the userspace implementation. > > >> From one side it seems very logical to use ip/iplink_vxlan for vxlan > > >> device manipulations. Moreover, since the remotes are used pretty much > > >> the same way as the group address, adding the remotes management to > > >> ip/iplink_vxlan makes a lot of sense. Besides, creation of stand alone > > >> tool for remote list manipulation in vxlan seemed to me little bit far > > >> fetched. > > >> > > >> On the other hand, I quite agree with you that > > >> ip link add vxlan0 ... dstadd 192.168.1.1 > > >> or > > >> ip link set vxlan0 ... dstdel 192.168.1.1 > > >> looks weird at least. > > > > > > Don't like add/delete semantics here either. > > > Maybe replace or modify, > > > > I think that replace or modify do not express the actual operation > > meaning. My intention with dstadd was "add remote host X to > > pseudo-multicast group". Replace/modify maybe nice to have features to > > avoid doing delete+ add. > > The alternative would be to require iproute2 to always provide the > full list of remote addresses like we do we route nexthops. > > I do like the add/del though and don't see a problem with requiring > an ''ip link set [..] dstadd/dstdel'' I'm feeling Ok about "ip link set [..] dstadd/dstdel". What does bother me is that you can't have different parameters for "ip link add" and "ip link set" for vxlan (and other iplink) utility. So, one can use ip link add [..] dstdel which does not make sense... > > > or has this grown enough that having its own > > > command line tool "vxlan ..." makes sense? > > > > Say, misc/vxlan that will handle remote destinations management? Or > > should it take care of some vxlan parameters currently implemented in > > ip/iplink_vxlan and bridge/fdb? > > What do we gain from a separate tool? -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/30/13 at 03:46pm, Mike Rapoport wrote: > I'm feeling Ok about "ip link set [..] dstadd/dstdel". What does bother > me is that you can't have different parameters for "ip link add" and "ip > link set" for vxlan (and other iplink) utility. So, one can use > ip link add [..] dstdel > which does not make sense... You can easily pass an additional argument into iplink_modify() and exclude certain options in the "add" use case. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 30 May 2013 12:44:24 +0100 Thomas Graf <tgraf@suug.ch> wrote: > > Say, misc/vxlan that will handle remote destinations management? Or > > should it take care of some vxlan parameters currently implemented in > > ip/iplink_vxlan and bridge/fdb? > > What do we gain from a separate tool? At some point the syntax becomes unwieldy, could even just be a shell script. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 30, 2013 at 6:57 PM, Thomas Graf <tgraf@suug.ch> wrote: > On 05/30/13 at 03:46pm, Mike Rapoport wrote: >> I'm feeling Ok about "ip link set [..] dstadd/dstdel". What does bother >> me is that you can't have different parameters for "ip link add" and "ip >> link set" for vxlan (and other iplink) utility. So, one can use >> ip link add [..] dstdel >> which does not make sense... > > You can easily pass an additional argument into iplink_modify() > and exclude certain options in the "add" use case. I think there's no need to pass an additional argument to iplink_modify. The vxlan_parse_opts may check the flags in nlmsghdr to distinguish between the "add" and "set" cases. Than we'll have 'ip link add [..]' as it was and the 'ip link set [..]' will be used to manage default destinations. -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2 Jun 2013 10:09:23 +0300 Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: > On Thu, May 30, 2013 at 6:57 PM, Thomas Graf <tgraf@suug.ch> wrote: > > On 05/30/13 at 03:46pm, Mike Rapoport wrote: > >> I'm feeling Ok about "ip link set [..] dstadd/dstdel". What does bother > >> me is that you can't have different parameters for "ip link add" and "ip > >> link set" for vxlan (and other iplink) utility. So, one can use > >> ip link add [..] dstdel > >> which does not make sense... > > > > You can easily pass an additional argument into iplink_modify() > > and exclude certain options in the "add" use case. > > I think there's no need to pass an additional argument to iplink_modify. > The vxlan_parse_opts may check the flags in nlmsghdr to distinguish > between the "add" and "set" cases. > Than we'll have 'ip link add [..]' as it was and the 'ip link set > [..]' will be used to manage default destinations. > > -- > Sincerely yours, > Mike. I think multiple destinations should be handled like multipath routes. I.e you don't specify multiple destinations on the command line, you specify them individually and can add/delete them If you delete the last destination then the forwarding entry should disappear. The collapsing of multiple entries into one entry in table is an internal data structure choice of vxlan and shouldn't be part of the netlink API requirement. The API to iproute2/netlink should look like routing (through bridge fdb command). Feel free to reject this if since I don't actually use this stuff. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 5, 2013 at 7:30 AM, Stephen Hemminger <stephen@networkplumber.org> wrote: > On Sun, 2 Jun 2013 10:09:23 +0300 > Mike Rapoport <mike.rapoport@ravellosystems.com> wrote: > >> On Thu, May 30, 2013 at 6:57 PM, Thomas Graf <tgraf@suug.ch> wrote: >> > On 05/30/13 at 03:46pm, Mike Rapoport wrote: >> >> I'm feeling Ok about "ip link set [..] dstadd/dstdel". What does bother >> >> me is that you can't have different parameters for "ip link add" and "ip >> >> link set" for vxlan (and other iplink) utility. So, one can use >> >> ip link add [..] dstdel >> >> which does not make sense... >> > >> > You can easily pass an additional argument into iplink_modify() >> > and exclude certain options in the "add" use case. >> >> I think there's no need to pass an additional argument to iplink_modify. >> The vxlan_parse_opts may check the flags in nlmsghdr to distinguish >> between the "add" and "set" cases. >> Than we'll have 'ip link add [..]' as it was and the 'ip link set >> [..]' will be used to manage default destinations. >> >> -- >> Sincerely yours, >> Mike. > > > I think multiple destinations should be handled like multipath routes. > I.e you don't specify multiple destinations on the command line, you specify them > individually and can add/delete them > > If you delete the last destination then the forwarding entry should disappear. > The collapsing of multiple entries into one entry in table is an internal data structure > choice of vxlan and shouldn't be part of the netlink API requirement. > > The API to iproute2/netlink should look like routing (through bridge fdb command). > Feel free to reject this if since I don't actually use this stuff. Well, if we're to follow David Stevens suggestion to make default destination fdb entry with ALL_ZEROS_MAC (1), they surely can be managed using 'bridge fdb'. (1) http://thread.gmane.org/gmane.linux.network/270969/focus=271791 -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c index 1025326..be6c0ac 100644 --- a/ip/iplink_vxlan.c +++ b/ip/iplink_vxlan.c @@ -28,11 +28,87 @@ static void explain(void) fprintf(stderr, " [ port MIN MAX ] [ [no]learning ]\n"); fprintf(stderr, " [ [no]proxy ] [ [no]rsc ]\n"); fprintf(stderr, " [ [no]l2miss ] [ [no]l3miss ]\n"); + fprintf(stderr, " [ dstadd DST ]\n"); + fprintf(stderr, " [ dstdel ADDR ]\n"); fprintf(stderr, "\n"); fprintf(stderr, "Where: VNI := 0-16777215\n"); fprintf(stderr, " ADDR := { IP_ADDRESS | any }\n"); fprintf(stderr, " TOS := { NUMBER | inherit }\n"); fprintf(stderr, " TTL := { 1..255 | inherit }\n"); + fprintf(stderr, " DST := [ ADDR [port PORT] [vni VNI] [via DEV]]\n"); +} + +static int vxlan_parse_dstadd(int *argcp, char ***argvp, struct nlmsghdr *n) +{ + int argc = *argcp; + char **argv = *argvp; + __u32 vni, ifindex; + __u16 port; + struct rtattr *nest; + int addr_set = 0; + + nest = addattr_nest(n, 1024, IFLA_VXLAN_REMOTE_NEW); + + while (argc > 0) { + if (!matches(*argv, "vni")) { + NEXT_ARG(); + if (get_u32(&vni, *argv, 0) || + vni >= 1u << 24) + invarg("invalid id", *argv); + addattr32(n, 1024, IFLA_VXLAN_REMOTE_VNI, vni); + } else if (!matches(*argv, "port")) { + NEXT_ARG(); + if (get_u16(&port, *argv, 0)) + invarg("port", *argv); + addattr32(n, 1024, IFLA_VXLAN_REMOTE_PORT, htons(port)); + } else if (!matches(*argv, "via")) { + NEXT_ARG(); + ifindex = if_nametoindex(*argv); + addattr32(n, 1024, IFLA_VXLAN_REMOTE_IFINDEX, ifindex); + } else { + inet_prefix addr; + get_prefix(&addr, *argv, AF_UNSPEC); + addattr_l(n, 1024, IFLA_VXLAN_REMOTE_ADDR, + &addr.data, addr.bytelen); + addr_set = 1; + } + argc--, argv++; + } + + if (!addr_set) + incomplete_command(); + + addattr_nest_end(n, nest); + + *argcp = argc; + *argvp = argv; + return 0; +} + +static int vxlan_parse_dstdel(int *argcp, char ***argvp, struct nlmsghdr *n) +{ + int argc = *argcp; + char **argv = *argvp; + struct rtattr *nest; + + nest = addattr_nest(n, 1024, IFLA_VXLAN_REMOTE_DEL); + + while (argc > 0) { + inet_prefix addr; + get_prefix(&addr, *argv, AF_UNSPEC); + addattr_l(n, 1024, IFLA_VXLAN_REMOTE_ADDR, + &addr.data, addr.bytelen); + argc--, argv++; + } + + if (argc == *argcp) + incomplete_command(); + + addattr_nest_end(n, nest); + + *argcp = argc; + *argvp = argv; + return 0; } static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv, @@ -54,6 +130,7 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv, __u32 age = 0; __u32 maxaddr = 0; struct ifla_vxlan_port_range range = { 0, 0 }; + struct rtattr *remotes; while (argc > 0) { if (!matches(*argv, "id") || @@ -125,6 +202,16 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv, invarg("max port", *argv); range.low = htons(minport); range.high = htons(maxport); + } else if (!matches(*argv, "dstadd")) { + NEXT_ARG(); + remotes = addattr_nest(n, 1024, IFLA_VXLAN_REMOTES); + vxlan_parse_dstadd(&argc, &argv, n); + addattr_nest_end(n, remotes); + } else if (!matches(*argv, "dstdel")) { + NEXT_ARG(); + remotes = addattr_nest(n, 1024, IFLA_VXLAN_REMOTES); + vxlan_parse_dstdel(&argc, &argv, n); + addattr_nest_end(n, remotes); } else if (!matches(*argv, "nolearning")) { learning = 0; } else if (!matches(*argv, "learning")) { @@ -187,6 +274,41 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv, return 0; } +static void vxlan_print_remote(FILE *f, struct rtattr *attr) +{ + struct rtattr *tb[IFLA_VXLAN_REMOTE_MAX]; + char s1[1024]; + + parse_rtattr_nested(tb, IFLA_VXLAN_REMOTE_MAX, attr); + + if (tb[IFLA_VXLAN_REMOTE_ADDR]) { + struct rtattr *i = tb[IFLA_VXLAN_REMOTE_ADDR]; + if (RTA_PAYLOAD(i) >= sizeof(struct in6_addr)) { + struct in6_addr addr; + memcpy(&addr, RTA_DATA(i), sizeof(struct in6_addr)); + fprintf(f, " %s\n", + format_host(AF_INET6, sizeof(struct in6_addr), + &addr, s1, sizeof(s1))); + } else if (RTA_PAYLOAD(i) >= sizeof(__be32)) { + __be32 addr = rta_getattr_u32(i); + fprintf(f, " %s\n", + format_host(AF_INET, 4, &addr, s1, sizeof(s1))); + } + } +} + +static void vxlan_print_remotes(FILE *f, struct rtattr *attr) +{ + struct rtattr *i; + int rem, n = 0; + + fprintf(f, "\n default destinations :\n"); + + rem = RTA_PAYLOAD(attr); + for (i = RTA_DATA(attr); RTA_OK(i, rem); i = RTA_NEXT(i, rem), n++) + vxlan_print_remote(f, i); +} + static void vxlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[]) { __u32 vni; @@ -277,6 +399,9 @@ static void vxlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[]) if (tb[IFLA_VXLAN_LIMIT] && (maxaddr = rta_getattr_u32(tb[IFLA_VXLAN_LIMIT]) != 0)) fprintf(f, "maxaddr %u ", maxaddr); + + if (tb[IFLA_VXLAN_REMOTES]) + vxlan_print_remotes(f, tb[IFLA_VXLAN_REMOTES]); } struct link_util vxlan_link_util = {
Signed-off-by: Mike Rapoport <mike.rapoport@ravellosystems.com> --- ip/iplink_vxlan.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+)