*(I forgot to mention before, this is running with VPP installed from
binaries with release .stable.1701)*

With PF do you mean packet filter? I don't think we have any such
configuration. If there is anything else I should provide then please tell
:)

I decided to try to attach to the VPP process with gdb and I actually get a
crash when trying to do "ip probe":

vpp# ip probe 10.0.1.1 TenGigabitEthernet0/6/0
exec error: Misc

Program received signal SIGSEGV, Segmentation fault.
ip4_probe_neighbor (vm=vm@entry=0x7f681533e720 <vlib_global_main>,
dst=dst@entry=0x7f67d345cc50, sw_if_index=sw_if_index@entry=1)
    at
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:2223
2223
 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:
No such file or directory.
(gdb) bt
#0  ip4_probe_neighbor (vm=vm@entry=0x7f681533e720 <vlib_global_main>,
dst=dst@entry=0x7f67d345cc50, sw_if_index=sw_if_index@entry=1)
    at
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:2223

Whether this is related or not I'm not sure because yesterday I could do
the probe but got "Resolution failed". I've attached the stack trace at any
rate.

/Tomas

On 11 May 2017 at 20:25, Damjan Marion (damarion) <damar...@cisco.com>
wrote:

> Dear Tomas,
>
> Can you please share your PF configuration so I can try to reproduce?
>
> Thanks,
>
> Damjan
>
> On 11 May 2017, at 17:07, Tomas Brännström <tomas.a.brannst...@tieto.com>
> wrote:
>
> Hello
> Since the last mail I sent I've managed to get our test client working and
> VPP running in a KVM VM.
>
> We are still facing some problems though. We have a two servers, one where
> the virtual machines are running and one we use as the openstack
> controller. They are connected to each other with a 10G NIC. We have SR-IOV
> configured for the 10G NIC.
>
> So VPP is installed in a VM, and all interfaces work OK, then can be
> reached from outside the VM etc. Following the basic examples on the wiki,
> we configure VPP to take over the interfaces:
>
> vpp# set int ip address TenGigabitEthernet0/6/0 10.0.1.101/24
> vpp# set int ip address TenGigabitEthernet0/7/0 10.0.2.101/24
> vpp# set int state TenGigabitEthernet0/6/0 up
> vpp# set int state TenGigabitEthernet0/7/0 up
>
> But when trying to ping for example the physical NIC on the other server,
> we get no reply:
>
> vpp# ip probe 10.0.1.1 TenGigabitEthernet0/6/0
> ip probe-neighbor: Resolution failed for 10.0.1.1
>
> If I do a tcpdump on the physical interface when trying to ping, I see ARP
> packets being sent so -something- is happening, but it seems that packets
> are not correctly arriving to VPP... I can't ping from the physical host
> either, but the ARP cache is updated on the host when trying to ping from
> VPP.
>
> I've tried dumping counters etc. but I can't really see anything. The
> trace does not show anything either. This is the output from "show
> hardware":
>
> vpp# show hardware
>               Name                Idx   Link  Hardware
> TenGigabitEthernet0/6/0            1     up   TenGigabitEthernet0/6/0
>   Ethernet address fa:16:3e:04:42:d1
>   Intel 82599 VF
>     carrier up full duplex speed 10000 mtu 9216
>     rx queues 1, rx desc 1024, tx queues 1, tx desc 1024
>
>     tx frames ok                                           3
>     tx bytes ok                                          126
>     extended stats:
>       tx good packets                                      3
>       tx good bytes                                      126
> TenGigabitEthernet0/7/0            2     up   TenGigabitEthernet0/7/0
>   Ethernet address fa:16:3e:f2:15:a5
>   Intel 82599 VF
>     carrier up full duplex speed 10000 mtu 9216
>     rx queues 1, rx desc 1024, tx queues 1, tx desc 1024
>
> I've tried a similar setup between two virtual box VM's and that worked
> OK, so I'm thinking it might have something to do with SR-IOV for some
> reason. I'm having a hard time troubleshooting this since I'm not sure how
> to check where the packets actually get lost...
>
> /Tomas
>
> _______________________________________________
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
>
>
Program received signal SIGSEGV, Segmentation fault.
ip4_probe_neighbor (vm=vm@entry=0x7f681533e720 <vlib_global_main>, 
dst=dst@entry=0x7f67d345cc50, sw_if_index=sw_if_index@entry=1)
    at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:2223
