Re: [vpp-dev] FD.io Maintenance: 2021-08-31 15:00 UTC to 1900 UTC

2021-08-31 Thread Vanessa Valderrama 
Our maintenance is running behind schedule. There was a last minute
decision to migrate the instances to YUL1 and avoid another outage next
week.

This required Nexus to migrate as well. We're in the process of
migrating the attached volumes which will take an additional 1.5 to 2 hours.

We appreciate your patience and will send an update when maintenance is
complete

Thank you,

Vanessa

On 8/31/21 7:57 PM, Vanessa Valderrama wrote:
>
> Jenkins is being placed in shutdown mode in preparation for maintenance.
>
>
> On 8/30/21 4:10 PM, Vanessa Valderrama wrote:
>>
>> Maintenance reminder
>>
>> Jenkins will be placed in shutdown mode at 14:00 UTC
>>
>> On 8/27/21 12:55 PM, Vanessa Valderrama wrote:
>>>
>>> *What:*
>>>
>>> In preparation for Jenkins and Ingress to migrate to the new data
>>> center The Linux Foundation will be migrating the instances from V2
>>> to V3 flavors.
>>>
>>> *When:*
>>>
>>> 2021-08-31 15:00 UTC to 1900 UTC
>>>
>>>
>>> *Impact:*
>>>
>>> Due to the Ingress migration, all systems will be unavailable during
>>> the maintenance window.
>>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20056): https://lists.fd.io/g/vpp-dev/message/20056
Mute This Topic: https://lists.fd.io/mt/85192020/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 Maintenance: 2021-08-31 15:00 UTC to 1900 UTC

2021-08-31 Thread Vanessa Valderrama 
Jenkins is being placed in shutdown mode in preparation for maintenance.


On 8/30/21 4:10 PM, Vanessa Valderrama wrote:
>
> Maintenance reminder
>
> Jenkins will be placed in shutdown mode at 14:00 UTC
>
> On 8/27/21 12:55 PM, Vanessa Valderrama wrote:
>>
>> *What:*
>>
>> In preparation for Jenkins and Ingress to migrate to the new data
>> center The Linux Foundation will be migrating the instances from V2
>> to V3 flavors.
>>
>> *When:*
>>
>> 2021-08-31 15:00 UTC to 1900 UTC
>>
>>
>> *Impact:*
>>
>> Due to the Ingress migration, all systems will be unavailable during
>> the maintenance window.
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20055): https://lists.fd.io/g/vpp-dev/message/20055
Mute This Topic: https://lists.fd.io/mt/85192020/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] VPp 2101 (pcap trace)

2021-08-31 Thread Dave Barach 
The following configuration works as expected:

 

set term pag off

loop create

loop create

set int ip address loop0 10.20.36.1/24

set int ip address loop1 10.20.37.1/24

set int state loop0 up

set int state loop1 up

 

packet-generator new {

name s0

limit 10

size 128-128

interface loop0

node ethernet-input

data { IP4: feed.face.000 -> dead.0.0

   UDP: 10.20.36.168 -> 10.20.37.10

   UDP: 1234 -> 2345

   incrementing 114

}

}

packet-generator new {

name s1

limit 10

size 128-128

interface loop1

node ethernet-input

data { IP4: feed.face.001 -> dead.0.1

   UDP: 10.20.37.10 -> 10.20.36.168

   UDP: 1234 -> 2345

   incrementing 114

}

}

 

ip route add 10.20.36.168/32 via drop

ip route add 10.20.37.10/23 via drop

 

 

classify filter pcap mask l3 ip4 src match l3 ip4 src 10.20.37.10

classify filter pcap mask l3 ip4 dst match l3 ip4 dst 10.20.37.10

 

DBGvpp# sh class filter

Filter Used By Table(s)

-- 

packet tracer: first table none

pcap rx/tx/drop:   first table 1

 

DBGvpp# sh cla t index 1 verbose # Note the NextTbl field...

  TableIdx  Sessions   NextTbl  NextNode

 1 1 0-1

  Heap: base 0x7fffaef45000, size 128k, locked, unmap-on-destroy, name 
'classify'

  page stats: page-size 4K, total 32, mapped 2, not-mapped 30

numa 0: 2 pages, 8k bytes

  total: 127.95K, used: 1.38K, free: 126.58K, trimmable: 126.50K

  nbuckets 8, skip 1 match 2 flag 0 offset 0

  mask 

  linear-search buckets 0

 

[4]: heap offset 1280, elts 2, normal

