Neale,

I could not find scapy installed in the normal path (i.e. "which scapy"), but I'm not sure if it is directly executable. You can find the "V=1 TEST=mpls make test" output on vagrant+virtualbox:puppetlabs/ubuntu-16.04.64-nocm in this pastebin doc: http://pastebin.com/uGAUREhK

Thanks,
-daw-


On 1/4/2017 10:59 AM, Neale Ranns (nranns) wrote:

Hi,

The reason the MPLS tests are failing is because scapy cannot decode an MPLS label stack (output from some .show() instrumentation);

<class 'scapy.layers.l2.Ether'>

###[ Ethernet ]###

  dst = 02:01:00:00:ff:02

src       = 02:fe:e5:05:0e:13

type      = 0x8847

###[ MPLS ]###

     label = 33L

cos       = 0L

s         = 0L       <<<<<< NON End-of-stack

ttl       = 254

###[ Padding ]###

load = '\x00\x061\xffE\x00\x00#\x00\x01\x00\x00@\x11 \xa6\xac\x10\x01\x01\xac\x10\x01\x02\x04\xd2\x04\xd2\x00\x0f\xd0\x92257 1 1'

we patch scapy for this purpose, see;

<ROOT>/test/patches/scapy-2.3.3/mpls.py.patch

on my vagrant 14.04 there is no other scapy installation, this patch applies fine and all MPLS tests pass.

On a UCS 14.04, with another scapy installation:

/usr/local/lib/python2.7/dist-packages/scapy/contrib/mpls.py

the MPLS test fail.

On a UCS 16.04 no scpay installation, tests pass.

Do you have scapy installed in the machines on which the tests fail/pass? Or am I barking up the wrong virtualenv tree J

Thanks,

neale

    *From: *Dave Wallace <dwallac...@gmail.com>
    *Date: *Wednesday, 4 January 2017 at 15:38
    *To: *"Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at
    Cisco)" <ksek...@cisco.com>, "Maciek Konstantynowicz (mkonstan)"
    <mkons...@cisco.com>, "Neale Ranns (nranns)" <nra...@cisco.com>
    *Cc: *"csit-...@lists.fd.io" <csit-...@lists.fd.io>,
    "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
    *Subject: *Re: [csit-dev] [vpp-dev] vpp make test for verify - are
    we there yet ? [awoken]

    Klement,

    I'm in the process of modifying the base Vagrantfile/build scripts
    to replace building the VPP native package and installing it in
the VM to simply running "make test" which takes much less time. All of the test runs that I have performed are clean builds on a
    virgin git clone repo.

    That being said, I'll give the "git clean -dfX */" a try and see
    if I get different results on the 2nd pass and report back.

    Thanks,
    -daw-

    On 1/4/17 10:23 AM, Klement Sekera -X (ksekera - PANTHEON
    TECHNOLOGIES at Cisco) wrote:

        Hi Dave,

        could you please try running git clean -dfX */ in a workspace, where 
you see

        the failures, and then givet it another try? For me this seems to clear 
issues

        up. Damjans recent changes might have caused (quoting Damjan) "major

        disturbances in the force", leaving build artifacts behind.

        Just be sure to stash/commit any changes you have in the workspace since

        the git clean nukes everything unknown from the ws.

        Thanks,

        Klement

        Quoting Dave Wallace (2017-01-04 16:12:38)

                As I mentioned on the VPP call yesterday, I'm seeing what 
appears to be

                the same GRE test failures on Ubuntu 16.10 (bare metal).  I'm 
also seeing

                the same failures on vagrant+virtualbox with

                puppetlabs/ubuntu-16.04.64-nocm. I also am getting failures on 
3 out of 4

                MPLS tests on both environments.

                However, all tests pass on vagrant+virtualbox with

                puppetlabs/ubuntu-14.04.64-nocm.

                Thanks,

                -daw-

                On 1/4/17 9:47 AM, Maciek Konstantynowicz (mkonstan) wrote:

              baremetal trusty:

              $ lsb_release -a

              No LSB modules are available.

              Distributor ID: Ubuntu

              Description:    Ubuntu 14.04.4 LTS

              Release:    14.04

              Codename:   trusty

              $ uname -a

              Linux homes1 3.16.0-77-generic #99~14.04.1-Ubuntu SMP Tue Jun 28 
19:17:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

              -Maciek

              On 4 Jan 2017, at 13:42, Neale Ranns (nranns) [1]<nra...@cisco.com> 
<mailto:nra...@cisco.com>  wrote:

              Hi Klement, Maciek,

              What environment are you running the tests in?

              I get different results. Running in the default vagrant env 
provided in 17.0. Everything passes apart from:

              
======================================================================

              Bidirectional Forwarding Detection (BFD)

              
======================================================================

              verify session goes down after inactivity                   OK

              hold BFD session up                                         OK

              large remote RequiredMinRxInterval                          ERROR 
[ temp dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ]

              bring BFD session up                                        ERROR 
[ temp dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ]

              verify slow periodic control frames while session down      ERROR 
