Re: [vpp-dev] Static ARP Flag Question

[John Lo (loj)]

Hi Jon,

I am in the process of fixing up something in handling of IP neighbor pools.  I 
can include fixing the S/D bits of ARP flag in my patch, if you are not in a 
hurry to have this fixed.

Regards,
John

From: Jon Loeliger 
Sent: Friday, May 11, 2018 12:09 PM
To: John Lo (loj) 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Static ARP Flag Question

On Thu, May 10, 2018 at 7:28 PM, John Lo (loj) 
> wrote:
Hi Jon,

Hi John,

This is not the right behavior.

I had that suspicion... :-)

  I think it is caused by reuse of a static ARP entry in  the IP4 neighbor pool 
with static bit still set.  The code merely set the dynamic bit in the flags 
but left the static bit untouched (similarly for the static path) in arp.c 
function vnet_arp_set_ip4_over_ethernet_internal ():

  e->time_last_updated = vlib_time_now (vm);
  if (is_static)
e->flags |= ETHERNET_ARP_IP4_ENTRY_FLAG_STATIC;
  else
e->flags |= ETHERNET_ARP_IP4_ENTRY_FLAG_DYNAMIC;

Ah, right.  So it should always be one or the other, and never both.  Right?

I spotted another error in the function 
vnet_arp_flush_ip4_over_ethernet_internal()

 if (e->flags & ETHERNET_ARP_IP4_ENTRY_FLAG_STATIC)
{
  e->flags &= ETHERNET_ARP_IP4_ENTRY_FLAG_DYNAMIC;
}
  else if (e->flags & ETHERNET_ARP_IP4_ENTRY_FLAG_DYNAMIC)
{
  arp_entry_free (eai, e);
}

I believe the “if static” path should be:
  e->flags &= ~ETHERNET_ARP_IP4_ENTRY_FLAG_DYNAMIC;

Would you like to submit a patch to fix them?

Sure!  I will make a first-effort and submit a patch!

jdl

[vpp-dev] VPP automatic restart

[Demian Pecile]

Hi
It’s possible to configure VPP to restart if the process hang ?

Thanks


--
Demian Pecile
Siete Capas S.R.L.
Periodistas Neuquinos 136
Piso 4 - Dpto. A - 8300 Neuquen
Argentina
Tel +54-299-4479172 
Cel. +549-299-5833500

Re: [vpp-dev] gerrit.fd.io froblem access

[Florin Coras]

Depending on the DNS server, the answer is different … 

$ dig +nocmd +noall +answer gerrit.fd.io
gerrit.fd.io.   5   IN  CNAME   dev.fd.io.
dev.fd.io.  5   IN  A   162.253.54.31
$ dig +nocmd +noall +answer gerrit.fd.io @8.8.8.8
gerrit.fd.io.   5   IN  CNAME   awscloud.fd.io.
awscloud.fd.io. 5   IN  A   52.10.107.188

Florin

> On May 15, 2018, at 3:03 PM, Florin Coras  wrote:
> 
> I’m getting in Chrome NET::ERR_CERT_COMMON_NAME_INVALID
> 
> And dig says: 
> 
> ;; ANSWER SECTION:
> gerrit.fd.io .  5   IN  CNAME   
> dev.fd.io .
> dev.fd.io .5   IN  A   
> 162.253.54.31
> 
> Florin
> 
> 
>> On May 15, 2018, at 2:50 PM, Dave Barach > > wrote:
>> 
>> You might check your DNS result for gerrit.fd.io . 
>> Here's what I see, as of a minute ago: 
>> 
>> $ dig gerrit.fd.io 
>> 
>> ; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> gerrit.fd.io 
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2545
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 65494
>> ;; QUESTION SECTION:
>> ;gerrit.fd.io .IN  A
>> 
>> ;; ANSWER SECTION:
>> gerrit.fd.io . 203 IN  CNAME   
>> awscloud.fd.io .
>> awscloud.fd.io . 7103IN  A   
>> 52.10.107.188
>> 
>> ;; Query time: 0 msec
>> ;; SERVER: 127.0.0.53#53(127.0.0.53)
>> ;; WHEN: Tue May 15 17:48:54 EDT 2018
>> ;; MSG SIZE  rcvd: 80
>> 
>> I see no issue with the certificate being offered by [the above version of] 
>> gerrit.fd.io .
>> 
>> HTH... Dave
>> 
>> -Original Message-
>> From: vpp-dev@lists.fd.io  > > On Behalf Of Alexey
>> Sent: Tuesday, May 15, 2018 5:17 PM
>> To: vpp-dev >
>> Subject: [vpp-dev] gerrit.fd.io  froblem access
>> 
>> The source code repositaries is problem access. 
>> 
>> 
>> Your connection is not secure
>> 
>> The owner of gerrit.fd.io  has configured their 
>> website improperly. To protect your information from being stolen, Firefox 
>> has not connected to this website.
>> 
>> This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox 
>> may only connect to it securely. As a result, it is not possible to add an 
>> exception for this certificate.
>> 
>> 
>> 
>> gerrit.fd.io  uses an invalid security certificate.
>> 
>> The certificate is only valid for docs.fd.io 
>> 
>> Error code: SSL_ERROR_BAD_CERT_DOMAIN
>> 
>> The bypass error is returned blank page.
>> 
>> 
>> 
>> 
> 
> 

