lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 5 Mar 2015 01:17:59 -0800 From: Vivek Venkatraman <vivek@...ulusnetworks.com> To: "Eric W. Biederman" <ebiederm@...ssion.com> Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org, roopa <roopa@...ulusnetworks.com>, Stephen Hemminger <stephen@...workplumber.org>, santiago@...reenet.org Subject: Re: [PATCH net-next 8/8] ipmpls: Basic device for injecting packets into an mpls tunnel It is great to see an MPLS data plane implementation make it into the kernel. I have a couple of questions on this patch. On Wed, Feb 25, 2015 at 9:18 AM, Eric W. Biederman <ebiederm@...ssion.com> wrote: > > > Allow creating an mpls tunnel endpoint with > > ip link add type ipmpls. > > This tunnel has an mpls label for it's link layer address, and by > default sends all ingress packets over loopback to the local MPLS > forwarding logic which performs all of the work. > Is it correct that to achieve IPoMPLS, each LSP has to be installed as a link/netdevice? If ingress packets loopback with the label associated with the link to hit the MPLS forwarding logic, how does it work if each packet has to be then forwarded with a different label stack? One use case is a common IP/MPLS application such as L3VPNs (RFC 4364) where multiple VPNs may reside over the same LSP, each having its own VPN (inner) label. > Ingress IPv4, IPv6 and MPLS packets are supported. > > A new arp type ARPHRD_MPLS is defined for network devices that > whose link-layer addresses is an mpls label stack. > > This is the most bare bones version of this tunnel device I can think > of. Not even packet counters have been implemented. Offloads > and features in general are not supported, just to keep it simple and > obviously correct to start with. In principle it should be able to > allow binding to a physical network device and pass all of the > offloads through ipmpls like the vlan, macvlan, or even ipvlan does. > Allowing a very fast light weight connection to the network. > > The technical tricky bit to residing over something besides > the loopback device is how to get the next-hop mac address. > Neighbour table integration? Something else? > Thanks, Vivek -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists