date:20181129

[vpp-dev] Question regarding captive portal

2018-11-29 Thread carlito nueno

Hi all,

GigabitEthernet4/0/0 = LAN interface - 192.168.1.1
Tap1 = tap interface - 192.168.1.2
Clients connected to LAN interface - 192.168.1.100 - 200

GigabitEthernet5/0/0 = WAN interface

I want to redirect any traffic (tcp or udp) from clients
(192.168.1.100 - 200) to a server running locally on the tap1
interface (192.168.1.2:80). This local server is a captive portal
server.

Example:
Client visits google.com in a browser
Instead of the browser showing google.com, it is shown 192.168.1.2:80/index.html

How do I accomplish this?

I came across ip punt redirect, but I am not familiar with it.

Thanks for the help.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11466): https://lists.fd.io/g/vpp-dev/message/11466
Mute This Topic: https://lists.fd.io/mt/28506160/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] question about multicast mpls

2018-11-29 Thread xyxue

Hi Neale，

Is there any cli configuration examples about multicast mpls ? 

Thanks,
Xue

From: Neale Ranns via Lists.Fd.Io
Date: 2018-11-28 20:59
To: 薛欣颖; vpp-dev
CC: vpp-dev
Subject: Re: [vpp-dev] question about multicast mpls
Hi Xue,

MPLS multicast has been supported for a while. Please see the unit tests for 
examples: test/test_mpls.py test_mcast_*()

Regards,
Neale

De :  au nom de xyxue 
Date : mercredi 28 novembre 2018 à 13:04
À : vpp-dev 
Objet : [vpp-dev] question about multicast mpls

Hi guys,

I found "multicast" in the mpls cli. Is the vpp support multicast mpls now ?
Is there any example show about multicast mpls?

Thank you very much for your reply.

Thanks,
Xue

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11465): https://lists.fd.io/g/vpp-dev/message/11465
Mute This Topic: https://lists.fd.io/mt/28430049/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Build failing on AArch64

2018-11-29 Thread Sirshak Das

I am yet to try. Will do so and update.

Get Outlook for iOS


From: Juraj Linkeš 
Sent: Thursday, November 29, 2018 7:48 PM
To: Ole Troan; Sirshak Das
Cc: vpp-dev@lists.fd.io; Honnappa Nagarahalli; Lijian Zhang (Arm Technology 
China)
Subject: RE: [vpp-dev] Build failing on AArch64

Hi Ole,

I tried it and it does solve the issue, thanks!

Sirshak, does it work for you too?

Juraj

From: Ole Troan [mailto:otr...@employees.org]
Sent: Wednesday, November 28, 2018 9:25 AM
To: Sirshak Das 
Cc: Juraj Linkeš ; vpp-dev@lists.fd.io; Honnappa 
Nagarahalli ; Lijian Zhang (Arm Technology China) 

Subject: Re: [vpp-dev] Build failing on AArch64

Sirshak,

Can you try adding:

DEPENDS api_headers

Inside
add_vpp_executable(vpp_api_test ENABLE_EXPORTS

in src/vat/CMakeLists.txt

Cheers,
Ole

> On 28 Nov 2018, at 06:32, Sirshak Das 
> mailto:sirshak@arm.com>> wrote:
>
> It takes 3 iterations to get to a proper build:
>
> First Iteration:
>
> FAILED: vat/CMakeFiles/vpp_api_test.dir/types.c.o
> ccache /usr/lib/ccache/cc -DHAVE_MEMFD_CREATE -Dvpp_api_test_EXPORTS 
> -I/home/sirdas/code/commitc/vpp/src -I. -Iinclude -march=armv8-a+crc -g -O2 
> -DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Werror   
> -Wno-address-of-packed-member -pthread -MD -MT 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o -MF 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o.d -o 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o   -c 
> /home/sirdas/code/commitc/vpp/src/vat/types.c
> In file included from 
> /home/sirdas/code/commitc/vpp/src/vpp/api/vpe_all_api_h.h:25,
>from /home/sirdas/code/commitc/vpp/src/vpp/api/types.h:20,
>from /home/sirdas/code/commitc/vpp/src/vat/types.c:19:
> /home/sirdas/code/commitc/vpp/src/vnet/vnet_all_api_h.h:32:10: fatal error: 
> vnet/bonding/bond.api.h: No such file or directory
> #include 
> ^
>
> Second Iteration:
>
> FAILED: vat/CMakeFiles/vpp_api_test.dir/types.c.o
> ccache /usr/lib/ccache/cc -DHAVE_MEMFD_CREATE -Dvpp_api_test_EXPORTS 
> -I/home/sirdas/code/commitc/vpp/src -I. -Iinclude -march=armv8-a+crc -g -O2 
> -DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Werror   
> -Wno-address-of-packed-member -pthread -MD -MT 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o -MF 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o.d -o 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o   -c 
> /home/sirdas/code/commitc/vpp/src/vat/types.c
> In file included from /home/sirdas/code/commitc/vpp/src/vpp/api/types.h:20,
>from /home/sirdas/code/commitc/vpp/src/vat/types.c:19:
> /home/sirdas/code/commitc/vpp/src/vpp/api/vpe_all_api_h.h:32:10: fatal error: 
> vpp/stats/stats.api.h: No such file or directory
> #include 
> ^~~
> compilation terminated.
> [142/1163] Building C object vat/CMakeFiles/vpp_api_test.dir/api_format.c.o^C
> ninja: build stopped: interrupted by user.
> Makefile:691: recipe for target 'vpp-build' failed
> make[1]: *** [vpp-build] Interrupt
> Makefile:366: recipe for target 'build-release' failed
> make: *** [build-release] Interrupt
>
> Had to kill as it was stuck.
>
> Third Interation:
>
> Finally it got built properly.
>
> This is a manageble error for dev purposes but will give lot false
> negatives for CI.
> Anyone familiar with VAT please help.
>
>
> Thank you
> Sirshak Das
>
> Ole Troan writes:
>
>> Juraj,
>>
>> Seems like a dependency problem. VAT depends on a generated file that hasn’t 
>> been generated yet.
>>
>> Ole
>>
>>> On 27 Nov 2018, at 18:04, Juraj Linkeš 
>>> mailto:juraj.lin...@pantheon.tech>> wrote:
>>>
>>> Hi Ole,
>>>
>>>  I'm hitting the same issue.
>>>
>>>  Running the build with V=2 doesn't actually produce more 
>>> output.
>>>
>>> Which means my logs are the same as Sirshak's. But in any case I attached 
>>> the output from a run with V=2.
>>>
>>> I can provide other info if there's more you need - or you can try 
>>> accessing one of our ThunderX's in the FD.io lab if you have access.
>>>
>>> Thanks,
>>> Juraj
>>>
>>> From: Ole Troan [mailto:otr...@employees.org]
>>> Sent: Tuesday, November 27, 2018 5:43 PM
>>> To: Juraj Linkeš 
>>> mailto:juraj.lin...@pantheon.tech>>
>>> Cc: Sirshak Das mailto:sirshak@arm.com>>; 
>>> vpp-dev@lists.fd.io; Honnappa Nagarahalli 
>>> mailto:honnappa.nagaraha...@arm.com>>; Lijian 
>>> Zhang (Arm Technology China) 
>>> mailto:lijian.zh...@arm.com>>
>>> Subject: Re: [vpp-dev] Build failing on AArch64
>>>
>>> Juraj,
>>>
>>> Without a make log this is just a guessing game.
>>>
>>> Cheers
>>> Ole
>>>
>>> On 27 Nov 2018, at 17:34, Juraj Linkeš 
>>> mailto:juraj.lin...@pantheon.tech>> wrote:
>>>
>>> Hi Sirshak and Ole,
>>>
>>> I'm hitting the same issue. The build fails on a clean repository, but the 
>>> subsequent build works fine, which is fine for local builds, but still 
>>> needs to be fixed.
>>>
>>> Running the build with V=2 doesn't actually produce more output.

Re: [vpp-dev] Verify issues (GRE)

2018-11-29 Thread Florin Coras

Hi Juraj, 

Those tests exercise the stack in vpp, so they don’t use up linux stack ports. 
Moreover, both cut-through and through-the-stack tests use self.shm_prefix when 
connecting to vpp’s binary api. So, as long as that variable is properly 
updated, VCL and implicitly LDP will attach and use ports on the right vpp 
instance. 

As for sock_test_client/server not being properly killed, did you find 
something in the logs that would indicate why it happened? 

Florin

> On Nov 29, 2018, at 3:18 AM, Juraj Linkeš  wrote:
> 
> Hi Ole,
>  
> I've noticed a few thing about the VCL testcases:
> -The VCL testcasess are all using the same ports, which makes them 
> unsuitable for parallel test runs
> -Another thing about these testcases is that when they're don't 
> finish properly the sock_test_server and client stay running as zombie 
> processes (and thus use up ports). It's easily reproducible locally by 
> interrupting the tests, but I'm not sure whether this could actually arise in 
> CI
> -Which means that if one testcase finishes improperly (e.g. is killed 
> because of a timeout) all of the other VCL testcases will likely also fail
>  
> Hope this helps if there's anyone looking into those tests,
> Juraj
>  
> From: Ole Troan [mailto:otr...@employees.org ] 
> Sent: Wednesday, November 28, 2018 7:56 PM
> To: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: [vpp-dev] Verify issues (GRE)
>  
> Guys,
> 
> The verify job have been unstable over the last few days.
> We see some instability in the Jenkins build system, in the test harness 
> itself, and in the tests.
> On my 18.04 machine I’m seeing intermittent failures in GRE, GBP, DHCP, VCL.
> 
> It looks like Jenkins is functioning correctly now.
> Ed and I are also testing a revert of all the changes made to the test 
> framework itself over the last couple of days. A bit harsh, but we think this 
> might be the quickest way back to some level of stability.
> 
> Then we need to fix the tests that are in themselves unstable.
> 
> Any volunteers to see if they can figure out why GRE fails?
> 
> Cheers,
> Ole
> 
> 
> GRE Test Case 
> ==
> GRE IPv4 tunnel TestsOK
> GRE IPv6 tunnel TestsOK
> GRE tunnel L2 Tests  OK
> 19:37:47,505 Unexpected packets captured:
> Packet #0:
>   0201FF0202FE70A06AD308004500 p.j...E.
> 0010  002A00013F11219FAC100101AC10 .*?.!...
> 0020  010204D204D2001672A9343336392033 r.4369 3
> 0030  2033202D31202D31  3 -1 -1
> 
> ###[ Ethernet ]### 
>   dst   = 02:01:00:00:ff:02
>   src   = 02:fe:70:a0:6a:d3
>   type  = IPv4
> ###[ IP ]### 
>  version   = 4
>  ihl   = 5
>  tos   = 0x0
>  len   = 42
>  id= 1
>  flags = 
>  frag  = 0
>  ttl   = 63
>  proto = udp
>  chksum= 0x219f
>  src   = 172.16.1.1
>  dst   = 172.16.1.2
>  \options   \
> ###[ UDP ]### 
> sport = 1234
> dport = 1234
> len   = 22
> chksum= 0x72a9
> ###[ Raw ]### 
>load  = '4369 3 3 -1 -1'
> 
> Ten more packets
> 
> 
> ###[ UDP ]### 
> sport = 1234
> dport = 1234
> len   = 22
> chksum= 0x72a9
> ###[ Raw ]### 
>load  = '4369 3 3 -1 -1'
> 
> ** Ten more packets
> 
> Print limit reached, 10 out of 257 packets printed
> 19:37:47,770 REG: Couldn't remove configuration for object(s):
> 19:37:47,770 
> GRE tunnel VRF Tests 
> ERROR [ temp dir used by test case: /tmp/vpp-unittest-TestGRE-hthaHC ]
> 
> ==
> ERROR: GRE tunnel VRF Tests
> --
> Traceback (most recent call last):
>   File "/vpp/16257/test/test_gre.py", line 61, in tearDown
> super(TestGRE, self).tearDown()
>   File "/vpp/16257/test/framework.py", line 546, in tearDown
> self.registry.remove_vpp_config(self.logger)
>   File "/vpp/16257/test/vpp_object.py", line 86, in remove_vpp_config
> (", ".join(str(x) for x in failed)))
> Exception: Couldn't remove configuration for object(s): 1:2.2.2.2/32
> 
> ==
> FAIL: GRE tunnel VRF Tests
> --
> Traceback (most recent call last):
>   File "/vpp/16257/test/test_gre.py", line 787, in test_gre_vrf
> remark="GRE decap packets in wrong VRF")
>   File "/vpp/16257/test/vpp_pg_interface.py", line 264, in 
> assert_nothing_captured
> (self.name, remark))
>