[ temp dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ]

              no packets when zero BFD RemoteMinRxInterval                ERROR 
[ temp dir used by test case: /tmp/vpp-unittest-BFDTestCase-F7O6hZ ]

              details below. Different runs give different combinations of 
failures from this BFD list.

              /neale

              
=====================================================================

              ERROR: large remote RequiredMinRxInterval

              
----------------------------------------------------------------------

              Traceback (most recent call last):

               File "/vpp/test/test_bfd.py", line 257, in 
test_large_required_min_rx

                 self.bfd_session_up()

               File "/vpp/test/test_bfd.py", line 219, in bfd_session_up

                 p = self.wait_for_bfd_packet()

               File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet

                 p = self.pg0.wait_for_packet(timeout=timeout)

               File "/vpp/test/vpp_pg_interface.py", line 217, in 
wait_for_packet

                 self.wait_for_capture_file(timeout)

               File "/vpp/test/vpp_pg_interface.py", line 204, in 
wait_for_capture_file

                 raise Exception("Capture file did not appear within timeout")

              Exception: Capture file did not appear within timeout

              
======================================================================

              ERROR: bring BFD session up

              
----------------------------------------------------------------------

              Traceback (most recent call last):

               File "/vpp/test/test_bfd.py", line 234, in test_session_up

                 self.bfd_session_up()

               File "/vpp/test/test_bfd.py", line 219, in bfd_session_up

                 p = self.wait_for_bfd_packet()

               File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet

                 p = self.pg0.wait_for_packet(timeout=timeout)

               File "/vpp/test/vpp_pg_interface.py", line 217, in 
wait_for_packet

                 self.wait_for_capture_file(timeout)

               File "/vpp/test/vpp_pg_interface.py", line 204, in 
wait_for_capture_file

                 raise Exception("Capture file did not appear within timeout")

              Exception: Capture file did not appear within timeout

              
======================================================================

              ERROR: verify slow periodic control frames while session down

              
----------------------------------------------------------------------

              Traceback (most recent call last):

               File "/vpp/test/test_bfd.py", line 187, in test_slow_timer

                 self.wait_for_bfd_packet()

               File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet

                 p = self.pg0.wait_for_packet(timeout=timeout)

               File "/vpp/test/vpp_pg_interface.py", line 217, in 
wait_for_packet

                 self.wait_for_capture_file(timeout)

               File "/vpp/test/vpp_pg_interface.py", line 204, in 
wait_for_capture_file

                 raise Exception("Capture file did not appear within timeout")

              Exception: Capture file did not appear within timeout

              
======================================================================

              ERROR: no packets when zero BFD RemoteMinRxInterval

              
----------------------------------------------------------------------

              Traceback (most recent call last):

               File "/vpp/test/test_bfd.py", line 201, in 
test_zero_remote_min_rx

                 p = self.wait_for_bfd_packet()

               File "/vpp/test/test_bfd.py", line 171, in wait_for_bfd_packet

                 p = self.pg0.wait_for_packet(timeout=timeout)

               File "/vpp/test/vpp_pg_interface.py", line 217, in 
wait_for_packet

                 self.wait_for_capture_file(timeout)

               File "/vpp/test/vpp_pg_interface.py", line 204, in 
wait_for_capture_file

                 raise Exception("Capture file did not appear within timeout")

              Exception: Capture file did not appear within timeout

              Ran 64 tests in 84.161s

              On 04/01/2017, 09:45, [2]"csit-dev-boun...@lists.fd.io on behalf 
of Klement Sekera
            -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)"
            
<mailto:csit-dev-boun...@lists.fd.ioonbehalfofKlementSekera-X%28ksekera-PANTHEONTECHNOLOGIESatCisco%29>
  [3]<csit-dev-boun...@lists.fd.io on behalf of
            ksek...@cisco.com>
            <mailto:csit-dev-boun...@lists.fd.ioonbehalfofksek...@cisco.com>  
wrote:

                 I tried doing a git checkout origin/stable/1701 - is that the 
correct

                 branch? On that one, the GRE indeed doesn't work, but I don't 
think it's

                 'make test' issue, here's a sample from packet trace:

                 ------------------- Start of thread 0 vpp_main 
-------------------

                 Packet 1

                 00:00:07:119382: pg-input

                   stream pcap1, 88 bytes

                   current data 0, length 88, free-list 6, trace 0x0

                   IP4: 02:01:00:00:ff:02 -> 02:fe:39:17:74:65

                   GRE: 2.2.2.2 -> 172.16.1.1

                     tos 0x00, ttl 64, length 74, checksum 0xc96f

                     fragment id 0x0001

                   GRE 0x0001

                 00:00:07:119802: ethernet-input

                   IP4: 02:01:00:00:ff:02 -> 02:fe:39:17:74:65

                 00:00:07:120048: ip4-input

                   GRE: 2.2.2.2 -> 172.16.1.1

                     tos 0x00, ttl 64, length 74, checksum 0xc96f

                     fragment id 0x0001

                   GRE 0x0001

                 00:00:07:120113: ip4-lookup

                   fib 0 dpo-idx 5 flow hash: 0x00000000

                   GRE: 2.2.2.2 -> 172.16.1.1

                     tos 0x00, ttl 64, length 74, checksum 0xc96f

                     fragment id 0x0001

                   GRE 0x0001

                 00:00:07:120404: ip4-local

                     GRE: 2.2.2.2 -> 172.16.1.1

                       tos 0x00, ttl 64, length 74, checksum 0xc96f

                       fragment id 0x0001

                     GRE 0x0001

                 00:00:07:120495: gre-input

                   GRE: tunnel 0 len 74 src 2.2.2.2 dst 172.16.1.1

                 00:00:07:120543: error-drop

                   gre-input: unknown protocol

                 all 50 packets printed in the packet trace share the same 
