OpenVZ Forum - RDF feed
type: channel
items: [PATCH] Virtual ethernet tunnel (v.2)
items: [PATCH] Module for ip utility to support veth device (v.2)
items: Re: [PATCH] Virtual ethernet tunnel (v.2)

[PATCH] Virtual ethernet tunnel (v.2)
type: item
description: Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other. Mainly it allows to communicate between network namespaces but it can be used as is as well. Eric recently sent a similar driver called etun. This implementation uses another interface - the RTM_NRELINK message introduced by Patric. The newlink callback is organized that way to make it easy to create the peer device in the separate namespace when we have them in kernel. Changes from v.1: * percpu statistics; * standard convention for nla policy names; * module alias added; * xmit function fixes noticed by Patric; * code cleanup. The patch for an ip utility is also provided. Signed-off-by: Pavel Emelianov <xemul@openvz.org> Since ethtool interface was taken from Eric's patch, I think that he would like to see his Signed-off line as well (however he didn't answer yesterday). --- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 7d57f4a..7e144be 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -119,6 +119,12 @@ config TUN If you don't know what to use this for, you don't need it. +config VETH + tristate "Virtual ethernet device" + ---help--- + The device is an ethernet tunnel. Devices are created in pairs. When + one end receives the packet it appears on its pair and vice versa. + config NET_SB1000 tristate "General Instruments Surfboard 1000" depends on PNP diff --git a/drivers/net/Makefile b/drivers/net/Makefile index a77affa..4764119 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -185,6 +185,7 @@ obj-$(CONFIG_MACSONIC) += macsonic.o obj-$(CONFIG_MACMACE) += macmace.o obj-$(CONFIG_MAC89x0) += mac89x0.o obj-$(CONFIG_TUN) += tun.o +obj-$(CONFIG_VETH) += veth.o obj-$(CONFIG_NET_NETX) += netx-eth.o obj-$(CONFIG_DL2K) += dl2k.o obj-$(CONFIG_R8169) += r8169.o diff --git a/drivers/net/veth.c b/drivers/net/veth.c new file mode 100644 index 0000000..e7ad43d --- /dev/null +…
creator: Pavel Emelianov
date: 2007-06-07T11:13:02-00:00

[PATCH] Module for ip utility to support veth device (v.2)
type: item
description: The usage is # ip link add [name] type veth [peer <name>] [mac <mac>] [peer_mac <mac>] This version doesn't include the fix for ip/iplink.c as Patrick said that he had included it into his patches already. Signed-off-by: Pavel Emelianov <xemul@openvz.org> --- diff --git a/ip/Makefile b/ip/Makefile index 9a5bfe3..b46bce3 100644 --- a/ip/Makefile +++ b/ip/Makefile @@ -8,8 +8,9 @@ RTMONOBJ=rtmon.o ALLOBJ=$(IPOBJ) $(RTMONOBJ) SCRIPTS=ifcfg rtpr routel routef TARGETS=ip rtmon +LIBS=link_veth.so -all: $(TARGETS) $(SCRIPTS) +all: $(TARGETS) $(SCRIPTS) $(LIBS) ip: $(IPOBJ) $(LIBNETLINK) $(LIBUTIL) @@ -24,3 +25,6 @@ clean: LDLIBS += -ldl LDFLAGS += -Wl,-export-dynamic + +%.so: %.c + $(CC) $(CFLAGS) -shared $< -o $@ diff --git a/ip/link_veth.c b/ip/link_veth.c new file mode 100644 index 0000000..f2e4079 --- /dev/null +++ b/ip/link_veth.c @@ -0,0 +1,86 @@ +/* + * ip/link_veth.c + * + * Virtual ETHernet tunnel supprt. + * + * Author: Pavel Emelianov <xemul@openvz.org> + */ + +#include <stdio.h> +#include <string.h> + +#include "utils.h" +#include "ip_common.h" +#include "veth.h" + +#define ETH_ALEN 6 + +static void usage(void) +{ + printf("Usage: ip link add ... " + "[peer <peer-name>] [mac <mac>] [peer_mac <mac>]\n"); +} + +static int veth_parse_opt(struct link_util *lu, int argc, char **argv, + struct nlmsghdr *hdr) +{ + __u8 mac[ETH_ALEN]; + + for (; argc != 0; argv++, argc--) { + if (strcmp(*argv, "peer") == 0) { + argv++; + argc--; + if (argc == 0) { + usage(); + return -1; + } + + addattr_l(hdr, 1024, VETH_INFO_PEER, + *argv, strlen(*argv)); + + continue; + } + + if (strcmp(*argv, "mac") == 0) { + argv++; + argc--; + if (argc == 0) { + usage(); + return -1; + } + + if (hexstring_a2n(*argv, mac, sizeof(mac)) == NULL) + return -1; + + addattr_l(hdr, 1024, VETH_INFO_MAC, + mac, ETH_ALEN); + continue; + } + + if (strcmp(*argv, "peer_mac") == 0) { + argv++; + argc--; + if (argc == 0) { + usage(); + return -1; + } + + if (hexstring_a2n(*argv, mac, sizeof(mac)) == NULL) + return…
creator: Pavel Emelianov
date: 2007-06-07T11:16:34-00:00