Re: [vpp-dev] Build failing on AArch64

2018-11-29 Thread Juraj Linkeš

Hi Ole,

I tried it and it does solve the issue, thanks!

Sirshak, does it work for you too?

Juraj

From: Ole Troan [mailto:otr...@employees.org]
Sent: Wednesday, November 28, 2018 9:25 AM
To: Sirshak Das 
Cc: Juraj Linkeš ; vpp-dev@lists.fd.io; Honnappa 
Nagarahalli ; Lijian Zhang (Arm Technology China) 

Subject: Re: [vpp-dev] Build failing on AArch64

Sirshak,

Can you try adding:

DEPENDS api_headers

Inside
add_vpp_executable(vpp_api_test ENABLE_EXPORTS

in src/vat/CMakeLists.txt

Cheers,
Ole

> On 28 Nov 2018, at 06:32, Sirshak Das 
> mailto:sirshak@arm.com>> wrote:
>
> It takes 3 iterations to get to a proper build:
>
> First Iteration:
>
> FAILED: vat/CMakeFiles/vpp_api_test.dir/types.c.o
> ccache /usr/lib/ccache/cc -DHAVE_MEMFD_CREATE -Dvpp_api_test_EXPORTS 
> -I/home/sirdas/code/commitc/vpp/src -I. -Iinclude -march=armv8-a+crc -g -O2 
> -DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Werror   
> -Wno-address-of-packed-member -pthread -MD -MT 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o -MF 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o.d -o 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o   -c 
> /home/sirdas/code/commitc/vpp/src/vat/types.c
> In file included from 
> /home/sirdas/code/commitc/vpp/src/vpp/api/vpe_all_api_h.h:25,
>from /home/sirdas/code/commitc/vpp/src/vpp/api/types.h:20,
>from /home/sirdas/code/commitc/vpp/src/vat/types.c:19:
> /home/sirdas/code/commitc/vpp/src/vnet/vnet_all_api_h.h:32:10: fatal error: 
> vnet/bonding/bond.api.h: No such file or directory
> #include 
> ^
>
> Second Iteration:
>
> FAILED: vat/CMakeFiles/vpp_api_test.dir/types.c.o
> ccache /usr/lib/ccache/cc -DHAVE_MEMFD_CREATE -Dvpp_api_test_EXPORTS 
> -I/home/sirdas/code/commitc/vpp/src -I. -Iinclude -march=armv8-a+crc -g -O2 
> -DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Werror   
> -Wno-address-of-packed-member -pthread -MD -MT 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o -MF 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o.d -o 
> vat/CMakeFiles/vpp_api_test.dir/types.c.o   -c 
> /home/sirdas/code/commitc/vpp/src/vat/types.c
> In file included from /home/sirdas/code/commitc/vpp/src/vpp/api/types.h:20,
>from /home/sirdas/code/commitc/vpp/src/vat/types.c:19:
> /home/sirdas/code/commitc/vpp/src/vpp/api/vpe_all_api_h.h:32:10: fatal error: 
> vpp/stats/stats.api.h: No such file or directory
> #include 
> ^~~
> compilation terminated.
> [142/1163] Building C object vat/CMakeFiles/vpp_api_test.dir/api_format.c.o^C
> ninja: build stopped: interrupted by user.
> Makefile:691: recipe for target 'vpp-build' failed
> make[1]: *** [vpp-build] Interrupt
> Makefile:366: recipe for target 'build-release' failed
> make: *** [build-release] Interrupt
>
> Had to kill as it was stuck.
>
> Third Interation:
>
> Finally it got built properly.
>
> This is a manageble error for dev purposes but will give lot false
> negatives for CI.
> Anyone familiar with VAT please help.
>
>
> Thank you
> Sirshak Das
>
> Ole Troan writes:
>
>> Juraj,
>>
>> Seems like a dependency problem. VAT depends on a generated file that hasn’t 
>> been generated yet.
>>
>> Ole
>>
>>> On 27 Nov 2018, at 18:04, Juraj Linkeš 
>>> mailto:juraj.lin...@pantheon.tech>> wrote:
>>>
>>> Hi Ole,
>>>
>>>  I'm hitting the same issue.
>>>
>>>  Running the build with V=2 doesn't actually produce more 
>>> output.
>>>
>>> Which means my logs are the same as Sirshak's. But in any case I attached 
>>> the output from a run with V=2.
>>>
>>> I can provide other info if there's more you need - or you can try 
>>> accessing one of our ThunderX's in the FD.io lab if you have access.
>>>
>>> Thanks,
>>> Juraj
>>>
>>> From: Ole Troan [mailto:otr...@employees.org]
>>> Sent: Tuesday, November 27, 2018 5:43 PM
>>> To: Juraj Linkeš 
>>> mailto:juraj.lin...@pantheon.tech>>
>>> Cc: Sirshak Das mailto:sirshak@arm.com>>; 
>>> vpp-dev@lists.fd.io; Honnappa Nagarahalli 
>>> mailto:honnappa.nagaraha...@arm.com>>; Lijian 
>>> Zhang (Arm Technology China) 
>>> mailto:lijian.zh...@arm.com>>
>>> Subject: Re: [vpp-dev] Build failing on AArch64
>>>
>>> Juraj,
>>>
>>> Without a make log this is just a guessing game.
>>>
>>> Cheers
>>> Ole
>>>
>>> On 27 Nov 2018, at 17:34, Juraj Linkeš 
>>> mailto:juraj.lin...@pantheon.tech>> wrote:
>>>
>>> Hi Sirshak and Ole,
>>>
>>> I'm hitting the same issue. The build fails on a clean repository, but the 
>>> subsequent build works fine, which is fine for local builds, but still 
>>> needs to be fixed.
>>>
>>> Running the build with V=2 doesn't actually produce more output. There one 
>>> more bit of information I can provide - this behavior is present on 
>>> Ubuntu1804 (4.15.0-38-generic), but builds on Ubuntu1604 
>>> (4.4.0-138-generic) work right away, which explains why CI didn't catch it.
>>>
>>> This is the patch that introduced the issue: 
>>> https://gerrit.fd.io/r/#/c/16109/
>>>
>>> Juraj
>>>
>>>

Re: [vpp-dev] Verify issues (GRE)

2018-11-29 Thread Ole Troan

Juraj,

Yes, here lays trouble.
I managed to get into the stuck while running VCL situation locally too.
It’s hard to reproduce though, and when it happened I didn’t manage to figure 
out much from strace/gdb.

Cheers,
Ole


> I've noticed a few thing about the VCL testcases:
> -The VCL testcasess are all using the same ports, which makes them 
> unsuitable for parallel test runs
> -Another thing about these testcases is that when they're don't 
> finish properly the sock_test_server and client stay running as zombie 
> processes (and thus use up ports). It's easily reproducible locally by 
> interrupting the tests, but I'm not sure whether this could actually arise in 
> CI
> -Which means that if one testcase finishes improperly (e.g. is killed 
> because of a timeout) all of the other VCL testcases will likely also fail
>  
> Hope this helps if there's anyone looking into those tests,
> Juraj
>  
> From: Ole Troan [mailto:otr...@employees.org] 
> Sent: Wednesday, November 28, 2018 7:56 PM
> To: vpp-dev 
> Subject: [vpp-dev] Verify issues (GRE)
>  
> Guys,
> 
> The verify job have been unstable over the last few days.
> We see some instability in the Jenkins build system, in the test harness 
> itself, and in the tests.
> On my 18.04 machine I’m seeing intermittent failures in GRE, GBP, DHCP, VCL.
> 
> It looks like Jenkins is functioning correctly now.
> Ed and I are also testing a revert of all the changes made to the test 
> framework itself over the last couple of days. A bit harsh, but we think this 
> might be the quickest way back to some level of stability.
> 
> Then we need to fix the tests that are in themselves unstable.
> 
> Any volunteers to see if they can figure out why GRE fails?
> 
> Cheers,
> Ole
> 
> 
> GRE Test Case 
> ==
> GRE IPv4 tunnel TestsOK
> GRE IPv6 tunnel TestsOK
> GRE tunnel L2 Tests  OK
> 19:37:47,505 Unexpected packets captured:
> Packet #0:
>   0201FF0202FE70A06AD308004500 p.j...E.
> 0010  002A00013F11219FAC100101AC10 .*?.!...
> 0020  010204D204D2001672A9343336392033 r.4369 3
> 0030  2033202D31202D31  3 -1 -1
> 
> ###[ Ethernet ]### 
>   dst   = 02:01:00:00:ff:02
>   src   = 02:fe:70:a0:6a:d3
>   type  = IPv4
> ###[ IP ]### 
>  version   = 4
>  ihl   = 5
>  tos   = 0x0
>  len   = 42
>  id= 1
>  flags = 
>  frag  = 0
>  ttl   = 63
>  proto = udp
>  chksum= 0x219f
>  src   = 172.16.1.1
>  dst   = 172.16.1.2
>  \options   \
> ###[ UDP ]### 
> sport = 1234
> dport = 1234
> len   = 22
> chksum= 0x72a9
> ###[ Raw ]### 
>load  = '4369 3 3 -1 -1'
> 
> Ten more packets
> 
> 
> ###[ UDP ]### 
> sport = 1234
> dport = 1234
> len   = 22
> chksum= 0x72a9
> ###[ Raw ]### 
>load  = '4369 3 3 -1 -1'
> 
> ** Ten more packets
> 
> Print limit reached, 10 out of 257 packets printed
> 19:37:47,770 REG: Couldn't remove configuration for object(s):
> 19:37:47,770 
> GRE tunnel VRF Tests 
> ERROR [ temp dir used by test case: /tmp/vpp-unittest-TestGRE-hthaHC ]
> 
> ==
> ERROR: GRE tunnel VRF Tests
> --
> Traceback (most recent call last):
>   File "/vpp/16257/test/test_gre.py", line 61, in tearDown
> super(TestGRE, self).tearDown()
>   File "/vpp/16257/test/framework.py", line 546, in tearDown
> self.registry.remove_vpp_config(self.logger)
>   File "/vpp/16257/test/vpp_object.py", line 86, in remove_vpp_config
> (", ".join(str(x) for x in failed)))
> Exception: Couldn't remove configuration for object(s): 1:2.2.2.2/32
> 
> ==
> FAIL: GRE tunnel VRF Tests
> --
> Traceback (most recent call last):
>   File "/vpp/16257/test/test_gre.py", line 787, in test_gre_vrf
> remark="GRE decap packets in wrong VRF")
>   File "/vpp/16257/test/vpp_pg_interface.py", line 264, in 
> assert_nothing_captured
> (self.name, remark))
> AssertionError: Non-empty capture file present for interface pg0 (GRE decap 
> packets in wrong VRF)
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11453): https://lists.fd.io/g/vpp-dev/message/11453
> Mute This Topic: https://lists.fd.io/mt/28473762/899915
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe:

