date:20190502

[vpp-dev] GARP support in VPP

2019-05-02 Thread Shahid Khan

Hi,

does VPP support sending GARP ?

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

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

[vpp-dev] vpp dpdk crypto dev - are multiple crypto algorithms supported concurrently? #vpp

2019-05-02 Thread Jitendra Saini

Hello,

Sorry for repost.. I had posted this query 2 days ago but did not get any 
update. Help from your side will be much useful.

*Context* : Using dpdk + vpp for user plane packet processing
*Desired* : want to use dpdk crypto-dev scheduler to have 2 cores dedicated for 
crypto operations
*Issue* : crypto devices of different types (AES_MB & AES_GCM) are not 
supported concurrently.
*Query* : *Have anyone used crypto scheduler and able to support multiple 
crypto device types? Any way to have such support enabled?

*
*Details:*
We want to use 4 cores in total for user plane processing with following 
deployment
Core-1: vpp worker thread - downlink
Core-2 : vpp worker thread - uplink
Core-3 : crypto-slave-1 (Cipher: aes-cbc-128)
Core-4 : crypto-slave-2 (Cipher: aes-gcm-128)
 
*Configurations:*
        vdev crypto_aesni_mb_pmd1,name= aesni_mb_1,socket_id=0
        vdev crypto_aesni_gcm_pmd1,name= aesni_gcm_1,socket_id=0
        vdev crypto_scheduler,slave=aesni_ mb_1,slave=aesni_gcm_1,mode= 
multi-core,corelist=3-4, ordering=enable,slave_buff_ size=8192

*Query - Detail * : with above log output, we see crypto-slaves aesni_mb_1 &  
aesni_gcm_1 deployed on both worker threads but from Test Results we see 
following - 
AES Traffic - works through crypto scehdular 
GCM Traffic - does not work. (Error - dpdk-esp-decrypt            Failed to get 
crypto session)
 
Can someone please help to understand this behavior / suggest if any approach 
worked for you to support multiple crypto algorithms?
Thanks in advance

Log output below - 
vpp# *sh dpdk crypto devices* 
aesni_mb_1               crypto_aesni_mb     up        
  numa_node 0, max_queues 8
  free_resources 2, used_resources 2
  SYMMETRIC_CRYPTO, SYM_OPERATION_CHAINING, CPU_AVX2, CPU_AESNI
  Cipher: aes-cbc-128, aes-cbc-192, aes-cbc-256, aes-ctr-128, aes-ctr-192, 
aes-ctr-256
  Auth: md5-96, sha1-96, sha-256-128, sha-384-192, sha-512-256, aes-xcbc-mac-96
 
aesni_gcm_1              crypto_aesni_gcm    up        
  numa_node 0, max_queues 8
  free_resources 2, used_resources 2
  SYMMETRIC_CRYPTO, SYM_OPERATION_CHAINING, CPU_AVX2, CPU_AESNI, 
MBUF_SCATTER_GATHER
  Cipher: aes-gcm-128, aes-gcm-192, aes-gcm-256
  Auth: aes-gmac-128, aes-gmac-256
 
crypto_scheduler         crypto_scheduler    up        
  numa_node 0, max_queues 8
  free_resources 2, used_resources 2
  SYMMETRIC_CRYPTO, SYM_OPERATION_CHAINING, CPU_AVX2, CPU_AESNI, 
MBUF_SCATTER_GATHER
  Cipher: aes-gcm-128, aes-gcm-192, aes-gcm-256
  Auth:
 
 
vpp# *sh dpdk crypto placement verbose*
Thread 1 (vpp_wk_0):
  aesni_mb_1           dev-id  0 inbound-queue  0 outbound-queue  1
    Cipher: aes-cbc-128, aes-cbc-192, aes-cbc-256, aes-ctr-128, aes-ctr-192, 
aes-ctr-256
    Auth: md5-96, sha1-96, sha-256-128, sha-384-192, sha-512-256, 
aes-xcbc-mac-96
  aesni_gcm_1          dev-id  1 inbound-queue  0 outbound-queue  1
    Cipher:
    Auth: aes-gmac-128, aes-gmac-256
  crypto_scheduler     dev-id  2 inbound-queue  0 outbound-queue  1
    Cipher: aes-gcm-128, aes-gcm-192, aes-gcm-256
    Auth:
 
Thread 2 (vpp_wk_1):
  aesni_mb_1           dev-id  0 inbound-queue  2 outbound-queue  3
    Cipher: aes-cbc-128, aes-cbc-192, aes-cbc-256, aes-ctr-128, aes-ctr-192, 
aes-ctr-256
    Auth: md5-96, sha1-96, sha-256-128, sha-384-192, sha-512-256, 
aes-xcbc-mac-96
  aesni_gcm_1          dev-id  1 inbound-queue  2 outbound-queue  3
    Cipher:
    Auth: aes-gmac-128, aes-gmac-256
  crypto_scheduler     dev-id  2 inbound-queue  2 outbound-queue  3
    Cipher: aes-gcm-128, aes-gcm-192, aes-gcm-256
    Auth:

Thanks
Best Regards,
Jitendra Saini
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12896): https://lists.fd.io/g/vpp-dev/message/12896
Mute This Topic: https://lists.fd.io/mt/31453891/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] HQoS- Traffic shaping - Pipe profiles

2019-05-02 Thread Abeeha Aqeel

Hi everyone, 

I’ve been testing the behavior of the HQoS plugin in VPP. As for now there is 
only a single subport (Subport 0),  and 4096 pipes in each subport. I tested 
HQoS for the default profile (profile 0) which should assign approximately 
2-3Mbps to each user on a 10Gbps link. For two iperf3 clients simultaneously 
sending traffic to vpp, HQoS is working fine and limiting traffic to 2Mbps per 
client but for greater number of clients it does not function the same way. 

Below is a simple topology I have implemented to test the HQoS functionality. I 
tried changing the token bucket rate, token bucket size and tc_period values 
but still not much luck. I have attached results for 10  clients with different 
combinations of token bucket size, token bucket rate and tc_period.

Any ideas what the problem might be ? 

Also, in what proportion should the tb_rate, tb_size , tc_rate and tc_period 
should be set ? 
 

S#
Rate (Bytes per second)
Token Bucket Size (Bytes)
TC Period (ms)
Total no of PPPoE sessions
Expected Result (Commulative average bandwidth in Mbps)
Actual Result (Commulative average bandwidth in Mbps)
Comments

Subport
Pipe
Subport 
Pipe
Subport
Pipe