Re: [PATCH] Virtual ethernet tunnel (v.2)
type: item
description: Pavel Emelianov wrote: > Ben Greear wrote: > > [snip] > > >>>> I would also like some way to identify veth from other device types, >>>> preferably >>>> something like a value in sysfs. However, that should not hold up >>>> >>>> >>> We can do this with ethtool. It can get and print the driver name of >>> the device. >>> >>> >> I think I'd like something in sysfs that we could query for any >> interface. Possible return >> strings could be: >> VLAN >> VETH >> ETH >> PPP >> BRIDGE >> AP /* wifi access point interface */ >> STA /* wifi station */ >> .... >> >> I will cook up a patch for consideration after veth goes in. >> >> > > Ben, could you please tell what sysfs features do you > plan to implement? > I think this is the only thing that has a chance of getting into the kernel. Basically, I have a user-space app and I want to be able to definitively know the type for all interfaces. Currently, I have a hodge-podge of logic to query various ioctls and /proc files and finally, guess by name if nothing else works. There must be a better way :P I have another sysfs patch that allows setting a default skb->mark for an interface so that you can set the skb->mark before it hits the connection tracking logic, but I'm been told this one has very little chance of getting into the kernel. The skb->mark patch is only useful (as far as I can tell) if you also include a patch Patrick McHardy did for me that allowed the conn-tracking logic to use skb->mark as part of it's tuple. This allows me to do NAT between virtual routers (routing tables) on the same machine using veth-equivalent drivers to connect the routers. He thinks this will probably not ever get into the kernel either. I have another sysctl related send-to-self patch that also has little chance of getting into the kernel, but it might be quite useful with veth (it's useful to me..but my needs aren't exactly mainstream :)) I'll post this separately for consideration.... Thanks, Ben -- Ben Greear <greearb@candelatech.com…
creator: Ben Greear
date: 2007-06-08T17:00:20-00:00

Re: [PATCH] Virtual ethernet tunnel (v.2)
type: item
description: On 08.06.2007 19:00, Ben Greear wrote: > I have another sysfs patch that allows setting a default skb->mark for > an interface so that you can set the skb->mark > before it hits the connection tracking logic, but I'm been told this one > has very little chance > of getting into the kernel. The skb->mark patch is only useful (as far > as I can tell) if you > also include a patch Patrick McHardy did for me that allowed the > conn-tracking logic to > use skb->mark as part of it's tuple. This allows me to do NAT between > virtual routers > (routing tables) on the same machine using veth-equivalent drivers to > connect the > routers. He thinks this will probably not ever get into the kernel either. Are these patches available somewhere? I'm currently doing NAT between virtual routers by some advanced iproute2/iptables trickery, but I have no way to handle the occasional tuple conflict. Regards, Carl-Daniel _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Carl-Daniel Hailfinge
date: 2007-06-08T19:49:17-00:00

Re: [PATCH] Virtual ethernet tunnel (v.2)
type: item
description: Carl-Daniel Hailfinger wrote: > On 08.06.2007 19:00, Ben Greear wrote: >> I have another sysfs patch that allows setting a default skb->mark for >> an interface so that you can set the skb->mark >> before it hits the connection tracking logic, but I'm been told this one >> has very little chance >> of getting into the kernel. The skb->mark patch is only useful (as far >> as I can tell) if you >> also include a patch Patrick McHardy did for me that allowed the >> conn-tracking logic to >> use skb->mark as part of it's tuple. This allows me to do NAT between >> virtual routers >> (routing tables) on the same machine using veth-equivalent drivers to >> connect the >> routers. He thinks this will probably not ever get into the kernel either. > > Are these patches available somewhere? I'm currently doing NAT between > virtual routers by some advanced iproute2/iptables trickery, but I have > no way to handle the occasional tuple conflict. A consolidated patch against 2.6.20.12 is here. It has a lot more than just the patches mentioned above, but it shouldn't hurt anything to have the whole patch applied: http://www.candelatech.com/oss/candela_2.6.20.patch The original patch for using skb->mark as a tuple was written by Patrick McHardy, and is here: http://www.candelatech.com/oss/skb_mark_conntrack.patch His patch merged with my patch to sysfs to set skb->mark on ingress is here: http://www.candelatech.com/oss/conntrack_mark_with_ssyctl.patch Thanks, Ben > > Regards, > Carl-Daniel -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Ben Greear
date: 2007-06-08T23:46:32-00:00