Re: [vpp-dev] gerrit.fd.io froblem access

[Demian Pecile]

Its working fine from here.

Chrome 67.0.3396.40 (Build oficial) beta (64 bits) mac os x, and Safari Versión 
11.1 (13605.1.33.1.4)

Regards.

Demian

> El 15 may. 2018, a las 18:16, Alexey  
> escribió:
> 
> The source code repositaries is problem access. 
> 
> 
> Your connection is not secure
> 
> The owner of gerrit.fd.io has configured their website improperly. To protect 
> your information from being stolen, Firefox has not connected to this website.
> 
> This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox 
> may only connect to it securely. As a result, it is not possible to add an 
> exception for this certificate.
> 
> 
> 
> gerrit.fd.io uses an invalid security certificate.
> 
> The certificate is only valid for docs.fd.io
> 
> Error code: SSL_ERROR_BAD_CERT_DOMAIN
> 
> The bypass error is returned blank page.
> 
> 
> 

--
Demian Pecile
Siete Capas S.R.L.
Periodistas Neuquinos 136
Piso 4 - Dpto. A - 8300 Neuquen
Argentina
Tel +54-299-4479172 
Cel. +549-299-5833500

Re: [vpp-dev] gerrit.fd.io froblem access

[Florin Coras]

I’m getting in Chrome NET::ERR_CERT_COMMON_NAME_INVALID

And dig says: 

;; ANSWER SECTION:
gerrit.fd.io.   5   IN  CNAME   dev.fd.io.
dev.fd.io.  5   IN  A   162.253.54.31

Florin


> On May 15, 2018, at 2:50 PM, Dave Barach  wrote:
> 
> You might check your DNS result for gerrit.fd.io . 
> Here's what I see, as of a minute ago: 
> 
> $ dig gerrit.fd.io 
> 
> ; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> gerrit.fd.io 
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2545
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 65494
> ;; QUESTION SECTION:
> ;gerrit.fd.io . IN  A
> 
> ;; ANSWER SECTION:
> gerrit.fd.io .  203 IN  CNAME   
> awscloud.fd.io .
> awscloud.fd.io .  7103IN  A   
> 52.10.107.188
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.53#53(127.0.0.53)
> ;; WHEN: Tue May 15 17:48:54 EDT 2018
> ;; MSG SIZE  rcvd: 80
> 
> I see no issue with the certificate being offered by [the above version of] 
> gerrit.fd.io .
> 
> HTH... Dave
> 
> -Original Message-
> From: vpp-dev@lists.fd.io   > On Behalf Of Alexey
> Sent: Tuesday, May 15, 2018 5:17 PM
> To: vpp-dev >
> Subject: [vpp-dev] gerrit.fd.io  froblem access
> 
> The source code repositaries is problem access. 
> 
> 
> Your connection is not secure
> 
> The owner of gerrit.fd.io has configured their website improperly. To protect 
> your information from being stolen, Firefox has not connected to this website.
> 
> This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox 
> may only connect to it securely. As a result, it is not possible to add an 
> exception for this certificate.
> 
> 
> 
> gerrit.fd.io uses an invalid security certificate.
> 
> The certificate is only valid for docs.fd.io
> 
> Error code: SSL_ERROR_BAD_CERT_DOMAIN
> 
> The bypass error is returned blank page.
> 
> 
> 
> 
> 

Re: [vpp-dev] gerrit.fd.io froblem access

[Dave Barach]

You might check your DNS result for gerrit.fd.io. Here's what I see, as of a 
minute ago: 

$ dig gerrit.fd.io

; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> gerrit.fd.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2545
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;gerrit.fd.io.  IN  A

;; ANSWER SECTION:
gerrit.fd.io.   203 IN  CNAME   awscloud.fd.io.
awscloud.fd.io. 7103IN  A   52.10.107.188

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue May 15 17:48:54 EDT 2018
;; MSG SIZE  rcvd: 80