Re: [vpp-dev] Verify issues (GRE)

2018-11-29 Thread Juraj Linkeš

Hi Ole,

I've noticed a few thing about the VCL testcases:

-The VCL testcasess are all using the same ports, which makes them 
unsuitable for parallel test runs

-Another thing about these testcases is that when they're don't finish 
properly the sock_test_server and client stay running as zombie processes (and 
thus use up ports). It's easily reproducible locally by interrupting the tests, 
but I'm not sure whether this could actually arise in CI

-Which means that if one testcase finishes improperly (e.g. is killed 
because of a timeout) all of the other VCL testcases will likely also fail

Hope this helps if there's anyone looking into those tests,
Juraj

From: Ole Troan [mailto:otr...@employees.org]
Sent: Wednesday, November 28, 2018 7:56 PM
To: vpp-dev 
Subject: [vpp-dev] Verify issues (GRE)

Guys,

The verify job have been unstable over the last few days.
We see some instability in the Jenkins build system, in the test harness 
itself, and in the tests.
On my 18.04 machine I’m seeing intermittent failures in GRE, GBP, DHCP, VCL.

It looks like Jenkins is functioning correctly now.
Ed and I are also testing a revert of all the changes made to the test 
framework itself over the last couple of days. A bit harsh, but we think this 
might be the quickest way back to some level of stability.