1
125000
305175
100
100
10
40
10
24.4
8.1
vpp remains stable
2
125000
305175
100
100
10
60
10
24.4
12.72
vpp remains stable
3
125000
305175
100
100
10
100
10
24.4
11.4
vpp remains stable
4
125000
305175
100
1000
10
40
10
24.4
12.1
vpp remains stable
5
125000
305175
1000
1000
10
40
10
24.4
12.03
vpp remains stable
6
125000
305175
1000
1000
10
100
10
24.4
2.21
vpp crashes after a few seconds
7
125000
305175
100
100
10
60
10
24.4
12.1
vpp remains stable



Regards,
 
Abeeha Aqeel
Network Design Engineer, 
xFlow Research Inc. 
abeeha.aq...@xflowresearch.com

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

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

[vpp-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-05-02 Thread Anton Baranov via RT

Hello Jan

>From logs I see that the job was waiting (sleep) from 04:45:12 til 05:26:36 
>which could cause jnlp session to timed out as we have 10m idle timeout 
>(client and server side) set on jenkins.fd.io 

Could you check that error: 

05:26:36 Reservation unsuccessful:
05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File exists

Cheers,

-- 
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation

On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> Hello,
> 
> We are experiencing quite a lot of network issues when running CSIT
> tests for 19.04 report:
> 
> Caused: hudson.remoting.ChannelClosedException: Channel "unknown":
> Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> 1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is closing
> down or has closed down
> 
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/console
> 
> Could you, please, have a look on it?
> 
> Thank you very much.
> 
> Regards,
> Jan


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

View/Reply Online (#12904): https://lists.fd.io/g/vpp-dev/message/12904
Mute This Topic: https://lists.fd.io/mt/31454816/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] [FD.io Helpdesk #74794] Jenkins.fd.io network issues - CSIT-1904 rls showstopper [CRITICAL]

2019-05-02 Thread Maciek Konstantynowicz via RT

Hello,

CRITICAL ISSUE: ALL CSIT PERFORMANCE TESTING JOBS ARE EFFECTED. 1904 RLS 
SHOWSTOPPER.

This is now a critical issue as all CSIT performance testing jobs
are failing, preventing FD.io CSIT project to complete the 
CSIT-1904 release.

This ticket #74794, is related to the same underlying jnlp connectivity issue
reported in other recent tickets #74795, #73486, #73487, but apparently issue
was observed earlier #70022, and much earlier too..

It was attributed to haproxy issues (Layer4 timeouts), but the issue is still
happening. Below is the sorted list of timestamps from Peter Mikus script
as per earlier note in this case. One can see that multiple jobs get affected
at the same time.

Please advise on resolution, and if any assistance is needed from 
FD.io CSIT
project.

Thank you for your attention!

Cheers,
-Maciek

2019.04.27-10:54:40  java.nio.channels.ClosedChannelException
2019.04.27-10:55:06  java.nio.channels.ClosedChannelException
2019.04.27-10:55:10  java.nio.channels.ClosedChannelException
2019.04.28-09:32:20  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.05.01-13:48:18  java.nio.channels.ClosedChannelException
2019.05.01-13:48:18  java.nio.channels.ClosedChannelException
2019.05.01-13:48:18  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:27  java.nio.channels.ClosedChannelException
2019.05.01-17:59:20  java.nio.channels.ClosedChannelException

On 2 May 2019, at 07:47, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at 
Cisco) mailto:pmi...@cisco.com>> wrote:

Hello,

This issue is starting to be very serious and impacting deliverables for CSIT 
project.

Can you please investigate with priority.

Subset of failed jobs (just few examples from past days):
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/38/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/37/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/36/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/35/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/34/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/20/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/19/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/18/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/17/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/15/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/13/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/16/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/17/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/18/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/19/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/10/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/14/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/15/
https://jenkins.fd.io/job/csit-dpdk-perf-verify-1904-3n-skx/8/
https://jenkins.fd.io/job/csit-dpdk-perf-verify-1904-3n-skx/10/
https://jenkins.fd.io/job/csit-vpp-perf-mrr-daily-master/666/
https://jenkins.fd.io/job/csit-vpp-perf-mrr-daily-master/665/

Thank you.

Note: From logs, it can be quite easily extracted dates and times of outages 
and correlation in time.


jobs=('https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/38/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/37/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/36/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/35/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/34/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/20/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/19/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/18/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/17/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/15/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/13/'
  'https://jenkins.fd.io/job/csit-vpp-perf

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-05-02 Thread Vratko Polak -X via RT

> I increased idle timeout from 10min to 60min.

Was it around the time this [2] job failed recently?

  16:14:44 ++ sleep 184s
  16:16:29 FATAL: command execution failed

Vratko.

[2] https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-hsw/335/console

-Original Message-
From: csit-...@lists.fd.io  On Behalf Of Kenny Paul via RT
Sent: Tuesday, 2019-April-30 18:22
To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues


I increased idle timeout from 10min to 60min. Let's see if that makes any 
difference.

Regards,

--
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation

On Tue Apr 30 10:03:46 2019, vrpo...@cisco.com wrote:
> >> interleaved by quick periods of activity
> 
> >>> 09:26:36 ++ sleep 197s
> 
> > send any keepalive packages
> 
> I always assumed the console outputs are enough to keep jnlp 
> connection alive.
> 
> Also, I believe this failure over weekend has hit multiple jobs at 
> once.
> 
> For example https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-
> hsw/333/console
>   09:32:54 ++ sleep 184s
>   09:33:09 FATAL: command execution failed
> 
> Vratko.
> 
> -Original Message-
> From: csit-...@lists.fd.io  On Behalf Of Kenny 
> Paul via RT
> Sent: Tuesday, 2019-April-30 15:57
> To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
> 
> Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network 
> issues
> 
> Hello Vratko,
> 
> Thank you for explanation. I'm wondering within that period of time 
> when reservation was unsuccessful (~40min) does the job keep jnlp 
> connection alive (send any keepalive packages)?
> 
> I checked the haproxy node where jnlp is runnining and I don't see any 
> DOWN notification for it
> 
> Thanks,
> --
> Anton Baranov
> Sr. System Operations Engineer
> The Linux Foundation
> 
> On Tue Apr 30 09:27:56 2019, vrpo...@cisco.com wrote:
> > > 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir':
> > > File
> > > exists
> >
> > That error is expected, it just means  the testbed is currently used 
> > by another job, so this job should sleep a while and try again.
> >
> > > the job was waiting (sleep) from 04:45:12 til 05:26:36
> >
> > I believe my browser is showing me UTC timestamps, which show values 
> > larger by 4 hours.
> >
> > > we have 10m idle timeout
> >
> > The ~3m period of sleeps are interleaved by quick periods of 
> > activity, so we usually do not hit the timeout.
> >
> > But the final sleep probably took longer for some reason
> >
> > 09:26:36 ++ sleep 197s
> > 09:32:20 FATAL: command execution failed
> >
> > and something bad has happened in less than 6 minutes.
> > So it does not look like the 10m timeout.
> >
> > Vratko.
> >
> > -Original Message-
> >  From: csit-...@lists.fd.io  On Behalf Of 
> > Kenny Paul via RT
> > Sent: Tuesday, 2019-April-30 15:09
> >  To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
> > 
> > Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> >  Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network 
> > issues
> >
> > Hello Jan
> >
> > From logs I see that the job was waiting (sleep) from 04:45:12 til
> >  05:26:36 which could cause jnlp session to timed out as we have 10m 
> > idle timeout (client and server side) set on jenkins.fd.io
> >
> > Could you check that error:
> >
> > 05:26:36 Reservation unsuccessful:
> >  05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': 
> > File exists
> >
> > Cheers,
> >
> > --
> > Anton Baranov
> > Sr. System Operations Engineer
> > The Linux Foundation
> >
> > On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> > > Hello,
> > >
> > > We are experiencing quite a lot of network issues when running 
> > > CSIT tests for 19.04 report:
> > >
> > > Caused: hudson.remoting.ChannelClosedException: Channel "unknown":
> > > Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> > >   1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is 
> > > closing down or has closed down
> > >
> > > https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-
> > > hsw/13/consol
> > > e
> > >
> > > Could you, please, have a look on it?
> > >
> > > Thank you very much.
> > >
> > > Regards,
> > > Jan
> >
> >
> 
> 



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

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

[vpp-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-05-02 Thread Anton Baranov via RT

Hello Vratko,

Thank you for explanation. I'm wondering within that period of time when 
reservation was unsuccessful (~40min) does the job keep jnlp connection alive 
(send any keepalive packages)? 

I checked the haproxy node where jnlp is runnining and I don't see any DOWN 
notification for it

Thanks,
-- 
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation

On Tue Apr 30 09:27:56 2019, vrpo...@cisco.com wrote:
> > 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File
> > exists
> 
> That error is expected, it just means
> the testbed is currently used by another job,
> so this job should sleep a while and try again.
> 
> > the job was waiting (sleep) from 04:45:12 til 05:26:36
> 
> I believe my browser is showing me UTC timestamps,
> which show values larger by 4 hours.
> 
> > we have 10m idle timeout
> 
> The ~3m period of sleeps are interleaved by quick periods
> of activity, so we usually do not hit the timeout.
> 
> But the final sleep probably took longer for some reason
> 
> 09:26:36 ++ sleep 197s
> 09:32:20 FATAL: command execution failed
> 
> and something bad has happened in less than 6 minutes.
> So it does not look like the 10m timeout.
> 
> Vratko.
> 
> -Original Message-
> From: csit-...@lists.fd.io  On Behalf Of Kenny
> Paul via RT
> Sent: Tuesday, 2019-April-30 15:09
> To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)
> 
> Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network
> issues
> 
> Hello Jan
> 
> From logs I see that the job was waiting (sleep) from 04:45:12 til
> 05:26:36 which could cause jnlp session to timed out as we have 10m
> idle timeout (client and server side) set on jenkins.fd.io
> 
> Could you check that error:
> 
> 05:26:36 Reservation unsuccessful:
> 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File
> exists
> 
> Cheers,
> 
> --
> Anton Baranov
> Sr. System Operations Engineer
> The Linux Foundation
> 
> On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> > Hello,
> >
> > We are experiencing quite a lot of network issues when running CSIT
> > tests for 19.04 report:
> >
> > Caused: hudson.remoting.ChannelClosedException: Channel "unknown":
> > Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> >  1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is closing
> > down or has closed down
> >
> > https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/console
> >
> > Could you, please, have a look on it?
> >
> > Thank you very much.
> >
> > Regards,
> > Jan
> 
> 


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

View/Reply Online (#12899): https://lists.fd.io/g/vpp-dev/message/12899
Mute This Topic: https://lists.fd.io/mt/31454812/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] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-05-02 Thread Vratko Polak -X via RT

> 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File exists

That error is expected, it just means
the testbed is currently used by another job,
so this job should sleep a while and try again.

> the job was waiting (sleep) from 04:45:12 til 05:26:36

I believe my browser is showing me UTC timestamps,
which show values larger by 4 hours.

> we have 10m idle timeout

The ~3m period of sleeps are interleaved by quick periods
of activity, so we usually do not hit the timeout.

But the final sleep probably took longer for some reason

  09:26:36 ++ sleep 197s
  09:32:20 FATAL: command execution failed

and something bad has happened in less than 6 minutes.
So it does not look like the 10m timeout.

Vratko.

-Original Message-
From: csit-...@lists.fd.io  On Behalf Of Kenny Paul via RT
Sent: Tuesday, 2019-April-30 15:09
To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Hello Jan

>From logs I see that the job was waiting (sleep) from 04:45:12 til 05:26:36 
>which could cause jnlp session to timed out as we have 10m idle timeout 
>(client and server side) set on jenkins.fd.io 

Could you check that error: 

05:26:36 Reservation unsuccessful:
05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File exists

Cheers,

--
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation

On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> Hello,
> 
> We are experiencing quite a lot of network issues when running CSIT 
> tests for 19.04 report:
> 
> Caused: hudson.remoting.ChannelClosedException: Channel "unknown":
> Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> 1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is closing 
> down or has closed down
> 
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/console
> 
> Could you, please, have a look on it?
> 
> Thank you very much.
> 
> Regards,
> Jan



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

View/Reply Online (#12898): https://lists.fd.io/g/vpp-dev/message/12898
Mute This Topic: https://lists.fd.io/mt/31419993/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] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-05-02 Thread Vratko Polak -X via RT

>> interleaved by quick periods of activity

>>> 09:26:36 ++ sleep 197s

> send any keepalive packages

I always assumed the console outputs are enough
to keep jnlp connection alive.

Also, I believe this failure over weekend
has hit multiple jobs at once.

For example 
https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-hsw/333/console
  09:32:54 ++ sleep 184s
  09:33:09 FATAL: command execution failed

Vratko.

-Original Message-
From: csit-...@lists.fd.io  On Behalf Of Kenny Paul via RT
Sent: Tuesday, 2019-April-30 15:57
To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Hello Vratko,

Thank you for explanation. I'm wondering within that period of time when 
reservation was unsuccessful (~40min) does the job keep jnlp connection alive 
(send any keepalive packages)? 

I checked the haproxy node where jnlp is runnining and I don't see any DOWN 
notification for it

Thanks,
--
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation

On Tue Apr 30 09:27:56 2019, vrpo...@cisco.com wrote:
> > 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File 
> > exists
> 
> That error is expected, it just means
> the testbed is currently used by another job, so this job should sleep 
> a while and try again.
> 
> > the job was waiting (sleep) from 04:45:12 til 05:26:36
> 
> I believe my browser is showing me UTC timestamps, which show values 
> larger by 4 hours.
> 
> > we have 10m idle timeout
> 
> The ~3m period of sleeps are interleaved by quick periods of activity, 
> so we usually do not hit the timeout.
> 
> But the final sleep probably took longer for some reason
> 
> 09:26:36 ++ sleep 197s
> 09:32:20 FATAL: command execution failed
> 
> and something bad has happened in less than 6 minutes.
> So it does not look like the 10m timeout.
> 
> Vratko.
> 
> -Original Message-
> From: csit-...@lists.fd.io  On Behalf Of Kenny 
> Paul via RT
> Sent: Tuesday, 2019-April-30 15:09
> To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
> 
> Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network 
> issues
> 
> Hello Jan
> 
> From logs I see that the job was waiting (sleep) from 04:45:12 til
> 05:26:36 which could cause jnlp session to timed out as we have 10m 
> idle timeout (client and server side) set on jenkins.fd.io
> 
> Could you check that error:
> 
> 05:26:36 Reservation unsuccessful:
> 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File 
> exists
> 
> Cheers,
> 
> --
> Anton Baranov
> Sr. System Operations Engineer
> The Linux Foundation
> 
> On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> > Hello,
> >
> > We are experiencing quite a lot of network issues when running CSIT 
> > tests for 19.04 report:
> >
> > Caused: hudson.remoting.ChannelClosedException: Channel "unknown":
> > Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> >  1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is closing 
> > down or has closed down
> >
> > https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/consol
> > e
> >
> > Could you, please, have a look on it?
> >
> > Thank you very much.
> >
> > Regards,
> > Jan
> 
> 



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

View/Reply Online (#12905): https://lists.fd.io/g/vpp-dev/message/12905
Mute This Topic: https://lists.fd.io/mt/31419993/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] [FD.io Helpdesk #74794] Jenkins.fd.io network issues - CSIT-1904 rls showstopper [CRITICAL]

2019-05-02 Thread Maciek Konstantynowicz via RT

Hello,

CRITICAL ISSUE: ALL CSIT PERFORMANCE TESTING JOBS ARE EFFECTED. 1904 RLS 
SHOWSTOPPER.

This is now a critical issue as all CSIT performance testing jobs
are failing, preventing FD.io CSIT project to complete the 
CSIT-1904 release.

This ticket #74794, is related to the same underlying jnlp connectivity issue
reported in other recent tickets #74795, #73486, #73487, but apparently issue
was observed earlier #70022, and much earlier too..

It was attributed to haproxy issues (Layer4 timeouts), but the issue is still
happening. Below is the sorted list of timestamps from Peter Mikus script
as per earlier note in this case. One can see that multiple jobs get affected
at the same time.

Please advise on resolution, and if any assistance is needed from 
FD.io CSIT
project.

Thank you for your attention!

Cheers,
-Maciek

2019.04.27-10:54:40  java.nio.channels.ClosedChannelException
2019.04.27-10:55:06  java.nio.channels.ClosedChannelException
2019.04.27-10:55:10  java.nio.channels.ClosedChannelException
2019.04.28-09:32:20  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
2019.05.01-13:48:18  java.nio.channels.ClosedChannelException
2019.05.01-13:48:18  java.nio.channels.ClosedChannelException
2019.05.01-13:48:18  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
2019.05.01-13:48:27  java.nio.channels.ClosedChannelException
2019.05.01-17:59:20  java.nio.channels.ClosedChannelException

On 2 May 2019, at 07:47, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at 
Cisco) mailto:pmi...@cisco.com>> wrote:

Hello,

This issue is starting to be very serious and impacting deliverables for CSIT 
project.

Can you please investigate with priority.

Subset of failed jobs (just few examples from past days):
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/38/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/37/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/36/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/35/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/34/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/20/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/19/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/18/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/17/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/15/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/13/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/16/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/17/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/18/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/19/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/10/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/14/
https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/15/
https://jenkins.fd.io/job/csit-dpdk-perf-verify-1904-3n-skx/8/
https://jenkins.fd.io/job/csit-dpdk-perf-verify-1904-3n-skx/10/
https://jenkins.fd.io/job/csit-vpp-perf-mrr-daily-master/666/
https://jenkins.fd.io/job/csit-vpp-perf-mrr-daily-master/665/

Thank you.

Note: From logs, it can be quite easily extracted dates and times of outages 
and correlation in time.


jobs=('https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/38/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/37/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/36/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/35/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/34/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/20/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/19/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/18/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/17/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/15/'
  'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/13/'
  'https://jenkins.fd.io/job/csit-vpp-perf

[vpp-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-05-02 Thread Anton Baranov via RT


I increased idle timeout from 10min to 60min. Let's see if that makes any 
difference.

Regards,

-- 
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation

On Tue Apr 30 10:03:46 2019, vrpo...@cisco.com wrote:
> >> interleaved by quick periods of activity
> 
> >>> 09:26:36 ++ sleep 197s
> 
> > send any keepalive packages
> 
> I always assumed the console outputs are enough
> to keep jnlp connection alive.
> 
> Also, I believe this failure over weekend
> has hit multiple jobs at once.
> 
> For example https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-
> hsw/333/console
>   09:32:54 ++ sleep 184s
>   09:33:09 FATAL: command execution failed
> 
> Vratko.
> 
> -Original Message-
> From: csit-...@lists.fd.io  On Behalf Of Kenny
> Paul via RT
> Sent: Tuesday, 2019-April-30 15:57
> To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)
> 
> Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network
> issues
> 
> Hello Vratko,
> 
> Thank you for explanation. I'm wondering within that period of time
> when reservation was unsuccessful (~40min) does the job keep jnlp
> connection alive (send any keepalive packages)?
> 
> I checked the haproxy node where jnlp is runnining and I don't see any
> DOWN notification for it
> 
> Thanks,
> --
> Anton Baranov
> Sr. System Operations Engineer
> The Linux Foundation
> 
> On Tue Apr 30 09:27:56 2019, vrpo...@cisco.com wrote:
> > > 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir':
> > > File
> > > exists
> >
> > That error is expected, it just means
> >  the testbed is currently used by another job, so this job should
> > sleep
> > a while and try again.
> >
> > > the job was waiting (sleep) from 04:45:12 til 05:26:36
> >
> > I believe my browser is showing me UTC timestamps, which show values
> > larger by 4 hours.
> >
> > > we have 10m idle timeout
> >
> > The ~3m period of sleeps are interleaved by quick periods of
> > activity,
> > so we usually do not hit the timeout.
> >
> > But the final sleep probably took longer for some reason
> >
> > 09:26:36 ++ sleep 197s
> > 09:32:20 FATAL: command execution failed
> >
> > and something bad has happened in less than 6 minutes.
> > So it does not look like the 10m timeout.
> >
> > Vratko.
> >
> > -Original Message-
> >  From: csit-...@lists.fd.io  On Behalf Of Kenny
> > Paul via RT
> > Sent: Tuesday, 2019-April-30 15:09
> >  To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)
> > 
> > Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> >  Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network
> > issues
> >
> > Hello Jan
> >
> > From logs I see that the job was waiting (sleep) from 04:45:12 til
> >  05:26:36 which could cause jnlp session to timed out as we have 10m
> > idle timeout (client and server side) set on jenkins.fd.io
> >
> > Could you check that error:
> >
> > 05:26:36 Reservation unsuccessful:
> >  05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File
> > exists
> >
> > Cheers,
> >
> > --
> > Anton Baranov
> > Sr. System Operations Engineer
> > The Linux Foundation
> >
> > On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> > > Hello,
> > >
> > > We are experiencing quite a lot of network issues when running CSIT
> > > tests for 19.04 report:
> > >
> > > Caused: hudson.remoting.ChannelClosedException: Channel "unknown":
> > > Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> > >   1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is
> > > closing
> > > down or has closed down
> > >
> > > https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-
> > > hsw/13/consol
> > > e
> > >
> > > Could you, please, have a look on it?
> > >
> > > Thank you very much.
> > >
> > > Regards,
> > > Jan
> >
> >
> 
> 


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

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

[vpp-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-05-02 Thread Anton Baranov via RT

Haproxy reload happened at that time: 2019-04-30 16:16:29. Could you give 
another try ?

On Tue Apr 30 12:40:42 2019, vrpo...@cisco.com wrote:
> > I increased idle timeout from 10min to 60min.
> 
> Was it around the time this [2] job failed recently?
> 
> 16:14:44 ++ sleep 184s
> 16:16:29 FATAL: command execution failed
> 
> Vratko.
> 
> [2] https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-
> hsw/335/console
> 
> -Original Message-
> From: csit-...@lists.fd.io  On Behalf Of Kenny
> Paul via RT
> Sent: Tuesday, 2019-April-30 18:22
> To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)
> 
> Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network
> issues
> 
> 
> I increased idle timeout from 10min to 60min. Let's see if that makes
> any difference.
> 
> Regards,
> 
> --
> Anton Baranov
> Sr. System Operations Engineer
> The Linux Foundation
> 
> On Tue Apr 30 10:03:46 2019, vrpo...@cisco.com wrote:
> > >> interleaved by quick periods of activity
> >
> > >>> 09:26:36 ++ sleep 197s
> >
> > > send any keepalive packages
> >
> > I always assumed the console outputs are enough to keep jnlp
> > connection alive.
> >
> > Also, I believe this failure over weekend has hit multiple jobs at
> > once.
> >
> > For example https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-
> > hsw/333/console
> >   09:32:54 ++ sleep 184s
> >   09:33:09 FATAL: command execution failed
> >
> > Vratko.
> >
> > -Original Message-
> >  From: csit-...@lists.fd.io  On Behalf Of Kenny
> > Paul via RT
> > Sent: Tuesday, 2019-April-30 15:57
> >  To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)
> > 
> > Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> >  Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network
> > issues
> >
> > Hello Vratko,
> >
> > Thank you for explanation. I'm wondering within that period of time
> > when reservation was unsuccessful (~40min) does the job keep jnlp
> > connection alive (send any keepalive packages)?
> >
> > I checked the haproxy node where jnlp is runnining and I don't see
> > any
> > DOWN notification for it
> >
> > Thanks,
> > --
> > Anton Baranov
> > Sr. System Operations Engineer
> > The Linux Foundation
> >
> > On Tue Apr 30 09:27:56 2019, vrpo...@cisco.com wrote:
> > > > 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir':
> > > > File
> > > > exists
> > >
> > > That error is expected, it just means  the testbed is currently
> > > used
> > > by another job, so this job should sleep a while and try again.
> > >
> > > > the job was waiting (sleep) from 04:45:12 til 05:26:36
> > >
> > > I believe my browser is showing me UTC timestamps, which show
> > > values
> > > larger by 4 hours.
> > >
> > > > we have 10m idle timeout
> > >
> > > The ~3m period of sleeps are interleaved by quick periods of
> > > activity, so we usually do not hit the timeout.
> > >
> > > But the final sleep probably took longer for some reason
> > >
> > > 09:26:36 ++ sleep 197s
> > > 09:32:20 FATAL: command execution failed
> > >
> > > and something bad has happened in less than 6 minutes.
> > > So it does not look like the 10m timeout.
> > >
> > > Vratko.
> > >
> > > -Original Message-
> > >   From: csit-...@lists.fd.io  On Behalf Of
> > > Kenny Paul via RT
> > > Sent: Tuesday, 2019-April-30 15:09
> > >   To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco)
> > > 
> > > Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> > >   Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network
> > > issues
> > >
> > > Hello Jan
> > >
> > > From logs I see that the job was waiting (sleep) from 04:45:12 til
> > >   05:26:36 which could cause jnlp session to timed out as we have
> > > 10m
> > > idle timeout (client and server side) set on jenkins.fd.io
> > >
> > > Could you check that error:
> > >
> > > 05:26:36 Reservation unsuccessful:
> > >   05:26:36 mkdir: cannot create directory '/tmp/reservation_dir':
> > > File exists
> > >
> > > Cheers,
> > >
> > > --
> > > Anton Baranov
> > > Sr. System Operations Engineer
> > > The Linux Foundation
> > >
> > > On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> > > > Hello,
> > > >
> > > > We are experiencing quite a lot of network issues when running
> > > > CSIT tests for 19.04 report:
> > > >
> > > > Caused: hudson.remoting.ChannelClosedException: Channel
> > > > "unknown":
> > > > Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> > > >1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is
> > > > closing down or has closed down
> > > >
> > > > https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-
> > > > hsw/13/consol
> > > > e
> > > >
> > > > Could you, please, have a look on it?
> > > >
> > > > Thank you very much.
> > > >
> > > > Regards,
> > > > Jan
> > >
> > >
> >
> >
> 
> 


-- 
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group

Re: [vpp-dev] [FD.io Helpdesk #74794] Jenkins.fd.io network issues - CSIT-1904 rls showstopper [CRITICAL]

2019-05-02 Thread Trishan de Lanerolle via RT

Hi Maciek,

A quick acknowledgment, we have seen this ticket. The vexhost CSIT team has
been notified to prioritize and troubleshoot.

Have asked Mohammed for an update for 11am TSC call too.

Regards,
Trishan


On Thu, May 2, 2019, 5:13 AM Maciek Konstantynowicz via RT <
fdio-helpd...@rt.linuxfoundation.org> wrote:

>
> https://rt.linuxfoundation.org/Ticket/Display.html?id=74794 >
>
> Hello,
>
> CRITICAL ISSUE: ALL CSIT PERFORMANCE TESTING JOBS ARE EFFECTED. 1904 RLS
> SHOWSTOPPER.
>
> This is now a critical issue as all CSIT performance testing jobs
> are failing, preventing FD.io CSIT project to complete the
> CSIT-1904 release.
>
> This ticket #74794, is related to the same underlying jnlp connectivity
> issue
> reported in other recent tickets #74795, #73486, #73487, but apparently
> issue
> was observed earlier #70022, and much earlier too..
>
> It was attributed to haproxy issues (Layer4 timeouts), but the issue is
> still
> happening. Below is the sorted list of timestamps from Peter Mikus script
> as per earlier note in this case. One can see that multiple jobs get
> affected
> at the same time.
>
> Please advise on resolution, and if any assistance is needed from FD.io<
> http://FD.io> CSIT
> project.
>
> Thank you for your attention!
>
> Cheers,
> -Maciek
>
> 2019.04.27-10:54:40  java.nio.channels.ClosedChannelException
> 2019.04.27-10:55:06  java.nio.channels.ClosedChannelException
> 2019.04.27-10:55:10  java.nio.channels.ClosedChannelException
> 2019.04.28-09:32:20  java.nio.channels.ClosedChannelException
> 2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
> 2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
> 2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
> 2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
> 2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
> 2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
> 2019.04.30-16:16:29  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:18  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:18  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:18  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:26  java.nio.channels.ClosedChannelException
> 2019.05.01-13:48:27  java.nio.channels.ClosedChannelException
> 2019.05.01-17:59:20  java.nio.channels.ClosedChannelException
>
> On 2 May 2019, at 07:47, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at
> Cisco) mailto:pmi...@cisco.com>> wrote:
>
> Hello,
>
> This issue is starting to be very serious and impacting deliverables for
> CSIT project.
>
> Can you please investigate with priority.
>
> Subset of failed jobs (just few examples from past days):
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/38/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/37/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/36/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/35/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/34/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/20/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/19/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/18/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/17/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/15/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-skx/13/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/16/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/17/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/18/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/19/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/10/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/14/
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/15/
> https://jenkins.fd.io/job/csit-dpdk-perf-verify-1904-3n-skx/8/
> https://jenkins.fd.io/job/csit-dpdk-perf-verify-1904-3n-skx/10/
> https://jenkins.fd.io/job/csit-vpp-perf-mrr-daily-master/666/
> https://jenkins.fd.io/job/csit-vpp-perf-mrr-daily-master/665/
>
> Thank you.
>
> Note: From logs, it can be quite easily extracted dates and times of
> outages and correlation in time.
>
>
> jobs=('https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/38/'
>   'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/37/'
>   'https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-2n-skx/36/'
>   'https://jenkins.fd.io/job/csit-vpp-perf-ve

[vpp-dev] query on vpp/frr integration.

2019-05-02 Thread Manjunath Munavalli

Hi,

I am using the frr and vpp integration using the router plugin (vppsb).
The routing is working as expected.
I wanted to understand how the vpp is forwarding only the control plane
(routing protocol messages) to FRR and the data plane messages is forwarded
by vpp.

I do understand that the data plane messages are forwarded by looking up
the FIB entries, but i am not able to understand how only control plane
messages are sent  to FRR using the tap interface, how are those packets
classified.

Please briefly explain how it is working.

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

View/Reply Online (#12907): https://lists.fd.io/g/vpp-dev/message/12907
Mute This Topic: https://lists.fd.io/mt/31454818/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] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-05-02 Thread Dave Barach via Lists.Fd.Io

Unfortunately, this thread landed in the vpp-dev@lists.fd.io moderation queue. 
I check the queue fairly often, but relying on a manual process to approve 
helpdesk postings is not the way to go.

It would work much better if folks managed to subscribe 
fdio-helpd...@rt.linuxfoundation.org to the vpp-dev and csit-dev mailing lists. 
Set delivery disabled, to avoid accidental ticket creation.

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Vratko Polak -X 
via RT
Sent: Tuesday, April 30, 2019 10:04 AM
To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network 
issues

>> interleaved by quick periods of activity

>>> 09:26:36 ++ sleep 197s

> send any keepalive packages

I always assumed the console outputs are enough to keep jnlp connection alive.

Also, I believe this failure over weekend has hit multiple jobs at once.

For example 
https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-hsw/333/console
  09:32:54 ++ sleep 184s
  09:33:09 FATAL: command execution failed

Vratko.

-Original Message-
From: csit-...@lists.fd.io  On Behalf Of Kenny Paul via RT
Sent: Tuesday, 2019-April-30 15:57
To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Hello Vratko,

Thank you for explanation. I'm wondering within that period of time when 
reservation was unsuccessful (~40min) does the job keep jnlp connection alive 
(send any keepalive packages)? 

I checked the haproxy node where jnlp is runnining and I don't see any DOWN 
notification for it

Thanks,
--
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation

On Tue Apr 30 09:27:56 2019, vrpo...@cisco.com wrote:
> > 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File 
> > exists
> 
> That error is expected, it just means
> the testbed is currently used by another job, so this job should sleep 
> a while and try again.
> 
> > the job was waiting (sleep) from 04:45:12 til 05:26:36
> 
> I believe my browser is showing me UTC timestamps, which show values 
> larger by 4 hours.
> 
> > we have 10m idle timeout
> 
> The ~3m period of sleeps are interleaved by quick periods of activity, 
> so we usually do not hit the timeout.
> 
> But the final sleep probably took longer for some reason
> 
> 09:26:36 ++ sleep 197s
> 09:32:20 FATAL: command execution failed
> 
> and something bad has happened in less than 6 minutes.
> So it does not look like the 10m timeout.
> 
> Vratko.
> 
> -Original Message-
> From: csit-...@lists.fd.io  On Behalf Of Kenny 
> Paul via RT
> Sent: Tuesday, 2019-April-30 15:09
> To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
> 
> Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network 
> issues
> 
> Hello Jan
> 
> From logs I see that the job was waiting (sleep) from 04:45:12 til
> 05:26:36 which could cause jnlp session to timed out as we have 10m 
> idle timeout (client and server side) set on jenkins.fd.io
> 
> Could you check that error:
> 
> 05:26:36 Reservation unsuccessful:
> 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File 
> exists
> 
> Cheers,
> 
> --
> Anton Baranov
> Sr. System Operations Engineer
> The Linux Foundation
> 
> On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> > Hello,
> >
> > We are experiencing quite a lot of network issues when running CSIT 
> > tests for 19.04 report:
> >
> > Caused: hudson.remoting.ChannelClosedException: Channel "unknown":
> > Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> >  1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is closing 
> > down or has closed down
> >
> > https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/consol
> > e
> >
> > Could you, please, have a look on it?
> >
> > Thank you very much.
> >
> > Regards,
> > Jan
> 
> 



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

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

[vpp-dev] VLAN Sub-interface without "exact-match" forward \ send packets without MAC header #vpp #vpp

2019-05-02 Thread amir_so

Hi,

I'm using VPP v19.01-release, 

When trying to work with VLAN sub-interface I found that once I set the 
"Exact-match" I can ping to the interface and it forward traffic correctly,
But if I set it without the "Exact-match" parameter the packet sent back \ 
forward to this port without the MAC & IP headers.

Please find below trace with and without the "Exact-match" parameter:
(I've set in bold the output part - the 00:01:08:00 is the start of the ARP 
reply after the MAC addresses and VLAN)

Is it known issue ?

Regards,
Amir 


*Without exact match*

vpp# show trace

--- Start of thread 0 vpp_main ---

Packet 1

 

00:02:22:849934: dpdk-input

  TenGigabitEthernet6/0/0 rx queue 0

  buffer 0x4c56: current data 0, length 60, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0

                 ext-hdr-valid

                 l4-cksum-computed l4-cksum-correct

  PKT MBUF: port 2, nb_segs 1, pkt_len 60

    buf_len 2176, data_len 60, ol_flags 0x181, data_off 128, phys_addr 
0xde331600

    packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0

    rss 0x0 fdir.hi 0x0 fdir.lo 0x0

    Packet Offload Flags

      PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet

      PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid

      PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid 100

    Packet Types

      RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet

  ARP: 00:20:d2:56:b7:bf -> ff:ff:ff:ff:ff:ff 802.1q vlan 100

  request, type ethernet/IP4, address size 6/4

  00:20:d2:56:b7:bf/1.1.1.2 -> 00:00:00:00:00:00/1.1.1.1

00:02:22:849954: ethernet-input

  frame: flags 0x3, hw-if-index 3, sw-if-index 3

  ARP: 00:20:d2:56:b7:bf -> ff:ff:ff:ff:ff:ff 802.1q vlan 100

00:02:22:849962: arp-input

  request, type ethernet/IP4, address size 6/4

  00:20:d2:56:b7:bf/1.1.1.2 -> 00:00:00:00:00:00/1.1.1.1

00:02:22:849979: *TenGigabitEthernet6/0/0-output*

  TenGigabitEthernet6/0/0.100

  0x1b10: *00:02:00:20:d2:be -> 00:01:08:00:06:04*

00:02:22:849982: TenGigabitEthernet6/0/0-tx

  TenGigabitEthernet6/0/0 tx queue 0

  buffer 0x4c56: current data 18, length 42, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0

                 ext-hdr-valid

                 l4-cksum-computed l4-cksum-correct vlan-1-deep l2-hdr-offset 0 
l3-hdr-offset 18

  PKT MBUF: port 2, nb_segs 1, pkt_len 42

    buf_len 2176, data_len 42, ol_flags 0x181, data_off 146, phys_addr 
0xde331600

    packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0

    rss 0x0 fdir.hi 0x0 fdir.lo 0x0

    Packet Offload Flags

      PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet

      PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid

      PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid 257

    Packet Types

      RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet

 

  0x1b10: 00:02:00:20:d2:be -> 00:01:08:00:06:04


*With "exact match"*
vpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1
 
00:00:52:453193: dpdk-input
  TenGigabitEthernet6/0/0 rx queue 0
  buffer 0x4ddc: current data 0, length 60, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
                 ext-hdr-valid
                 l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 2, nb_segs 1, pkt_len 60
    buf_len 2176, data_len 60, ol_flags 0x181, data_off 128, phys_addr 
0xde337780
    packet_type 0x1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
    rss 0x0 fdir.hi 0x0 fdir.lo 0x0
    Packet Offload Flags
      PKT_RX_VLAN (0x0001) RX packet is a 802.1q VLAN packet
      PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
      PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid 100
    Packet Types
      RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  ARP: 00:20:d2:56:b7:bf -> ff:ff:ff:ff:ff:ff 802.1q vlan 100
  request, type ethernet/IP4, address size 6/4
  00:20:d2:56:b7:bf/1.1.1.2 -> 00:00:00:00:00:00/1.1.1.1
00:00:52:453203: ethernet-input
  frame: flags 0x3, hw-if-index 3, sw-if-index 3
  ARP: 00:20:d2:56:b7:bf -> ff:ff:ff:ff:ff:ff 802.1q vlan 100
00:00:52:453214: arp-input
  request, type ethernet/IP4, address size 6/4
  00:20:d2:56:b7:bf/1.1.1.2 -> 00:00:00:00:00:00/1.1.1.1
00:00:52:453442: *TenGigabitEthernet6/0/0-output*
  TenGigabitEthernet6/0/0.100
  ARP: *00:20:d2:be:1b:10 -> 00:20:d2:56:b7:bf 802.1q vlan 100*
  reply, type ethernet/IP4, address size 6/4
  00:20:d2:be:1b:10/1.1.1.1 -> 00:20:d2:56:b7:bf/1.1.1.2
00:00:52:453447: TenGigabitEthernet6/0/0-tx
  TenGigabitEthernet6/0/0 tx queue 0
  buffer 0x4ddc:

[vpp-dev] TESTING in progress: May see job failures over the next 2 hours

2019-05-02 Thread Ed Kern via Lists.Fd.Io


In an attempt to work around the LF   HA-proxy to debug csit job connectivity 
issues I have to
‘hardwire’ connections (or attempt to do so at any rate) directly back to the 
jenkins IP.

No real idea if it will work or if there will be any side impact…ill be hand 
cranking a job or two
in an attempt to test….


Ill send another note if I finish early or if I need to extend past two hours.

thanks,

Ed


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

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

[vpp-dev] Routing of ipv6 packets over PPPoE

2019-05-02 Thread Raj

Hello all,

I have PPPoE working successfully over IPv4, and able to ping outside.
IPv6 negotiation by control plane is successful and an IPv6 session is
created using the following command:

create pppoe session client-ip client-ip fe80::60bb:6a:38cc:6b03
session-id 25740 client-mac 08:00:27:44:cd:23

vpp# show pppoe session
...
[1] sw-if-index 5 client-ip fe80::60bb:6a:38cc:6b03 session-id 25740
encap-if-index 1 decap-fib-index 0 local-mac 08:00:27:47:6e:4b
client-mac 08:00:27:44:cd:23

So far its fine.

Next I need to allocate a block of IPv6 address to the PPPoE client
using DHCP-PD.

When a block of IP address is allocated to a PPPoE client, how does
the routing work? How will VPP route the packets, ingress from north,
belonging to a network, to correct PPPoE encapsulation, including MAC
and PPPoE ID?

I guess I am missing some routing command here.

Thanks and Regards,

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

View/Reply Online (#12912): https://lists.fd.io/g/vpp-dev/message/12912
Mute This Topic: https://lists.fd.io/mt/31456403/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] TESTING in progress: May see job failures over the next 2 hours

2019-05-02 Thread Ed Kern via Lists.Fd.Io

testing is continuing on and off but to this point I don’t think we have seen 
job failures only
jobs occasionally queuing ….

debug continues

Ed



> On May 2, 2019, at 10:19 AM, Ed Kern via Lists.Fd.Io 
>  wrote:
> 
> 
> In an attempt to work around the LF   HA-proxy to debug csit job connectivity 
> issues I have to
> ‘hardwire’ connections (or attempt to do so at any rate) directly back to the 
> jenkins IP.
> 
> No real idea if it will work or if there will be any side impact…ill be hand 
> cranking a job or two
> in an attempt to test….
> 
> 
> Ill send another note if I finish early or if I need to extend past two hours.
> 
> thanks,
> 
> Ed
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12911): https://lists.fd.io/g/vpp-dev/message/12911
> Mute This Topic: https://lists.fd.io/mt/31456357/675649
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [e...@cisco.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#12913): https://lists.fd.io/g/vpp-dev/message/12913
Mute This Topic: https://lists.fd.io/mt/31456357/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] Routing of ipv6 packets over PPPoE

2019-05-02 Thread Ole Troan

Hi Raj,

> Hello all,
> 
> I have PPPoE working successfully over IPv4, and able to ping outside.
> IPv6 negotiation by control plane is successful and an IPv6 session is
> created using the following command:
> 
> create pppoe session client-ip client-ip fe80::60bb:6a:38cc:6b03
> session-id 25740 client-mac 08:00:27:44:cd:23
> 
> vpp# show pppoe session
> ...
> [1] sw-if-index 5 client-ip fe80::60bb:6a:38cc:6b03 session-id 25740
> encap-if-index 1 decap-fib-index 0 local-mac 08:00:27:47:6e:4b
> client-mac 08:00:27:44:cd:23
> 
> So far its fine.
> 
> Next I need to allocate a block of IPv6 address to the PPPoE client
> using DHCP-PD.
> 
> When a block of IP address is allocated to a PPPoE client, how does
> the routing work? How will VPP route the packets, ingress from north,
> belonging to a network, to correct PPPoE encapsulation, including MAC
> and PPPoE ID?
> 
> I guess I am missing some routing command here.

Is this a DHCPv6 PD server running on the VPP instance?
Or is it operating as a relay?
If so I tihnk we covered most of the alternatives in
https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00

Which long go has expired.

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

View/Reply Online (#12914): https://lists.fd.io/g/vpp-dev/message/12914
Mute This Topic: https://lists.fd.io/mt/31456403/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] TESTING in progress: May see job failures over the next 2 hours

2019-05-02 Thread Ed Kern via Lists.Fd.Io

done testing….depending on how the csit jobs run (or stop) this evening we may 
have to restart
jenkins friday am to have a jenkins configuration change become active.

Ill follow up tomorrow am.

Ed




> On May 2, 2019, at 12:06 PM, Ed Kern via Lists.Fd.Io 
>  wrote:
> 
> testing is continuing on and off but to this point I don’t think we have seen 
> job failures only
> jobs occasionally queuing ….
> 
> debug continues
> 
> Ed
> 
> 
> 
>> On May 2, 2019, at 10:19 AM, Ed Kern via Lists.Fd.Io 
>>  wrote:
>> 
>> 
>> In an attempt to work around the LF   HA-proxy to debug csit job 
>> connectivity issues I have to
>> ‘hardwire’ connections (or attempt to do so at any rate) directly back to 
>> the jenkins IP.
>> 
>> No real idea if it will work or if there will be any side impact…ill be hand 
>> cranking a job or two
>> in an attempt to test….
>> 
>> 
>> Ill send another note if I finish early or if I need to extend past two 
>> hours.
>> 
>> thanks,
>> 
>> Ed
>> 
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#12911): https://lists.fd.io/g/vpp-dev/message/12911
>> Mute This Topic: https://lists.fd.io/mt/31456357/675649
>> Group Owner: vpp-dev+ow...@lists.fd.io
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [e...@cisco.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12913): https://lists.fd.io/g/vpp-dev/message/12913
> Mute This Topic: https://lists.fd.io/mt/31456357/675649
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [e...@cisco.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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

[vpp-dev] GARP support in VPP

[vpp-dev] vpp dpdk crypto dev - are multiple crypto algorithms supported concurrently? #vpp

[vpp-dev] HQoS- Traffic shaping - Pipe profiles

[vpp-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Re: [vpp-dev] [FD.io Helpdesk #74794] Jenkins.fd.io network issues - CSIT-1904 rls showstopper [CRITICAL]

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

[vpp-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Re: [vpp-dev] [FD.io Helpdesk #74794] Jenkins.fd.io network issues - CSIT-1904 rls showstopper [CRITICAL]

[vpp-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

[vpp-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Re: [vpp-dev] [FD.io Helpdesk #74794] Jenkins.fd.io network issues - CSIT-1904 rls showstopper [CRITICAL]

[vpp-dev] query on vpp/frr integration.

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

[vpp-dev] VLAN Sub-interface without "exact-match" forward \ send packets without MAC header #vpp #vpp

[vpp-dev] TESTING in progress: May see job failures over the next 2 hours

[vpp-dev] Routing of ipv6 packets over PPPoE

Re: [vpp-dev] TESTING in progress: May see job failures over the next 2 hours

Re: [vpp-dev] Routing of ipv6 packets over PPPoE

Re: [vpp-dev] TESTING in progress: May see job failures over the next 2 hours

21 matches

Site Navigation

Mail list logo

Footer information