On 12 May 2017, at 08:01, Tomas Brännström 
<tomas.a.brannst...@tieto.com<mailto:tomas.a.brannst...@tieto.com>> wrote:

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

I strongly suggest that you use 17.04 release at least.


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 :)

PF = SR-IOV Physical Function


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<mailto: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<mailto: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<http://10.0.1.101/24>
vpp# set int ip address TenGigabitEthernet0/7/0 
10.0.2.101/24<http://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<mailto:vpp-dev@lists.fd.io>
https://lists.fd.io/mailman/listinfo/vpp-dev


<vpp_stacktrace.txt>

_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Reply via email to