On Tue, Dec 6, 2022 at 1:42 PM David Ahern <dsahern@xxxxxxxxx> wrote:
>
> On 12/6/22 1:36 PM, team lnx wrote:
> > On Tue, Dec 6, 2022 at 12:10 PM David Ahern <dsahern@xxxxxxxxx> wrote:
> >>
> >> On 12/6/22 9:43 AM, team lnx wrote:
> >>> Hello,
> >>>
> >>> I am a beginner for xdp and following is the setup
> >>>
> >>> 3rd party Board - (64 bit arch): This has 2 ethernet interfaces
> >>> supporting XDP (v0 and v1)
> >>> Host machine: Ubuntu
> >>>
> >>> step 1: 3rd party Board <-----connected over ethernet (v0) ------> Host - Ubuntu
> >>> step 2: echo "1" > /proc/sys/net/ipv4/ip_forward
> >>> step 3: Assign static ip address for v0 and v1
> >>> step 4: run: xdp_fwd -D v0 v1 on 3rd party Board
> >>> step 5: start ping from host to v0 of 3rd party Board with expectation
> >>> of forwarding from v0 to v1
> >>>
> >>> Observation : In the above experiment I see xdp_fwd has a return code
> >>> always set to XDP_PASS and when I traced it found that below
> >>> conditions is the reason
> >>> in net/core/filter.c
> >>> if (res.type != RTN_UNICAST) {
> >>> return BPF_FIB_LKUP_RET_NOT_FWDED;
> >>> }
> >>>
> >>> 1. Could you please help in understanding the reason behind this ?
> >>
> >> RTN_LOCAL means delivery to a local process -- ie., nothing to forward
> >> to another device / host.
> >>
> >> RTN_MULTICAST and RTN_BROADCAST: broadcast is not supported. Multicast
> >> ... I forget how to use that. The fib lookup and xdp_fwd test predates
> >> multicast support
> >>
> >>
> >>> 2. Once #1 is resolved, do we need to add manually arp table/neighbor
> >>> information as well ?
> >>>
> >>
> >> the xdp_fwd app is a demo. In a production deployment, you will need to
> >> have something manage the neighbor entries for hosts. e.g., look at `ip
> >> neigh ... managed` if you have a new enough kernel.
> >>
> >
> > Thanks for the response,
> > Understood #2, but for #1
> > I have initiated ping from Host (ubuntu) -> V0 (ethernet) of 3rd party
> > board with intention of forwarding/redirecting to V1 on the same board
> >
> > But I see XDP_PASS being returned instead of XDP_REDIRECT, anything
> > missing/wrong in steps ?
> >
>
> look at the return code from the fib_lookup. It indicates why the lookup
> failed if it does not return BPF_FIB_LKUP_RET_SUCCESS:
>
> enum {
> BPF_FIB_LKUP_RET_SUCCESS, /* lookup successful */
> BPF_FIB_LKUP_RET_BLACKHOLE, /* dest is blackholed; can be
> dropped */
> BPF_FIB_LKUP_RET_UNREACHABLE, /* dest is unreachable; can be
> dropped */
> BPF_FIB_LKUP_RET_PROHIBIT, /* dest not allowed; can be
> dropped */
> BPF_FIB_LKUP_RET_NOT_FWDED, /* packet is not forwarded */
> BPF_FIB_LKUP_RET_FWD_DISABLED, /* fwding is not enabled on
> ingress */
> BPF_FIB_LKUP_RET_UNSUPP_LWT, /* fwd requires encapsulation */
> BPF_FIB_LKUP_RET_NO_NEIGH, /* no neighbor entry for nh */
> BPF_FIB_LKUP_RET_FRAG_NEEDED, /* fragmentation required to fwd */
> };
>
>
Sure, I did search for it and read some article but found that
BPF_FIB_LKUP_RET_NOT_FWDED means packets
are not forwarded and only unicast are forwarded. Verified prog id and
map id using bpftool to confirm if it has any issue
interface details:
prog/xdp id: 4
map_ids: 1
btf_id: 7
./bpftool map show id 1
1: devmap name xdp_tx_ports flags 0x80
Any hints or suggestions on debugging this issue would be helpful !
Thanks
|