On Wed, Oct 23, 2019 at 11:49:57AM +0800, wenxu wrote:
>
> On 10/22/2019 11:47 PM, Pablo Neira Ayuso wrote:
> > Hi,
> >
> > This is a RFC patchset, untested, to introduce new infrastructure to
> > specify protocol decapsulation and encapsulation actions. This patchset
> > comes with initial support for VLAN, eg.
> >
> > 1) VLAN decapsulation:
> >
> > ... meta iif . vlan id { eth0 . 10, eth1 . 11} decap vlan
> >
> > The decapsulation is a single statement with no extra options.
>
> Currently there is no vlan meta match expr. So it is better to
> extend the meta expr or add new ntf_vlan_get_expr?
There's nft_payload to get the vlan information.
> > 2) VLAN encapsulation:
> >
> > add vlan "network0" { type push; id 100; proto 0x8100; }
> > add vlan "network1" { type update; id 101; }
> > ... encap vlan set ip daddr map { 192.168.0.0/24 : "network0",
> > 192.168.1.0/24 : "network1" }
> >
> > The idea is that the user specifies the vlan policy through object
> > definition, eg. "network0" and "network1", then it applies this policy
> > via the "encap vlan set" statement.
> >
> > This infrastructure should allow for more encapsulation protocols
> > with little work, eg. MPLS.
>
> So the tunnel already exist in nft_tunnel also can add in this encapsulation protocols
> as ip.
>
> like ip-route
>
> encap ip id 100 dst 10.0.0.1?
Not sure what you mean, please, extend your coment.