0: [1280]: next_index 0 advance 0 opaque 0 action 0 metadata 0

k: 0a14250a

hits 10, last_heard 0.00

 

1 active elements

1 free lists

0 linear-search buckets

 

DBGvpp# sh cla t index 0 verbose

  TableIdx  Sessions   NextTbl  NextNode

 0 1-1-1

  Heap: base 0x7fffaef66000, size 128k, locked, unmap-on-destroy, name 
'classify'

  page stats: page-size 4K, total 32, mapped 2, not-mapped 30

numa 0: 2 pages, 8k bytes

  total: 127.95K, used: 1.34K, free: 126.61K, trimmable: 126.53K

  nbuckets 8, skip 1 match 1 flag 0 offset 0

  mask 

  linear-search buckets 0

 

[7]: heap offset 1280, elts 2, normal

0: [1280]: next_index 0 advance 0 opaque 0 action 0 metadata 0

k: 0a14250a

hits 10, last_heard 0.00

 

1 active elements

1 free lists

0 linear-search buckets

 

Classification which matches either an ip4 src or and ip4 dst requires two 
(chained) tables, as shown in the example above. 

 

Looking at the output you sent, classifier table 1’s NextTbl field is set to ~0 
which explains why the classification isn’t working. You don’t need to send 
traffic; make sure that you have a two-table chain with the required 
mask/matches installed.

 

If you can come up with a reproducible debug CLI sequence which results in 
incorrect table programming, please send it so we can fix it.

 

Thanks... Dave 

 

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Benoit Ganne 
(bganne) via lists.fd.io
Sent: Tuesday, August 31, 2021 12:36 PM
To: chetan bhasin ; vpp-dev 
Subject: Re: [vpp-dev] VPp 2101 (pcap trace)

 

> Any idea why it's not working? Or what I am doing wrong?

 

I am not sure, it should be working but there might be a bug lurking 
somewhere...

I'll look at it when I have time.

 

Best

ben

 

> On Thu, Aug 26, 2021, 20:59 chetan bhasin  <  mailto:chetan.bhasin...@gmail.com> > 
> wrote:

> 

> 

> Hi Benoit,

> 

> I have tried those options but it is not working , it is only 

> capturing the section classify filter rule that is based on dst ip 

> address.

> 

> 1) Tried with classify filter [Only dest ip with 10.20.36.168 is 

> coming in pcap]

> 

> classify filter pcap mask l3 ip4 src match l3 ip4 src 10.20.36.168

> 

> classify filter pcap mask l3 ip4 dst match l3 ip4 dst 10.20.36.168

> 

> pcap trace rx tx max 100 filter file capture.pcap

> 

> 

> 

> 

> vpp# show classify filter

> 

> Filter Used By Table(s)

> 

> -- 

> 

> packet tracer: first table none

> 

> pcap rx/tx/drop:   first table 1

> 

> 

> 

> 

> vpp# show classify tables index 1 verbose

> 

>   TableIdx  Sessions   NextTbl  NextNode

> 

>  1 1-1-1

> 

>   Heap: base 0x7f5db406c000, size 128k, locked, unmap-on-destroy, 

> name 'classify'

> 

>   page stats: page-size 4K, tot

Re: [vpp-dev] VPp 2101 (pcap trace)

2021-08-31 Thread Benoit Ganne (bganne) via lists.fd.io 
> Any idea why it's not working? Or what I am doing wrong?

I am not sure, it should be working but there might be a bug lurking 
somewhere...
I'll look at it when I have time.

Best
ben