I see no issue with the certificate being offered by [the above version of] 
gerrit.fd.io.

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Alexey
Sent: Tuesday, May 15, 2018 5:17 PM
To: vpp-dev 
Subject: [vpp-dev] gerrit.fd.io froblem access

The source code repositaries is problem access. 


Your connection is not secure

The owner of gerrit.fd.io has configured their website improperly. To protect 
your information from being stolen, Firefox has not connected to this website.

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox 
may only connect to it securely. As a result, it is not possible to add an 
exception for this certificate.



gerrit.fd.io uses an invalid security certificate.

The certificate is only valid for docs.fd.io

Error code: SSL_ERROR_BAD_CERT_DOMAIN

The bypass error is returned blank page.




-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9293): https://lists.fd.io/g/vpp-dev/message/9293
View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/19238145
Mute This Topic: https://lists.fd.io/mt/19238145/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] gerrit.fd.io froblem access

[Alexey]

The source code repositaries is problem access. 


Your connection is not secure

The owner of gerrit.fd.io has configured their website improperly. To protect 
your information from being stolen, Firefox has not connected to this website.

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox 
may only connect to it securely. As a result, it is not possible to add an 
exception for this certificate.



gerrit.fd.io uses an invalid security certificate.

The certificate is only valid for docs.fd.io

Error code: SSL_ERROR_BAD_CERT_DOMAIN

The bypass error is returned blank page.

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9292): https://lists.fd.io/g/vpp-dev/message/9292
View All Messages In Topic (1): https://lists.fd.io/g/vpp-dev/topic/19238145
Mute This Topic: https://lists.fd.io/mt/19238145/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP 18.01.2 Release scheduled for Thursday May 17

[Dave Wallace]

Folks,

VPP 18.01.2 Release is now scheduled for Thursday May 17.

Thanks,
-daw-

On 3/28/18 11:33 PM, Dave Wallace wrote:

Folks,

Due to ongoing 18.01 CSIT Performance testing and bug fixes, the VPP 
18.01.2 Release is being postponed.  The tentative release date is now 
Thursday April 19, 2018 or Thursday May 10, 2018 depending on the 
availability of CSIT resources.


Thanks,
-daw-

On 03/22/2018 11:21 AM, Dave Wallace wrote:

Folks,

Per the discussion at this week's VPP Bi-weekly Meeting, there have 
been enough bug fixes committed to VPP stable/1801 since the release 
of VPP 18.01.1 to merit another maintenance release for VPP 18.01.


VPP 18.01.2 Release is scheduled for next Thursday March 29, 2018. 
This is a maintenance release, thus only bug fixes are allowed.  
Please remember to create a Jira ticket for each bug fix and include 
the Jira ID in the first line of the commit message.


If you are working on a bug fix that you would like to be included in 
VPP 18.01.2, then please reply to this email and ensure that it is 
published no later than Tuesday March 27, 2018 to allow time for 
review. I will begin the release process on Wed March 28th at 9am 
PDT/12pm EDT.


Thanks,
-daw-

Re: [vpp-dev] question about the VCL

[Florin Coras]

Xyxue,

VCL hasn’t yet been updated to work in dgram mode. Try the builtin udp echo 
client/server or tests/vnet/session/udp_echo. Note however that you can’t 
expect udp to deliver all the bytes from one end to the other because of packet 
drops so try half-duplex testing. For some examples see [1].

Florin

[1] https://wiki.fd.io/view/VPP/HostStack/EchoClientServer 