Then we need to fix the tests that are in themselves unstable.

Any volunteers to see if they can figure out why GRE fails?

Cheers,
Ole


GRE Test Case
==
GRE IPv4 tunnel TestsOK
GRE IPv6 tunnel TestsOK
GRE tunnel L2 Tests  OK
19:37:47,505 Unexpected packets captured:
Packet #0:
  0201FF0202FE70A06AD308004500 p.j...E.
0010  002A00013F11219FAC100101AC10 .*?.!...
0020  010204D204D2001672A9343336392033 r.4369 3
0030  2033202D31202D31  3 -1 -1

###[ Ethernet ]###
  dst   = 02:01:00:00:ff:02
  src   = 02:fe:70:a0:6a:d3
  type  = IPv4
###[ IP ]###
 version   = 4
 ihl   = 5
 tos   = 0x0
 len   = 42
 id= 1
 flags =
 frag  = 0
 ttl   = 63
 proto = udp
 chksum= 0x219f
 src   = 172.16.1.1
 dst   = 172.16.1.2
 \options   \
###[ UDP ]###
sport = 1234
dport = 1234
len   = 22
chksum= 0x72a9
###[ Raw ]###
   load  = '4369 3 3 -1 -1'

Ten more packets


###[ UDP ]###
sport = 1234
dport = 1234
len   = 22
chksum= 0x72a9
###[ Raw ]###
   load  = '4369 3 3 -1 -1'

