Thank you Damjan
so the new graph will be something like:
device-input--> ethernet-input --> ip6-input --> my-forwarder-plugin -->
ethernet-output (or error drop)
i dont understand how to use the ip6-unicast feature arc ?
generally i dont understand the use of 'arcs' - why do i have to explicit
If it is ip6 traffic why you don't use ip6-unicast feature arc?
ip6-input node can take care for ip6 hdr checks and pass packets to your
feature node..
--
Damjan
> On 16 Apr 2018, at 09:44, Sara Gittlin wrote:
>
> Thank you Damjan,
> The my-forwarder plugin performs l3 lookup (3D array - o
Thank you Damjan,
The my-forwarder plugin performs l3 lookup (3D array - on some bytes of
the dest-IP (v6) and decides about the output interface.
then sends to interface-output node - this works perfectly (with static
arp/ndp installed in the dest/source machines) when dest-ip and src-ip are
in
Dear Sara,
It is perfectly fine to send all ARP packets (identified by ethertype) to
arp-inut node from my-forwarder-plugin.
I'm just afraid that if you go that route that this is just a start of
problems
Can you describe your use case in more details, we may come up with better
solution.
Hi
my VPP contains a customized forwarder plugin
the graph is looking like :
device-input--> my-forwarder-plugin --> ethernet-output (or error drop)
this is good as long as the traversed traffic is within the same subnet
but if not - i need to integrate/reuse VPP ARP/NDP nodes and the node
wh