> On May 14, 2018, at 11:59 PM, xyxue  wrote:
> 
> 
> Hi Florin， Ed，
> 
> I'm testing VCL , and the IPPROTO_RAW is a test case .Since it is not 
> supported ,I'm testing the UDP mode:
> 
> server:./vcl_test_server -D 2
> client:./vcl_test_client -D 2.1.1.1 2 
> 
> An assert occure when client startup. More info is shown below:
> DBGvpp# 0: /home/vpp/build-data/../src/vnet/session/session_node.c:214 
> (session_tx_fill_buffer) assertion `n_bytes_read > 0' fails
> 
> Thread 1 "vpp_main" received signal SIGABRT, Aborted.
> 0x75c39428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x75c39428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x75c3b02a in __GI_abort () at abort.c:89
> #2  0x004074de in os_panic () at 
> /home/vpp/build-data/../src/vpp/vnet/main.c:310
> #3  0x764202be in debugger () at 
> /home/vpp/build-data/../src/vppinfra/error.c:84
> #4  0x764206f6 in _clib_error (how_to_die=2, function_name=0x0, 
> line_number=0, fmt=0x774e8b18 "%s:%d (%s) assertion `%s' fails")
> at /home/vpp/build-data/../src/vppinfra/error.c:143
> #5  0x771d2d48 in session_tx_fill_buffer (vm=0x77b8a980 
> , ctx=0x7fffb61e1100, b=0x7ffe87338a80, 
> n_bufs=0x7fffb6aaf996, 
> peek_data=0 '\000') at 
> /home/vpp/build-data/../src/vnet/session/session_node.c:214
> #6  0x771d3e34 in session_tx_fifo_read_and_snd_i (vm=0x77b8a980 
> , node=0x7fffb6bb2900, e=0x7fffb63b1dd0, 
> s=0x7fffb6149c80, n_tx_packets=0x7fffb6aafb4c, peek_data=0 '\000') at 
> /home/vpp/build-data/../src/vnet/session/session_node.c:449
> #7  0x771d4847 in session_tx_fifo_dequeue_and_snd (vm=0x77b8a980 
> , node=0x7fffb6bb2900, e0=0x7fffb63b1dd0, 
> s0=0x7fffb6149c80, n_tx_pkts=0x7fffb6aafb4c) at 
> /home/vpp/build-data/../src/vnet/session/session_node.c:536
> #8  0x771d567c in session_queue_node_fn (vm=0x77b8a980 
> , node=0x7fffb6bb2900, frame=0x0)
> at /home/vpp/build-data/../src/vnet/session/session_node.c:789
> #9  0x778de072 in dispatch_node (vm=0x77b8a980 
> , node=0x7fffb6bb2900, type=VLIB_NODE_TYPE_INPUT, 
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x0, 
> last_time_stamp=2385171693806) at /home/vpp/build-data/../src/vlib/main.c:988
> #10 0x778dff5f in vlib_main_or_worker_loop (vm=0x77b8a980 
> , is_main=1) at /home/vpp/build-data/../src/vlib/main.c:1505
> #11 0x778e0a12 in vlib_main_loop (vm=0x77b8a980 
> ) at /home/vpp/build-data/../src/vlib/main.c:1633
> #12 0x778e1438 in vlib_main (vm=0x77b8a980 , 
> input=0x7fffb6aaffb0) at /home/vpp/build-data/../src/vlib/main.c:1787
> #13 0x7794e264 in thread0 (arg=140737349462400) at 
> /home/vpp/build-data/../src/vlib/unix/main.c:568
> #14 0x76445090 in clib_calljmp () at 
> /home/vpp/build-data/../src/vppinfra/longjmp.S:110
> #15 0x7fffd1c0 in ?? ()
> #16 0x7794e6e5 in vlib_unix_main (argc=3, argv=0x7fffe418) at 
> /home/vpp/build-data/../src/vlib/unix/main.c:632
> #17 0x00406f22 in main (argc=3, argv=0x7fffe418) at 
> /home/vpp/build-data/../src/vpp/vnet/main.c:249
> (gdb) 
> 
> Is there anything I can do to fix it?
> 
> Thanks,
> Xyxue
> 
> 

Re: [vpp-dev] problem in xcrw testing

[John Lo (loj)]

The GRE tunnel needs to be put in L2 mode so it can be a valid l2-output 
interface. You can do that by putting the GRE tunnel into a bridge domain, or 
xconnect it to peer interface:

vpp# set int l2  bri ?
  set interface l2 bridge  set interface l2 bridge  
 [bvi] [shg]
vpp# set int l2 xconnect ?
  set interface l2 xconnectset interface l2 xconnect 
 

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of xyxue
Sent: Tuesday, May 15, 2018 8:10 AM
To: Neale Ranns (nranns) ; vpp-dev 
Subject: Re: [vpp-dev] problem in xcrw testing


Hi Neale，

After I changed my configuration (the configuration and the trace info is shown 
below)

create host-interface name eth1 mac 00:50:56:3a:32:d2
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb
set interface l2 xcrw host-eth5 next teb-gre0-output rw 
4558fd2fa5720b0101020b0101016558


VPP# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:01:18:847131: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5afaa73c nsec 0x2c4032d7 vlan 0
00:01:18:847197: ethernet-input
  IP4: 00:50:56:c0:00:05 -> 00:50:56:c0:00:04
00:01:18:847305: l2-input
  l2-input: sw_if_index 2 dst 00:50:56:c0:00:04 src 00:50:56:c0:00:05
00:01:18:847323: l2-output
  l2-output: sw_if_index 4 dst 00:50:56:c0:00:04 src 00:50:56:c0:00:05 data 08 