> On Thu, Aug 26, 2021, 20:59 chetan bhasin   > wrote:
> 
> 
>   Hi Benoit,
> 
>   I have tried those options but it is not working , it is only
> capturing the section classify filter rule that is based on dst ip
> address.
> 
>   1) Tried with classify filter [Only dest ip with 10.20.36.168 is
> coming in pcap]
> 
>   classify filter pcap mask l3 ip4 src match l3 ip4 src 10.20.36.168
> 
>   classify filter pcap mask l3 ip4 dst match l3 ip4 dst 10.20.36.168
> 
>   pcap trace rx tx max 100 filter file capture.pcap
> 
> 
> 
> 
>   vpp# show classify filter
> 
>   Filter Used By Table(s)
> 
>   -- 
> 
>   packet tracer: first table none
> 
>   pcap rx/tx/drop:   first table 1
> 
> 
> 
> 
>   vpp# show classify tables index 1 verbose
> 
> TableIdx  Sessions   NextTbl  NextNode
> 
>1 1-1-1
> 
> Heap: base 0x7f5db406c000, size 128k, locked, unmap-on-destroy,
> name 'classify'
> 
> page stats: page-size 4K, total 32, mapped 2, not-mapped
> 0, unknown 30
> 
>   numa 0: 2 pages, 8k bytes
> 
> total: 127.95K, used: 1.31K, free: 126.64K, trimmable:
> 126.56K
> 
> nbuckets 8, skip 1 match 2 flag 0 offset 0
> 
> mask
> 
> 
> linear-search buckets 0
> 
> 
> 
> 
>   [7]: heap offset 1216, elts 2, normal
> 
>   0: [1216]: next_index 0 advance 0 opaque 0 action 0 metadata 0
> 
>   k:
> 0a1424a8
> 
>   hits 45, last_heard 0.00
> 
> 
> 
> 
>   1 active elements
> 
>   1 free lists
> 
>   0 linear-search buckets
> 
> 
> 
> 
>   [root@bfs-dl360g10-47-vm14 ~]# tcpdump -n -r /tmp/capture.pcap
> 
>   reading from file /tmp/capture.pcap, link-type EN10MB (Ethernet)
> 
>   01:00:33.671990 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 9478, length 64
> 
>   01:00:33.672834 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 9478, length 64
> 
>   01:00:33.672839 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 9478, length 64
> 
>   01:00:34.674316 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 9479, length 64
> 
>   01:00:34.675239 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 9479, length 64
> 
>   01:00:34.675239 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 9479, length 64
> 
>   01:00:35.676526 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 9480, length 64
> 
>   01:00:35.676565 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 9480, length 64
> 
>   01:00:35.676566 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 9480, length 64
> 
> 
> 
> 
> 
>   2) Default behaviour without any classify filter .
> 
>   vpp# pcap trace rx tx max 100 file capture.pcap
> 
>   vpp# pcap trace off
> 
>   Write 100 packets to /tmp/capture.pcap, and stop capture...
> 
> 
> 
> 
> 
>   tcpdump -n -r /tmp/capture.pcap |grep ICMP
> 
>   reading from file /tmp/capture.pcap, link-type EN10MB (Ethernet)
> 
>   01:02:36.635239 IP 10.20.36.168 > 10.20.35.126 
> : ICMP echo request, id 26102, seq 11266, length 64
> 
>   01:02:36.636018 IP 10.20.36.168 > 10.20.35.126 
> : ICMP echo request, id 26102, seq 11266, length 64
> 
>   01:02:36.636018 IP 10.20.36.168 > 10.20.35.126 
> : ICMP echo request, id 26102, seq 11266, length 64
> 
>   01:02:36.636108 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 11266, length 64
> 
>   01:02:36.636975 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 11266, length 64
> 
>   01:02:36.636975 IP 10.20.35.126 > 10.20.36.168 
> : ICMP echo reply, id 26102, seq 11266, length 64
> 
> 
> 
> 
>   Regards,
> 
>   Chetan
> 
> 
> 
> 
> 
>   On Thu, Aug 26, 2021 at 6:00 PM chetan bhasin
> mailto:chetan.bhasin...@gmail.com> > wrote:
> 
> 
>   Hi Ben,
> 
>   Thanks for your response . Let me try this and get back to
> you.
> 
>   Thanks,
>   Chetan
> 
>   On Thu, Aug 26, 2021 at 5:52 PM Benoit Ganne (bganne)
> mailto:b

Re: [vpp-dev] VPP plugins in C++

2021-08-31 Thread Dave Barach 
It’s possible, modulo a bunch of easily anticipated header-file and build 
system issues.

FWIW… Dave

> On Aug 31, 2021, at 9:23 AM, Satya Murthy  wrote:
> 
> Hi ,
> 
> Is it possible to develop a vpp plugin in C++ (or) does VPP framework pose 
> any restrictions ? 
> 
> Appreciate your inputs on this.
> 
> -- 
> Thanks & Regards,
> Murthy 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20052): https://lists.fd.io/g/vpp-dev/message/20052
Mute This Topic: https://lists.fd.io/mt/85275658/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 plugins in C++

2021-08-31 Thread Satya Murthy 
Hi ,

Is it possible to develop a vpp plugin in C++ (or) does VPP framework pose any 
restrictions ?

Appreciate your inputs on this.

--
Thanks & Regards,
Murthy

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20051): https://lists.fd.io/g/vpp-dev/message/20051
Mute This Topic: https://lists.fd.io/mt/85275658/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-