Hi Christophe, This one might help you:
https://git.fd.io/vpp/commit/?id=e2e95ce6550a28a6ba5870c9c550acb619883f1a <https://git.fd.io/vpp/commit/?id=e2e95ce6550a28a6ba5870c9c550acb619883f1a> Thanks, Damjan > On 29 Nov 2016, at 12:24, Christophe FONTAINE > <[email protected]> wrote: > > I just did the test with the same platform (I added another intel NIC), same > problem (assert on VLIB_FRAME_IS_ALLOCATED) in debug. > And so, I got an identical backtrace. > # set int span GigabitEthernet8/0/0 destination GigabitEthernet3/0/0 > > Christophe > >> -----Original Message----- >> From: Damjan Marion [mailto:[email protected]] >> Sent: lundi 28 novembre 2016 21:57 >> To: Christophe FONTAINE <[email protected]> >> Cc: [email protected] >> Subject: Re: [vpp-dev] How to transfer packets between 2 bridge domains ? >> >> >> Have you tried with different physical interfaces used for source and mirror? >> >>> On 28 Nov 2016, at 19:33, Christophe Fontaine >> <[email protected]> wrote: >>> >>> Hi, >>> >>> I do have a span 1-N working patch, but I also do have some bugs on >>> the frame allocation (I think). >>> >>> I was able to reproduce the same bugs with the 1-1 span node (ie >>> without any patch on my side). >>> >>> Setup: >>> >>> vpp# create sub-interface GigabitEthernet8/0/0 442 vpp# set int span >>> GigabitEthernet8/0/0 destination GigabitEthernet8/0/0.442 vpp# set int >>> state GigabitEthernet8/0/0 up vpp# set int state >>> GigabitEthernet8/0/0.442 up >>> >>> >>> From there, I send some packets with scapy (and I receive the copy on >>> the appropriate VLAN ) scapy # while True: >>> sendp(Ether(dst='00:1b:21:6f:27:b6')/IP(dst='255.255.255.255')/ICMP(), >>> iface='enp1s0f0', count=200) >>> >>> >>> Not so many packets at once, but that's enough to have 2 asserts which >>> raised, whithout being deterministic (backtraces below) >>> - VLIB_FRAME_IS_ALLOCATED >>> - VLIB_FRAME_PENDING >>> >>> My vpp configuration file is the following: >>> heapsize 2G >>> cpu { >>> main-core 0 >>> corelist-workers 3,7 >>> } >>> >>> dpdk { >>> socket-mem 1024 >>> uio-driver uio_pci_generic >>> dev 0000:08:00.0 >>> } >>> >>> >>> Where can I dig a bit more and resolve these bugs ? >>> Thanks, >>> Christophe >>> >>> >>> #0 0x00007ffff51945f7 in __GI_raise (sig=sig@entry=6) at >>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >>> #1 0x00007ffff5195ce8 in __GI_abort () at abort.c:90 >>> #2 0x0000000000c2c135 in os_panic () at >>> /root/vpp/build-data/../vpp/vnet/main.c:314 >>> #3 0x00007ffff605a984 in debugger () at >>> /root/vpp/build-data/../vppinfra/vppinfra/error.c:84 >>> #4 0x00007ffff605ad8b in _clib_error (how_to_die=2, >>> function_name=0x0, line_number=0, fmt=0x7ffff7542160 "%s:%d (%s) >>> assertion `%s' fails") at >>> /root/vpp/build-data/../vppinfra/vppinfra/error.c:143 >>> #5 0x00007ffff74e949a in vlib_get_frame (vm=0x1244c80 >>> <vlib_global_main>, frame_index=20599040) at >>> /root/vpp/build-data/../vlib/vlib/node_funcs.h:226 >>> #6 0x00007ffff74ecfa8 in dispatch_pending_node (vm=0x1244c80 >>> <vlib_global_main>, p=0x7fff762cf118, >>> last_time_stamp=25415901095678999) >>> at /root/vpp/build-data/../vlib/vlib/main.c:1099 >>> #7 0x00007ffff74ef0ff in vlib_main_loop (vm=0x1244c80 >>> <vlib_global_main>) at /root/vpp/build-data/../vlib/vlib/main.c:1543 >>> #8 0x00007ffff74ef77d in vlib_main (vm=0x1244c80 <vlib_global_main>, >>> input=0x7fff75149fb0) at /root/vpp/build-data/../vlib/vlib/main.c:1678 >>> #9 0x00007ffff7780b0c in thread0 (arg=19156096) at >>> /root/vpp/build-data/../vlib/vlib/unix/main.c:485 >>> #10 0x00007ffff607ec30 in clib_calljmp () at >>> /root/vpp/build-data/../vppinfra/vppinfra/longjmp.S:110 >>> #11 0x00007fffffffcec0 in ?? () >>> #12 0x00007ffff7780f6c in vlib_unix_main (argc=41, >>> argv=0x7fffffffe178) at >>> /root/vpp/build-data/../vlib/vlib/unix/main.c:545 >>> #13 0x0000000000c2be16 in main (argc=41, argv=0x7fffffffe178) at >>> /root/vpp/build-data/../vpp/vnet/main.c:255 >>> >>> >>> frame 5: >>> >>> #5 0x00007ffff74e949a in vlib_get_frame (vm=0x1244c80 >>> <vlib_global_main>, frame_index=20599040) at >>> /root/vpp/build-data/../vlib/vlib/node_funcs.h:226 >>> 226 ASSERT (f->flags & VLIB_FRAME_IS_ALLOCATED); >>> >>> >>> >>> >>> >>> And here is the other one: >>> >>> (gdb) bt >>> #0 0x00007ffff51945f7 in __GI_raise (sig=sig@entry=6) at >>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >>> #1 0x00007ffff5195ce8 in __GI_abort () at abort.c:90 >>> #2 0x0000000000c2c135 in os_panic () at >>> /root/vpp/build-data/../vpp/vnet/main.c:314 >>> #3 0x00007ffff605a984 in debugger () at >>> /root/vpp/build-data/../vppinfra/vppinfra/error.c:84 >>> #4 0x00007ffff605ad8b in _clib_error (how_to_die=2, >>> function_name=0x0, line_number=0, fmt=0x7ffff7542160 "%s:%d (%s) >>> assertion `%s' fails") at >>> /root/vpp/build-data/../vppinfra/vppinfra/error.c:143 >>> #5 0x00007ffff74ed174 in dispatch_pending_node (vm=0x1244c80 >>> <vlib_global_main>, p=0x7fff762c9470, >>> last_time_stamp=25416170327760415) >>> at /root/vpp/build-data/../vlib/vlib/main.c:1124 >>> #6 0x00007ffff74ef0ff in vlib_main_loop (vm=0x1244c80 >>> <vlib_global_main>) at /root/vpp/build-data/../vlib/vlib/main.c:1543 >>> #7 0x00007ffff74ef77d in vlib_main (vm=0x1244c80 <vlib_global_main>, >>> input=0x7fff75149fb0) at /root/vpp/build-data/../vlib/vlib/main.c:1678 >>> #8 0x00007ffff7780b0c in thread0 (arg=19156096) at >>> /root/vpp/build-data/../vlib/vlib/unix/main.c:485 >>> #9 0x00007ffff607ec30 in clib_calljmp () at >>> /root/vpp/build-data/../vppinfra/vppinfra/longjmp.S:110 >>> #10 0x00007fffffffcec0 in ?? () >>> #11 0x00007ffff7780f6c in vlib_unix_main (argc=41, >>> argv=0x7fffffffe178) at >>> /root/vpp/build-data/../vlib/vlib/unix/main.c:545 >>> #12 0x0000000000c2be16 in main (argc=41, argv=0x7fffffffe178) at >>> /root/vpp/build-data/../vpp/vnet/main.c:255 >>> >>> >>> #5 0x00007ffff74ed174 in dispatch_pending_node (vm=0x1244c80 >>> <vlib_global_main>, p=0x7fff762c9470, >>> last_time_stamp=25416170327760415) >>> at /root/vpp/build-data/../vlib/vlib/main.c:1124 >>> 1124 ASSERT (f->flags & VLIB_FRAME_PENDING); >>> >>> >>> >>> >>> >>> >>> >>> On 11/25/2016 02:21 PM, Christophe FONTAINE wrote: >>>> Yes, I think so. >>>> I'll give it a try and modify the span node. >>>> >>>> Christophe >>>> >>>> PS: I have modified the l2patch feature to also support the connection on >> the tx side, if anyone is interested, I can submit it. >>>> >>>> Here is the journey of a packet sent with scapy on the vlan 442, >>>> getting flooded on the 1st bd, sent to the other bd, and Sent back >>>> with the appropriate vlan (443) >>>> >>>> >>>> 00:19:55:173391: dpdk-input >>>> GigabitEthernet8/0/0 rx queue 0 >>>> buffer 0x5727: current data 0, length 60, free-list 0, totlen-nifb 0, >>>> trace >> 0x60 >>>> PKT MBUF: port 0, nb_segs 1, pkt_len 60 >>>> buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr >> 0xfd721fc0 >>>> packet_type 0x0 >>>> ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 442 >>>> request, type ethernet/IP4, address size 6/4 >>>> 78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0 >>>> 00:19:55:173394: ethernet-input >>>> ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 442 >>>> 00:19:55:173398: l2-input >>>> l2-input: sw_if_index 2 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00 >>>> 00:19:55:173400: l2-input-vtr >>>> l2-input-vtr: sw_if_index 2 dst 28:94:0f:fe:00:40 src >>>> 00:00:00:00:00:00 data 08 06 00 01 08 00 06 04 00 01 78 24 >>>> 00:19:55:173401: l2-flood >>>> l2-flood: sw_if_index 2 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00 >>>> bd_index 1 >>>> 00:19:55:173403: l2-output >>>> l2-output: sw_if_index 4 dst 28:94:0f:fe:00:40 src >>>> 00:00:00:00:00:00 >>>> 00:19:55:173404: l2-patch >>>> L2_PATCH: rx 2 tx 5 >>>> 00:19:55:173405: loop1-output >>>> loop1 >>>> ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 >>>> request, type ethernet/IP4, address size 6/4 >>>> 78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0 >>>> 00:19:55:173410: ethernet-input >>>> ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 >>>> 00:19:55:173411: l2-input >>>> l2-input: sw_if_index 5 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00 >>>> 00:19:55:173413: l2-flood >>>> l2-flood: sw_if_index 5 dst 28:94:0f:fe:00:40 src 00:00:00:00:00:00 >>>> bd_index 2 >>>> 00:19:55:173414: l2-output >>>> l2-output: sw_if_index 3 dst 28:94:0f:fe:00:40 src >>>> 00:00:00:00:00:00 >>>> 00:19:55:173415: GigabitEthernet8/0/0-output >>>> GigabitEthernet8/0/0.443 >>>> ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 443 >>>> request, type ethernet/IP4, address size 6/4 >>>> 78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0 >>>> 00:19:55:173416: GigabitEthernet8/0/0-tx >>>> GigabitEthernet8/0/0 tx queue 1 >>>> buffer 0x5727: current data 0, length 60, free-list 0, totlen-nifb 0, >>>> trace >> 0x60 >>>> ARP: 00:00:00:00:00:00 -> 28:94:0f:fe:00:40 802.1q vlan 443 >>>> request, type ethernet/IP4, address size 6/4 >>>> 78:24:af:a1:37:8d/10.10.2.31 -> 00:00:00:00:00:00/0.0.0.0 >>>> >>>>> -----Original Message----- >>>>> From: Damjan Marion [mailto:[email protected]] >>>>> Sent: vendredi 25 novembre 2016 14:12 >>>>> To: Christophe FONTAINE <[email protected]> >>>>> Cc: [email protected] >>>>> Subject: Re: [vpp-dev] How to transfer packets between 2 bridge >> domains ? >>>>> >>>>> >>>>> Is this something which can be solved simply by telling to span node >>>>> to have multiple destination interfaces? >>>>> >>>>>> On 24 Nov 2016, at 20:22, Christophe FONTAINE >>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I’m working on Tap as a Service feature for OpenStack [1], and I >>>>>> hope I just >>>>> don’t know how to configure VPP to transfer packets between 2 bridge >>>>> domains. >>>>>> The global setup follows the blueprint [2], but basically, here is >>>>>> what I have >>>>> : >>>>>> >>>>>> VhostUser0/0/1 >>>>>> | >>>>>> span >>>>>> | >>>>>> loop0 loop1 >>>>>> | | >>>>>> [BD-A] === [BD-B]--VhostUser0/0/2 >>>>>> | >>>>>> Gigabit/0/0/1.3901 >>>>>> >>>>>> Booth bridge domains are configured to flood the traffic. >>>>>> This 2 bridge domain setup is required to be able to have the >>>>>> traffic from1 >>>>> spanned interface (named tap-flow) copied to multiple destination >>>>> (named tap-service), as well as multiple tap-flows to a single >>>>> tap-service. >>>>>> >>>>>> The problem I have is that I can't use 2 loopback interfaces with a >>>>>> cross >>>>> connect because the xconnect feature: >>>>>> - is tied to the device-input feature mask: when incoming packets >>>>>> are flooded by the bridge, the packets are sent to interface-out, >>>>>> and to not go thru the rx path >>>>>> - as it is tied to the device-input feature mask, we can't have >>>>>> xconnect AND >>>>> bridge features enabled at the same time. >>>>>> Same problem with the l2patch. >>>>>> >>>>>> I tried different things, such as using the input and output >>>>>> classifiers to >>>>> redirect packets to the appropriate interface-out (eg: loop2-tx >>>>> )nodes, using the same vhost user socket as client and server to >>>>> loopback the traffic from 2 bridge domains, using 2 sub-interfaces >>>>> from a loopback interface to transfer the packets from 1 bd to the >>>>> other, but I think I'm missing something important ! >>>>>> The only way I got this working was by using an external veth pair, >>>>>> each end >>>>> connected to 1 bd... not a real solution for me. >>>>>> >>>>>> I thought I could write an 'xconnect-tx node' to be able to >>>>>> transfer the >>>>> packets (this node would be like the output classifier ), but I >>>>> wanted first to know whether this is the only solution. >>>>>> >>>>>> Many thanks ! >>>>>> Christophe >>>>>> >>>>>> [1] https://github.com/christophefontaine/tap-as-a-service >>>>>> [2] >>>>>> https://wiki.openstack.org/wiki/Blueprint-networking-vpp-taas#Possi >>>>>> ble >>>>>> _implementations >>> This message and any attachments (the "message") are confidential, >> intended solely for the addressees. If you are not the intended recipient, >> please notify the sender immediately by e-mail and delete this message >> from your system. In this case, you are not authorized to use, copy this >> message and/or disclose the content to any other person. E-mails are >> susceptible to alteration. Neither Qosmos nor any of its subsidiaries or >> affiliates shall be liable for the message if altered, changed or falsified. >>> >>> Ce message et toutes ses pièces jointes (ci-après le "message")sont >> confidentiels et établis à l'intention exclusive de ses destinataires. Si >> vous >> avez reçu ce message par erreur, merci d’en informer immédiatement son >> émetteur par courrier électronique et d’effacer ce message de votre >> système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce >> message et/ou en divulguer le contenu à un tiers. Tout message >> électronique est susceptible d'altération. Qosmos et ses filiales déclinent >> toute responsabilité au titre de ce message s'il a été altéré, déformé ou >> falsifié. > > This message and any attachments (the "message") are confidential, intended > solely for the addressees. If you are not the intended recipient, please > notify the sender immediately by e-mail and delete this message from your > system. In this case, you are not authorized to use, copy this message and/or > disclose the content to any other person. E-mails are susceptible to > alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be > liable for the message if altered, changed or falsified. > > Ce message et toutes ses pièces jointes (ci-après le "message")sont > confidentiels et établis à l'intention exclusive de ses destinataires. Si > vous avez reçu ce message par erreur, merci d’en informer immédiatement son > émetteur par courrier électronique et d’effacer ce message de votre système. > Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message > et/ou en divulguer le contenu à un tiers. Tout message électronique est > susceptible d'altération. Qosmos et ses filiales déclinent toute > responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.
_______________________________________________ vpp-dev mailing list [email protected] https://lists.fd.io/mailman/listinfo/vpp-dev