00 45 01 00 40 00 01 00 00 40 01
00:01:18:847336: error-drop
  l2-output: L2 Output interface not valid


It doesn't seem to be in effect. Is there something I missed?


Thanks,
Xyxue


From: Neale Ranns
Date: 2018-05-15 15:58
To: 薛欣颖; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] problem in xcrw testing
Hi Xyxue,

The GRE tunnel needs to be in L2 mode, which in the case of GRE is known as 
‘transparent ethernet bridging’. So:
  create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb

/neale




From: > on behalf of xyxue 
>
Date: Tuesday, 15 May 2018 at 08:50
To: "vpp-dev@lists.fd.io" 
>
Subject: [vpp-dev] problem in xcrw testing


Hi guys，

I’m testing the xcrw . But the packet were 'error-drop'. My configuration and 
trace info is shown below:

create host-interface name eth1 mac 00:50:56:3a:32:d2
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1
set interface ip address gre0 100.1.1.2/24
VPP# set interface l2 xcrw host-eth5 next gre4-input rw 
4558fd2fa5720b0101020b0101016558
VPP# set interface l2 xcrw xcrw0 next host-eth1-output rw 1234

VPP# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:00:22:692356: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5af559c7 nsec 0x8bb04a9 vlan 0
00:00:22:692493: ethernet-input
  IP4: 00:50:56:c0:00:05 -> 00:50:56:31:35:92
00:00:22:692706: l2-input
  l2-input: sw_if_index 2 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05
00:00:22:692724: l2-output
  l2-output: sw_if_index 4 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05 data 08 
00 45 01 00 40 00 01 00 00 40 01
00:00:22:692737: l2-xcrw
  L2_XCRW: next index 1 tx_fib_index -1
00:00:22:692753: gre4-input
  GRE: tunnel 0 len 88 src 11.1.1.2 dst 11.1.1.1
00:00:22:692771: error-drop
  gre4-input: GRE input packets dropped due to missing tunnel

Is there any problem in my configuration?

Thanks，
Xyxue

Re: [vpp-dev] problem in xcrw testing

[xyxue]

Hi Neale，

After I changed my configuration (the configuration and the trace info is shown 
below) 

create host-interface name eth1 mac 00:50:56:3a:32:d2 
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb
set interface l2 xcrw host-eth5 next teb-gre0-output rw 
4558fd2fa5720b0101020b0101016558

VPP# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:01:18:847131: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5afaa73c nsec 0x2c4032d7 vlan 0
00:01:18:847197: ethernet-input
  IP4: 00:50:56:c0:00:05 -> 00:50:56:c0:00:04
00:01:18:847305: l2-input
  l2-input: sw_if_index 2 dst 00:50:56:c0:00:04 src 00:50:56:c0:00:05
00:01:18:847323: l2-output
  l2-output: sw_if_index 4 dst 00:50:56:c0:00:04 src 00:50:56:c0:00:05 data 08 
00 45 01 00 40 00 01 00 00 40 01
00:01:18:847336: error-drop
  l2-output: L2 Output interface not valid

It doesn't seem to be in effect. Is there something I missed?

Thanks,
Xyxue


 
From: Neale Ranns
Date: 2018-05-15 15:58
To: 薛欣颖; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] problem in xcrw testing
Hi Xyxue,
 
The GRE tunnel needs to be in L2 mode, which in the case of GRE is known as 
‘transparent ethernet bridging’. So:
  create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb
 
/neale

 
 
From:  on behalf of xyxue 
Date: Tuesday, 15 May 2018 at 08:50
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] problem in xcrw testing
 
 
Hi guys，

I’m testing the xcrw . But the packet were 'error-drop'. My configuration and 
trace info is shown below:

create host-interface name eth1 mac 00:50:56:3a:32:d2 
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1
set interface ip address gre0 100.1.1.2/24
VPP# set interface l2 xcrw host-eth5 next gre4-input rw 
4558fd2fa5720b0101020b0101016558
VPP# set interface l2 xcrw xcrw0 next host-eth1-output rw 1234

VPP# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:00:22:692356: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5af559c7 nsec 0x8bb04a9 vlan 0
00:00:22:692493: ethernet-input
  IP4: 00:50:56:c0:00:05 -> 00:50:56:31:35:92
00:00:22:692706: l2-input
  l2-input: sw_if_index 2 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05
00:00:22:692724: l2-output
  l2-output: sw_if_index 4 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05 data 08 
00 45 01 00 40 00 01 00 00 40 01
00:00:22:692737: l2-xcrw
  L2_XCRW: next index 1 tx_fib_index -1