** Ten more packets

Print limit reached, 10 out of 257 packets printed
19:37:47,770 REG: Couldn't remove configuration for object(s):
19:37:47,770 
GRE tunnel VRF Tests ERROR 
[ temp dir used by test case: /tmp/vpp-unittest-TestGRE-hthaHC ]

==
ERROR: GRE tunnel VRF Tests
--
Traceback (most recent call last):
  File "/vpp/16257/test/test_gre.py", line 61, in tearDown
super(TestGRE, self).tearDown()
  File "/vpp/16257/test/framework.py", line 546, in tearDown
self.registry.remove_vpp_config(self.logger)
  File "/vpp/16257/test/vpp_object.py", line 86, in remove_vpp_config
(", ".join(str(x) for x in failed)))
Exception: Couldn't remove configuration for object(s): 1:2.2.2.2/32

==
FAIL: GRE tunnel VRF Tests
--
Traceback (most recent call last):
  File "/vpp/16257/test/test_gre.py", line 787, in test_gre_vrf
remark="GRE decap packets in wrong VRF")
  File "/vpp/16257/test/vpp_pg_interface.py", line 264, in 
assert_nothing_captured
(self.name, remark))
AssertionError: Non-empty capture file present for interface pg0 (GRE decap 
packets in wrong VRF)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11453): https://lists.fd.io/g/vpp-dev/message/11453
Mute This Topic: https://lists.fd.io/mt/28473762/899915
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [juraj.lin...@pantheon.tech]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11459): https://lists.fd.io/g/vpp-dev/message/11459
Mute This Topic: https://lists.fd.io/mt/28473762/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Verify issues (GRE)