fate...

                 Thanks,

                 Klement

                 Quoting Maciek Konstantynowicz (mkonstan) (2017-01-03 18:46:19)

                // Typed this email before the live discussion on vpp call just 
now -

                still sending it out :)

                Hello, After the previous ver of this thread went into a frenzy 
of emails

                and fixes in vpp make test code,

                I wanted to re-check the situation.

                And as it is a New Year, I’m not lazy anymore, and did run make 
test in

                both vpp branches :)

                vpp master branch works, stable/1701 does not..

                1. master

                    Ran 65 tests in 90.838s

                    OK (skipped=5)

                    make[1]: Leaving directory `/home/maciek/src/vpp2/test'

                2. stable/1701

                  
======================================================================

                  ERROR: GRE tunnel Tests

                  Exception: Capture file did not appear within timeout

                  
======================================================================

                  ERROR: GRE tunnel L2 Tests

                  Exception: Capture file did not appear within timeout

                  
======================================================================

                  ERROR: MPLS Local Label Binding test

                  AttributeError: label

                  
======================================================================

                  ERROR: MPLS label imposition test

                  IndexError: Layer [IP] not found

                  
======================================================================

                  ERROR: MPLS label swap tests

                  AttributeError: label

                  
======================================================================

                  ERROR: MPLS Tunnel Tests

                  
----------------------------------------------------------------------

                  IndexError: Layer [IP] not found

                  Ran 64 tests in 59.980s

                  FAILED (errors=6, skipped=5)

                  make[1]: *** [test] Error 1

                  make[1]: Leaving directory `/home/maciek/src/vpp2/test'

                  make: *** [test] Error 2

                Fix?

                -Maciek

                  On 12 Dec 2016, at 16:19, Maciek Konstantynowicz (mkonstan)

                  [4]<[1]mkons...@cisco.com> <mailto:[1]mkons...@cisco.com>  
wrote:

                  Hello, Does anyone know if vpp make test is back on track to 
be ready to

                  be used for vpp make verify jobs on a per patch basis?

                  Being lazy I know - cause I could run it myself :)

                  -Maciek

              References

                Visible links

                1. [5]mailto:mkons...@cisco.com

                 _______________________________________________

                 csit-dev mailing list

                 [6]csit-...@lists.fd.io <mailto:6]csit-...@lists.fd.io>

                 [7]https://lists.fd.io/mailman/listinfo/csit-dev

              _______________________________________________

              csit-dev mailing list

              [8]csit-...@lists.fd.io <mailto:8]csit-...@lists.fd.io>

              [9]https://lists.fd.io/mailman/listinfo/csit-dev

            References

                Visible links

                1.mailto:nra...@cisco.com

                
2.mailto:csit-dev-boun...@lists.fd.ioonbehalfofklementsekera-x(ksekera-pantheontechnologiesatcisco)
            
<mailto:csit-dev-boun...@lists.fd.ioonbehalfofklementsekera-x%28ksekera-pantheontechnologiesatcisco%29>

                3.mailto:csit-dev-boun...@lists.fd.ioonbehalfofksek...@cisco.com

                4. mailto:[1]mkons...@cisco.com <mailto:1]mkons...@cisco.com>

                5.mailto:mkons...@cisco.com

                6.mailto:csit-...@lists.fd.io

                7.https://lists.fd.io/mailman/listinfo/csit-dev

                8.mailto:csit-...@lists.fd.io

                9.https://lists.fd.io/mailman/listinfo/csit-dev


_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
        • ... Ed Warnicke
          • ... Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
  • Re: [vpp-dev]... Maciek Konstantynowicz (mkonstan)
    • Re: [vpp... Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
      • Re: ... Neale Ranns (nranns)
        • ... Maciek Konstantynowicz (mkonstan)
          • ... Dave Wallace
            • ... Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
              • ... Dave Wallace
              • ... Neale Ranns (nranns)
              • ... Dave Wallace
              • ... Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
              • ... Dave Wallace
              • ... Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
              • ... Neale Ranns (nranns)
              • ... Neale Ranns (nranns)
              • ... Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
              • ... Neale Ranns (nranns)
              • ... Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
          • ... Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
    • Re: [vpp... Andrew 👽 Yourtchenko

Reply via email to