In order to prevent the calculation of the checksum twice your node would need
to run instead of ip4-rewrite - is that your intention? – there’s quite a bit
more going on in that node! If instead you want your node to run as well as
ip4-rewrite, then it can be an output-feature (arc=ip4-output), where it will
receive all packets egressing through that interface post rewrite encapsulation.
/neale
-----Original Message-----
From: korian edeline <korian.edel...@ulg.ac.be>
Date: Thursday, 18 January 2018 at 12:36
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "Dave Barach (dbarach)"
<dbar...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Create an arc
Hello Neale, Dave,
Thanks for your answers.
I would like to catch all (not on a prefix basis) traffic to-be-forwarded.
- I would need the TX sw_if_index, so i think the nodes should be placed
after ip4-lookup.
- i have to be before ip4-rewrite, not to compute checksums 2 times.
Right now, my nodes are placed before lookup, via ip4-unicast feature
arc and they can be enabled/disabled via vnet_feature_enable_disable.
Something similar, but after lookup, would be really convenient.
Regards,
Korian
On 01/18/2018 11:01 AM, Neale Ranns (nranns) wrote:
> Hi Korian,
>
> Constructing the VLIB graph between ipX-lookup and ipX-rewrite (and
really to interface-output) is best achieved by following the DPO architecture.
You can read a little about it here:
> https://wiki.fd.io/view/VPP/DPOs_and_Feature_Arcs
>
> Step one is to implement a new DPOs to represent your two new nodes.
You’ll find many examples of DPOs in vnet/dpo/*. Step 2 is then to ‘resolve’
the IP prefix via your DPO. The means for that is, e.g, from
vnet/bier/bier_table.c:
>
> bt->bt_lfei = fib_table_entry_special_dpo_add(mpls_fib_index,
> &pfx,
> FIB_SOURCE_BIER,
>
FIB_ENTRY_FLAG_EXCLUSIVE,
> &dpo);
>
> the rather badly named EXCLUSIVE flag means the caller is providing the
DPO and so FIB has no need to perform its usual resolution. The FIB_SOURCE_BIER
identifies ‘who’ is providing the forwarding information (the DPO) and thus the
relative priority of that information. There is a simple linear priority scheme
among the sources enumerated by fib_source_t.
> Step 3 is to ‘stack’ your DPOs, i.e. to form the chain/graph that will be
followed in the data-plane. The FIB API above automatically stacks the
load_balance_t DPO (which is the result of the lookup) on your DPO passed.
>
> note that the above provides you with ‘override’ semantics, i.e. for a
given prefix you can override (assuming your source has higher priority) the
existing forwarding information for that prefix. If instead your requirements
are to apply further rules/checks/replications on the packets before they are
forwarded using the existing information, then this is what I call
‘interposition’. I have an outstanding patch for this:
> https://gerrit.fd.io/r/#/c/9336/
> I’ll try and get it finished soon.
>
> The last issue to consider is whether your override or interposition
needs to affect only the prefix you specify in the call to
fib_table_entry_special_dpo_add() or to all longer mask prefixes that it
covers. For example, if you specify 10.0.0.0/24, and some other source
specifies 10.0.0.0/25 and 10.128.0.0/25 then your prefix is never matched. In
order to ‘push’ your forwarding down to all longer mask prefixes in the
sub-tree one needs to explicitly specify this. Again, this is an outstanding
patch:
> https://gerrit.fd.io/r/#/c/9477/
>
>
> Having said all that, if what you are after Is not running your feature
on a per-prefix basis, but instead on a per-output interface basis, then you
want the ip4-output feature arc ☺
>
> hth,
> neale
>
>
> -----Original Message-----
> From: "Dave Barach (dbarach)" <dbar...@cisco.com>
> Date: Wednesday, 17 January 2018 at 16:21
> To: korian edeline <korian.edel...@ulg.ac.be>, "vpp-dev@lists.fd.io"
<vpp-dev@lists.fd.io>, "Neale Ranns (nranns)" <nra...@cisco.com>
> Subject: RE: [vpp-dev] Create an arc
>
> Dear Korian,
>
> Steering traffic from ip4_lookup to <some-node> is easily
accomplished by setting the fib result [dpo->dpoi_next_node] to send matching
traffic where you want it to go.
>
> Add an arc from ip4/6_lookup to <some-node> by calling
vlib_node_add_next(...) to create the arc, then create fib entries with
dpoi_next_node set to the returned next_index.
>
> This is not a feature arc problem. Attempting to solve it as such
will cause no end of trouble.
>
> Neale, please jump in as needed...
>
> HTH... Dave
>
> -----Original Message-----
> From: vpp-dev-boun...@lists.fd.io
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of korian edeline
> Sent: Wednesday, January 17, 2018 9:30 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Create an arc
>
> Hi all,
>
> Here is the deal:
>
> I have 2 nodes (my-node-1, my-node-2), I would like my-node-1 to
receive packets from ip4-lookup, forwarding to either ip4-rewrite, error-drop
or my-node-2. my-node-2 should only receive from my-node-1 and forward to
ip4-rewrite or error-drop.
>
> If I put them BEFORE ip4-lookup, i can use pre-built arc ip4-unicast
and everything works perfect. But i figured that if i want them after
ip4-lookup, i have to create my own arc. So here is what i have, plus replacing
occurences of "ip4-unicast" by "my-arc".
>
> VNET_FEATURE_ARC_INIT (my_arc, static) = {
> .arc_name = "my-arc,
> .start_nodes = VNET_FEATURES ("ip4-lookup"),
> .arc_index_ptr = &my_main.feature_arc_index };
>
> What am i missing ?
>
> Thanks
>
> Korian
>
> _______________________________________________
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
>
--
Korian Edeline
Université de Liège (ULg)
Bât. B28 Algorithmique des Grands Systèmes
Quartier Polytech 1
Allée de la Découverte 10
4000 Liège
Phone: +32 4 366 56 05
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