2018-11-29 Thread Neale Ranns via Lists.Fd.Io


Hi Ole,

I think this should fix the GRE tests:
  https://gerrit.fd.io/r/#/c/16272/

/Neale


-Message d'origine-
De :  au nom de Ole Troan 
Date : mercredi 28 novembre 2018 à 19:55
À : vpp-dev 
Objet : [vpp-dev] Verify issues (GRE)

Guys,

The verify job have been unstable over the last few days.
We see some instability in the Jenkins build system, in the test harness 
itself, and in the tests.
On my 18.04 machine I’m seeing intermittent failures in GRE, GBP, DHCP, VCL.

It looks like Jenkins is functioning correctly now.
Ed and I are also testing a revert of all the changes made to the test 
framework itself over the last couple of days. A bit harsh, but we think this 
might be the quickest way back to some level of stability.

Then we need to fix the tests that are in themselves unstable.

Any volunteers to see if they can figure out why GRE fails?

Cheers,
Ole


GRE Test Case 

==
GRE IPv4 tunnel TestsOK
GRE IPv6 tunnel TestsOK
GRE tunnel L2 Tests  OK
19:37:47,505 Unexpected packets captured:
Packet #0:
  0201FF0202FE70A06AD308004500 p.j...E.
0010  002A00013F11219FAC100101AC10 .*?.!...
0020  010204D204D2001672A9343336392033 r.4369 3
0030  2033202D31202D31  3 -1 -1

