Hi Korian, Ip4-rewrite does not do a full checksum calculation, it’s an ‘incremental’ update based on the fact only the TTL is decrementing – so the checksum on the packet must be correct on entry to this node. If your node runs before this, and modifies the header, it will need to do a checksum update. So, whether your nodes run before or after ip4-rewrite, two checksums will occur.
You mentioned before that your nodes need access to the TX interface – this is not necessarily known in (or just after) ip4-lookup. In ip4-lookup the result of the lookup is always a load_balance_t object, from which we select a bucket, and follow the arc according to the DPO type we find there, but that DPO type is not necessarily an adjacency and therefore one cannot necessarily derive from the DPO the TX interface. You’d have to walk down the DPO chain to do that. The point in the switch path when the adjacency is reached, and hence the TX interface known, is ip4-rewrite. /neale From: korian edeline <korian.edel...@ulg.ac.be> Date: Thursday, 18 January 2018 at 14:41 To: "Dave Barach (dbarach)" <dbar...@cisco.com>, "Neale Ranns (nranns)" <nra...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] Create an arc Hello Neale, Dave, @Neale I would like to apply my modifications and let ip4-rewrite apply its, and compute the checksum (once). I don't want to replace it for the reason you cited (MTU, etc) .I don't want to put my node after ip4-rewrite, because i will apply my modifications, and have to recompute the checksum. Just to clarify and be sure that i am not off topic: my first node is an extended version of the vnet/classify classifiers, the second one is a rewrite node based on the classifier matchings. @Dave This solution looks good to me. I'm going to give a try. Thanks Korian On 01/18/2018 01:57 PM, Dave Barach (dbarach) wrote: Here's one way to solve the problem, which should result in a patch we can merge: * Add head-of-feature-arc processing to ip4/6_lookup_inline() under control of an integer argument [which will be passed as a constant 0 or 1]. * Create a couple of new nodes “ip4-lookup-with-post-lookup-arc” [or some better name] in ip4/6_forward.c, which instantiate the head of feature arc code * Add the “…with-post-lookup-arc” nodes to the current pre-lookup rx feature arc, before the vanilla lookup nodes. * Make the …with-post-lookup-arc” nodes siblings of the normal lookup nodes, so they inherit successor arcs/indices automatically. * Add your node(s) to the post-lookup arc To make traffic flow: enable the …with-post-lookup-arc nodes in the current rx feature arc AND enable your node(s) on the post-lookup arc If done correctly, this should cost zero clock cycles in the speed path: a hard requirement. HTH… D. -----Original Message----- From: korian edeline [mailto:korian.edel...@ulg.ac.be] Sent: Thursday, January 18, 2018 6:37 AM To: Neale Ranns (nranns) <nra...@cisco.com><mailto:nra...@cisco.com>; Dave Barach (dbarach) <dbar...@cisco.com><mailto:dbar...@cisco.com>; vpp-dev@lists.fd.io<mailto: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<mailto:dbar...@cisco.com>> > Date: Wednesday, 17 January 2018 at 16:21 > To: korian edeline > <korian.edel...@ulg.ac.be<mailto:korian.edel...@ulg.ac.be>>, > "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" > <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>, "Neale Ranns (nranns)" > <nra...@cisco.com<mailto: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> > [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<mailto: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<mailto: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 -- 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