00:00:22:692753: gre4-input
  GRE: tunnel 0 len 88 src 11.1.1.2 dst 11.1.1.1
00:00:22:692771: error-drop
  gre4-input: GRE input packets dropped due to missing tunnel
  
Is there any problem in my configuration?
  
Thanks，
Xyxue

[vpp-dev] Marvell's AI from last call

[Natalie Samsonov]

 Hi,

1.  We are working now on upstreaming Marvell's PMD support in VPP DPDK 
plugin.
   I'm attaching the patch as well in case you want play with it.

2.  Regarding the L3FWD performance difference between MUSDK and DPDK, 
currently we don't have numbers with VPP L3FW.
We only have  the numbers with two different applications. One is our own L3FW 
application running on top of MUSDK and other is a standard DPDL L3FWD 
application, so it's not a fair comparison.

Best Regards,
Natalie Samsonov





0001-plugins-dpdk-Add-support-for-net_mrvl-dpdk-driver.patch
Description: 0001-plugins-dpdk-Add-support-for-net_mrvl-dpdk-driver.patch

Re: [vpp-dev] Query on VPP behaviour when IP from same subnet configured on plain and vlan interface

[bindiya Kurle]

Hi Ole,
Thanks for pointers for IPv6.

"Are you saying that the following works in Linux:"
[Bindiya] : Yes .Little change to your configuration below

192.0.2.1/24 -> Eth0
192.0.2.2/24 -> *Eth0.111*(vlan interface on eth0)



Or are you saying that Linux ignores the second entry and just uses the
first entry in the FIB?
[Bindiya ] : in this config yes , ping to destination IP 192.0.2.10(VLAN)
will go on plain interface (ARP resolved on plain interface)
In VPP arp will be generated on VLAN interface

 What then happens with the 192.0.2.2 address?
[Bindiya ] : wrt Linux 192.0.2.2 it will be ignored
   wrt VPP it will use vlan interface.

workaround will be to add static route.
As suggested earlier this seems to be invalid scenario. Thanks for the help
.

Regards,
Bindiya
---

Are you saying that the following works in Linux:

192.0.2.1/24 -> Eth0
192.0.2.2/24 -> Eth1

Where Eth0 and Eth1 are connected to the same L2.

Or are you saying that Linux ignores the second entry and just uses the
first entry in the FIB?
What then happens with the 192.0.2.2 address?


Below is the configuration that test case was doing:
.
13.0.0.200 ---|GigabitEthernet1/0/0 (plain
interface)13.0.0.2
  |
GigabitEthernet1/0/0.111(vlan interface)13.0.0.5packet to send out
destination IP (13.0.0.200)

In this configuration , Ping to the same destination IP(IP: 13.0.0.200)
works (in Linux)as kernel pick up the plain interface route since that is
the 1st route in its routing table.

But VPP ends up requesting ARP(IP: 13.0.0.200) on a VLAN interface which
fails since the ARP is reachable only via the plain interface.



Regards,

Bindiya



On Tue, May 15, 2018 at 1:00 PM, Ole Troan  wrote:

> Hi Bindiya,
>
> > Linux had allowed this configuration and test cases which were running
> on Linux failed on VPP.
> > The reason why it had passed is that linux always picks up the 1st entry
> that gets added in routing table i.e. plain interface while in VPP fib
> entry always return last interface that get added. Hence was curious if
> this was intentional?
>
> Are you saying that the following works in Linux:
>
> 192.0.2.1/24 -> Eth0
> 192.0.2.2/24 -> Eth1
>
> Where Eth0 and Eth1 are connected to the same L2.
>
> Or are you saying that Linux ignores the second entry and just uses the
> first entry in the FIB?
> What then happens with the 192.0.2.2 address?
>
> > Your point "While IPv6 notionally has support for that" is this from the
> RFC, could you please direct me to that?
>
> Look for "inbound load balancing" and "same link" in RFC4861 and RFC4862.
> It is pretty hand-wavy. E.g. it could be implemented as a new virtual
> interface hiding the two underlaying physical interfaces.
>
> Cheers,
> Ole
>

Re: [vpp-dev] problem in xcrw testing

[Neale Ranns]

Hi Xyxue,

The GRE tunnel needs to be in L2 mode, which in the case of GRE is known as 
‘transparent ethernet bridging’. So:
  create gre tunnel src 11.1.1.2 dst 11.1.1.1 teb

/neale



From:  on behalf of xyxue 
Date: Tuesday, 15 May 2018 at 08:50
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] problem in xcrw testing


Hi guys，

I’m testing the xcrw . But the packet were 'error-drop'. My configuration and 
trace info is shown below:

create host-interface name eth1 mac 00:50:56:3a:32:d2
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1
set interface ip address gre0 100.1.1.2/24
VPP# set interface l2 xcrw host-eth5 next gre4-input rw 
4558fd2fa5720b0101020b0101016558
VPP# set interface l2 xcrw xcrw0 next host-eth1-output rw 1234

VPP# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:00:22:692356: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5af559c7 nsec 0x8bb04a9 vlan 0
00:00:22:692493: ethernet-input
  IP4: 00:50:56:c0:00:05 -> 00:50:56:31:35:92
00:00:22:692706: l2-input
  l2-input: sw_if_index 2 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05
00:00:22:692724: l2-output
  l2-output: sw_if_index 4 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05 data 08 
00 45 01 00 40 00 01 00 00 40 01
00:00:22:692737: l2-xcrw
  L2_XCRW: next index 1 tx_fib_index -1
00:00:22:692753: gre4-input
  GRE: tunnel 0 len 88 src 11.1.1.2 dst 11.1.1.1
00:00:22:692771: error-drop
  gre4-input: GRE input packets dropped due to missing tunnel

Is there any problem in my configuration?

Thanks，
Xyxue

Re: [vpp-dev] Query on VPP behaviour when IP from same subnet configured on plain and vlan interface

[Ole Troan]

Hi Bindiya,

> Linux had allowed this configuration and test cases which were running on 
> Linux failed on VPP.
> The reason why it had passed is that linux always picks up the 1st entry that 
> gets added in routing table i.e. plain interface while in VPP fib entry 
> always return last interface that get added. Hence was curious if this was 
> intentional?

Are you saying that the following works in Linux:

192.0.2.1/24 -> Eth0
192.0.2.2/24 -> Eth1

Where Eth0 and Eth1 are connected to the same L2.

Or are you saying that Linux ignores the second entry and just uses the first 
entry in the FIB?
What then happens with the 192.0.2.2 address?

> Your point "While IPv6 notionally has support for that" is this from the RFC, 
> could you please direct me to that?

Look for "inbound load balancing" and "same link" in RFC4861 and RFC4862.
It is pretty hand-wavy. E.g. it could be implemented as a new virtual interface 
hiding the two underlaying physical interfaces.

Cheers,
Ole

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9284): https://lists.fd.io/g/vpp-dev/message/9284
View All Messages In Topic (6): https://lists.fd.io/g/vpp-dev/topic/18621611
Mute This Topic: https://lists.fd.io/mt/18621611/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: Message signed with OpenPGP

Re: [vpp-dev] Using custom openssl with vpp #vpp

[ductm18]

Hi Florin,

Yep, that works. After adding some flags into the .am file, I can link the 
openssl plugin with openssl 1.1.
Thank you!

DucTM

Re: [vpp-dev] question about the VCL

[xyxue]

Hi Florin， Ed，

I'm testing VCL , and the IPPROTO_RAW is a test case .Since it is not supported 
,I'm testing the UDP mode:

server:./vcl_test_server -D 2
client:./vcl_test_client -D 2.1.1.1 2 