###[ Ethernet ]### 
  dst   = 02:01:00:00:ff:02
  src   = 02:fe:70:a0:6a:d3
  type  = IPv4
###[ IP ]### 
 version   = 4
 ihl   = 5
 tos   = 0x0
 len   = 42
 id= 1
 flags = 
 frag  = 0
 ttl   = 63
 proto = udp
 chksum= 0x219f
 src   = 172.16.1.1
 dst   = 172.16.1.2
 \options   \
###[ UDP ]### 
sport = 1234
dport = 1234
len   = 22
chksum= 0x72a9
###[ Raw ]### 
   load  = '4369 3 3 -1 -1'

Ten more packets


###[ UDP ]### 
sport = 1234
dport = 1234
len   = 22
chksum= 0x72a9
###[ Raw ]### 
   load  = '4369 3 3 -1 -1'

** Ten more packets

Print limit reached, 10 out of 257 packets printed
19:37:47,770 REG: Couldn't remove configuration for object(s):
19:37:47,770 
GRE tunnel VRF Tests 
ERROR [ temp dir used by test case: /tmp/vpp-unittest-TestGRE-hthaHC ]


==
ERROR: GRE tunnel VRF Tests

--
Traceback (most recent call last):
  File "/vpp/16257/test/test_gre.py", line 61, in tearDown
super(TestGRE, self).tearDown()
  File "/vpp/16257/test/framework.py", line 546, in tearDown
self.registry.remove_vpp_config(self.logger)
  File "/vpp/16257/test/vpp_object.py", line 86, in remove_vpp_config
(", ".join(str(x) for x in failed)))
Exception: Couldn't remove configuration for object(s): 1:2.2.2.2/32


==
FAIL: GRE tunnel VRF Tests

--
Traceback (most recent call last):
  File "/vpp/16257/test/test_gre.py", line 787, in test_gre_vrf
remark="GRE decap packets in wrong VRF")
  File "/vpp/16257/test/vpp_pg_interface.py", line 264, in 
assert_nothing_captured
(self.name, remark))
AssertionError: Non-empty capture file present for interface pg0 (GRE decap 
packets in wrong VRF)

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11458): https://lists.fd.io/g/vpp-dev/message/11458
Mute This Topic: https://lists.fd.io/mt/28473762/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Question regarding captive portal

Re: [vpp-dev] question about multicast mpls

Re: [vpp-dev] Build failing on AArch64

Re: [vpp-dev] Verify issues (GRE)

Re: [vpp-dev] Build failing on AArch64

Re: [vpp-dev] Verify issues (GRE)

Re: [vpp-dev] Verify issues (GRE)

Re: [vpp-dev] Verify issues (GRE)

8 matches

Site Navigation

Mail list logo

Footer information