The session_register_transport() has the foreach code.
1381 /* *INDENT-OFF* */
1382 if (output_node != ~0)
1383 {
1384 foreach_vlib_main (
https://docs.fd.io/vpp/19.08/db/d96/threads_8h.html#a26faa6aef056b1bbb12dc83ce874923c
) (({
1385 next_index = vlib_node_add_next (
> On Oct 2, 2019, at 6:48 PM, Ranadip Das wrote:
>
> Hello,
>
> I am seeing vlib_node_add_next is getting used in two different ways.
>
> vlib_node_add_next(vm, node_index, next_node_index);
>
> And
>
> foreach_vlib_main (({
> next_index = vlib_node_add_next (this_vlib_main,
Hello,
I am seeing vlib_node_add_next is getting used in two different ways.
vlib_node_add_next(vm, node_index, next_node_index);
And
foreach_vlib_main (({
next_index = vlib_node_add_next (this_vlib_main, node_index, next_node_index);
}));
The first one (without foreach_vlib_main) calls
To create GRE tunnel in L2 mode, you can add “teb” keyword in the create CLI
which makes the GRE tunnel work in transparent ethernet bridging mode:
vpp# create gre ?
create gre tunnelcreate gre tunnel src dst
[instance ] [outer-fib-id ] [teb | erspan ] [del]
In
Gre is l3 in this case. Right? This limits the possible use cases.
Is there any plan to support l2 gre over ipsec transport mode? It seems vpp
17 support s this feature. Not sure why it is dropped in 19.
On Wed, Oct 2, 2019, 12:18 AM Neale Ranns (nranns) wrote:
>
> Hi Chuan,
>
> IPSec and GRE
Hi Chuan,
IPSec and GRE is supported using the tunnel protection mechanism :
https://wiki.fd.io/view/VPP/IPSec
GRE over IPSec is only support when the SA is in tunnel mode. This means there
is a double encap of the IP header ; once by the SA (in tunnel mode) and once
by the tunnel itself.
