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
