From: Neale Ranns <ne...@graphiant.com> 
Sent: Monday, April 19, 2021 12:04 PM
To: hem...@mnkcg.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] dst mac-address look up?

 

 

 

From: hem...@mnkcg.com <mailto:hem...@mnkcg.com>  <hem...@mnkcg.com
<mailto:hem...@mnkcg.com> >
Date: Monday, 19 April 2021 at 17:23
To: hem...@mnkcg.com <mailto:hem...@mnkcg.com>  <hem...@mnkcg.com
<mailto:hem...@mnkcg.com> >, Neale Ranns <ne...@graphiant.com
<mailto:ne...@graphiant.com> >, vpp-dev@lists.fd.io
<mailto:vpp-dev@lists.fd.io>  <vpp-dev@lists.fd.io
<mailto:vpp-dev@lists.fd.io> >
Subject: RE: [vpp-dev] dst mac-address look up?

I do see a correct adj in the output from "sh adj" for the pg1 interface.  

 

[@16] ipv6 via 2002::2 pg1: mtu:9000 next:4 flags:[]
002590ebe8ed02fee2df6d1386dd

 

So the issue is how I get adj_index in the VPP plugin code is clearly not
working.

 

    u32 adj_index = vnet_buffer (b)->ip.adj_index[VLIB_TX];

    ip_adjacency_t *adj = adj_get(adj_index);

 

[the adjacency is written into the packet metadata as a result of a
forwarding decision. Usually this is ip[46]-lookup. As you said your plugin
bypasses that, so you need to do your own lookup to get the adj - hence the
table I was suggesting.]

 

Ah, I see - it's the good old layer-3 routing lookup.  My plugin has already
found the egress interface (via other means).  But the layer-2 information
to forward the packet is incomplete.  On any hardware switch/router when
layer-2 information is incomplete, one uses ARP/ND to complete the
information.  From the output of "show adj", it's clear, the adj is a
glean-adj from ARP/ND.  So, why not use ip-neighbor table to complete the
layer-2 information?  Using a control-plane table is tricky.  What if the
VPP node uses 32 virtual switched ports.  If a control-plane table is used,
how is the result of table lookup provisioned because the user would need to
find the mac of next hop for each of the 32 switched ports.  What happens
when next hop ports change?  ARP/ND detect such a change automatically.

 

This is why I am saying, my plugin use case should just use the ip-neighbor
table which currently does not support a lookup with ip+interface.  I am
adding such a lookup.  Also, such a lookup is supported by ARP/ND code of
any hardware router/switch.

 

Thanks,

 

Hemant

 

/neale

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19255): https://lists.fd.io/g/vpp-dev/message/19255
Mute This Topic: https://lists.fd.io/mt/82127329/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to