Re: [patch v2, kernel version 3.2.1] net/ipv4/ip_gre: Ethernetmultipoint GRE over IP

[David Lamparter]

On Tue, Jan 17, 2012 at 10:56:51AM +0100, Åtefan Gula wrote:
> DÅa 17. januÃra 2012 10:50, David Lamparter <equinox@xxxxxxxxxx> napÃsal/a:
> > On Mon, Jan 16, 2012 at 11:52:25PM +0100, Åtefan Gula wrote:
> >> DÅa 16. januÃra 2012 21:29, David Lamparter <equinox@xxxxxxxxxx> napÃsal/a:
> >> > At the risk of repeating myself, Linux GRE support already has
> >> > provisions for multipoint tunnels. And unlike your code, those reuse the
> >> > existing neighbor table infrastructure, including all of its user
> >> > interface and introspection capabilities.
> >> >
> >> > It's actually slightly visible in your patch:
> >> >
> >> > On Mon, Jan 16, 2012 at 08:45:14PM +0100, Åtefan Gula wrote:
> >> >> +++ linux-3.2.1-my/net/ipv4/ip_gre.c Â2012-01-16 20:42:03.000000000 +0100
> >> >> @@ -716,7 +942,19 @@ static netdev_tx_t ipgre_tunnel_xmit(str
> >> > [...]
> >> >> Â Â Â Â Â Â Â /* NBMA tunnel */
> >> >>
> >> >> Â Â Â Â Â Â Â if (skb_dst(skb) == NULL) {
> >> >
> >> >
> >> > -David
> >>
> >> That code you are referring to is used only for routed traffic inside
> >> GRE - L3 traffic over L3 routed infrastructure. My patch is dealing
> >> with L2 traffic over L3 routed infrastructure - so the decision here
> >> is based on destination MAC addresses and not based on IPv4/IPv6
> >> addresses.
> >
> > Yes, it currently only does IPv4/IPv6 -> IPv4 through the neighbor
> > table. That doesn't mean it can't be extended to handle ethernet
> > addresses the same way.
> 
> Routing mechanisms and switching mechanisms works completely
> different, in switching you simply don't have anything like next-hop
> from routing, which can be resolved by utilizing modified ARP message
> and there is also absolutely no hierarchy in MAC address (like you
> have in routing table), so I seriously doubt that it can be done the
> same way, but I am opened to ideas here. So how would you do like to
> do that?

NBMA GRE does not use routing mechanisms, it uses the neighbor table.
The neighbor table does not use any hierarchy in its lookups.

So you have the existing neighbor table use cases:
 - IPv4 -> MAC with in-kernel ARP
 - IPv6 -> MAC with in-kernel ND
 - IPv4 -> IPv4 on NBMA GRE devices (without in-kernel filling)
 - IPv6 -> IPv4 on NBMA GRE devices (without in-kernel filling)
You could add to that:
 - MAC -> IPv4 on NBMA GRETAP devices


-David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/