An assert occure when client startup. More info is shown below:
DBGvpp# 0: /home/vpp/build-data/../src/vnet/session/session_node.c:214 
(session_tx_fill_buffer) assertion `n_bytes_read > 0' fails

Thread 1 "vpp_main" received signal SIGABRT, Aborted.
0x75c39428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x75c39428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x75c3b02a in __GI_abort () at abort.c:89
#2  0x004074de in os_panic () at 
/home/vpp/build-data/../src/vpp/vnet/main.c:310
#3  0x764202be in debugger () at 
/home/vpp/build-data/../src/vppinfra/error.c:84
#4  0x764206f6 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x774e8b18 "%s:%d (%s) assertion `%s' fails")
at /home/vpp/build-data/../src/vppinfra/error.c:143
#5  0x771d2d48 in session_tx_fill_buffer (vm=0x77b8a980 
, ctx=0x7fffb61e1100, b=0x7ffe87338a80, 
n_bufs=0x7fffb6aaf996, 
peek_data=0 '\000') at 
/home/vpp/build-data/../src/vnet/session/session_node.c:214
#6  0x771d3e34 in session_tx_fifo_read_and_snd_i (vm=0x77b8a980 
, node=0x7fffb6bb2900, e=0x7fffb63b1dd0, 
s=0x7fffb6149c80, n_tx_packets=0x7fffb6aafb4c, peek_data=0 '\000') at 
/home/vpp/build-data/../src/vnet/session/session_node.c:449
#7  0x771d4847 in session_tx_fifo_dequeue_and_snd (vm=0x77b8a980 
, node=0x7fffb6bb2900, e0=0x7fffb63b1dd0, 
s0=0x7fffb6149c80, n_tx_pkts=0x7fffb6aafb4c) at 
/home/vpp/build-data/../src/vnet/session/session_node.c:536
#8  0x771d567c in session_queue_node_fn (vm=0x77b8a980 
, node=0x7fffb6bb2900, frame=0x0)
at /home/vpp/build-data/../src/vnet/session/session_node.c:789
#9  0x778de072 in dispatch_node (vm=0x77b8a980 , 
node=0x7fffb6bb2900, type=VLIB_NODE_TYPE_INPUT, 
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x0, 
last_time_stamp=2385171693806) at /home/vpp/build-data/../src/vlib/main.c:988
#10 0x778dff5f in vlib_main_or_worker_loop (vm=0x77b8a980 
, is_main=1) at /home/vpp/build-data/../src/vlib/main.c:1505
#11 0x778e0a12 in vlib_main_loop (vm=0x77b8a980 ) 
at /home/vpp/build-data/../src/vlib/main.c:1633
#12 0x778e1438 in vlib_main (vm=0x77b8a980 , 
input=0x7fffb6aaffb0) at /home/vpp/build-data/../src/vlib/main.c:1787
#13 0x7794e264 in thread0 (arg=140737349462400) at 
/home/vpp/build-data/../src/vlib/unix/main.c:568
#14 0x76445090 in clib_calljmp () at 
/home/vpp/build-data/../src/vppinfra/longjmp.S:110
#15 0x7fffd1c0 in ?? ()
#16 0x7794e6e5 in vlib_unix_main (argc=3, argv=0x7fffe418) at 
/home/vpp/build-data/../src/vlib/unix/main.c:632
#17 0x00406f22 in main (argc=3, argv=0x7fffe418) at 
/home/vpp/build-data/../src/vpp/vnet/main.c:249
(gdb) 

Is there anything I can do to fix it?

Thanks,
Xyxue

Re: [vpp-dev] Query on VPP behaviour when IP from same subnet configured on plain and vlan interface

[bindiya Kurle]

Hi Ole,

Linux had allowed this configuration and test cases which were running on
Linux failed on VPP.
The reason why it had passed is that linux always picks up the 1st entry
that gets added in routing table i.e. plain interface while in VPP fib
entry always return last interface that get added. Hence was curious if
this was intentional?

Your point "While IPv6 notionally has support for that" is this from the
RFC, could you please direct me to that?

Thanks,
Bindiya


On Tue, May 15, 2018 at 12:32 AM, Ole Troan  wrote:

> >  Thanks for the response. Any plans to differ this behaviour in future
> to support multiple interfaces in the same subnet?
>
> How do you intend for that to work?
> (While IPv6 notionally has support for that, as far as I know no
> implementations support it.
>



> Best regards,
> Ole
>
>
>
> 
>
>

[vpp-dev] problem in xcrw testing

[xyxue]

Hi guys，

I’m testing the xcrw . But the packet were 'error-drop'. My configuration and 
trace info is shown below:

create host-interface name eth1 mac 00:50:56:3a:32:d2 
create host-interface name eth5 mac 00:50:56:31:35:92
set interface ip address host-eth1 11.1.1.2/24
create gre tunnel src 11.1.1.2 dst 11.1.1.1
set interface ip address gre0 100.1.1.2/24
VPP# set interface l2 xcrw host-eth5 next gre4-input rw 
4558fd2fa5720b0101020b0101016558
VPP# set interface l2 xcrw xcrw0 next host-eth1-output rw 1234

VPP# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:00:22:692356: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x2001 len 78 snaplen 78 mac 66 net 80
  sec 0x5af559c7 nsec 0x8bb04a9 vlan 0
00:00:22:692493: ethernet-input
  IP4: 00:50:56:c0:00:05 -> 00:50:56:31:35:92
00:00:22:692706: l2-input
  l2-input: sw_if_index 2 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05
00:00:22:692724: l2-output
  l2-output: sw_if_index 4 dst 00:50:56:31:35:92 src 00:50:56:c0:00:05 data 08 
00 45 01 00 40 00 01 00 00 40 01
00:00:22:692737: l2-xcrw
  L2_XCRW: next index 1 tx_fib_index -1
00:00:22:692753: gre4-input
  GRE: tunnel 0 len 88 src 11.1.1.2 dst 11.1.1.1
00:00:22:692771: error-drop
  gre4-input: GRE input packets dropped due to missing tunnel
  
Is there any problem in my configuration?
  
Thanks，
Xyxue