2223    
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:
 No such file or directory.
(gdb) bt
#0  ip4_probe_neighbor (vm=vm@entry=0x7f681533e720 <vlib_global_main>, 
dst=dst@entry=0x7f67d345cc50, sw_if_index=sw_if_index@entry=1)
    at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:2223
#1  0x00007f6814c60aab in ip4_probe_neighbor_wait (retry_count=3, 
sw_if_index=1, a=0x7f67d345cc50, vm=0x7f681533e720 <vlib_global_main>)
    at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/lookup.c:848
#2  probe_neighbor_address (vm=0x7f681533e720 <vlib_global_main>, 
input=<optimized out>, cmd=<optimized out>)
    at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/lookup.c:929
#3  0x00007f68150efb71 in vlib_cli_dispatch_sub_commands 
(vm=vm@entry=0x7f681533e720 <vlib_global_main>,
    cm=cm@entry=0x7f681533e988 <vlib_global_main+616>, 
input=input@entry=0x7f67d345ce40, parent_command_index=<optimized out>)
    at /w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vlib/vlib/cli.c:484
#4  0x00007f68150eff07 in vlib_cli_dispatch_sub_commands 
(vm=vm@entry=0x7f681533e720 <vlib_global_main>,
    cm=cm@entry=0x7f681533e988 <vlib_global_main+616>, 
input=input@entry=0x7f67d345ce40, 
parent_command_index=parent_command_index@entry=0)
    at /w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vlib/vlib/cli.c:462
#5  0x00007f68150f0150 in vlib_cli_input (vm=vm@entry=0x7f681533e720 
<vlib_global_main>, input=input@entry=0x7f67d345ce40,
    function=function@entry=0x5d17b0 <shmem_cli_output>, 
function_arg=function_arg@entry=140083902926392)
    at /w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vlib/vlib/cli.c:558
#6  0x00000000005c02bd in vl_api_cli_request_t_handler (mp=<optimized out>) at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vpp/vpp-api/api.c:2116
#7  0x00007f681577dba3 in vl_msg_api_handler_with_vm_node 
(am=am@entry=0x7f68159872e0 <api_main>, the_msg=the_msg@entry=0x304a2c44,
    vm=vm@entry=0x7f681533e720 <vlib_global_main>, 
node=node@entry=0x7f67d3454000)
    at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vlib-api/vlibapi/api_shared.c:510
#8  0x00007f68155697b3 in memclnt_process (vm=<optimized out>, 
node=0x7f67d3454000, f=<optimized out>)
    at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vlib-api/vlibmemory/memory_vlib.c:487
#9  0x00007f68150fae36 in vlib_process_bootstrap (_a=<optimized out>) at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vlib/vlib/main.c:1218
#10 0x00007f6814272d90 in clib_calljmp () at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vppinfra/vppinfra/longjmp.S:110
#11 0x00007f67d357be30 in ?? ()
#12 0x00007f68150fbed1 in vlib_process_startup (f=0x0, p=0x7f67d3454000, 
vm=0x7f681533e720 <vlib_global_main>)
    at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vlib/vlib/main.c:1240
#13 dispatch_process (vm=0x7f681533e720 <vlib_global_main>, p=0x7f67d3454000, 
last_time_stamp=133007346616438, f=0x0)
    at 
/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vlib/vlib/main.c:1283
#14 0x0000000200000003 in ?? ()
#15 0x000000cf00000001 in ?? ()
#16 0x0000000300000002 in ?? ()
#17 0x7379687000000007 in ?? ()
#18 0x00000003006d656d in ?? ()
#19 0x000000210000000b in ?? ()
#20 0x62616c2d736c706d in ?? ()
#21 0x736f706d692d6c65 in ?? ()
#22 0x65722d6e6f697469 in ?? ()
#23 0x6425203a6e727574 in ?? ()
#24 0x0000000000000000 in ?? ()
(gdb) q
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Reply via email to