Re: [vpp-dev] [vpp-committers] VPP committers: VPP PTL vote

[John Lo (loj) via lists.fd.io]

+1   -John

From: vpp-committ...@lists.fd.io  On Behalf Of Dave 
Barach via lists.fd.io
Sent: Friday, September 25, 2020 3:14 PM
To: vpp-committ...@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-committers] VPP committers: VPP PTL vote

Folks,

The self-nomination period closed yesterday. We had one self-nomination, from 
Damjan Marion. At this point, we can proceed with a vote.

I'm sure that Damjan will do a great job, so let me start:

Damjan Marion as VPP PTL: +1

Please vote +1, 0, -1. For once, the "reply-all" button is everyone's friend.

Thanks... Dave



-Original Message-
From: d...@barachs.net 
mailto:d...@barachs.net>>
Sent: Thursday, September 17, 2020 10:32 AM
To: 'vpp-dev@lists.fd.io' mailto:vpp-dev@lists.fd.io>>; 
't...@lists.fd.io' mailto:t...@lists.fd.io>>
Subject: Happy Trails to Me...



Folks,



I'm departing the employment rolls towards the end of next month. Although I 
intend to remain active in the fd.io vpp community as a coder, committer, and 
resident greybeard, it's time for the community to pick a new PTL.



According to the project governance document, 
https://fd.io/docs/tsc/FD.IO-Technical-Community-Document-12-12-2017.pdf:



3.2.3.1 Project Technical Leader Candidates Candidates for the project's PTL 
will be derived from the Committers of the Project. Candidates must 
self-nominate.



I'd like to invite any interested vpp project committer to self-nominate for 
the PTL role. Please email vpp-dev@lists.fd.io.



Let's close the self-nomination period in one week: more specifically, by 5pm 
EDT on Thursday, September 24, 2020; committer vote to follow thereafter.



I'll be glad to answer unicast questions about the PTL role from eligible 
committers.



Thanks... Dave












-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17533): https://lists.fd.io/g/vpp-dev/message/17533
Mute This Topic: https://lists.fd.io/mt/77125879/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] vlib_add_trace(...) - stop inlining?

[John Lo (loj) via lists.fd.io]

Make sense to me, as saving trace data is already impacting "normal" 
performance. The extra function call is probably not much more overhead.   -John

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
lists.fd.io
Sent: Monday, June 08, 2020 10:13 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vlib_add_trace(...) - stop inlining?

Folks,

It looks to me like inlining vlib_add_trace(...) is probably a mistake in terms 
of code bloat. Does anyone hate the idea of changing it to a standard function?

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

View/Reply Online (#16689): https://lists.fd.io/g/vpp-dev/message/16689
Mute This Topic: https://lists.fd.io/mt/74752449/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 #vnet apparent buffer prefetch issue - seeing "l3 mac mismatch" discards

[John Lo (loj) via lists.fd.io]

Never mind.  I have not caught up to newer messages in the thread when I 
replied.  -John

From: vpp-dev@lists.fd.io  On Behalf Of John Lo (loj) via 
lists.fd.io
Sent: Friday, June 05, 2020 4:40 PM
To: dmar...@me.com; m...@ciena.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] #vpp #vnet apparent buffer prefetch issue - seeing "l3 
mac mismatch" discards

May be it is this one?  https://gerrit.fd.io/r/c/vpp/+/26961   -John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Damjan Marion 
via lists.fd.io
Sent: Friday, June 05, 2020 11:51 AM
To: m...@ciena.com<mailto:m...@ciena.com>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] #vpp #vnet apparent buffer prefetch issue - seeing "l3 
mac mismatch" discards


Have you tried to use "git bisect" to find which patch fixes this issue?

—
Damjan


On 4 Jun 2020, at 22:15, Bly, Mike via lists.fd.io<http://lists.fd.io> 
mailto:mbly=ciena@lists.fd.io>> wrote:

Hello,

We are observing a small percentage of frames being discarded in simple 2-port 
L2 xconnect setup when a constant, same frame, single (full duplex) traffic 
profile is offered to the system. The frames are being discarded due to a 
failed VLAN classification when all frames offered have the same VLAN present, 
i.e. send two sets of 1B of the same frame in two directions (A <-> B), see x% 
discarded due to random VLAN classification issues.

We did not see this issue in v18.07.1. At the start of the year we upgraded to 
19.08 and started seeing this issue during scale testing. We have been trying 
to root cause it and are at a point where we need some assistance. Moving from 
our integrated VPP solution to using stock VPP built in an Ubuntu container, we 
have found this issue to be present in all releases between 19.08 – 20.01, but 
appears fixed in 20.05. We are not in a position where we can immediately 
upgrade to v20.05, so we need a solution for the v19.08 code base, based on key 
changes v20.01 -> v20.05. As such, we are looking for guidance on potentially 
relevant changes made between v20.01 and v20.05.

VPP configuration used:
create sub-interfaces TenGigabitEthernet19/0/0 100 dot1q 100
create sub-interfaces TenGigabitEthernet19/0/1 100 dot1q 100
set interface state TenGigabitEthernet19/0/0 up
set interface state TenGigabitEthernet19/0/0.100 up
set interface state TenGigabitEthernet19/0/1 up
set interface state TenGigabitEthernet19/0/1.100 up
set interface l2 xconnect TenGigabitEthernet19/0/0.100 
TenGigabitEthernet19/0/1.100
set interface l2 xconnect TenGigabitEthernet19/0/1.100 
TenGigabitEthernet19/0/0.100

Traffic/setup:

·Two traffic generator connections to 10G physical NICs, each 
connection having a single traffic stream, where all frames are the same

·No NIC offloading being used, no RSS, single worker thread separate 
from master

·64B frames with fixed/cross-matching unicast L2 MAC addresses, non-IP 
Etype, incrementing payload

·1 billion frames full duplex, offered at max “lossless” throughput, 
e.g. approx. 36% of 10Gb/s for v20.05

o   “lossless” is maximum throughput allowed without observing “show interface” 
-> “rx-miss” statistics

Resulting statistics:

Working v18.07.1 with proper/expected “error” statistics:
vpp# show version
vpp v18.07.1

vpp# show errors
   CountNode  Reason
20l2-output   L2 output packets
20l2-inputL2 input packets

Non-Working v20.01 with unexpected “error” statistics:
vpp# show version
vpp v20.01-release

vpp# show errors
   CountNode  Reason
174332l2-output   L2 output packets
174332l2-inputL2 input packets
 25668 ethernet-input l3 mac mismatch <-- 
we should NOT be seeing these

Working v20.05 with proper/expected “error” statistics:
vpp# show version
vpp v20.05-release

vpp# show errors
   CountNode  Reason
20l2-output   L2 output packets
20l2-inputL2 input packets

Issue found:

In eth_input_process_frame() calls to eth_input_get_etype_and_tags() are 
sometimes failing to properly parse/store the “etype” and/or “tag” values, 
which then results later on in failed VLAN classification and resultant “l3 mac 
mismatch” discards due to parent L3 mode.

Here is a sample debug profiling of the discards. We implement some 
down-n-dirty debug statistics as shown:

·bad_l3_frm_offset[256] is showing which frame in “n_left” sequence of 
a given batch was discarded

·bad_l3_batch_size[256] is showing the size of each batch of frames 
being processed when a discard occurs

(gdb) p bad_

Re: [vpp-dev] #vpp #vnet apparent buffer prefetch issue - seeing "l3 mac mismatch" discards

[John Lo (loj) via lists.fd.io]

May be it is this one?  https://gerrit.fd.io/r/c/vpp/+/26961   -John

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Friday, June 05, 2020 11:51 AM
To: m...@ciena.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] #vpp #vnet apparent buffer prefetch issue - seeing "l3 
mac mismatch" discards


Have you tried to use "git bisect" to find which patch fixes this issue?

—
Damjan



On 4 Jun 2020, at 22:15, Bly, Mike via lists.fd.io 
mailto:mbly=ciena@lists.fd.io>> wrote:

Hello,

We are observing a small percentage of frames being discarded in simple 2-port 
L2 xconnect setup when a constant, same frame, single (full duplex) traffic 
profile is offered to the system. The frames are being discarded due to a 
failed VLAN classification when all frames offered have the same VLAN present, 
i.e. send two sets of 1B of the same frame in two directions (A <-> B), see x% 
discarded due to random VLAN classification issues.

We did not see this issue in v18.07.1. At the start of the year we upgraded to 
19.08 and started seeing this issue during scale testing. We have been trying 
to root cause it and are at a point where we need some assistance. Moving from 
our integrated VPP solution to using stock VPP built in an Ubuntu container, we 
have found this issue to be present in all releases between 19.08 – 20.01, but 
appears fixed in 20.05. We are not in a position where we can immediately 
upgrade to v20.05, so we need a solution for the v19.08 code base, based on key 
changes v20.01 -> v20.05. As such, we are looking for guidance on potentially 
relevant changes made between v20.01 and v20.05.

VPP configuration used:
create sub-interfaces TenGigabitEthernet19/0/0 100 dot1q 100
create sub-interfaces TenGigabitEthernet19/0/1 100 dot1q 100
set interface state TenGigabitEthernet19/0/0 up
set interface state TenGigabitEthernet19/0/0.100 up
set interface state TenGigabitEthernet19/0/1 up
set interface state TenGigabitEthernet19/0/1.100 up
set interface l2 xconnect TenGigabitEthernet19/0/0.100 
TenGigabitEthernet19/0/1.100
set interface l2 xconnect TenGigabitEthernet19/0/1.100 
TenGigabitEthernet19/0/0.100

Traffic/setup:

·Two traffic generator connections to 10G physical NICs, each 
connection having a single traffic stream, where all frames are the same

·No NIC offloading being used, no RSS, single worker thread separate 
from master

·64B frames with fixed/cross-matching unicast L2 MAC addresses, non-IP 
Etype, incrementing payload

·1 billion frames full duplex, offered at max “lossless” throughput, 
e.g. approx. 36% of 10Gb/s for v20.05

o   “lossless” is maximum throughput allowed without observing “show interface” 
-> “rx-miss” statistics

Resulting statistics:

Working v18.07.1 with proper/expected “error” statistics:
vpp# show version
vpp v18.07.1

vpp# show errors
   CountNode  Reason
20l2-output   L2 output packets
20l2-inputL2 input packets

Non-Working v20.01 with unexpected “error” statistics:
vpp# show version
vpp v20.01-release

vpp# show errors
   CountNode  Reason
174332l2-output   L2 output packets
174332l2-inputL2 input packets
 25668 ethernet-input l3 mac mismatch <-- 
we should NOT be seeing these

Working v20.05 with proper/expected “error” statistics:
vpp# show version
vpp v20.05-release

vpp# show errors
   CountNode  Reason
20l2-output   L2 output packets
20l2-inputL2 input packets

Issue found:

In eth_input_process_frame() calls to eth_input_get_etype_and_tags() are 
sometimes failing to properly parse/store the “etype” and/or “tag” values, 
which then results later on in failed VLAN classification and resultant “l3 mac 
mismatch” discards due to parent L3 mode.

Here is a sample debug profiling of the discards. We implement some 
down-n-dirty debug statistics as shown:

·bad_l3_frm_offset[256] is showing which frame in “n_left” sequence of 
a given batch was discarded

·bad_l3_batch_size[256] is showing the size of each batch of frames 
being processed when a discard occurs

(gdb) p bad_l3_frm_offset
$1 = {1078, 1078, 1078, 1078, 0 , 383, 383, 383, 383, 0 
}

(gdb) p bad_l3_batch_size
$2 = {0 , 1424, 0, 0, 1356, 3064}

I did manage to find the following thread, which seems to be possibly related 
to our issue: https://lists.fd.io/g/vpp-dev/message/15488 Sharing just in case 
it is in fact relevant.

Finally, are VPP performance regressions monitoring/checking “vpp show errors” 
content? We are looking to understand how this may have gone unnoticed between 
v18.07.1 and 20.05 release efforts given the simplicity of the configuration 

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

[John Lo (loj) via lists.fd.io]

Any input packets with mcast bit set on its DMAC will not be dropped.  This 
would apply to all mcast/bcast packets.  Only packets with unicast DMAC not 
matching interface MAC are dropped by NIC or ethernet-input node.-John

From: Balaji Venkatraman (balajiv) 
Sent: Thursday, June 04, 2020 4:55 PM
To: John Lo (loj) ; Nagaraju Vemuri 
Cc: Andrew  Yourtchenko ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Hi John,

I assume the pass thru/drop applies to multicast frames too(assuming we have 
IGMP enabled segment). Correct?

Thanks!

--
Regards,
Balaji.


From: mailto:vpp-dev@lists.fd.io>> on behalf of "John Lo 
(loj) via lists.fd.io" 
mailto:loj=cisco@lists.fd.io>>
Reply-To: "John Lo (loj)" mailto:l...@cisco.com>>
Date: Wednesday, June 3, 2020 at 1:38 PM
To: Nagaraju Vemuri mailto:nagarajuiit...@gmail.com>>
Cc: Andrew  Yourtchenko mailto:ayour...@gmail.com>>, 
"vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

We can use “show node counters” which should display counter for packets 
dropped due to MAC mismatch.  -John

From: Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>>
Sent: Wednesday, June 03, 2020 3:10 PM
To: John Lo (loj) mailto:l...@cisco.com>>
Cc: Andrew  Yourtchenko mailto:ayour...@gmail.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Also, do we have any counters to validate this patch?

On Wed, Jun 3, 2020 at 11:41 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Hi Nagaraju,

No extra config required than standard L3 setup you already have with IP 
address/subnet on your interface.  Such L3 interface should drop packets with 
unicast DMAC which does not match interface MAC.   If you can pull/clone the 
latest VPP, either master or stable/2005 branch, and build, the image should 
have my patch included.  Please let us know if it solve your problem or not.

Regards,
John

From: Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>>
Sent: Wednesday, June 03, 2020 1:52 PM
To: Andrew  Yourtchenko mailto:ayour...@gmail.com>>
Cc: John Lo (loj) mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Sure Andrew.
I will help with that.

Do I need to configure something in VPP with this patch to drop such packets?

Thanks,
Nagaraju


On Wed, Jun 3, 2020 at 10:48 AM Andrew  Yourtchenko 
mailto:ayour...@gmail.com>> wrote:
20.05.1. The fix was ready just a little bit too late to be a safe to merge 
right at the moment of the release, so given the size of the patch and that the 
issue was there for a couple of releases already I made a call to postpone it 
till the first dot release.

As for the timing for the 20.05.1 - still TBD.

Would you be able to build the VPP in your own environment and give the 
feedback whether John’s fix addresses the issue you are seeing ?

--a

On 3 Jun 2020, at 19:23, Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>> wrote:
Thanks John.

Which release will have your fixes?


On Wed, Jun 3, 2020 at 10:21 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
I recently submitted two patches, one for master and the other for stable/2005, 
to fix an issue with L3 virtual interfaces not filter input packets with wrong 
unicast MAC address:
https://gerrit.fd.io/r/c/vpp/+/27027
https://gerrit.fd.io/r/c/vpp/+/27311

Perhaps it is the issue you are hitting.

Regards,
John

From: Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>>
Sent: Wednesday, June 03, 2020 1:06 PM
To: John Lo (loj) mailto:l...@cisco.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Hi John,

Sorry, I should have been more clear.

We are using Virtual machines(KVM based) on which VPP runs.
KVM qemu creates bridge (using brctl) on physical machine and creates TAP 
interfaces from this bridge for Virtual Machines(VMs) networking.

We run VPP on VMs and configure interfaces with L3 IP address.
When we send traffic, this linux bridge forwards traffic from one interface of 
VM to another interface on a different VM.
If the bridge has no mac-to-port binding info, it is forwarding packets to all 
interfaces, so all VPPs receive these packets.
And the VPP whose MAC is not matching with this packet, just forwards this 
packet again.
We want VPP to drop a packet if the destination MAC doesnt match with VPP 
interfaces MAC addresses.

Hope I am clear now.

Thanks,
Nagaraju



On Wed, Jun 3, 2020 at 8:53 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Please clarify the following:

> When the bridge has no binding info about MAC-to-port, bridge is flooding 
>

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

[John Lo (loj) via lists.fd.io]

We can use “show node counters” which should display counter for packets 
dropped due to MAC mismatch.  -John

From: Nagaraju Vemuri 
Sent: Wednesday, June 03, 2020 3:10 PM
To: John Lo (loj) 
Cc: Andrew  Yourtchenko ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Also, do we have any counters to validate this patch?

On Wed, Jun 3, 2020 at 11:41 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Hi Nagaraju,

No extra config required than standard L3 setup you already have with IP 
address/subnet on your interface.  Such L3 interface should drop packets with 
unicast DMAC which does not match interface MAC.   If you can pull/clone the 
latest VPP, either master or stable/2005 branch, and build, the image should 
have my patch included.  Please let us know if it solve your problem or not.

Regards,
John

From: Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>>
Sent: Wednesday, June 03, 2020 1:52 PM
To: Andrew  Yourtchenko mailto:ayour...@gmail.com>>
Cc: John Lo (loj) mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Sure Andrew.
I will help with that.

Do I need to configure something in VPP with this patch to drop such packets?

Thanks,
Nagaraju


On Wed, Jun 3, 2020 at 10:48 AM Andrew  Yourtchenko 
mailto:ayour...@gmail.com>> wrote:
20.05.1. The fix was ready just a little bit too late to be a safe to merge 
right at the moment of the release, so given the size of the patch and that the 
issue was there for a couple of releases already I made a call to postpone it 
till the first dot release.

As for the timing for the 20.05.1 - still TBD.

Would you be able to build the VPP in your own environment and give the 
feedback whether John’s fix addresses the issue you are seeing ?

--a

On 3 Jun 2020, at 19:23, Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>> wrote:

Thanks John.

Which release will have your fixes?


On Wed, Jun 3, 2020 at 10:21 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
I recently submitted two patches, one for master and the other for stable/2005, 
to fix an issue with L3 virtual interfaces not filter input packets with wrong 
unicast MAC address:
https://gerrit.fd.io/r/c/vpp/+/27027
https://gerrit.fd.io/r/c/vpp/+/27311

Perhaps it is the issue you are hitting.

Regards,
John

From: Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>>
Sent: Wednesday, June 03, 2020 1:06 PM
To: John Lo (loj) mailto:l...@cisco.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Hi John,

Sorry, I should have been more clear.

We are using Virtual machines(KVM based) on which VPP runs.
KVM qemu creates bridge (using brctl) on physical machine and creates TAP 
interfaces from this bridge for Virtual Machines(VMs) networking.

We run VPP on VMs and configure interfaces with L3 IP address.
When we send traffic, this linux bridge forwards traffic from one interface of 
VM to another interface on a different VM.
If the bridge has no mac-to-port binding info, it is forwarding packets to all 
interfaces, so all VPPs receive these packets.
And the VPP whose MAC is not matching with this packet, just forwards this 
packet again.
We want VPP to drop a packet if the destination MAC doesnt match with VPP 
interfaces MAC addresses.

Hope I am clear now.

Thanks,
Nagaraju



On Wed, Jun 3, 2020 at 8:53 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Please clarify the following:

> When the bridge has no binding info about MAC-to-port, bridge is flooding 
> packets to all interfaces.

  1.  Is this linux bridge that’s in the kernel so not a bridge domain inside 
VPP?
  2.  So packets are flooded to all interfaces in the bridge. Are you saying 
each of the interface is on a separate VPP instance?

> Hence VPP receives some packets whose MAC address is owned by some other VPP 
> instance.
> We want to drop such packets. By default VPP is forwarding these packets.

  1.  How is VPP receiving packets from its interface and forwarding them?
  2.  Is the interface in L3 mode with an IP address/subnet configured?
  3.  It can be helpful to provide “show interface addr” output or, even 
better, provide a packet trace from VPP on how one or more of the packet is 
received and forwarded.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Nagaraju Vemuri
Sent: Tuesday, June 02, 2020 8:13 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] VPP forwarding packets not destined to it #vpp


Hi,

We are using linux bridge to connect different interfaces owned by different 
VPP instances.
When the bridge has no binding info about MAC-to-port, bridge is flooding 
packets to all interfaces.
Hence VPP receives some packets whose MAC

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

[John Lo (loj) via lists.fd.io]

Hi Nagaraju,

No extra config required than standard L3 setup you already have with IP 
address/subnet on your interface.  Such L3 interface should drop packets with 
unicast DMAC which does not match interface MAC.   If you can pull/clone the 
latest VPP, either master or stable/2005 branch, and build, the image should 
have my patch included.  Please let us know if it solve your problem or not.

Regards,
John

From: Nagaraju Vemuri 
Sent: Wednesday, June 03, 2020 1:52 PM
To: Andrew  Yourtchenko 
Cc: John Lo (loj) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Sure Andrew.
I will help with that.

Do I need to configure something in VPP with this patch to drop such packets?

Thanks,
Nagaraju


On Wed, Jun 3, 2020 at 10:48 AM Andrew  Yourtchenko 
mailto:ayour...@gmail.com>> wrote:
20.05.1. The fix was ready just a little bit too late to be a safe to merge 
right at the moment of the release, so given the size of the patch and that the 
issue was there for a couple of releases already I made a call to postpone it 
till the first dot release.

As for the timing for the 20.05.1 - still TBD.

Would you be able to build the VPP in your own environment and give the 
feedback whether John’s fix addresses the issue you are seeing ?

--a


On 3 Jun 2020, at 19:23, Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>> wrote:

Thanks John.

Which release will have your fixes?


On Wed, Jun 3, 2020 at 10:21 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
I recently submitted two patches, one for master and the other for stable/2005, 
to fix an issue with L3 virtual interfaces not filter input packets with wrong 
unicast MAC address:
https://gerrit.fd.io/r/c/vpp/+/27027
https://gerrit.fd.io/r/c/vpp/+/27311

Perhaps it is the issue you are hitting.

Regards,
John

From: Nagaraju Vemuri 
mailto:nagarajuiit...@gmail.com>>
Sent: Wednesday, June 03, 2020 1:06 PM
To: John Lo (loj) mailto:l...@cisco.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Hi John,

Sorry, I should have been more clear.

We are using Virtual machines(KVM based) on which VPP runs.
KVM qemu creates bridge (using brctl) on physical machine and creates TAP 
interfaces from this bridge for Virtual Machines(VMs) networking.

We run VPP on VMs and configure interfaces with L3 IP address.
When we send traffic, this linux bridge forwards traffic from one interface of 
VM to another interface on a different VM.
If the bridge has no mac-to-port binding info, it is forwarding packets to all 
interfaces, so all VPPs receive these packets.
And the VPP whose MAC is not matching with this packet, just forwards this 
packet again.
We want VPP to drop a packet if the destination MAC doesnt match with VPP 
interfaces MAC addresses.

Hope I am clear now.

Thanks,
Nagaraju



On Wed, Jun 3, 2020 at 8:53 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Please clarify the following:

> When the bridge has no binding info about MAC-to-port, bridge is flooding 
> packets to all interfaces.

  1.  Is this linux bridge that’s in the kernel so not a bridge domain inside 
VPP?
  2.  So packets are flooded to all interfaces in the bridge. Are you saying 
each of the interface is on a separate VPP instance?

> Hence VPP receives some packets whose MAC address is owned by some other VPP 
> instance.
> We want to drop such packets. By default VPP is forwarding these packets.

  1.  How is VPP receiving packets from its interface and forwarding them?
  2.  Is the interface in L3 mode with an IP address/subnet configured?
  3.  It can be helpful to provide “show interface addr” output or, even 
better, provide a packet trace from VPP on how one or more of the packet is 
received and forwarded.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Nagaraju Vemuri
Sent: Tuesday, June 02, 2020 8:13 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] VPP forwarding packets not destined to it #vpp


Hi,

We are using linux bridge to connect different interfaces owned by different 
VPP instances.
When the bridge has no binding info about MAC-to-port, bridge is flooding 
packets to all interfaces.
Hence VPP receives some packets whose MAC address is owned by some other VPP 
instance.
We want to drop such packets. By default VPP is forwarding these packets.

We tried using "set interface l2 forward  disable", but this did not 
help.

Please suggest what we can do.

Thanks,
Nagaraju


--
Thanks,
Nagaraju Vemuri


--
Thanks,
Nagaraju Vemuri



--
Thanks,
Nagaraju Vemuri
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16646): https://lists.fd.io/g/vpp-dev/message/16646
Mute This Topic: https://lists.fd.io/mt/74640593/21656
Mute #vpp: https://lists.f

Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

[John Lo (loj) via lists.fd.io]

I recently submitted two patches, one for master and the other for stable/2005, 
to fix an issue with L3 virtual interfaces not filter input packets with wrong 
unicast MAC address:
https://gerrit.fd.io/r/c/vpp/+/27027
https://gerrit.fd.io/r/c/vpp/+/27311

Perhaps it is the issue you are hitting.

Regards,
John

From: Nagaraju Vemuri 
Sent: Wednesday, June 03, 2020 1:06 PM
To: John Lo (loj) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP forwarding packets not destined to it #vpp

Hi John,

Sorry, I should have been more clear.

We are using Virtual machines(KVM based) on which VPP runs.
KVM qemu creates bridge (using brctl) on physical machine and creates TAP 
interfaces from this bridge for Virtual Machines(VMs) networking.

We run VPP on VMs and configure interfaces with L3 IP address.
When we send traffic, this linux bridge forwards traffic from one interface of 
VM to another interface on a different VM.
If the bridge has no mac-to-port binding info, it is forwarding packets to all 
interfaces, so all VPPs receive these packets.
And the VPP whose MAC is not matching with this packet, just forwards this 
packet again.
We want VPP to drop a packet if the destination MAC doesnt match with VPP 
interfaces MAC addresses.

Hope I am clear now.

Thanks,
Nagaraju



On Wed, Jun 3, 2020 at 8:53 AM John Lo (loj) 
mailto:l...@cisco.com>> wrote:
Please clarify the following:

> When the bridge has no binding info about MAC-to-port, bridge is flooding 
> packets to all interfaces.

  1.  Is this linux bridge that’s in the kernel so not a bridge domain inside 
VPP?
  2.  So packets are flooded to all interfaces in the bridge. Are you saying 
each of the interface is on a separate VPP instance?

> Hence VPP receives some packets whose MAC address is owned by some other VPP 
> instance.
> We want to drop such packets. By default VPP is forwarding these packets.

  1.  How is VPP receiving packets from its interface and forwarding them?
  2.  Is the interface in L3 mode with an IP address/subnet configured?
  3.  It can be helpful to provide “show interface addr” output or, even 
better, provide a packet trace from VPP on how one or more of the packet is 
received and forwarded.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Nagaraju Vemuri
Sent: Tuesday, June 02, 2020 8:13 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] VPP forwarding packets not destined to it #vpp


Hi,

We are using linux bridge to connect different interfaces owned by different 
VPP instances.
When the bridge has no binding info about MAC-to-port, bridge is flooding 
packets to all interfaces.
Hence VPP receives some packets whose MAC address is owned by some other VPP 
instance.
We want to drop such packets. By default VPP is forwarding these packets.

We tried using "set interface l2 forward  disable", but this did not 
help.

Please suggest what we can do.

Thanks,
Nagaraju


--
Thanks,
Nagaraju Vemuri
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16641): https://lists.fd.io/g/vpp-dev/message/16641
Mute This Topic: https://lists.fd.io/mt/74640593/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
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 forwarding packets not destined to it #vpp

[John Lo (loj) via lists.fd.io]

Please clarify the following:

> When the bridge has no binding info about MAC-to-port, bridge is flooding 
> packets to all interfaces.

  1.  Is this linux bridge that’s in the kernel so not a bridge domain inside 
VPP?
  2.  So packets are flooded to all interfaces in the bridge. Are you saying 
each of the interface is on a separate VPP instance?

> Hence VPP receives some packets whose MAC address is owned by some other VPP 
> instance.
> We want to drop such packets. By default VPP is forwarding these packets.

  1.  How is VPP receiving packets from its interface and forwarding them?
  2.  Is the interface in L3 mode with an IP address/subnet configured?
  3.  It can be helpful to provide “show interface addr” output or, even 
better, provide a packet trace from VPP on how one or more of the packet is 
received and forwarded.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Nagaraju Vemuri
Sent: Tuesday, June 02, 2020 8:13 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP forwarding packets not destined to it #vpp


Hi,

We are using linux bridge to connect different interfaces owned by different 
VPP instances.
When the bridge has no binding info about MAC-to-port, bridge is flooding 
packets to all interfaces.
Hence VPP receives some packets whose MAC address is owned by some other VPP 
instance.
We want to drop such packets. By default VPP is forwarding these packets.

We tried using "set interface l2 forward  disable", but this did not 
help.

Please suggest what we can do.

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

View/Reply Online (#16635): https://lists.fd.io/g/vpp-dev/message/16635
Mute This Topic: https://lists.fd.io/mt/74640593/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
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 - DPDK - No ARP learning on VPP and no ARP reply sent.

[John Lo (loj) via lists.fd.io]

Hi Laurent,

VPP interface and sub-interface come up in L3 mode by default, unless it is put 
into L2 mode for either bridging or cross connect:

DBGvpp# set interface l2 bridge ?
  set interface l2 bridge  set interface l2 bridge  
 [bvi|uu-fwd] [shg]
DBGvpp# set interface l2 xconnect ?
  set interface l2 xconnectset interface l2 xconnect 
 

Thus, your setup has the interface in VirtualFunctionEthernet0/5/0.101 in L3 
mode with its assigned IP/subnet as shown by your “sho interface address” 
output:

set interface state VirtualFunctionEthernet0/5/0 up
create sub-interfaces VirtualFunctionEthernet0/5/0 101
set interface state VirtualFunctionEthernet0/5/0.101 up
set interface ip address VirtualFunctionEthernet0/5/0.101 
100.100.101.2/24

How is the interface on TOR connected to VirtualFunctionEthernet0/5/0 
configured?  Is it in L3 mode with the same VLAN sub-interface configured with 
IP address of 100.100.101.1?  If it is in L2 mode with VLANs, is there a host 
on that VLAN which owns IP address 100.100.100.1 which will respond to your 
ping.

It would be helpful to get a packet trace using the following VPP CLI to show 
how packets are received by your DPDK interface and handled by VPP:

clear trace
trace add dpdk-input 10
show trace

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Laurent Dumont
Sent: Wednesday, May 20, 2020 10:55 AM
To: Balaji Venkatraman (balajiv) 
Cc: Mrityunjay Kumar ; vpp-dev 
Subject: Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply 
sent.

Yep

And that's on VLAN 101.

I just did a few tests and as soon as I remove the vlan from both sides, it 
starts working and I can ping across.

Just to be sure this isn't me with a bad VPP configuration. Is the following 
enough to have basic L2 connectivity with a vlan?

set interface state VirtualFunctionEthernet0/5/0 up
create sub-interfaces VirtualFunctionEthernet0/5/0 101
set interface state VirtualFunctionEthernet0/5/0.101 up
set interface ip address VirtualFunctionEthernet0/5/0.101 
100.100.101.2/24

That's assuming that the TOR config is functional and correct as well :)

Thanks!

On Wed, May 20, 2020 at 1:46 AM Balaji Venkatraman (balajiv) 
mailto:bala...@cisco.com>> wrote:
Hi Laurent,

Trying to understand your setup:

Do you have :
  100.100.101.x/24
TOR[.1] <>[.2] VLAN

So, is the interface on TOR end also on a vlan (with same id)?


--
Regards,
Balaji.


From: Laurent Dumont mailto:laurentfdum...@gmail.com>>
Date: Tuesday, May 19, 2020 at 4:58 PM
To: "Balaji Venkatraman (balajiv)" mailto:bala...@cisco.com>>
Cc: Mrityunjay Kumar mailto:kumarn...@gmail.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply 
sent.

Hey everyone,

Thank you for all the comments. Just trying to work my way through it! :)

Just as a sanity check, here is what it looks like on a fresh VPP (without any 
config).

# Configure the VPP client with the proper vlan and IP address.
set interface state VirtualFunctionEthernet0/5/0 up
create sub-interfaces VirtualFunctionEthernet0/5/0 101
set interface state VirtualFunctionEthernet0/5/0.101 up
set interface ip address VirtualFunctionEthernet0/5/0.101 
100.100.101.2/24

I then have the following :
vpp# show interface address
VirtualFunctionEthernet0/5/0 (up):
VirtualFunctionEthernet0/5/0.101 (up):
  L3 100.100.101.2/24
local0 (dn):

TOR IP : 100.100.101.1 - VLAN 101
vpp# ping 100.100.101.1

Statistics: 5 sent, 0 received, 100% packet loss

vpp# show hardware-interfaces
  NameIdx   Link  Hardware
VirtualFunctionEthernet0/5/0   1 up   VirtualFunctionEthernet0/5/0
  Link speed: 10 Gbps
  Ethernet address fa:16:3e:92:30:f1
  Intel X710/XL710 Family VF
carrier up full duplex mtu 9206  promisc
flags: admin-up promisc pmd maybe-multiseg subif tx-offload 
intel-phdr-cksum rx-ip4-cksum
Devargs:
rx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
tx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
pci: device 8086:154c subsystem 103c: address :00:05.00 numa 0
max rx packet len: 9728
promiscuous: unicast on all-multicast on
vlan offload: strip off filter on qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum qinq-strip
   outer-ipv4-cksum vlan-filter jumbo-frame scatter
rx offload active: ipv4-cksum jumbo-frame scatter
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
   tcp-tso outer-ipv4-cksum qinq-insert vxlan-tnl-tso
   gre-tnl-tso ipip-tnl-tso geneve-tnl-tso multi-segs
tx offload active: udp-cksum tcp-cksum multi-segs
rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other 
ipv6-frag
   ipv6-tcp ipv6-udp ipv6-sctp ipv6-other 

Re: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply sent.

[John Lo (loj) via lists.fd.io]

The new vpp cli to show ip4-arp and ip6-neighbor entries is “show ip neighbors”:

DBGvpp# sho ip neighbor
Time   IPFlags  Ethernet
  Interface
  8.436410.0.3.3   D00:50:56:88:00:ac 
GigabitEthernet1b/0/0
 17.0595 7.0.0.2   D00:50:56:88:ca:7e 
GigabitEthernetb/0/0
114.1346   fc00:0:a00:6500::30 D00:50:56:88:ca:7e 
GigabitEthernetb/0/0

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Laurent Dumont
Sent: Thursday, May 14, 2020 10:25 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP - DPDK - No ARP learning on VPP and no ARP reply sent.

Hi!

I was doing some initial experimentation with VPP/SRIOV/DPDK and I just wanted 
to see if some of the things I was experiencing we're expected. I was looking 
at understanding the baseline behavior for something like VPP + DPDK.

I have a small test POC with the following topology.

VM Ubuntu 18.04( with the "linux-image-extra-virtual" package) --->  (VPP + 
DPDK + IP address on the VPP interface) ---> VF ---> PF (compute with SRIOV on 
X710 cards) ---> TOR interface - untagged.

What I am seeing :

  1.  VPP is telling me I have both RX and TX packets.
  2.  That said, no ARP entry for the TOR is seen on VPP
  3.  The interface on the TOR is also not seeing any ARP entry for the VPP 
interface. The TOR is also indicating that RX and TX packets are present.
Are there any inherent limitations to the ARP with VPP/DPDK?

One weird thing is that trying to show the ARP from VPP doesn't seem to be a 
valid command :
vpp# sh ip arp
show ip: unknown input `arp'

Here are some more debugging output.

vpp# show version
vpp v20.01-release built by root on 980ae64453f3 at 2020-01-29T22:13:47

vpp# show int address
VirtualFunctionEthernet0/5/0 (up):
  L3 1.2.3.4/31


vpp# show hardware-interfaces
  NameIdx   Link  Hardware
VirtualFunctionEthernet0/5/0   1 up   VirtualFunctionEthernet0/5/0
  Link speed: 10 Gbps
  Ethernet address fa:16:3e:92:30:f1
  Intel X710/XL710 Family VF
carrier up full duplex mtu 9206
flags: admin-up pmd maybe-multiseg tx-offload intel-phdr-cksum rx-ip4-cksum
Devargs:
rx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
tx: queues 1 (max 16), desc 1024 (min 64 max 4096 align 32)
pci: device 8086:154c subsystem 103c: address :00:05.00 numa 0
max rx packet len: 9728
promiscuous: unicast off all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum qinq-strip
   outer-ipv4-cksum vlan-filter jumbo-frame scatter
rx offload active: ipv4-cksum jumbo-frame scatter
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
   tcp-tso outer-ipv4-cksum qinq-insert vxlan-tnl-tso
   gre-tnl-tso ipip-tnl-tso geneve-tnl-tso multi-segs
tx offload active: udp-cksum tcp-cksum multi-segs
rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other 
ipv6-frag
   ipv6-tcp ipv6-udp ipv6-sctp ipv6-other l2-payload
rss active:none
tx burst function: i40e_xmit_pkts
rx burst function: i40e_recv_scattered_pkts_vec_avx2

tx frames ok  36
tx bytes ok 1512
rx frames ok  26
rx bytes ok 3014
extended stats:
  rx good packets 26
  tx good packets 36
  rx good bytes 3014
  tx good bytes 1512
  rx bytes  3014
  rx broadcast packets26
  tx bytes  1512
  tx broadcast packets36
local0 0down  local0
  Link speed: unknown
  local


vpp# show interface
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
VirtualFunctionEthernet0/5/0  1  up  9000/0/0/0 rx packets  
  26
rx bytes
2910
tx packets  
  36
tx bytes
1512
drops   
  14
ip4 
  25
local00 down  

Re: [vpp-dev] Reminder: VPP 20.05 RC1 is *tomorrow* 13th May 18:00 UTC

[John Lo (loj) via lists.fd.io]

Hi Andrew,

It would be good to include the following two patches:
https://gerrit.fd.io/r/c/vpp/+/27027
https://gerrit.fd.io/r/c/vpp/+/27029

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Mrityunjay Kumar
Sent: Wednesday, May 13, 2020 11:11 AM
To: Andrew Yourtchenko 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Reminder: VPP 20.05 RC1 is *tomorrow* 13th May 18:00 UTC

Hi Andrew
Long back I have given a patch. if possible can you please try to include it 
with vpp 2005.
https://gerrit.fd.io/r/c/vpp/+/21793

//MJ

Regards,
Mrityunjay Kumar.
Mobile: +91 - 9731528504


On Tue, May 12, 2020 at 4:53 PM Andrew Yourtchenko 
mailto:ayour...@gmail.com>> wrote:
Hi all,

Just a friendly reminder that tomorrow at 18:00 UTC we have the VPP
20.05 RC1 milestone [0], during which a stable/2005 branch will be
created.

Until after I send an email announcing the end of that process, master
branch is still CLOSED for API changes and risky commits.

You may have notice that verify jobs are still being a bit
temperamental - some of the changes appeared to have made the
situation a bit better, but Dave and myself are still working on it to
properly diagnose the root cause of this intermittent issue. If you
have any persistent infrastructure-related difficulties with the
commits that you would like to see merged before the new stable branch
being cut, please let me know ASAP.

thanks!

--a
/* your friendly 20.05 release manager */

[0]: https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_20.05
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16364): https://lists.fd.io/g/vpp-dev/message/16364
Mute This Topic: https://lists.fd.io/mt/74156235/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] clang-9

[John Lo (loj) via lists.fd.io]

Hi Damjan,

I took a look at the console log. It seems to me the traceback after vxlan test 
case was due to running out of space. So test run was aborted thereafter:

07:56:20 
==
07:56:20 VXLAN Test Case
07:56:20 
==
07:56:20 Decapsulation test   
9.69 OK
07:56:20 Encapsulation test   
9.05 OK
07:56:20 Encapsulation test send big frame from pg1   
9.81 OK
07:56:20 Traceback (most recent call last):
07:56:20   File 
"/w/workspace/vpp-verify-master-ubuntu1804/build-root/build-test/src/run_tests.py",
 line 859, in 
07:56:20 results = run_forked(suites)
07:56:20   File 
"/w/workspace/vpp-verify-master-ubuntu1804/build-root/build-test/src/run_tests.py",
 line 456, in run_forked
07:56:20 manager)
07:56:20   File 
"/w/workspace/vpp-verify-master-ubuntu1804/build-root/build-test/src/run_tests.py",
 line 152, in __init__
07:56:20 self.stdouterr_queue = manager.StreamQueue(ctx=get_context())
07:56:20   File "/usr/lib/python3.6/multiprocessing/managers.py", line 662, in 
temp
07:56:20 token, exp = self._create(typeid, *args, **kwds)
07:56:20   File "/usr/lib/python3.6/multiprocessing/managers.py", line 556, in 
_create
07:56:20 id, exposed = dispatch(conn, None, 'create', (typeid,)+args, kwds)
07:56:20   File "/usr/lib/python3.6/multiprocessing/managers.py", line 82, in 
dispatch
07:56:20 raise convert_to_error(kind, result)
07:56:20 multiprocessing.managers.RemoteError:
07:56:20 
---
07:56:20 Traceback (most recent call last):
07:56:20   File "/usr/lib/python3.6/multiprocessing/managers.py", line 195, in 
handle_request
07:56:20 result = func(c, *args, **kwds)
07:56:20   File "/usr/lib/python3.6/multiprocessing/managers.py", line 359, in 
create
07:56:20 obj = callable(*args, **kwds)
07:56:20   File "/usr/lib/python3.6/multiprocessing/queues.py", line 42, in 
__init__
07:56:20 self._rlock = ctx.Lock()
07:56:20   File "/usr/lib/python3.6/multiprocessing/context.py", line 67, in 
Lock
07:56:20 return Lock(ctx=self.get_context())
07:56:20   File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 162, 
in __init__
07:56:20 SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
07:56:20   File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 59, 
in __init__
07:56:20 unlink_now)
07:56:20 OSError: [Errno 28] No space left on device
...

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Tuesday, April 28, 2020 10:14 AM
To: vpp-dev 
Subject: [vpp-dev] clang-9


Folks,

As there is bug in gnu assembler which is shipping with ubuntu 18.04 we are not 
able to produce working binaries with avx512 instruction set.
Because of that, I had to change default to avx2. reported bug[1], but it is 
ignored for a year.

As alternative[2], I wanted to consider using clang-9 which is shipped with 
ubuntu 18.04 and seems like it is even capable of producing faster binaries 
than gcc.
Unfortunately, "make test" is failing at several places including vxlan, ipsec 
and tcp stack[3].

May I ask folks who “own” that code to take a quick look?

Thanks,

Damjan

[1] https://bugs.launchpad.net/ubuntu/cosmic/+source/binutils/+bug/1819961
[2] https://gerrit.fd.io/r/c/vpp/+/26744
[3] https://jenkins.fd.io/job/vpp-verify-master-ubuntu1804/3615/console



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

View/Reply Online (#16215): https://lists.fd.io/g/vpp-dev/message/16215
Mute This Topic: https://lists.fd.io/mt/73327785/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] ACL question

[John Lo (loj) via lists.fd.io]

Try “make test TEST=acl_plugin”.   -John

From: vpp-dev@lists.fd.io  On Behalf Of Govindarajan 
Mohandoss
Sent: Tuesday, April 28, 2020 11:22 PM
To: Paul Vinciguerra 
Cc: Andrew  Yourtchenko ; vpp-dev@lists.fd.io; nd 
; Lijian Zhang ; Jieqiang Wang 
; nd 
Subject: Re: [vpp-dev] ACL question

Hi Paul,
  How can I selectively run only the test_acl_plugin.py instead of running make 
test ?

Thanks
Govind

From: Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>
Sent: Tuesday, April 28, 2020 9:22 PM
To: Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>
Cc: Andrew  Yourtchenko mailto:ayour...@gmail.com>>; 
vpp-dev@lists.fd.io; nd 
mailto:n...@arm.com>>; Lijian Zhang 
mailto:lijian.zh...@arm.com>>; Jieqiang Wang 
mailto:jieqiang.w...@arm.com>>
Subject: Re: [vpp-dev] ACL question

See: src/plugins/acl/test/test_acl_plugin.py

On Tue, Apr 28, 2020 at 7:19 PM Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>> wrote:
Sure Andrew. Is there a unit test case for ACL plugin ?

From: Andrew  Yourtchenko mailto:ayour...@gmail.com>>
Sent: Tuesday, April 28, 2020 4:57 PM
To: Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>
Cc: vpp-dev@lists.fd.io; nd 
mailto:n...@arm.com>>; Lijian Zhang 
mailto:lijian.zh...@arm.com>>; Jieqiang Wang 
mailto:jieqiang.w...@arm.com>>
Subject: Re: [vpp-dev] ACL question

1-3: no.
4: please make a “make test” test case illustrating the problem and share it.
--a

On 28 Apr 2020, at 22:37, Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>> wrote:


Hi Andrew,

  I am working on ACL plugin SF+SL optimization on ARM servers.

  I am finding prefetches in ACL node is becoming bottle neck. I see 
performance improvements on both SL & SF mode, when SF mode bihash table 
related prefetching is disabled.

  I need some help with right ACL config to verify my patch.



 I did the testing with Ingress ACL -- 1 Rule and 50 Rules (Rule:  - DPORT is incremented). The Traffic match all the 50 rules.



  When I tried to add 100 rules on the same rule set in SF mode:

  "acl_add_replace -1 ipv4 permit+reflect src 
192.81.1.1/32 dst 192.82.1.1/32 
proto 17 sport 100 dport 1,

   ... ,

   ipv4 permit+reflect src 192.81.1.1/32 dst 
192.82.1.1/32 proto 17 sport 100 dport 100",



   I see only 48 rules in show tables and 48th rule is added as “permit” all 
and not “permit + reflect”. Does it mean <0 – 47> rules will be SF and the rest 
will be in SL mode ?



"

vpp# show acl-plugin acl

acl-index 0 count 49 tag {}

   0: ipv4 permit+reflect src 192.81.1.1/32 dst 
192.82.1.1/32 proto 17 sport 100 dport 1

   

  47: ipv4 permit+reflect src 192.81.1.1/32 dst 
192.82.1.1/32 proto 17 sport 100 dport 48

  48: ipv4 permit src 0.0.0.0/0 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0

"



  1.  Is there a limit of 48 on number of rules that can be added into the Rule 
table (acl-index 0) in SF mode ?
  2.  Whether 48 rules in a ruleset is good enough to verify my optimization 
patch (Traffic flow will match all the 48 rules) ?
  3.  Can I associate more than 1 ACL rule set to an ingress interface (like 
“vat# acl_interface_set_acl_list TenGigabitEthernet1/0/0 input 0 1 2”) ? Each 
Rule set 0, 1, 2 will have different ACL rules. Do I need to test this case 
also to study the performance gain ?
  4.  In SL mode, When I tried to add 100 rules, only 53 rules are seen in show 
table. 53rd rule is added as permit all (Should I read it as permit all ?). Is 
there a limit on number of rules in SL mode ?

“

vpp# show acl-plugin acl

acl-index 0 count 54 tag {}

  0: ipv4 permit src 192.81.1.1/32 dst 
192.82.1.1/32 proto 17 sport 100 dport 1

  ….

 52: ipv4 permit src 192.81.1.1/32 dst 
192.82.1.1/32 proto 17 sport 100 dport 53

 53: ipv4 permit src 0.0.0.0/0 dst 
0.0.0.0/0 proto 0 sport 0-65535 dport 0-65535

  applied inbound on sw_if_index: 1

  used in lookup context index: 0

“



Thanks

Govind



> -Original Message-

> From: vpp-dev@lists.fd.io 
> mailto:vpp-dev@lists.fd.io>> On Behalf Of Govindarajan

> Mohandoss via Lists.Fd.Io

> Sent: Friday, March 27, 2020 11:32 AM

> To: Andrew  Yourtchenko mailto:ayour...@gmail.com>>

> Cc: vpp-dev@lists.fd.io

> Subject: Re: [vpp-dev] ACL question

>

> Thank you very much Andrew !! I will do some benchmarks and get back to

> you to understand it better.

>

> Thanks

> Govind

>

> > -Original Message-

> > From: 

Re: [vpp-dev] vpp project committer nomination: Benoit Ganne

[John Lo (loj) via lists.fd.io]

+1

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
lists.fd.io
Sent: Tuesday, April 21, 2020 7:40 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vpp project committer nomination: Benoit Ganne

Vpp project committers: please vote +1, 0, -1 on the mailto:vpp-dev@lists.fd.io 
mailer as to whether we should add Benoit Ganne as a vpp project committer. 

Ben has about 150 merged patches, see 
https://gerrit.fd.io/r/q/status:merged+owner:bganne%2540cisco.com. He has 
expressed interest in the role, and I believe that he will make a fine 
committer.

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

View/Reply Online (#16135): https://lists.fd.io/g/vpp-dev/message/16135
Mute This Topic: https://lists.fd.io/mt/73170252/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] VRF-aware bypass nodes

[John Lo (loj) via Lists.Fd.Io]

Hi Nick,

I reviewed your patch and merged it.  Really appreciate your effort to address 
the VRF limitation and also refactor the common VTEP handling code.

Regards,
John

From: Nick Zavaritsky 
Sent: Monday, March 02, 2020 7:35 AM
To: John Lo (loj) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VRF-aware bypass nodes

Hi John,

Patch submitted.

https://gerrit.fd.io/r/c/vpp/+/25563



On 27. Feb 2020, at 00:46, John Lo (loj) 
mailto:l...@cisco.com>> wrote:


Hi Nick,

I agree the current bypass node for various tunnel types, including geneve, 
gtpu, vxlan, and vxlan_gbp all have this issue in its hash lookup using only 
incoming packet DIP without checking VRF.  It is generally not an issue if 
bypass feature is enabled on all interfaces which are on the same VRF/IP-table 
corresponding to the same underlay network.  If another underlay VRF is setup 
on other interfaces with bypass enabled, the bypass error as you described will 
happen.

I have no objection if you like to submit a patch to fix this limitation.  I 
hope you are willing to fix bypass node not just for gtpu but all 4 tunnel 
types.  The code for all 4 bypass nodes are very similar except  tunnel type 
check, validation, and node names, etc.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Nick Zavaritsky
Sent: Wednesday, February 26, 2020 12:23 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] VRF-aware bypass nodes

Hi,

There are multiple kinds of bypass nodes in vpp. Bypass nodes intercept packets 
matching certain criteria and pass them directly to the protocol handler node. 
I am going to use GTPU as the illustrating example.

Bypass node SHOULD intercept packets with destination IP matching a local 
address and UDP destination port equal to 2152.

Bypass node MUST NOT intercept a packet if destination IP doesn’t match a local 
address. Otherwise enabling GTPU bypass would change the observable system 
behaviour.

An address is local within a certain VRF. It’s possible that an address is 
local in one VRF but it’s not in another. But GTPU bypass node is not VRF aware.

Image a vpp setup with 2 interfaces, associated with different VRF-s. The first 
interface address is 10.0.10.100, the other one — 192.168.0.7. Both have GTPU 
bypass enabled. Now GTPU bypass in the second interface will intercept packets 
sent to 10.0.10.100 (the first interface’s address), though it shouldn’t.

This is a somewhat contrived example, but it looks like bypass node should be 
VRF-aware for correctness.

Am I missing something?

Would you be open to a patch making GTPU bypass VRF-aware?

Best,
Nick

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

View/Reply Online (#15677): https://lists.fd.io/g/vpp-dev/message/15677
Mute This Topic: https://lists.fd.io/mt/71569502/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 project committers: formal vote to add Matt Smith as a vpp committer

[John Lo (loj) via Lists.Fd.Io]

+1   -John

From: vpp-dev@lists.fd.io  On Behalf Of d...@barachs.net
Sent: Monday, March 02, 2020 9:16 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vpp project committers: formal vote to add Matt Smith as a 
vpp committer

VPP committers, please vote +1, 0, -1 on adding Matt Smith 
(mgsm...@netgate.com) as a vpp project committer.
Matt has contributed O(100) merged patches, and he recently contributed the 
entire vrrp plugin. See https://gerrit.fd.io/r/q/owner:mgsmith%2540netgate.com
Please vote (on vpp-dev@lists.fd.io) by the end of 
this Wednesday, 2/4/2020, so we can put the results in front of the TSC this 
Thursday.
Thanks... Dave

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

View/Reply Online (#15657): https://lists.fd.io/g/vpp-dev/message/15657
Mute This Topic: https://lists.fd.io/mt/71675525/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] VRF-aware bypass nodes

[John Lo (loj) via Lists.Fd.Io]

Hi Nick,

I agree the current bypass node for various tunnel types, including geneve, 
gtpu, vxlan, and vxlan_gbp all have this issue in its hash lookup using only 
incoming packet DIP without checking VRF.  It is generally not an issue if 
bypass feature is enabled on all interfaces which are on the same VRF/IP-table 
corresponding to the same underlay network.  If another underlay VRF is setup 
on other interfaces with bypass enabled, the bypass error as you described will 
happen.

I have no objection if you like to submit a patch to fix this limitation.  I 
hope you are willing to fix bypass node not just for gtpu but all 4 tunnel 
types.  The code for all 4 bypass nodes are very similar except  tunnel type 
check, validation, and node names, etc.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Nick Zavaritsky
Sent: Wednesday, February 26, 2020 12:23 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VRF-aware bypass nodes

Hi,

There are multiple kinds of bypass nodes in vpp. Bypass nodes intercept packets 
matching certain criteria and pass them directly to the protocol handler node. 
I am going to use GTPU as the illustrating example.

Bypass node SHOULD intercept packets with destination IP matching a local 
address and UDP destination port equal to 2152.

Bypass node MUST NOT intercept a packet if destination IP doesn’t match a local 
address. Otherwise enabling GTPU bypass would change the observable system 
behaviour.

An address is local within a certain VRF. It’s possible that an address is 
local in one VRF but it’s not in another. But GTPU bypass node is not VRF aware.

Image a vpp setup with 2 interfaces, associated with different VRF-s. The first 
interface address is 10.0.10.100, the other one — 192.168.0.7. Both have GTPU 
bypass enabled. Now GTPU bypass in the second interface will intercept packets 
sent to 10.0.10.100 (the first interface’s address), though it shouldn’t.

This is a somewhat contrived example, but it looks like bypass node should be 
VRF-aware for correctness.

Am I missing something?

Would you be open to a patch making GTPU bypass VRF-aware?

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

View/Reply Online (#15575): https://lists.fd.io/g/vpp-dev/message/15575
Mute This Topic: https://lists.fd.io/mt/71569502/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] Change interface default MTU to 1500

[John Lo (loj) via Lists.Fd.Io]

Thanks Dave, that would be good.  -John

From: Dave Barach (dbarach) 
Sent: Wednesday, February 26, 2020 10:08 AM
To: John Lo (loj) ; vpp-dev 
Subject: RE: Change interface default MTU to 1500

OK, how about this: I'll add a VLIB_CONFIG_FUNCTION, or [more likely] add a 
system default MTU parameter to one of the existing config functions.

I'm sick of cluttering configs with interface MTU commands...

Thanks... Dave

From: John Lo (loj) mailto:l...@cisco.com>>
Sent: Wednesday, February 26, 2020 9:47 AM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>; 
vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: RE: Change interface default MTU to 1500

Hi Dave,

My memory was that in data center or cloud environment it is desirable to set 
MTU to jumbo frame size to avoid fragmentation by default.  Thus the question 
would be if it is reasonable to set default MTU size to 9000 for VPP and what 
kind of problem is it causing that would be fixed by changing it to 1500.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Wednesday, February 26, 2020 8:40 AM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Change interface default MTU to 1500


Folks,



I'm considering changing the default interface MTU to 1500, from the current 
value of 9000:



ethernet_register_interface (...)

{

  

  /* Standard default ethernet MTU. */

  vnet_sw_interface_set_mtu (vnm, hi->sw_if_index, 9000);

  

}



I've pinged some folks, and nobody remembers why we're setting the default MTU 
to 9000.



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

View/Reply Online (#15553): https://lists.fd.io/g/vpp-dev/message/15553
Mute This Topic: https://lists.fd.io/mt/71565329/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] Change interface default MTU to 1500

[John Lo (loj) via Lists.Fd.Io]

Hi Dave,

My memory was that in data center or cloud environment it is desirable to set 
MTU to jumbo frame size to avoid fragmentation by default.  Thus the question 
would be if it is reasonable to set default MTU size to 9000 for VPP and what 
kind of problem is it causing that would be fixed by changing it to 1500.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Wednesday, February 26, 2020 8:40 AM
To: vpp-dev 
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] Change interface default MTU to 1500


Folks,



I'm considering changing the default interface MTU to 1500, from the current 
value of 9000:



ethernet_register_interface (...)

{

  

  /* Standard default ethernet MTU. */

  vnet_sw_interface_set_mtu (vnm, hi->sw_if_index, 9000);

  

}



I've pinged some folks, and nobody remembers why we're setting the default MTU 
to 9000.



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

View/Reply Online (#15542): https://lists.fd.io/g/vpp-dev/message/15542
Mute This Topic: https://lists.fd.io/mt/71565329/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] L2 Bridge question on forwarding

[John Lo (loj) via Lists.Fd.Io]

The MAC address ad:ef:ad:ef:de:ad is a multicast address.  That’s why packet 
with that destination MAC is flooded in the bridge.  Try assign a unicast MAC 
address to gtpu_tunnel1.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of sunny cupertino
Sent: Friday, February 14, 2020 9:34 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] L2 Bridge question on forwarding

Hi All,

I request your help on L2 Bridge in VPP. I wanted to know if we can selectively 
forward L2 packets
to different interfaces on a bridge based on the ethernet address.
For e.g there is one interface and 2 GTPU tunnels on a L2 bridge.
I have added an entry into the L2 Fib table telling which interface to use for 
that
particular ethernet address (ad:ef:ad:ef:de:ad ).

vpp# show l2fib verbose
Mac-Address BD-Idx If-Idx BSN-ISN Age(min) static filter bvi 
Interface-Name
 ad:ef:ad:ef:de:ad1  4  0/0  no  -  - -   
gtpu_tunnel1
 01:00:5e:00:00:fb1  2  0/1  -   -  - -   
gtpu_tunnel0
 de:ad:be:ef:de:ad1  2  0/1  -   -  - -   
gtpu_tunnel0
 28:f1:0e:4e:c2:be1  3  0/5  -   -  - - 
 tap210

but when the packets arrive on tap210 they are sent to both tunnel1 and tunnel0 
as well.
I tried to switch off the flooding, in which case the packets are dropped 
saying L2 forward
feature is not enabled.  I request you to kindly let me know if this is 
possible at all to
achieve.

Thanks a lot,

Here some information about setup.

vpp# show bridge 3 detail
  BD-ID   Index   BSN  Age(min)  Learning  U-Forwrd   UU-Flood   Flooding  
ARP-Term   BVI-Intf
3   1  0 offonon   floodon   
offN/A

   Interface   If-idx ISN  SHG  BVI  TxFlood
VLAN-Tag-Rewrite
tap210   3 50-  * none
 gtpu_tunnel02 10-  * none
 gtpu_tunnel14 30-  * none
vpp#


trace:

Packet 1

01:08:35:178099: virtio-input
  virtio: hw_if_index 3 next-index 4 vring 0 len 1516
hdr: flags 0x00 gso_type 0x00 hdr_len 0 gso_size 0 csum_start 0 csum_offset 
0 num_buffers 1
01:08:35:178102: ethernet-input
  IP4: 28:f1:0e:4e:c2:be -> ad:ef:ad:ef:de:ad 802.1q vlan 4 priority 4
01:08:35:178104: l2-input
  l2-input: sw_if_index 3 dst ad:ef:ad:ef:de:ad src 28:f1:0e:4e:c2:be
01:08:35:178106: l2-learn
  l2-learn: sw_if_index 3 dst ad:ef:ad:ef:de:ad src 28:f1:0e:4e:c2:be bd_index 1
01:08:35:178109: l2-flood
  l2-flood: sw_if_index 3 dst ad:ef:ad:ef:de:ad src 28:f1:0e:4e:c2:be bd_index 1
  l2-flood: sw_if_index 3 dst ad:ef:ad:ef:de:ad src 28:f1:0e:4e:c2:be bd_index 1
01:08:35:178111: l2-output
  l2-output: sw_if_index 4 dst ad:ef:ad:ef:de:ad src 28:f1:0e:4e:c2:be data 81 
00 80 04 08 00 45 00 05 da 19 bf
  l2-output: sw_if_index 2 dst ad:ef:ad:ef:de:ad src 28:f1:0e:4e:c2:be data 81 
00 80 04 08 00 45 00 05 da 19 bf
01:08:35:178113: gtpu4-encap
  GTPU encap to gtpu_tunnel1 teid 7
  GTPU encap to gtpu_tunnel0 teid 3
01:08:35:178115: ip4-load-balance
  fib 4 dpo-idx 1 flow hash: 0x0005
  UDP: 192.168.50.40 -> 192.168.50.10
tos 0x00, ttl 254, length 1552, checksum 0xd159
fragment id 0x
  UDP: 11189 -> 2152
length 1532, checksum 0x
  fib 2 dpo-idx 1 flow hash: 0x0005
  UDP: 192.168.50.40 -> 192.168.50.10
tos 0x00, ttl 254, length 1552, checksum 0xd159


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

View/Reply Online (#15405): https://lists.fd.io/g/vpp-dev/message/15405
Mute This Topic: https://lists.fd.io/mt/71291032/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] QinQ and dot1ad any

[John Lo (loj) via Lists.Fd.Io]

Hi Jon,

You are right on both counts.  It is the combination of dot1q/ad-any and 
exact-match that we should reject.  It is also correct the check should be at 
lower level to reject the combination for both API and CLI.

Regards,
John

From: Jon Loeliger 
Sent: Wednesday, December 18, 2019 11:48 AM
To: John Lo (loj) 
Cc: Raj ; vpp-dev 
Subject: Re: [vpp-dev] QinQ and dot1ad any

On Tue, Dec 17, 2019 at 8:13 AM John Lo (loj) via 
Lists.Fd.Io<http://Lists.Fd.Io> 
mailto:cisco@lists.fd.io>> wrote:

Thus, sub-interface with "inner-dot1q any" is not an exact match sub-interface 
by definition since no match is present on inner tag.

I suppose the CLI:
>> create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q any 
>> exact-match
should have been rejected as exact match cannot be supported on the 
sub-interface.  This is something we should ideally fix in the CLI to avoid any 
confusion with the meaning of exact match.

Regards,
John

Hi John,

I have two questions here.  First, a clarification on what combinations of 
options
should be rejected.  Are you saying that the pair "inner-dot1q any" should be 
rejected,
or are you saying the trio "inner-do1q any exact match" should be rejected.  I 
suspect
you are meaning the latter.

Second, while rejecting it in the CLI would be nice, that would still allow the 
configuration
via the API, right?  So it might be better to reject it one layer down so it is 
caught by
both the CLI and the API.

Thanks,
jdl

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

View/Reply Online (#14924): https://lists.fd.io/g/vpp-dev/message/14924
Mute This Topic: https://lists.fd.io/mt/68757125/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] QinQ and dot1ad any

[John Lo (loj) via Lists.Fd.Io]

I don't think 8-10 S-VLANs with 4K C-VLANs totaling ~40K sub-interfaces will be 
an issue for VPP to handle, as long as the NICs being polled by device-input 
node from DPDK or other device drivers are not at a large scale.



I am not clear what was done with PPPoE to address similar issues. I suppose 
VPP can in theory be enhanced to support IP forwarding on "inner dot1q any" 
sub-interfaces as follows:

  *   All ARP entries for output IP addresses on that sub-interface must be 
statically provisioned by control plane via API or user CLI. This means the set 
IP ARP CLI/API needs to be enhanced to specify what are the inner VLAN tag to 
use for ARP entry.
  *   The handling of glean adjacency for any IP address using this 
sub-interface without ARP entry should probably be changed to not sent any ARP 
requests.
  *   We also need to enhance VPP's arp-request handling on that sub-interface 
so the VLAN tags are preserved on arp-response.  Or alternatively, require any 
neighbor of the sub-interface to have ARP entries provisioned so it won’t sent 
ARP requests.



I am not sure how much work will be involved in doing this, or if there is any 
other changes I may have missed.



Regards,

John



-Original Message-

From: vpp-dev@lists.fd.io  On Behalf Of Raj

Sent: Wednesday, December 18, 2019 8:32 AM

To: vpp-dev 

Subject: Re: [vpp-dev] QinQ and dot1ad any



On Tue, Dec 17, 2019 at 7:43 PM John Lo (loj)  wrote:



> Without exact match on a L3 sub-interface, VPP has no mechanism to

> know what VLAN tags to use for packet output, such as ARP request packets or 
> IP packets, on that sub-interface.



For a big QinQ network (like say about 8 - 10 S-VLAN each with 4K

C-VLANs) , the number of interface can become huge. Will that hit some internal 
VPP limits or will it become a performance problem?



Is it a good idea to have a mechanism to provide this information to VPP via a 
control plane application, like whats is being done for PPPoE, so that only 
outer VLAN interface needs to be created, while inner VLAN interface will be 
provided by the control plane application? Is this a road worth traveling?



Thanks and Regards,



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

View/Reply Online (#14923): https://lists.fd.io/g/vpp-dev/message/14923
Mute This Topic: https://lists.fd.io/mt/68757125/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] QinQ and dot1ad any

[John Lo (loj) via Lists.Fd.Io]

Hi Raj,

A sub-interface with "dot1q inner any" can only work with L2 forwarding via 
cross-connect or bridging where packets are forwarded using MAC header without 
any changes to MAC header nor VLAN IDs in VLAN tags.

For L3 IP forwarding, any VLAN tags on a packet must be exact match to a 
sub-interface which means both outer and inner VLAN tag IDs must be 
exact-matched to specific values defined of that sub-interface.  Without exact 
match on a L3 sub-interface, VPP has no mechanism to know what VLAN tags to use 
for packet output, such as ARP request packets or IP packets, on that 
sub-interface. Thus, sub-interface with "inner-dot1q any" is not an exact match 
sub-interface by definition since no match is present on inner tag.

I suppose the CLI:
>> create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q any 
>> exact-match
should have been rejected as exact match cannot be supported on the 
sub-interface.  This is something we should ideally fix in the CLI to avoid any 
confusion with the meaning of exact match.

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Raj
Sent: Tuesday, December 17, 2019 4:39 AM
To: vpp-dev 
Subject: [vpp-dev] QinQ and dot1ad any

Hello all,

When an interface is created using a command like:

create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q any 
exact-match

I can see that dual tagged packets with outer vlan 50 will be accepted by that 
interface.

But how does a packet goes out from this interface? Is there a means by which I 
can say that a given IP is with a specific S_VLAN:C_VLAN?

During testing VPP could receive an ARP packet, but when it sends it out, 
entire Ethernet header was missing. I guess there must be some means to add 
adjacency information so that correct headers can be added.

The trace is as follows:


00:01:04:749110: dpdk-input
  GigabitEthernet3/0/3 rx queue 0
  buffer 0x4c7d: current data 0, length 60, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x1
 ext-hdr-valid
 l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr
0x26b31fc0
packet_type 0x0 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_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
  ARP: 40:7b:1b:00:11:aa -> ff:ff:ff:ff:ff:ff 802.1ad vlan 50 802.1ad vlan 51
  request, type ethernet/IP4, address size 6/4
  40:7b:1b:00:11:aa/192.168.25.1 -> 00:00:00:00:00:00/192.168.25.2
00:01:04:749112: ethernet-input
  frame: flags 0x3, hw-if-index 1, sw-if-index 1
  ARP: 40:7b:1b:00:11:aa -> ff:ff:ff:ff:ff:ff 802.1ad vlan 50 802.1ad vlan 51
00:01:04:749113: arp-input
  request, type ethernet/IP4, address size 6/4
  40:7b:1b:00:11:aa/192.168.25.1 -> 00:00:00:00:00:00/192.168.25.2
00:01:04:749116: GigabitEthernet3/0/3-output
  GigabitEthernet3/0/3.50
  0x1235: 00:02:40:7b:1b:00 -> 00:01:08:00:06:04
00:01:04:749116: GigabitEthernet3/0/3-tx
  GigabitEthernet3/0/3 tx queue 0
  buffer 0x4c7d: current data 22, length 38, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x1
 ext-hdr-valid
 l4-cksum-computed l4-cksum-correct vlan-2-deep l2-hdr-offset 0 
l3-hdr-offset 22
  PKT MBUF: port 0, nb_segs 1, pkt_len 38
buf_len 2176, data_len 38, ol_flags 0x180, data_off 150, phys_addr
0x26b31fc0
packet_type 0x0 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_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
  0x1235: 00:02:40:7b:1b:00 -> 00:01:08:00:06:04

btw, if inner VLAN is specified, everything works fine.


Thanks and Regards,

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

View/Reply Online (#14914): https://lists.fd.io/g/vpp-dev/message/14914
Mute This Topic: https://lists.fd.io/mt/68757125/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] Trouble adding loopback to ip table

[John Lo (loj) via Lists.Fd.Io]

With the newer VPP, since around 18.04, IP table must be created before an 
interface can be set to it.  The default global IP table 0 is an exception 
because it is already present on startup.

The CLI is:
vpp# ip table ?
  ip table ip table [add|del] 

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Carl Baldwin
Sent: Tuesday, November 26, 2019 7:29 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Trouble adding loopback to ip table

Hi folks. I'm playing around a bit with vpp for the first time. I'm stuck on 
something and don't know where to go from here...

I'm trying to add a loopback interface to ip table 5. From the 
documentation[1], this table should be created by this command if it does not 
exist. However, what happened seems to contradict this.

vpp# set int l2 bridge loop0 13 bvi
loop0
vpp# set int state loop0 up
vpp# set int ip table loop0 5
set interface ip table: no such table 5

I cannot find any command that would explicitly create table 5 for me so that 
this can succeed. Maybe I missed something. Any thoughts on this?

For a little context, at the moment, I'm just going through this vxlan page [2] 
trying to get a better feel for vpp. I installed vpp on Ubuntu bionic according 
to the instructions. apt-cache shows that I have 19.08.1-release from 
packagecloud.io/fdio/release.

I do plan to dive a little bit more into the code. In the meantime, I will try 
to set up a build environment.

Thank you,
Carl

[1] 
https://docs.fd.io/vpp/17.04/clicmd_src_vnet_ip.html#clicmd_set_interface_ip_table
[2] 
https://wiki.fd.io/view/VPP/Using_VPP_as_a_VXLAN_Tunnel_Terminator#BVI_Interface_Creation_and_Setup
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14709): https://lists.fd.io/g/vpp-dev/message/14709
Mute This Topic: https://lists.fd.io/mt/62081854/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 19.04.3 Maintenance Release is complete!

[John Lo (loj) via Lists.Fd.Io]

Thank you very much, Dave!   Appreciate your quick action.   -John

From: vpp-dev@lists.fd.io  On Behalf Of Dave Wallace
Sent: Tuesday, October 29, 2019 2:02 PM
To: vpp-dev@lists.fd.io; csit-...@lists.fd.io
Subject: [vpp-dev] VPP 19.04.3 Maintenance Release is complete!

Folks,

The VPP 19.04.3 Maintenance Release is complete and artifacts are available on 
packagecloud.io [0].

Have a great day!
-daw-
"Your Friendly VPP 19.04 Release Manager"

[0] https://packagecloud.io/fdio/release
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14381): https://lists.fd.io/g/vpp-dev/message/14381
Mute This Topic: https://lists.fd.io/mt/39525404/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] How to configure l2 gre over ipsec in vpp 19.08

[John Lo (loj) via Lists.Fd.Io]

To create GRE tunnel in L2 mode, you can add “teb” keyword in the create CLI 
which makes the GRE tunnel work in transparent ethernet bridging mode:

vpp# create gre ?
  create gre tunnelcreate gre tunnel src  dst 
 [instance ] [outer-fib-id ] [teb | erspan ] [del]

In theory, a GRE tunnel can be configured with IPSec, as described by Neale, 
irrespective of it being in teb mode or not.  Neale, please correct me if it is 
not the case.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Chuan Han via 
Lists.Fd.Io
Sent: Wednesday, October 02, 2019 11:32 AM
To: Neale Ranns (nranns) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08

Gre is l3 in this case. Right? This limits the possible use cases.

Is there any plan to support l2 gre over ipsec transport mode? It seems vpp 17 
support s this feature. Not sure why it is dropped in 19.

On Wed, Oct 2, 2019, 12:18 AM Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:

Hi Chuan,

IPSec and GRE is supported using the tunnel protection mechanism :
  https://wiki.fd.io/view/VPP/IPSec

GRE over IPSec is only support when the SA is in tunnel mode. This means there 
is a double encap of the IP header ; once by the SA (in tunnel mode) and once 
by the tunnel itself. (Which has always been the case in VPP).

Example config follows :

  DBGvpp# ipsec sa add 20 spi 200 crypto-key 6541686776336961656264656f6f6579 
crypto-alg aes-cbc-128 tunnel-src 10.10.10.10 tunnel-dst 10.10.10.11
  DBGvpp# ipsec sa add 30 spi 300 crypto-key 6541686776336961656264656f6f6579 
crypto-alg aes-cbc-128 tunnel-src 10.10.10.11 tunnel-dst 10.10.10.10
  DBGvpp# create gre tunnel src 10.10.10.10 dst 10.10.10.11
gre0
  DBGvpp# ipsec tunnel protect gre0 sa-in 20 sa-out 30
  DBGvpp# sh ipsec protect
  gre0
   output-sa:
[1] sa 30 (0x1e) spi 300 (0x012c) protocol:esp flags:[tunnel ]
   input-sa:
[0] sa 20 (0x14) spi 200 (0x00c8) protocol:esp flags:[tunnel Protect ]

Regards,
neale


From: mailto:vpp-dev@lists.fd.io>> on behalf of "Chuan Han 
via Lists.Fd.Io" 
mailto:google@lists.fd.io>>
Reply to: "chuan...@google.com" 
mailto:chuan...@google.com>>
Date: Wednesday 2 October 2019 at 02:08
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Cc: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08

Hi, vpp experts,

I am trying to configure l2 gre over ipsec. I followed the steps here:
https://docs.fd.io/vpp/16.12/ipsec_gre_doc.html

I hit the following error:
create ipsec: unknown input `gre tunnel src 10.10.10.10 dst...'

My vpp version is v19.08.1-release

It seems on this version the "create ipsec gre tunnel" command does not work. 
If so, is there any other way of configuring l2 gre over ipsec in 19.08?

Please advise.

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

View/Reply Online (#14100): https://lists.fd.io/g/vpp-dev/message/14100
Mute This Topic: https://lists.fd.io/mt/34364734/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] Regarding "set interface state down"

[John Lo (loj) via Lists.Fd.Io]

I have similar setup with 10GE Intel NIC on bare-metal box running Ubuntu 
18.10.  I don’t see such an issue in the past up to the current VPP being used 
which is 19.04 (unless something changed with 19.08 or master).  The 10GE port 
is connected to an IXIA tester and when I set interface state down, the IXIA 
port also goes to the down state.  See the following output from VPP CLI which 
shows the link in carrier down/up state according to the “set interface state 
..” CLI:

vpp# set int state TenGigabitEthernet5/0/0 up
vpp# sho hard TenGigabitEthernet5/0/0
  NameIdx   Link  Hardware
TenGigabitEthernet5/0/01 up   TenGigabitEthernet5/0/0
  Link speed: 10 Gbps
  Ethernet address 90:e2:ba:6e:e7:dc
  Intel 82599
carrier up full duplex mtu 9206  promisc
flags: admin-up promisc pmd maybe-multiseg subif rx-ip4-cksum
rx: queues 8 (max 128), desc 1024 (min 32 max 4096 align 8)
tx: queues 9 (max 64), desc 1024 (min 32 max 4096 align 8)
pci: device 8086:10fb subsystem 8086:000c address :05:00.00 numa 0
module: id SFP/SFP+/SFP28, compatibility:
vendor: CISCO-TYCO, part 2163675-2
revision: A, serial: TED1614U0UF, date code: 12040200
cable length: 10m
max rx packet len: 15872
promiscuous: unicast on all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
   macsec-strip vlan-filter vlan-extend jumbo-frame scatter
   security keep-crc
rx offload active: ipv4-cksum jumbo-frame scatter
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
   tcp-tso macsec-insert multi-segs security
tx offload active: multi-segs
rss avail: ipv4 ipv4-tcp ipv4-udp ipv6 ipv6-tcp ipv6-udp ipv6-tcp-ex
   ipv6-udp-ex ipv6-ex ipv6-tcp-ex ipv6-udp-ex
rss active:ipv4 ipv4-tcp ipv4-udp ipv6 ipv6-tcp ipv6-udp ipv6-tcp-ex
   ipv6-udp-ex ipv6-ex ipv6-tcp-ex ipv6-udp-ex
tx burst function: ixgbe_xmit_pkts
rx burst function: ixgbe_recv_scattered_pkts_vec

rx frames ok261001142794
rx bytes ok  207756909187881
extended stats:
  rx good packets   261001143128
  rx good bytes  207756909513739
  rx q0packets  261001143128
  rx q0bytes 207756909513739
  mac local errors12
  mac remote errors5
  rx size 65 to 127 packets   5216652784
  rx size 128 to 255 packets 2384784
  rx size 256 to 511 packets 4769568
  rx size 512 to 1023 packets95390221918
  rx size 1024 to max packets88869405466
  rx total packets  261018946914
  rx total bytes 207771081309219
vpp# set int state TenGigabitEthernet5/0/0 down
vpp# sho hard TenGigabitEthernet5/0/0
  NameIdx   Link  Hardware
TenGigabitEthernet5/0/01down  TenGigabitEthernet5/0/0
  Link speed: 10 Gbps
  Ethernet address 90:e2:ba:6e:e7:dc
  Intel 82599
carrier down
flags: promisc pmd maybe-multiseg subif rx-ip4-cksum
rx: queues 8 (max 128), desc 1024 (min 32 max 4096 align 8)
tx: queues 9 (max 64), desc 1024 (min 32 max 4096 align 8)
pci: device 8086:10fb subsystem 8086:000c address :05:00.00 numa 0
module: id SFP/SFP+/SFP28, compatibility:
vendor: CISCO-TYCO, part 2163675-2
revision: A, serial: TED1614U0UF, date code: 12040200
cable length: 10m
max rx packet len: 15872
promiscuous: unicast on all-multicast off
vlan offload: strip off filter off qinq off
rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
   macsec-strip vlan-filter vlan-extend jumbo-frame scatter
   security keep-crc
rx offload active: ipv4-cksum jumbo-frame scatter
tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
   tcp-tso macsec-insert multi-segs security
tx offload active: multi-segs
rss avail: ipv4 ipv4-tcp ipv4-udp ipv6 ipv6-tcp ipv6-udp ipv6-tcp-ex
   ipv6-udp-ex ipv6-ex ipv6-tcp-ex ipv6-udp-ex
rss active:none
tx burst function: ixgbe_xmit_pkts
rx burst function: ixgbe_recv_scattered_pkts_vec

rx frames ok261033254872
rx bytes ok  207782470519777
rx missed4196707
extended stats:
  rx good packets   261033254872
  rx good bytes   

Re: [vpp-dev] Support for shared subnet

[John Lo (loj) via Lists.Fd.Io]

To clarify, what's implemented in VPP for IRB (Integrated Routing and Bridging) 
is via creation of BVI (Bridge Virtual Interface) interfaces on bridge domains. 
 Then IP addresses can then be configured on these BVIs to enable IP packets be 
routed (or L3 forwarded) among bridge domains or other IP destinations.   -John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Tuesday, September 10, 2019 2:37 PM
To: Andrew  Yourtchenko ; Burt Silverman 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Support for shared subnet

+1, see https://fdio-vpp.readthedocs.io/en/latest/usecases/homegateway.html for 
an IRB configuration which may be what's needed...

Dave

-Original Message-
From: Andrew  Yourtchenko  
Sent: Tuesday, September 10, 2019 1:41 PM
To: Burt Silverman 
Cc: Christian Hopps ; Dave Barach (dbarach) 
; krishnamurthy.m...@gmail.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Support for shared subnet

+1 

Access point is 99.999% certainly bridging and if it doesn’t (e.g. openwrt 
router config) the comment from Dave stands.

There are very corner cases scenarios that I vaguely remember like in cable 
space (IIRC, don’t take it for granted/true) to limit the broadcast domain 
without really splitting the subnet, but it is all very hackety hack :)

A bit more description about the original use case would be interesting in any 
case.

--a

> On 10 Sep 2019, at 19:19, Burt Silverman  wrote:
> 
> But Chris, I believe that wireless access point is using bridging -- not the 
> same thing. You probably can verify that by local log in to an ASUS router or 
> something else that uses Linux underneath, and double check me, using 
> ifconfig or ip commands.
> 
> Burt
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13941): https://lists.fd.io/g/vpp-dev/message/13941
> Mute This Topic: https://lists.fd.io/mt/34092746/675608
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [ayour...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13945): https://lists.fd.io/g/vpp-dev/message/13945
Mute This Topic: https://lists.fd.io/mt/34092746/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] table id for sub interfaces

[John Lo (loj) via Lists.Fd.Io]

The VPP CLI to set interface to an IP table also work on sub-interfaces if the 
name of the sub-interface is specified.  For example:

vpp# ip table 10
vpp# create sub-interfaces GigabitEthernet4/0/0 10
GigabitEthernet4/0/0.10
vpp# set int ip table GigabitEthernet4/0/0.10 10
vpp# set int ip address GigabitEthernet4/0/0.10 10.10.10.10/24
vpp# set int state GigabitEthernet4/0/0 up
vpp# set int state GigabitEthernet4/0/0.10 up
vpp# sho int addr GigabitEthernet4/0/0.10
GigabitEthernet4/0/0.10 (up):
  L3 10.10.10.10/24 ip4 table-id 10 fib-idx 3

vpp# show ip fib  table 10
ipv4-VRF:10, fib_index:3, flow hash:[src dst sport dport proto ] 
locks:[src:CLI:2, ]
0.0.0.0/0
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:45 buckets:1 uRPF:24 to:[0:0]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:49 buckets:1 uRPF:53 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.10.10.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:54 buckets:1 uRPF:59 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.10.10.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:53 buckets:1 uRPF:58 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet4/0/0.10: mtu:9000 
00505688b562810a0806
10.10.10.10/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:56 buckets:1 uRPF:63 to:[0:0]]
[0] [@2]: dpo-receive: 10.10.10.10 on GigabitEthernet4/0/0.10
10.10.10.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:55 buckets:1 uRPF:61 to:[0:0]]
[0] [@0]: dpo-drop ip4
224.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:51 buckets:1 uRPF:55 to:[0:0]]
[0] [@0]: dpo-drop ip4
240.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:50 buckets:1 uRPF:54 to:[0:0]]
[0] [@0]: dpo-drop ip4
255.255.255.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:52 buckets:1 uRPF:56 to:[0:0]]
[0] [@0]: dpo-drop ip4

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Satya Murthy
Sent: Tuesday, August 27, 2019 5:22 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] table id for sub interfaces

Hi,

Is there anyway I can associate a VPP sub-interface to a particular ip-fib 
table id ?
I could able to associate a physical interface to a table id, but not a sub 
interface. I did not find a CLI option to do this. Any inputs pls.

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13853): https://lists.fd.io/g/vpp-dev/message/13853
Mute This Topic: https://lists.fd.io/mt/33050491/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] GARP support in VPP

[John Lo (loj) via Lists.Fd.Io]

Right now, the only condition for VPP to send GARP would be on bonded 
interfaces in active-standby mode when the active link switches from one to the 
other.  GRAP is sent to help the upstream router/switch converge its routes 
faster.   There is no support for VPP to send GARP for other events.

The function to send out GARP is send_ip4_garp() in src/vnet/thernet/arp.c.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Shahid Khan
Sent: Saturday, May 04, 2019 3:32 AM
To: Shahid Khan 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] GARP support in VPP

anyone for below query ???

On Thu, May 2, 2019 at 2:37 PM Shahid Khan via Lists.Fd.Io 
mailto:gmail@lists.fd.io>> wrote:
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/1713129
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[shahidnasimk...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12928): https://lists.fd.io/g/vpp-dev/message/12928
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Problem with GTP in VPP

[John Lo (loj) via Lists.Fd.Io]

Looks like your GTPU tunnel is setup to send decap packets into L2 forwarding 
(either via "decap-next l2" CLI or default).  Now, you need to setup how to L2 
forward the decap packets.  You can either put this tunnel interface into a 
bridge domain or cross connect it to an output interface for the decap packets 
to be L2 forwarded as desired.   -John

From: vpp-dev@lists.fd.io  On Behalf Of Umberto Fattore
Sent: Friday, April 26, 2019 9:24 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Problem with GTP in VPP

Hi everybody,

I setup a GTPU tunnel in my VPP, receiving gtpu encapsulated packets. The setup 
is summarized as:

-- 

Msg->| GTP encap |>|   VPP   |
-- 

   192.168.4.97   192.168.4.14

Having a look at the trace in VPP, it seems that the received packet is 
correctly decap, but then for some reason it is dropped at the end, stating the 
following message: 'L2 feature forwarding disabled'.

Have any idea of the reason? Attached you can find the complete trace.

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

View/Reply Online (#12865): https://lists.fd.io/g/vpp-dev/message/12865
Mute This Topic: https://lists.fd.io/mt/31353279/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] Using wildcard-ip4-arp-publisher-process

[John Lo (loj) via Lists.Fd.Io]

More info from the want_ip4_arp_events API (see src/vnet/ip/ip.api) where the 
mac_ip param in the events will tell the client if the event is for ARP 
resolution in L# or MAC/IP info in BDs:

/** \brief Register for IP4 ARP resolution event on receing ARP reply or
   MAC/IP info from ARP requests in L2 BDs
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param enable_disable - 1 => register for events, 0 => cancel registration
@param pid - sender's pid
@param ip - exact IP4 address of interested arp resolution event, or
0 to get MAC/IP info from ARP requests in BDs
*/
autoreply define want_ip4_arp_events
{
  u32 client_index;
  u32 context;
  u8 enable_disable;
  u32 pid;
  vl_api_ip4_address_t ip;
};

/** \brief Tell client about an IP4 ARP resolution event or
   MAC/IP info from ARP requests in L2 BDs
@param client_index - opaque cookie to identify the sender
@param ip - the exact ip4 address of interest
@param pid - client pid registered to receive notification
@param sw_if_index - interface which received ARP packet
@param mac - the new mac address 
@param mac_ip - 0: ARP resolution event, 1: MAC/IP info from L2 BDs
*/
define ip4_arp_event
{
  u32 client_index;
  vl_api_ip4_address_t ip;
  u32 pid;
  u32 sw_if_index;
  vl_api_mac_address_t mac;
  u8 mac_ip;
};

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of John Lo (loj) via 
Lists.Fd.Io
Sent: Thursday, April 18, 2019 11:30 AM
To: Raj ; vpp-dev 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Using wildcard-ip4-arp-publisher-process

Hi Raj,

The registration for ARP events with specific IP is different to when 
registration for a wild card IP.

If a client register for ARP events for a specific IP address, an event will be 
sent by VPP to the client when ARP resolution occurred for the specified IP 
address in L3 FIB.

If a client register for ARP events for a wild card IP address, an event will 
be sent by VPP to client when an ARP request was sent by an interface in a 
bridge domain (BD) where the ARP-termination feature is enabled in that BD.  It 
has nothing to do with ARP resolution but rather an interface in a BD sent an 
ARP request or GARP.  It is designed for clients to learn MAC and IP of an 
interface in a BD which can be useful if these are interfaces for VMs.   Again 
- these events are generated from a BD for the registered client only if ARP 
termination is enabled on a BD.  ARP termination is not enabled on BDs by 
default.

Hope this helps,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Raj
Sent: Thursday, April 18, 2019 9:38 AM
To: vpp-dev 
Subject: [vpp-dev] Using wildcard-ip4-arp-publisher-process

Hi all,

I am trying to get ARP events from VPP and found that there is a 
'wildcard-ip4-arp-publisher-process' process which could be used. To use this, 
I registered a client using API `vpp.api.want_ip4_arp_events` using 0 as IP 
address argument. I could see that registration is happening and 
`wc_arp_set_publisher_node` function was getting invoked, as it should.

But the node was not reporting any ARP events to the client. Looking through 
the code, the main function in the node,  `wc_arp_process (vlib_main_t vm, 
vlib_node_runtime_t rt, vlib_frame_t * f)` is not getting invoked.

I also registered another client, using `vpp.api.want_ip4_arp_events` but using 
a valid IP addres  as IP address in argument.  Here I'm able to get the ARP 
events in the client process from ip-route-resolver-process, as expected.

I just need to figure out why wildcard-ip4-arp-publisher-process is not 
reporting ARP events, though ip-route-resolver-process is doing so.

Thanks and Regards,

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

View/Reply Online (#12816): https://lists.fd.io/g/vpp-dev/message/12816
Mute This Topic: https://lists.fd.io/mt/31223473/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] Using wildcard-ip4-arp-publisher-process

[John Lo (loj) via Lists.Fd.Io]

Hi Raj,

The registration for ARP events with specific IP is different to when 
registration for a wild card IP.

If a client register for ARP events for a specific IP address, an event will be 
sent by VPP to the client when ARP resolution occurred for the specified IP 
address in L3 FIB.

If a client register for ARP events for a wild card IP address, an event will 
be sent by VPP to client when an ARP request was sent by an interface in a 
bridge domain (BD) where the ARP-termination feature is enabled in that BD.  It 
has nothing to do with ARP resolution but rather an interface in a BD sent an 
ARP request or GARP.  It is designed for clients to learn MAC and IP of an 
interface in a BD which can be useful if these are interfaces for VMs.   Again 
- these events are generated from a BD for the registered client only if ARP 
termination is enabled on a BD.  ARP termination is not enabled on BDs by 
default.

Hope this helps,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Raj
Sent: Thursday, April 18, 2019 9:38 AM
To: vpp-dev 
Subject: [vpp-dev] Using wildcard-ip4-arp-publisher-process

Hi all,

I am trying to get ARP events from VPP and found that there is a 
'wildcard-ip4-arp-publisher-process' process which could be used. To use this, 
I registered a client using API `vpp.api.want_ip4_arp_events` using 0 as IP 
address argument. I could see that registration is happening and 
`wc_arp_set_publisher_node` function was getting invoked, as it should.

But the node was not reporting any ARP events to the client. Looking through 
the code, the main function in the node,  `wc_arp_process (vlib_main_t vm, 
vlib_node_runtime_t rt, vlib_frame_t * f)` is not getting invoked.

I also registered another client, using `vpp.api.want_ip4_arp_events` but using 
a valid IP addres  as IP address in argument.  Here I'm able to get the ARP 
events in the client process from ip-route-resolver-process, as expected.

I just need to figure out why wildcard-ip4-arp-publisher-process is not 
reporting ARP events, though ip-route-resolver-process is doing so.

Thanks and Regards,

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

View/Reply Online (#12815): https://lists.fd.io/g/vpp-dev/message/12815
Mute This Topic: https://lists.fd.io/mt/31223473/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 PPPoE Plugin

[John Lo (loj) via Lists.Fd.Io]

Hi Abeeha,

I submitted a patch to gerrt.fd.io to remove output nodes for PPPoE.
https://gerrit.fd.io/r/#/c/18993/

Would you like to try if it fixes your node index out of range issue?  I expect 
the patch can easily be cherry-picked to 1901.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of John Lo (loj) via 
Lists.Fd.Io
Sent: Wednesday, April 17, 2019 12:06 PM
To: Abeeha Aqeel ; hongjun...@intel.com; 
vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP PPPoE Plugin

Hi Abeeha,

Have you tried the suggestion I made previously in a similar thread to get rid 
of the dummy_interface_tx nodes for PPPoE sessions?

diff --git a/src/plugins/pppoe/pppoe.c b/src/plugins/pppoe/pppoe.c
index d73a718..f61926d 100644
--- a/src/plugins/pppoe/pppoe.c
+++ b/src/plugins/pppoe/pppoe.c
@@ -87,7 +87,7 @@ pppoe_interface_admin_up_down (vnet_main_t * vnm, u32 
hw_if_index, u32 flags)
VNET_DEVICE_CLASS (pppoe_device_class,static) = {
   .name = "PPPoE",
   .format_device_name = format_pppoe_name,
-  .tx_function = dummy_interface_tx,
+  //  .tx_function = dummy_interface_tx,
   .admin_up_down_function = pppoe_interface_admin_up_down,
};
/* *INDENT-ON* */

I believe this would prevent creation of TX nodes for PPPoE sessions which are 
not used anyway. Then you should not encounter any problem with node index 
assert error.

If it does work, please submit this patch via gerrit.fd.io so it can be merged 
upstream.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Abeeha Aqeel
Sent: Wednesday, April 17, 2019 8:20 AM
To: hongjun...@intel.com<mailto:hongjun...@intel.com>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: b...@xflowresearch.com<mailto:b...@xflowresearch.com>
Subject: [vpp-dev] VPP PPPoE Plugin

Dear Hongjun,

(PFA = Please find attached)

Code:
Branch: stable/1901
Patch: PFA: stable_1901_patch.txt

Configuration:
PFA: vpp-startup.conf

Steps for setting up:
PFA: setup_steps.bash

Attempted to make 10,000 connections.
Using API calls from control plane application; to create pppoe sessions
Final output from control plane before VPP crashed:
PFA: no_of_connections.png

VPP log-file:
PFA:vpp.log

Dump from journalctl:
PFA: journal_dump.txt

As you can see from the journalctl output, the code crashes on the Assertion 
‘node_index < 2^14’. And as you can see from the patch file included, we 
changed the original assertion from ‘less than 2^10’ to ‘less than 2^14’. We 
did that, because the original assertion crashes VPP way before even 7,000 
connections are connected. (Around 400 connections.)



Regards,

Abeeha Aqeel


From: AbduSami bin Khurram<mailto:abdusami.khur...@xflowresearch.com>
Sent: Wednesday, April 17, 2019 2:33 PM
To: Abeeha Aqeel<mailto:abeeha.aq...@xflowresearch.com>
Subject: RE: VPP PPPoE Plugin

Dear Abeeha,

(PFA = Please find attached)

Code:
Branch: stable/1901
Patch: PFA: stable_1901_patch.txt

Configuration:
PFA: vpp-startup.conf

Steps for setting up:
PFA: setup_steps.bash

Attempted to make 10,000 connections.
Using API calls from control plane application; to create pppoe sessions
Final output from control plane before VPP crashed:
PFA: no_of_connections.png

VPP log-file:
PFA:vpp.log

Dump from journalctl:
PFA: journal_dump.txt

As you can see from the journalctl output, the code crashes on the Assertion 
‘node_index < 2^14’. And as you can see from the patch file included, we 
changed the original assertion from ‘less than 2^10’ to ‘less than 2^14’. We 
did that, because the original assertion crashes VPP way before even 7,000 
connections are connected. (Around 400 connections.)

Warm Regards,

AbduSami bin Khurram
Software Design Engineer, xFlow Research Pvt. Ltd.
+92-331-5543190
abdusami.khur...@xflowresearch.com<mailto:abdusami.khur...@xflowresearch.com>
www.xflowresearch.com<http://www.xflowresearch.com>

From: Ni, Hongjun<mailto:hongjun...@intel.com>
Sent: 17 April 2019 13:04
To: Abeeha Aqeel<mailto:abeeha.aq...@xflowresearch.com>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: b...@xflowresearch.com<mailto:b...@xflowresearch.com>
Subject: RE: VPP PPPoE Plugin

Hi Aqeel,

Could you send out the core dump log when VPP crash with 7000 sessions?

Thanks,
Hongjun

From: Abeeha Aqeel [mailto:abeeha.aq...@xflowresearch.com]
Sent: Tuesday, April 16, 2019 8:01 PM
To: Ni, Hongjun mailto:hongjun...@intel.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: b...@xflowresearch.com<mailto:b...@xflowresearch.com>
Subject: VPP PPPoE Plugin

Dear Hongjun,

I am trying to create 64000 VPP sessions with the VPP Plugin. VPP is being used 
as the forwarding plane while our control plane separately caters the PPPoE 
control packets. The VPP is installed on Centos 7 on bare-metal server. The 
current implementation of the plugin included in VPP Stable 19.01 is allowing 
only 7000 sessions and VP

Re: [vpp-dev] VPP PPPoE Plugin

[John Lo (loj) via Lists.Fd.Io]

Hi Abeeha,

Have you tried the suggestion I made previously in a similar thread to get rid 
of the dummy_interface_tx nodes for PPPoE sessions?

diff --git a/src/plugins/pppoe/pppoe.c b/src/plugins/pppoe/pppoe.c
index d73a718..f61926d 100644
--- a/src/plugins/pppoe/pppoe.c
+++ b/src/plugins/pppoe/pppoe.c
@@ -87,7 +87,7 @@ pppoe_interface_admin_up_down (vnet_main_t * vnm, u32 
hw_if_index, u32 flags)
VNET_DEVICE_CLASS (pppoe_device_class,static) = {
   .name = "PPPoE",
   .format_device_name = format_pppoe_name,
-  .tx_function = dummy_interface_tx,
+  //  .tx_function = dummy_interface_tx,
   .admin_up_down_function = pppoe_interface_admin_up_down,
};
/* *INDENT-ON* */

I believe this would prevent creation of TX nodes for PPPoE sessions which are 
not used anyway. Then you should not encounter any problem with node index 
assert error.

If it does work, please submit this patch via gerrit.fd.io so it can be merged 
upstream.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Abeeha Aqeel
Sent: Wednesday, April 17, 2019 8:20 AM
To: hongjun...@intel.com; vpp-dev@lists.fd.io
Cc: b...@xflowresearch.com
Subject: [vpp-dev] VPP PPPoE Plugin

Dear Hongjun,

(PFA = Please find attached)

Code:
Branch: stable/1901
Patch: PFA: stable_1901_patch.txt

Configuration:
PFA: vpp-startup.conf

Steps for setting up:
PFA: setup_steps.bash

Attempted to make 10,000 connections.
Using API calls from control plane application; to create pppoe sessions
Final output from control plane before VPP crashed:
PFA: no_of_connections.png

VPP log-file:
PFA:vpp.log

Dump from journalctl:
PFA: journal_dump.txt

As you can see from the journalctl output, the code crashes on the Assertion 
‘node_index < 2^14’. And as you can see from the patch file included, we 
changed the original assertion from ‘less than 2^10’ to ‘less than 2^14’. We 
did that, because the original assertion crashes VPP way before even 7,000 
connections are connected. (Around 400 connections.)



Regards,

Abeeha Aqeel


From: AbduSami bin Khurram
Sent: Wednesday, April 17, 2019 2:33 PM
To: Abeeha Aqeel
Subject: RE: VPP PPPoE Plugin

Dear Abeeha,

(PFA = Please find attached)

Code:
Branch: stable/1901
Patch: PFA: stable_1901_patch.txt

Configuration:
PFA: vpp-startup.conf

Steps for setting up:
PFA: setup_steps.bash

Attempted to make 10,000 connections.
Using API calls from control plane application; to create pppoe sessions
Final output from control plane before VPP crashed:
PFA: no_of_connections.png

VPP log-file:
PFA:vpp.log

Dump from journalctl:
PFA: journal_dump.txt

As you can see from the journalctl output, the code crashes on the Assertion 
‘node_index < 2^14’. And as you can see from the patch file included, we 
changed the original assertion from ‘less than 2^10’ to ‘less than 2^14’. We 
did that, because the original assertion crashes VPP way before even 7,000 
connections are connected. (Around 400 connections.)

Warm Regards,

AbduSami bin Khurram
Software Design Engineer, xFlow Research Pvt. Ltd.
+92-331-5543190
abdusami.khur...@xflowresearch.com
www.xflowresearch.com

From: Ni, Hongjun
Sent: 17 April 2019 13:04
To: Abeeha Aqeel; 
vpp-dev@lists.fd.io
Cc: b...@xflowresearch.com
Subject: RE: VPP PPPoE Plugin

Hi Aqeel,

Could you send out the core dump log when VPP crash with 7000 sessions?

Thanks,
Hongjun

From: Abeeha Aqeel [mailto:abeeha.aq...@xflowresearch.com]
Sent: Tuesday, April 16, 2019 8:01 PM
To: Ni, Hongjun mailto:hongjun...@intel.com>>; 
vpp-dev@lists.fd.io
Cc: b...@xflowresearch.com
Subject: VPP PPPoE Plugin

Dear Hongjun,

I am trying to create 64000 VPP sessions with the VPP Plugin. VPP is being used 
as the forwarding plane while our control plane separately caters the PPPoE 
control packets. The VPP is installed on Centos 7 on bare-metal server. The 
current implementation of the plugin included in VPP Stable 19.01 is allowing 
only 7000 sessions and VPP crashes afterwards.

I tried to add the PPPoE plugin implemented by OpenBRAS 
(https://gerrit.fd.io/r/#/c/7407/) to the VPP Stable 19.01 ( 
https://github.com/FDio/vpp.git)  with DPDK 18.11.0.  VPP built successfully 
and started as well but the PPPoE plugin did not show in “vppctl show plugins”.

Kindly, suggest how to connect 64000 pppoe sessions with VPP.

Regards,

Abeeha Aqeel




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

View/Reply Online (#12810): https://lists.fd.io/g/vpp-dev/message/12810
Mute This Topic: https://lists.fd.io/mt/31199594/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 register node change upper limit

[John Lo (loj) via Lists.Fd.Io]

I think the way to not create TX nodes for PPPoE interfaces would be to just 
remove the .tx_function specified in its device class init in 
src/plugin/pppoe/pppoe.c:

/* *INDENT-OFF* */
VNET_DEVICE_CLASS (pppoe_device_class,static) = {
  .name = "PPPoE",
  .format_device_name = format_pppoe_name,
  .tx_function = dummy_interface_tx,   <== remove this line
  .admin_up_down_function = pppoe_interface_admin_up_down,
};
/* *INDENT-ON* */

The tx_function specified above is causing VPP infra to create a TX node for 
each PPPoE interfaces with this dummy-tx function which is clearly not used.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Abeeha Aqeel
Sent: Friday, April 05, 2019 4:07 AM
To: dmar...@me.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP register node change upper limit

The pppoe plugin?


Regards,

Abeeha Aqeel
Network Design Engineer
Xflow Research Inc.
+923245062309 (GMT+5)
abeeha.aq...@xflowresearch.com
www.xflowresearch.com

[cid:6e5d1814-0a3d-444b-9050-060db1465f05]


From: Damjan Marion via Lists.Fd.Io
Sent: Friday, April 5, 2019 1:03 PM
To: Abeeha Aqeel
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP register node change upper limit


On 5 Apr 2019, at 08:31, Abeeha Aqeel 
mailto:abeeha.aq...@xflowresearch.com>> wrote:

Can you please suggest what other lighter ways can be used to deal with a large 
number of sessions ?

Currently, I’ve changed the vlib_error_t to use 14 bits for node. That gives me 
1<<14 node indices  and roughly 7000-8000 interfaces. To further increase the 
number of sessions is it suitable to use 16 bits for node giving approximately 
30,000 interfaces? Will this effect any other critical functionality?

That code is simply wrong, and it needs to be rewritten….



From: Damjan Marion via Lists.Fd.Io
Sent: Monday, February 4, 2019 12:43 PM
To: Abeeha Aqeel
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP register node change upper limit


It is a bit of shame that that plugin doesn’t scale. Somebody will need to 
rewrite that plugin to make it right, i.e simple use of sub-interfaces will 
likely make this limitation to dissapear...

—
Damjan

On Feb 4, 2019, at 5:56 AM, Abeeha Aqeel 
mailto:abeeha.aq...@xflowresearch.com>> wrote:

I am using the vpp pppoe plugin and that’s how its working. I do see an option 
in the vnet/interface.c to create interfaces that do not need TX nodes, but I 
am not sure how to use that.

Also I can not figure out where the nodes created along with the pppoe sessions 
are being used as they do not show up in the “show runtime” or the trace of 
packets.

Regards,

Abeeha

From: Abeeha Aqeel
Sent: Friday, February 1, 2019 5:36 PM
Cc: vpp-dev@lists.fd.io
Subject: FW: [vpp-dev] VPP register node change upper limit




From: Abeeha Aqeel
Sent: Friday, February 1, 2019 5:32 PM
To: dmar...@me.com
Subject: RE: [vpp-dev] VPP register node change upper limit

I am using the vpp pppoe plugin and that’s how its working. I do see an option 
in the vnet/interface.c to create interfaces that do not need TX nodes, but I 
am not sure how to use that.

Also I can not figure out where the nodes created along with the pppoe sessions 
are being used as they do not show up in the “show runtime” or the trace of 
packets.



From: Damjan Marion via Lists.Fd.Io
Sent: Friday, February 1, 2019 5:23 PM
To: Abeeha Aqeel
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP register node change upper limit



On 1 Feb 2019, at 11:32, Abeeha Aqeel 
mailto:abeeha.aq...@xflowresearch.com>> wrote:

Dear All,

I am trying to create 64k PPPoE sessions with VPP but VPP crashes after 
creating 216 sessions each time. From the system logs it seems that it crashes 
while trying to register a node and that node’s index is greater than the limit 
(1024). (attached screenshot of the trace)

From the “show vlib graph”, I can see that two new nodes are registered for 
each session i.e. pppoe_session0-tx and pppoe_session0-output.

Can someone guide me to how to increase the upper limit on the number of nodes?

Currently number of nodes is limited by buffer metadata space, and the way how 
we calculate node errors (vlib_error_t).
Currently vlib_error_t is u16, and 10 bits are used for node. That gives you 1 
<< 10 of node indices, so roughly
300-400 interfaces (2 nodes per interface  + other registered nodes < 1024).

This is something we can improve, but the real question is, do you really want 
to go that way.
Have you considered using some more lighter way to deal with 

Re: [vpp-dev] Status of PPPoE Plugin

[John Lo (loj) via Lists.Fd.Io]

This part of the code mentioned let any MAC address with mcast bit through:
> +  /*if (!ethernet_address_cast (e0->dst_address) &&
>   (hi->hw_address != 0) &&
>   !eth_mac_equal ((u8 *) e0, hi->hw_address))
> error0 = ETHERNET_ERROR_L3_MAC_MISMATCH;

Regards,
John

From: Damjan Marion 
Sent: Friday, March 22, 2019 3:41 AM
To: Ni, Hongjun 
Cc: John Lo (loj) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Status of PPPoE Plugin



On 22 Mar 2019, at 07:34, Ni, Hongjun 
mailto:hongjun...@intel.com>> wrote:
Hi John,

For first PADI packet, its destination MAC is broadcast address.
Not sure it is accepted by ethernet-input node?


Sure it does, otherwise arp, dhcp, ... will not work.


Do we need special process to handle it?
5.1<https://tools.ietf.org/html/rfc2516#section-5.1> The PPPoE Active Discovery 
Initiation (PADI) packet


   The Host sends the PADI packet with the DESTINATION_ADDR set to the
   broadcast address.  The CODE field is set to 0x09 and the SESSION_ID
   MUST be set to 0x.

Thanks,
Hongjun

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of John Lo (loj) via Lists.Fd.Io
Sent: Thursday, March 21, 2019 11:34 PM
To: dmar...@me.com<mailto:dmar...@me.com>; Ni, Hongjun 
mailto:hongjun...@intel.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Status of PPPoE Plugin

Thanks for citing the PPPoE RFC 2516, Damjan.  The RFC goes on to describe how 
to resolve the MAC address for PPPoE sessions in Section 5 in discovery stage.  
As such, there is really no “L2 mode” for PPPoE sessions mentioned in my 
previous reply in this thread.  The root cause of the problem was MAC address 
resolution for PPPoE sessions.   -John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Damjan Marion 
via Lists.Fd.Io
Sent: Thursday, March 21, 2019 11:08 AM
To: Ni, Hongjun mailto:hongjun...@intel.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Status of PPPoE Plugin



> On 21 Mar 2019, at 06:20, Ni, Hongjun 
> mailto:hongjun...@intel.com>> wrote:
>
> Hi Raj,
>
> I think you may check the Ethernet type, if it is PPPoE packet, then MAC 
> check will be skipped.
>
> Thanks,
> Hongjun
>
> -Original Message-
> From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io] On Behalf Of Raj
> Sent: Wednesday, March 20, 2019 9:48 PM
> To: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Cc: alp.ars...@xflowresearch.com<mailto:alp.ars...@xflowresearch.com>; Ni, 
> Hongjun mailto:hongjun...@intel.com>>
> Subject: Re: [vpp-dev] Status of PPPoE Plugin
>
> I commented out the offending parts and now PPPoE is working fine.
>
> diff --git a/src/vnet/ethernet/node.c b/src/vnet/ethernet/node.c index 
> 53d5b4eb0..7c5f673e0 100755
> --- a/src/vnet/ethernet/node.c
> +++ b/src/vnet/ethernet/node.c
> @@ -429,14 +429,14 @@ ethernet_input_inline (vlib_main_t * vm,
> }
>   else
> {
> +  /*if (!ethernet_address_cast (e0->dst_address) &&
>   (hi->hw_address != 0) &&
>   !eth_mac_equal ((u8 *) e0, hi->hw_address))
> error0 = ETHERNET_ERROR_L3_MAC_MISMATCH;
>   if (!ethernet_address_cast (e1->dst_address) &&
>   (hi->hw_address != 0) &&
>   !eth_mac_equal ((u8 *) e1, hi->hw_address))
> +error1 = ETHERNET_ERROR_L3_MAC_MISMATCH;*/
>   vlib_buffer_advance (b0, sizeof (ethernet_header_t));
>   determine_next_node (em, variant, 0, type0, b0,
>, ); @@ -653,10 +653,10 @@ 
> ethernet_input_inline (vlib_main_t * vm,
> }
>   else
> {
> +  /*if (!ethernet_address_cast (e0->dst_address) &&
>   (hi->hw_address != 0) &&
>   !eth_mac_equal ((u8 *) e0, hi->hw_address))
> +error0 = ETHERNET_ERROR_L3_MAC_MISMATCH;*/
>   vlib_buffer_advance (b0, sizeof (ethernet_header_t));
>   determine_next_node (em, variant, 0, type0, b0,
>, );
>
> I am sure this is not a patch which will be accepted upstream.

I would say: for sure not.

> I am not sure how to _correctly_ fix this, so that it will be accepted by 
> upstream. If some pointers are given I can submit a patch to get PPPoE 
> working correctly again in VPP.

This is typical case of “shotgun wedding” between control plane and dataplane 
over the TAP interface.

RFC2516 Section 4. clearly says:

   The DESTINATION_ADDR field contains either a unicast Ethernet
   

Re: [vpp-dev] Status of PPPoE Plugin

[John Lo (loj) via Lists.Fd.Io]

Thanks for citing the PPPoE RFC 2516, Damjan.  The RFC goes on to describe how 
to resolve the MAC address for PPPoE sessions in Section 5 in discovery stage.  
As such, there is really no “L2 mode” for PPPoE sessions mentioned in my 
previous reply in this thread.  The root cause of the problem was MAC address 
resolution for PPPoE sessions.   -John

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
Lists.Fd.Io
Sent: Thursday, March 21, 2019 11:08 AM
To: Ni, Hongjun 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Status of PPPoE Plugin



> On 21 Mar 2019, at 06:20, Ni, Hongjun 
> mailto:hongjun...@intel.com>> wrote:
>
> Hi Raj,
>
> I think you may check the Ethernet type, if it is PPPoE packet, then MAC 
> check will be skipped.
>
> Thanks,
> Hongjun
>
> -Original Message-
> From: vpp-dev@lists.fd.io 
> [mailto:vpp-dev@lists.fd.io] On Behalf Of Raj
> Sent: Wednesday, March 20, 2019 9:48 PM
> To: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Cc: alp.ars...@xflowresearch.com; Ni, 
> Hongjun mailto:hongjun...@intel.com>>
> Subject: Re: [vpp-dev] Status of PPPoE Plugin
>
> I commented out the offending parts and now PPPoE is working fine.
>
> diff --git a/src/vnet/ethernet/node.c b/src/vnet/ethernet/node.c index 
> 53d5b4eb0..7c5f673e0 100755
> --- a/src/vnet/ethernet/node.c
> +++ b/src/vnet/ethernet/node.c
> @@ -429,14 +429,14 @@ ethernet_input_inline (vlib_main_t * vm,
> }
>   else
> {
> +  /*if (!ethernet_address_cast (e0->dst_address) &&
>   (hi->hw_address != 0) &&
>   !eth_mac_equal ((u8 *) e0, hi->hw_address))
> error0 = ETHERNET_ERROR_L3_MAC_MISMATCH;
>   if (!ethernet_address_cast (e1->dst_address) &&
>   (hi->hw_address != 0) &&
>   !eth_mac_equal ((u8 *) e1, hi->hw_address))
> +error1 = ETHERNET_ERROR_L3_MAC_MISMATCH;*/
>   vlib_buffer_advance (b0, sizeof (ethernet_header_t));
>   determine_next_node (em, variant, 0, type0, b0,
>, ); @@ -653,10 +653,10 @@ 
> ethernet_input_inline (vlib_main_t * vm,
> }
>   else
> {
> +  /*if (!ethernet_address_cast (e0->dst_address) &&
>   (hi->hw_address != 0) &&
>   !eth_mac_equal ((u8 *) e0, hi->hw_address))
> +error0 = ETHERNET_ERROR_L3_MAC_MISMATCH;*/
>   vlib_buffer_advance (b0, sizeof (ethernet_header_t));
>   determine_next_node (em, variant, 0, type0, b0,
>, );
>
> I am sure this is not a patch which will be accepted upstream.

I would say: for sure not.

> I am not sure how to _correctly_ fix this, so that it will be accepted by 
> upstream. If some pointers are given I can submit a patch to get PPPoE 
> working correctly again in VPP.

This is typical case of “shotgun wedding” between control plane and dataplane 
over the TAP interface.

RFC2516 Section 4. clearly says:

   The DESTINATION_ADDR field contains either a unicast Ethernet
   destination address, or the Ethernet broadcast address (0x).
   For Discovery packets, the value is either a unicast or broadcast
   address as defined in the Discovery section.  For PPP session
   traffic, this field MUST contain the peer's unicast address as
   determined from the Discovery stage.

   The SOURCE_ADDR field MUST contains the Ethernet MAC address of the
   source device.


So right thing to do here is to make sure that both control and session
packets are using single mac address, preferably MAC address of the VPP
interface where session traffic is received.


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

View/Reply Online (#12600): https://lists.fd.io/g/vpp-dev/message/12600
Mute This Topic: https://lists.fd.io/mt/28791570/675294
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [l...@cisco.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12602): https://lists.fd.io/g/vpp-dev/message/12602
Mute This Topic: https://lists.fd.io/mt/28791570/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] Status of PPPoE Plugin

[John Lo (loj) via Lists.Fd.Io]

Hi Hongjun,

I understand PPP is point to point so there is no MAC as such to check.  If it 
is PPPoE, are you sure we are supposed to accept packets with any MAC address?  
Is PPPoE also a point to point interface only and not on a Ethernet LAN?

With Ethernet, MAC check is required if interface is in L3 mode.  If interface 
is in L2 mode, then it is in promiscuous mode so MAC check is not needed.   

With PPPoE interface, I suppose if we put it in L2 mode, then MAC would not be 
checked so packet would be accepted.  If it is in L3 mode, is there any MAC 
address resolution mechanism to resolve the MAC between sender and receiver so 
the correct MAC address can be used?

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Ni, Hongjun
Sent: Thursday, March 21, 2019 1:21 AM
To: Raj ; vpp-dev 
Cc: alp.ars...@xflowresearch.com
Subject: Re: [vpp-dev] Status of PPPoE Plugin

Hi Raj,

I think you may check the Ethernet type, if it is PPPoE packet, then MAC check 
will be skipped.

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Raj
Sent: Wednesday, March 20, 2019 9:48 PM
To: vpp-dev 
Cc: alp.ars...@xflowresearch.com; Ni, Hongjun 
Subject: Re: [vpp-dev] Status of PPPoE Plugin

I commented out the offending parts and now PPPoE is working fine.

diff --git a/src/vnet/ethernet/node.c b/src/vnet/ethernet/node.c index 
53d5b4eb0..7c5f673e0 100755
--- a/src/vnet/ethernet/node.c
+++ b/src/vnet/ethernet/node.c
@@ -429,14 +429,14 @@ ethernet_input_inline (vlib_main_t * vm,
 }
   else
 {
+  /*if (!ethernet_address_cast (e0->dst_address) &&
   (hi->hw_address != 0) &&
   !eth_mac_equal ((u8 *) e0, hi->hw_address))
 error0 = ETHERNET_ERROR_L3_MAC_MISMATCH;
   if (!ethernet_address_cast (e1->dst_address) &&
   (hi->hw_address != 0) &&
   !eth_mac_equal ((u8 *) e1, hi->hw_address))
+error1 = ETHERNET_ERROR_L3_MAC_MISMATCH;*/
   vlib_buffer_advance (b0, sizeof (ethernet_header_t));
   determine_next_node (em, variant, 0, type0, b0,
, ); @@ -653,10 +653,10 @@ 
ethernet_input_inline (vlib_main_t * vm,
 }
   else
 {
+  /*if (!ethernet_address_cast (e0->dst_address) &&
   (hi->hw_address != 0) &&
   !eth_mac_equal ((u8 *) e0, hi->hw_address))
+error0 = ETHERNET_ERROR_L3_MAC_MISMATCH;*/
   vlib_buffer_advance (b0, sizeof (ethernet_header_t));
   determine_next_node (em, variant, 0, type0, b0,
, );

I am sure this is not a patch which will be accepted upstream. I am not sure 
how to _correctly_ fix this, so that it will be accepted by upstream. If some 
pointers are given I can submit a patch to get PPPoE working correctly again in 
VPP.


Thanks and Regards,

Raj

On Tue, Mar 19, 2019 at 1:09 PM Raj via Lists.Fd.Io 
 wrote:
>
> Another approach that can be used is to send all PPP/PPPoE control 
> packets encapsulated in NSH, and Control plane can process it and 
> return the packets to VPP which will decapsulate the NSH headers and 
> pass the packets on to PPPoE client.
>
> Thanks and Regards,
>
> Raj
>
> On Mon, Mar 18, 2019 at 7:44 PM Raj via Lists.Fd.Io 
>  wrote:
> >
> > On Thu, Dec 20, 2018 at 6:17 AM Ni, Hongjun  wrote:
> >
> > > For the issue you mentioned, Alp Arslan in the To list will submit a 
> > > patch to fix it.
> >
> > I can take a stab at this and prepare a patch to get PPPoE working 
> > again in VPP. I understand that this error happens because VPP will 
> > only allow packets whose destination MAC is the same as the 
> > interface MAC or bcast/mcast MAC. How should I go about fixing this?
> > Would turning off off this check for TAP interface work? Any better 
> > way to achieve this result?
> >
> > Thanks and Regards,
> >
> > Raj
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#12588): 
> https://lists.fd.io/g/vpp-dev/message/12588
> Mute This Topic: https://lists.fd.io/mt/28791570/157026
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
> [rajlistu...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12598): https://lists.fd.io/g/vpp-dev/message/12598
Mute This Topic: https://lists.fd.io/mt/28791570/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] About l2_to_bvi inline in src/vnet/l2/l2_bvi.h

[John Lo (loj) via Lists.Fd.Io]

Hi Milan,

The l2_len field in the buffer metadata area is valid only for L2 forwarding 
path.  It is overlaid with other L3 forwarding related fields.  Thus, packets 
coming into a bridge domain (BD) will have its l2_len setup correctly.  Once 
the packet leave the BD via its BVI interface into L3 forwarding path, the code 
in IP forwarding path cannot assume l2_len field is still valid.

In the IP forwarding path, one can generally assume current pointer is at start 
of IP header but should not assume there is always a MAC header before the IP 
header nor l2_len field is valid.  The packet could have been through tunnel 
enacp/decap prior getting to the IP forwarding path.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of milan...@gmail.com
Sent: Tuesday, March 19, 2019 12:57 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] About l2_to_bvi inline in src/vnet/l2/l2_bvi.h

Hello experts,

There appears to be a small nit in this function, though it upsets some 
calculations in my plugin which follows ip_input  in the case of BDs.

static_always_inline u32
 38 l2_to_bvi (vlib_main_t * vlib_main,
 39vnet_main_t * vnet_main,
 40vlib_buffer_t * b0,
 41u32 bvi_sw_if_index, next_by_ethertype_t * l3_next, u16 * next0)
 42 {
 43   /* Perform L3 my-mac filter */
 44   ethernet_header_t *e0 = vlib_buffer_get_current (b0);
 45   if (!ethernet_address_cast (e0->dst_address))
 46 {

 52
 53   /* Save L2 header position which may be changed due to packet replication 
*/
 54   vnet_buffer (b0)->l2_hdr_offset = b0->current_data;
 55
 56   /* Strip L2 header */
 57   u8 l2_len = vnet_buffer (b0)->l2.l2_len;
 58   vlib_buffer_advance (b0, l2_len);<<   When we 
do this, should we also do < l2.l2_len -= l2_len.  >  ??


 59
 60   u8 *l3h = vlib_buffer_get_current (b0);
 61   u16 ethertype = clib_net_to_host_u16 (*(u16 *) (l3h - 2));
 62


My plugin tries to get IP header later using u8 *l3h0 = (u8 *) h0 + vnet_buffer 
(b[0])->l2.l2_len; So this fails in the BD BVI case, but works all right for 
routed sub-interfaces
Should I always rather use (b[0])->l3 ??  Is there a safer way to find out, if 
a packet has L2 header stripped off , and starts from L3 header directly.

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

View/Reply Online (#12590): https://lists.fd.io/g/vpp-dev/message/12590
Mute This Topic: https://lists.fd.io/mt/30504309/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] Support for non TCP traffic

[John Lo (loj) via Lists.Fd.Io]

As stated by Dave, if you are doing L2 forwarding by putting the VM interfaces 
into a bridge domain, it will forward packets based on destination MAC address 
and would not be affected by ethertype nor L3/L4 headers.   -John

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Monday, March 18, 2019 7:25 AM
To: Eyle Brinkhuis ; vpp-dev@lists.fd.io; John Lo 
(loj) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Support for non TCP traffic

If the idea is simply to flood and/or forward at L2 these ethertypes, there’s a 
decent chance you won’t have to do anything beyond bridge configuration. If you 
want to process them (e.g. in a plugin), a call to 
ethernet_register_input_type(...) will deliver the goods to your code.

Copying John Lo, our L2 path expert...

HTH... Dave

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Eyle Brinkhuis
Sent: Monday, March 18, 2019 4:28 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Support for non TCP traffic

Hi all,

I couldn’t find an answer on the wiki for this case:

We are looking into building a VM platform (on openstack) with vpp. For one of 
our use cases we’d need to provide interconnectivity between VM’s for a HA 
setup (in this case FortiGate VM’s for a HA firewallinsetup). These FWs make 
use of non-TCP packets with ethertype 0x8890, 0x8891 and 0x8993. Can VPP work 
with these? If not, what would be the solution here?

Thanks,

Regards,

Eyle



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

View/Reply Online (#12577): https://lists.fd.io/g/vpp-dev/message/12577
Mute This Topic: https://lists.fd.io/mt/30471946/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] subif interface api handle function bug

[John Lo (loj) via Lists.Fd.Io]

Hi Joe,

Thank you very much for catching this bug.  I took a look at your patch which 
looks to be the right fix to this problem.  Without this fix, I suppose the 
work around is to always add BVI interface to a BD last, after all other 
interfaces are added in the BD.

Can you push your patch to fd.io gerrit directly for code review, please?  I'll 
be happy to review your patch and merge to master branch after it is built and 
passes regression properly.

The following URL describes how to push your patch to fd.io gerrit for review:
https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Pushing

Regards,
John
From: vpp-dev@lists.fd.io  On Behalf Of "Zhou You(Joe Zhou)
Sent: Wednesday, March 06, 2019 10:31 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] subif interface api handle function bug

Dear vpp devs:

  I met a bug while adding 802.1q subif interface into bridge domain via python 
api. BVI interface must be the first number of bridge domain, but after I added 
a subif into bd, subif took the first position of bd, and the l2 flooding 
didn't run well:

  here is the infomation:
  vpp# show bridge-domain 10 detail
  BD-ID   Index   BSN  Age(min)  Learning  U-Forwrd   UU-Flood   Flooding  
ARP-Term   BVI-Intf
   10   2  0  60onon   floodon   
off   loop10

   Interface   If-idx ISN  SHG  BVI  TxFlood
VLAN-Tag-Rewrite
GigabitEthernet2/0/0.10  8 70-  * pop-1
loop10   7 80*  * none
 GigabitEthernet1/0/01 11   0-  * none

  I read the code, found vl_api_create_vlan_subif_t_handler and 
vl_api_create_subif_t_handler function lacking an assignment of 
:template.flood_class = VNET_FLOOD_CLASS_NORMAL;
  I think it might be a bug, and create a patch, looking forward the bug to be 
fixed:-)

  
  Best Regards
  Joe Zhou


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

View/Reply Online (#12451): https://lists.fd.io/g/vpp-dev/message/12451
Mute This Topic: https://lists.fd.io/mt/30294062/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] New vpp project committer: Paul Vinciguerra

[John Lo (loj) via Lists.Fd.Io]

Congratulations Paul.  It is great to have you on board as one of the 
committers to share the load, I mean “joy” , of VPP.   -John

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Thursday, February 28, 2019 5:38 PM
To: vpp-dev@lists.fd.io; Paul Vinciguerra 
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] New vpp project committer: Paul Vinciguerra

Please join me in congratulating Paul on his election as a vpp project 
committer!

Thanks... Dave

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

View/Reply Online (#12395): https://lists.fd.io/g/vpp-dev/message/12395
Mute This Topic: https://lists.fd.io/mt/30168763/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] New vpp project committer nomination: Paul Vinciguerra

[John Lo (loj) via Lists.Fd.Io]

+1 from me.  -John

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Wednesday, February 27, 2019 7:38 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] New vpp project committer nomination: Paul Vinciguerra

In view of significant code contributions to the vpp project - see below - I'm 
pleased to nominate Paul Vinciguerra as a vpp project committer. I have high 
confidence that he'll be a major asset to the project in a committer role.

Paul has contributed 100 merged patches, concentrating on the "make test" .py 
framework. See 
https://gerrit.fd.io/r/#/q/status:merged+owner:%22Paul+Vinciguerra+%253Cpvinci%2540vinciconsulting.com%253E%22

Committers, please vote (+1, 0, -1) on 
vpp-dev@lists.fd.io. We'll need a recorded vote so 
that the TSC will approve Paul's nomination.

If at all possible please vote today, February 27, 2019 so we can add Paul's 
nomination to tomorrow's TSC agenda for final approval.

Thanks... Dave

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

View/Reply Online (#12360): https://lists.fd.io/g/vpp-dev/message/12360
Mute This Topic: https://lists.fd.io/mt/30151621/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] L2 xconnect feature on multiple interface

[John Lo (loj) via Lists.Fd.Io]

From “show interface” output, the rx/tx counters of TenGE4/0/0 matches that of 
tx/rx counters of 4/0/1.  So L2XC is working between them.  For the other L2XC 
pair, the rx counter of TenGE7/0/1 matches that of the tx counter of 7/0/0 so 
that also seem fine.  The rx of TenGE7/0/0 and tx of 7/0/1 are all 0’s which 
also matches.  Thus both L2XC pairs appear to function as expected.  Are you 
expecting packets in the TenGE7/0/0 to 7/0/1 direction and so think it is not 
working there?  Then you need to find out why TenGE7/0/0 is not receiving any 
packets.   -John

From: vpp-dev@lists.fd.io  On Behalf Of 
david.leitch@gmail.com
Sent: Saturday, January 19, 2019 4:20 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] L2 xconnect feature on multiple interface

Hi,

I want to use the L2 xconnect or L2 bridge feature on multiple interface , i.e 
suppose I have 4 ports :
x1 and x2  and also  y1 and y2.
I want to only do

vpp# set interface l2 xconnect x1 x2
vpp# set interface l2 xconnect x2 x1
vpp# set interface l2 xconnect y1 y2
vpp# set interface l2 xconnect y2 y1

so that all traffic from port x1 is sent to port x2 and vice versa ,
also all traffic from port y1 is sent to port y2 and vice versa.

but only one set of them works at the same time , for example only x1 and x2 
works but y1 and y2 not working
if i change the mode of x1 and x2 interface to L3 mode , y1 and y2 interface 
will work in L2 mode
I test this situation with l2 bridge and i have the same problem.
May i know ,why it doesn't work if i set l2 (xconnect or bridge) for multiple 
interface ???

here is my configuration and commands :

for l2 xconnect test :
vpp# set int state TenGigabitEthernet4/0/0 up
vpp# set int state TenGigabitEthernet4/0/1 up
vpp# set int state TenGigabitEthernet7/0/0 up
vpp# set int state TenGigabitEthernet7/0/1 up

vpp# set interface promiscuous on TenGigabitEthernet4/0/0
vpp# set interface promiscuous on TenGigabitEthernet4/0/1
vpp# set interface promiscuous on TenGigabitEthernet7/0/0
vpp# set interface promiscuous on TenGigabitEthernet7/0/1
vpp# set interface l2 xconnect TenGigabitEthernet4/0/0 TenGigabitEthernet4/0/1
vpp# set interface l2 xconnect TenGigabitEthernet4/0/1 TenGigabitEthernet4/0/0
vpp# set interface l2 xconnect TenGigabitEthernet7/0/1 TenGigabitEthernet7/0/0
vpp# set interface l2 xconnect TenGigabitEthernet7/0/0 TenGigabitEthernet7/0/1

vpp# show interface
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
TenGigabitEthernet21/0/0  5 down 9000/0/0/0
TenGigabitEthernet21/0/1  6 down 9000/0/0/0
TenGigabitEthernet24/0/0  7 down 9000/0/0/0
TenGigabitEthernet24/0/1  8 down 9000/0/0/0
TenGigabitEthernet4/0/0   1  up  9000/0/0/0 rx packets  
 2803151
rx bytes
   700562045
tx packets  
 3693049
tx bytes
  3791177782
tx-error
  62
TenGigabitEthernet4/0/1   2  up  9000/0/0/0 rx packets  
 3693049
rx bytes
  3791177782
tx packets  
 2803151
tx bytes
   700562045
TenGigabitEthernet7/0/0   3  up  9000/0/0/0 tx packets  
 4799610
tx bytes
  3764207865
TenGigabitEthernet7/0/1   4  up  9000/0/0/0 rx packets  
 4799610
rx bytes
  3764207865
local00 down  0/0/0/0


vpp# show mode
l3 local0
l2 xconnect TenGigabitEthernet4/0/0 TenGigabitEthernet4/0/1
l2 xconnect TenGigabitEthernet4/0/1 TenGigabitEthernet4/0/0
l2 xconnect TenGigabitEthernet7/0/0 TenGigabitEthernet7/0/1
l2 xconnect TenGigabitEthernet7/0/1 TenGigabitEthernet7/0/0
l3 TenGigabitEthernet21/0/0
l3 TenGigabitEthernet21/0/1
l3 TenGigabitEthernet24/0/0
l3 TenGigabitEthernet24/0/1

I have checked connectivity and sure that's correct
Regards,
david
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11958): https://lists.fd.io/g/vpp-dev/message/11958
Mute This Topic: https://lists.fd.io/mt/29289024/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] Help on VxLAN configuration

[John Lo (loj) via Lists.Fd.Io]

One can put the BD BVI interfaces into its own IP table and leave VXLAN encap 
and underlay in default global IP table. We would put the loopN interface into 
an IP table before assigning its IP address:

vpp# set int ip table ?
  set interface ip table   set interface ip table  


One can also specify the IP table for the VXLAN encap VRF in the create VXLAN 
tunnel CLI:

vpp# create vxlan tunnel ?
  create vxlan tunnel  create vxlan tunnel src 
 {dst |group  } 
vni  [instance ] [encap-vrf-id ] [decap-next [l2|node ]] [del]

where encap-vrf-id specifies an IP table for the underlay interface.  If it is 
not specified, it default to 0 or the global IP table.

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Xuekun
Sent: Tuesday, November 06, 2018 3:02 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Help on VxLAN configuration

Hi, All

How to isolate two VxLAN unicast tunnels when L3 routing available? For 
example, I have two tenants, with different vxlan tunnels connected to the VPP 
box. Each vxlan tunnel is under a different bridge domain with different loop 
interface. I need the loop interface to connect to external network. Now how to 
isolate the internal 10.10.10.x and 20.20.20.x network segment? 

...
create bridge-domain 1000 learn 1 forward 1 uu-flood 1 flood 1 arp-term 0
create vxlan tunnel src 172.168.1.1 dst 172.168.1.2 vni 100
set interface l2 bridge vxlan_tunnel0 1000
loopback create
set interface l2 bridge loop0 1000 bvi
set interface ip address loop0 10.10.10.1/24
... 
create bridge-domain 2000 learn 1 forward 1 uu-flood 1 flood 1 arp-term 0
create vxlan tunnel src 172.168.1.1 dst 172.168.1.3 vni 100
set interface l2 bridge vxlan_tunnel1 1000
loopback create
set interface l2 bridge loop1 2000 bvi
set interface ip address loop0 20.20.20.1/24


(sorry, today I'm a little messy)
Many thanks.

Thx, Xuekun

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

View/Reply Online (#11131): https://lists.fd.io/g/vpp-dev/message/11131
Mute This Topic: https://lists.fd.io/mt/27868329/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] Problem on VxLAN multicast mode

[John Lo (loj) via Lists.Fd.Io]

To answer another question from Xuekun about usage of VXLAN mcast tunnel, the 
advantage is that flooding to remote VTEPs only needs to send one packet into 
the mcast tunnel.  If there is no mcast tunnel, VPP will need to send a packet 
per unicast VXLAN tunnel to flood all remote VTEPs.-John

-Original Message-
From: Neale Ranns (nranns) 
Sent: Monday, November 05, 2018 11:00 AM
To: John Lo (loj) ; Xuekun ; Eyal Bari 
(ebari) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode


Hi Eyal, John,

I missed the fact that the tunnel classification is based only on the senders 
IP. Now it makes sense.

Thanks,
Neale


-Message d'origine-
De :  au nom de "John Lo (loj) via Lists.Fd.Io" 
 Répondre à : "John Lo (loj)"  Date 
: lundi 5 novembre 2018 à 16:17 À : Xuekun , "Eyal Bari 
(ebari)" , "vpp-dev@lists.fd.io"  Cc : 
"vpp-dev@lists.fd.io"  Objet : Re: [vpp-dev] Problem on 
VxLAN multicast mode

VPP does not support receiving of VXLAN packets from an unknown VTEP.  
Thus, any packet received in a BD from a VXLAN multicast tunnel must have its 
source IP match of the remote VTEP of an existing VXLAN unicast tunnel in the 
same BD.  If no such unicast tunnel is found, packets are dropped.  If it is 
found and MAC learning is enabled, the MAC will be learned with its output 
associated with the matching unicast VXLAN tunnel.  VPP does not learn unknown 
remote VTEPs and create a unicast tunnel automatically for better security.   

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Xuekun
Sent: Monday, November 05, 2018 8:07 AM
To: Eyal Bari (ebari) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode

Hi, Eyal

If need to create a unicast tunnel also, it means need to know the remote 
vtep address first. However the purpose of using mcast tunnel is to build 
tunnels across multiple vtep addresses which don't be known in advance.  For 
example, if there is a third server (server3: 192.168.1.3) in my env, what 
should I do? Still add a unicast tunnel ("create vxlan tunnel src 172.168.1.1 
dst 172.168.1.3 vni 100"), if so, just to setup the point-to-point vxlan tunnel 
and put all the tunnels in the same BD, then all servers are connected, and 
don't need to create the mcast tunnel. 

Is my understanding about mcast tunnel not correct? 
Thanks. 

Thx, Xuekun  

-Original Message-
From: Eyal Bari (ebari)  
Sent: Monday, November 05, 2018 7:58 PM
To: Hu, Xuekun ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode

Just to clarify, the mcast tunnel does not need to be under the bridge for 
receiving traffic, however for sending flooded traffic through the mcast tunnel 
it needs to be under the bridge...

eyal 

On 05/11/2018, 13:47, "vpp-dev@lists.fd.io on behalf of eyal bari via 
Lists.Fd.Io"  
wrote:

Hi, Xuekun,

Packets are only received on unicast tunnels.
So in your case you would need to create one and put it under the 
bridge-domain (the multicast tunnel does not need to be under the 
bridge-domain):
create vxlan tunnel src 172.168.1.1 dst 172.168.1.2 vni 100
set interface l2 bridge vxlan_tunnel0 1000
create vxlan tunnel src 172.168.1.1 group 239.1.1.1 
TenGigabitEthernet3d/0/1 vni 100


eyal

On 05/11/2018, 9:18, "vpp-dev@lists.fd.io on behalf of Xuekun" 
 wrote:

Hi, All

I'm configuring VPP as VxLAN multicast mode over multiple servers. 
To simplify the topology, I only used two servers: server1 as VPP; server2 
using vxlan kernel mode.

Server1:
set interface state TenGigabitEthernet3d/0/1 up
set interface ip address TenGigabitEthernet3d/0/1 172.168.1.1/24
create bridge-domain 1000 learn 1 forward 1 uu-flood 1 flood 1 
arp-term 0
create vxlan tunnel src 172.168.1.1 group 239.1.1.1 
TenGigabitEthernet3d/0/1 vni 100
set interface l2 bridge vxlan_tunnel0 1000  
loopback create 
set interface l2 bridge loop0 1000 bvi
set interface state loop0 up
set interface ip address loop0 192.168.1.1/24

Server2:
ifconfig enp11s0f1 172.168.1.2/24 up
ip link add vxlan0 type vxlan id 100 dstport 4789 group 239.1.1.1 
dev enp11s0f1
ifconfig vxlan0 192.168.1.2/24 up

Now, server1 and server2 are connected with VxLAN VNI 100 through 
multicast group 239.1.1.1.  
However, 192.168.1.1 and 192.168.1.2 could NOT be pingable each 
other. 

Trace log: 
Packet 1

 

Re: [vpp-dev] Problem on VxLAN multicast mode

[John Lo (loj) via Lists.Fd.Io]

VPP does not support receiving of VXLAN packets from an unknown VTEP.  Thus, 
any packet received in a BD from a VXLAN multicast tunnel must have its source 
IP match of the remote VTEP of an existing VXLAN unicast tunnel in the same BD. 
 If no such unicast tunnel is found, packets are dropped.  If it is found and 
MAC learning is enabled, the MAC will be learned with its output associated 
with the matching unicast VXLAN tunnel.  VPP does not learn unknown remote 
VTEPs and create a unicast tunnel automatically for better security.   

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Xuekun
Sent: Monday, November 05, 2018 8:07 AM
To: Eyal Bari (ebari) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode

Hi, Eyal

If need to create a unicast tunnel also, it means need to know the remote vtep 
address first. However the purpose of using mcast tunnel is to build tunnels 
across multiple vtep addresses which don't be known in advance.  For example, 
if there is a third server (server3: 192.168.1.3) in my env, what should I do? 
Still add a unicast tunnel ("create vxlan tunnel src 172.168.1.1 dst 
172.168.1.3 vni 100"), if so, just to setup the point-to-point vxlan tunnel and 
put all the tunnels in the same BD, then all servers are connected, and don't 
need to create the mcast tunnel. 

Is my understanding about mcast tunnel not correct? 
Thanks. 

Thx, Xuekun  

-Original Message-
From: Eyal Bari (ebari)  
Sent: Monday, November 05, 2018 7:58 PM
To: Hu, Xuekun ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode

Just to clarify, the mcast tunnel does not need to be under the bridge for 
receiving traffic, however for sending flooded traffic through the mcast tunnel 
it needs to be under the bridge...

eyal 

On 05/11/2018, 13:47, "vpp-dev@lists.fd.io on behalf of eyal bari via 
Lists.Fd.Io"  
wrote:

Hi, Xuekun,

Packets are only received on unicast tunnels.
So in your case you would need to create one and put it under the 
bridge-domain (the multicast tunnel does not need to be under the 
bridge-domain):
create vxlan tunnel src 172.168.1.1 dst 172.168.1.2 vni 100
set interface l2 bridge vxlan_tunnel0 1000
create vxlan tunnel src 172.168.1.1 group 239.1.1.1 
TenGigabitEthernet3d/0/1 vni 100


eyal

On 05/11/2018, 9:18, "vpp-dev@lists.fd.io on behalf of Xuekun" 
 wrote:

Hi, All

I'm configuring VPP as VxLAN multicast mode over multiple servers. To 
simplify the topology, I only used two servers: server1 as VPP; server2 using 
vxlan kernel mode.

Server1:
set interface state TenGigabitEthernet3d/0/1 up
set interface ip address TenGigabitEthernet3d/0/1 172.168.1.1/24
create bridge-domain 1000 learn 1 forward 1 uu-flood 1 flood 1 arp-term 0
create vxlan tunnel src 172.168.1.1 group 239.1.1.1 
TenGigabitEthernet3d/0/1 vni 100
set interface l2 bridge vxlan_tunnel0 1000  
loopback create 
set interface l2 bridge loop0 1000 bvi
set interface state loop0 up
set interface ip address loop0 192.168.1.1/24

Server2:
ifconfig enp11s0f1 172.168.1.2/24 up
ip link add vxlan0 type vxlan id 100 dstport 4789 group 239.1.1.1 dev 
enp11s0f1
ifconfig vxlan0 192.168.1.2/24 up

Now, server1 and server2 are connected with VxLAN VNI 100 through 
multicast group 239.1.1.1.  
However, 192.168.1.1 and 192.168.1.2 could NOT be pingable each other. 

Trace log: 
Packet 1

00:01:02:563831: dpdk-input
  TenGigabitEthernet3d/0/1 rx queue 0
  buffer 0x4b93: current data 14, length 78, free-list 0, clone-count 
0, totlen-nifb 0, trace 0x0
 ext-hdr-valid
 l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
  PKT MBUF: port 0, nb_segs 1, pkt_len 92
buf_len 2176, data_len 92, ol_flags 0x180, data_off 128, phys_addr 
0x4012e540
packet_type 0x291 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_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or 
without extension headers
  RTE_PTYPE_L4_UDP (0x0200) UDP packet
  IP4: 00:1e:67:34:31:6c -> 01:00:5e:01:01:01
  UDP: 172.168.1.2 -> 239.1.1.1
tos 0x00, ttl 1, length 78, checksum 0xe04b
fragment id 0x3ba7
  UDP: 54420 -> 4789
length 58, checksum 0x
00:01:02:563834: ip4-input-no-checksum
  UDP: 172.168.1.2 -> 239.1.1.1
 

Re: [vpp-dev] Problem switching a bonded interface from L2 to L3 mode

[John Lo (loj) via Lists.Fd.Io]

: arp-input
  request, type ethernet/IP4, address size 6/4
  00:00:5e:22:22:2c/110.0.0.2 -> 00:00:00:00:00:00/110.0.0.1
00:00:00:00: error-drop
  arp-input: Interface is not IP enabled

The mode switch code of bonding device:
static __clib_unused clib_error_t *
bond_set_l2_mode_function (vnet_main_t * vnm,
   struct vnet_hw_interface_t *bif_hw,
   i32 l2_if_adjust)
{
  bond_if_t *bif;
  u32 *sw_if_index;
  struct vnet_hw_interface_t *sif_hw;

  bif = bond_get_master_by_sw_if_index (bif_hw->sw_if_index);
  if (!bif)
return 0;

  if ((bif_hw->l2_if_count == 1) && (l2_if_adjust == 1))
{
  /* Just added first L2 interface on this port */
  vec_foreach (sw_if_index, bif->slaves)
  {
sif_hw = vnet_get_sup_hw_interface (vnm, *sw_if_index);
ethernet_set_flags (vnm, sif_hw->hw_if_index,
ETHERNET_INTERFACE_FLAG_ACCEPT_ALL);

/* ensure all packets go to ethernet-input */
ethernet_set_rx_redirect (vnm, sif_hw, 1);
  }
}

  return 0;
}

when I switch the mode of bonding interface to l2,

the function(blue color code above) redirects all the members to ethernet-input 
,

but when I switch it back to l3, all the members don't redirect to bond-input.


saint_...@aliyun.com<mailto:saint_...@aliyun.com>

From: steven luong via Lists.Fd.Io<mailto:sluong=cisco@lists.fd.io>
Date: 2018-10-25 12:06
To: saint_...@aliyun.com<mailto:saint_...@aliyun.com>; John Lo 
(loj)<mailto:l...@cisco.com>
CC: vpp-dev<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Problem switching a bonded interface from L2 to L3 mode
Are you using VPP native bonding driver or DPDK bonding driver? How do you 
configure the bonding interface? Please include the configuration and process 
to recreate the problem.

Steven

From: mailto:vpp-dev@lists.fd.io>> on behalf of "saint_sun 
孙 via Lists.Fd.Io" 
mailto:saint_sun=aliyun@lists.fd.io>>
Reply-To: "saint_...@aliyun.com<mailto:saint_...@aliyun.com>" 
mailto:saint_...@aliyun.com>>
Date: Wednesday, October 24, 2018 at 8:07 PM
To: "John Lo (loj)" mailto:l...@cisco.com>>
Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Problem switching a bonded interface from L2 to L3 mode

Ok, I forgot to click the reply-all. who is familiar with the problem I 
mentioned below please tell me,thanks!





2018年10月25日 星期四 +0800 10:32 发件人 John Lo (loj) 
mailto:l...@cisco.com>>:

Please include vpp-dev alias on any questions about VPP, instead of unicast an 
individual only. Then whoever is familiar with the area you are asking about 
may respond.  Does anyone know about the potential problem of switching between 
L2 and L3 modes on a bonded interface described in this email (I did change the 
email subject accordingly)?   -John



From: saint_sun 孙 mailto:saint_...@aliyun.com>>
Sent: Wednesday, October 24, 2018 8:52 PM
To: John Lo (loj) mailto:l...@cisco.com>>
Subject: Re: RE: RE: [vpp-dev]vlan interface support?



I am very grateful for your help.

And when I test the VLAN, maybe I find a bug that if I switch the mode of the 
Bonding interface to L2 and then switch back to L3，the bonding interface can 
not work as before.

I have found the error code that is in the mode switch function of bonding 
device: when set the mode of bonding interface to l2, all the members of the 
bonding interface will be set to l2, but when set the bonding interface back, 
all the members do not recover to l3.



At last I have another doubt that when I configure an IP address for an 
interface, then I ping the address from VPP, it’s failed, why?should I do other 
more settings?




2018年10月15日 星期一 +0800 22:20 发件人 John Lo (loj) 
mailto:l...@cisco.com>>:

If there is a BVI in a BD with sub-interfaces in the same BD which get packets 
with VLAN tags, it is best to configure a tag-rewrite operation on the 
sub-interfaces to pop their VLAN tags.  Then all packets are forwarded in BD 
without VLAN tags.  The CLI is “set interface l2 tag-rewrite  
pop 1” if the sub-interface has one VLAN tag.–John



From: saint_sun 孙 mailto:saint_...@aliyun.com>>
Sent: Monday, October 15, 2018 2:42 AM
To: John Lo (loj) mailto:l...@cisco.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: RE: [vpp-dev]vlan interface support?



I am very grateful to you for your advice！

I have tested it，But there is something wrong. when I receive an arp or ICMP 
packet from a l2 subif  that joins to bd 200 and encapsulates vlan 200，the 
reply packet that send from the subif does not have the vlan tag 200. Any more 
other configurations should I set？




可用于iOS的myMail发送


2018年10月14日 星期日 +0800 04:58 发件人 l...@cisco.com<mailto:l...@cisco.com> 
mailto:l...@cisco.com>>:

The equivalent of VLAN on a switch in VPP is a bridge domain or BD for short.  
One c

[vpp-dev] Problem switching a bonded interface from L2 to L3 mode

[John Lo (loj) via Lists.Fd.Io]

Please include vpp-dev alias on any questions about VPP, instead of unicast an 
individual only. Then whoever is familiar with the area you are asking about 
may respond.  Does anyone know about the potential problem of switching between 
L2 and L3 modes on a bonded interface described in this email (I did change the 
email subject accordingly)?   -John

From: saint_sun 孙 
Sent: Wednesday, October 24, 2018 8:52 PM
To: John Lo (loj) 
Subject: Re: RE: RE: [vpp-dev]vlan interface support?

I am very grateful for your help.
And when I test the VLAN, maybe I find a bug that if I switch the mode of the 
Bonding interface to L2 and then switch back to L3，the bonding interface can 
not work as before.
I have found the error code that is in the mode switch function of bonding 
device: when set the mode of bonding interface to l2, all the members of the 
bonding interface will be set to l2, but when set the bonding interface back, 
all the members do not recover to l3.

At last I have another doubt that when I configure an IP address for an 
interface, then I ping the address from VPP, it’s failed, why?should I do other 
more settings?



2018年10月15日 星期一 +0800 22:20 发件人 John Lo (loj) 
mailto:l...@cisco.com>>:

If there is a BVI in a BD with sub-interfaces in the same BD which get packets 
with VLAN tags, it is best to configure a tag-rewrite operation on the 
sub-interfaces to pop their VLAN tags.  Then all packets are forwarded in BD 
without VLAN tags.  The CLI is “set interface l2 tag-rewrite  
pop 1” if the sub-interface has one VLAN tag.–John



From: saint_sun 孙 mailto:saint_...@aliyun.com>>
Sent: Monday, October 15, 2018 2:42 AM
To: John Lo (loj) mailto:l...@cisco.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: RE: [vpp-dev]vlan interface support?



I am very grateful to you for your advice！

I have tested it，But there is something wrong. when I receive an arp or ICMP 
packet from a l2 subif  that joins to bd 200 and encapsulates vlan 200，the 
reply packet that send from the subif does not have the vlan tag 200. Any more 
other configurations should I set？




可用于iOS的myMail发送


2018年10月14日 星期日 +0800 04:58 发件人 l...@cisco.com<mailto:l...@cisco.com> 
mailto:l...@cisco.com>>:

The equivalent of VLAN on a switch in VPP is a bridge domain or BD for short.  
One can put interfaces or VLAN sub-interfaces in a BD to form a L2 network 
among all interfaces in it.  One can also create a loopback interface, put it 
in a BD as its BVI (Bridge Virtual Interface) and assign IP addresses to it.  
Then packet can be IP forwarded into a BD through its BVI.



Following is the VPP CLI sequence to create a loopback (resulting in interface 
name loop0), put it in BD 13 as a BVI, and put an IP address on it:



loopback create mac 1a:2b:3c:4d:5e:6f

set interface l2 bridge loop0 13 bvi

set interface state loop0 up

set interface ip address loop0 6.0.0.250/16



Regards,

John



From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of saint_sun ? via 
Lists.Fd.Io
Sent: Friday, October 12, 2018 3:52 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev]vlan interface support?



I have a question:

Does vpp has the function like the configuration example:

interface f0/1

switchport access vlan 10



Interface vlan 10

ip address 10.0.0.1 255.255.255.0



If vpp has the function, where can I find the command and the source code?



Another question, does vpp support superVLAN?



anyone who knows please tell me, appreciate for your reply very much!


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

View/Reply Online (#10975): https://lists.fd.io/g/vpp-dev/message/10975
Mute This Topic: https://lists.fd.io/mt/27628831/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] about gtpu encap

[John Lo (loj) via Lists.Fd.Io]

I believe you can cross connect two gtpu tunnel interfaces on the VPP in your 
GW to achieve what you need:
DBGvpp# set int l2 xconnect ?
  set interface l2 xconnectset interface l2 xconnect 
 

You need to set L2 xconnect on both gtpu tunnel interfaces to each other.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Liu Daolin (???)
Sent: Tuesday, October 23, 2018 3:51 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] about gtpu encap

Hi,

I have a question about gtpu encap node in VPP. My network topology is:

[cid:image002.jpg@01D46AC2.C0DA7910]

VPP is running on GW in Linux VM with two IP interfaces, and eNB & CN in the 
above graph are running on two different Linux VMs with only one IP interface. 
After starting VPP and some regular settings with CLI, I can ping CN from eNB 
side successfully, vice versa without any problem.

Currently, my requirement is that setting gtpu tunnels between both eNB<->GW 
and GW<->CN, and then from the eNB side, it will send UDP packet to GW with 
gtpu (port 2152, src IP 192.168.2.2, dst IP 192.168.2.1), and VPP can decap 
this gtpu packet (teid 261) to get T-PDU data, and then re-encap gtpu (teid 
262) and udp to send to CN (port 2152, src IP 192.168.3.1, dst IP 192.168.3.2). 
Something like this:

[cid:image002.jpg@01D46ABA.69062A20]

You can see below original packet from eNB side.

[cid:image003.jpg@01D46ABA.69062A20]

Actually, I don't need VPP to decode the payload in red color, i.e. T-PDU Data 
4500…… I just want to keep this T-PDU Data and then fill the new teid and src & 
dst IP to send to CN side. The output packet should like this:

[cid:image004.jpg@01D46ABA.69062A20]

I run below command to set tunnels:

vppctl create gtpu tunnel src 192.168.2.1 dst 192.168.2.2 teid 261
vppctl create gtpu tunnel src 192.168.3.2 dst 192.168.3.1 teid 262

and capture the original packet with "show trace" successfully. But the VPP 
treated the payload 4500…… as l2-input since I didn't set "decap-next node" in 
above command.

But if I use below command:

vppctl create gtpu tunnel src 192.168.2.1 dst 192.168.2.2 teid 261 decap-next 
node gtpu4-encap
vppctl create gtpu tunnel src 192.168.3.2 dst 192.168.3.1 teid 262 decap-next 
node gtpu4-encap

The VPP process will be crashed. Maybe I miss something or my command is not 
correct enough. Actually I found that there is no previous node for 
gtpu4-encap. I don't know why.

Could you please show me what should I do to satisfy my requirement which is 
not complex in my mind?

Thanks a lot!
Best regards
刘道林 (Daolin Liu)
T大连市共进科技有限公司
DALIAN GONGJIN TECHNOLOGY CO.,LTD
中国大连市高新园区软件园路1A-4-24层
Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
直线(TEL)：(86-411)39996705   分机(EXT)：76824
手机(Mobile)：(86)13704090959

本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄漏、阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接收到的文本。
 This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10926): https://lists.fd.io/g/vpp-dev/message/10926
Mute This Topic: https://lists.fd.io/mt/27566720/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] one question IP checksum

[John Lo (loj) via Lists.Fd.Io]

I don't know if VXLAN-GPE is implemented in VPP to handle IP payload without 
ethernet header properly.  You can try it to check what happens.  I would not 
be surprised if something need to be fixed in VXLAN-GPE encap/decap for it to 
work properly.  Hopefully the owner of VXLAN-GPE can comment further.

If your requirement is to have IP in IP tunnel, GRE tunnel may be a better 
choice which is fully supported by VPP.  Then everything will be handled in L3 
only.

Regards,
John

From: Zhang, Yuwei1 
Sent: Monday, October 22, 2018 10:44 PM
To: John Lo (loj) ; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] one question IP checksum

Thanks a lot, I think I got a better understanding cause of your help. As you 
said, the outer udp checksum is optional and often left as 0, is there any 
issue if I use VXLAN-GPE and send packet to ip4-input-nochecksum node which 
will skip the inner ip checksum verification?

Regards,
Yuwei
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of John Lo (loj) via Lists.Fd.Io
Sent: Monday, October 22, 2018 11:56 PM
To: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] one question IP checksum

Hi Yuwei,

I did not suggest one can create VXLAN tunnel and send the dcap packet directly 
to ip4-input or ip4-input-nochecksum.  It will not work because the VXLAN 
payload still have a MAC header before the IP header after decap.  That's why 
it only works if it is sent to ethernet-input.  You are getting checksum error, 
because ip4-input node is treating the MAC header as if it is an IP header.

I was suggesting you may be able to create VXLAN-GPE tunnel (with a different 
CLI to that of the VXLAN one) which is different to VXLAN tunnel.  With 
VXLAN-GPE, you can potentially send just IP packet without ethernet header, 
with the appropriate protocol field in the VXLAN-GPE header set accordingly.  
Then it is feasible to send the packet directly to ip4-input or 
ip4-input-nochecksum.  I am not sure how complete VXLAN-GPE handling is 
implemented in VPP so you may need to improve the code to handle it.

Note that big portion of performance gain you observed is because 
ethernet-input node is bypassed, in addition to saving from not calculating IP 
checksum.

As I described before, VXLAN is supposed to be used for L2 to carry ethernet 
packets.  If it is used for L3, it is not standard usage and will not 
interoperate properly with other devices. For L3, VXLAN-GPE should ideally be 
used as it is designed to handle encap/decap of various packet types, as GPE 
mean "generic protocol extension", including L2 and L3 protocols.

Regards,
John

From: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>
Sent: Monday, October 22, 2018 4:50 AM
To: John Lo (loj) mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] one question IP checksum

Hi John, thanks for your instructions, I tried to use your method with below 
steps:

1)  Create tunnel: vppctl create vxlan tunnel src 10.0.0.1 dst 10.0.0.2 vni 
24 encap-vrf-id 0 decap-next node ip4-input-no-checksum;

2)  Send vxlan traffic without inner ip header;
I can see obvious performance gain. But if I set the decap-next node 
ipv4-input, the vpp will drop the packet after decapsulation cause of the wrong 
inner ip header checksum. But when I set the decap-next node Ethernet-input, 
the packet will not be dropped. I'm a little confuse about this.

BTW, could you give me some explanation about which scenario should use vxlan 
over l2 and which scenario should use vxlan over l3? Thanks for your kindly 
help again!

Regards,
Yuwei
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of John Lo (loj) via Lists.Fd.Io
Sent: Saturday, October 20, 2018 11:06 PM
To: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] one question IP checksum

Hi Yuwei,

I see that you are using VXLAN to carry L3 packets which seems to still have 
ethernet header.  This is not standard usage of VXLAN so I am not aware of a 
way to achieve what you desired via some kind of configuration of VPP.  A more 
optimal (also not standard) way may be to just send IP payload in VXLLAN tunnel 
without Ethernet header.  Then on decap, you can send the packet directly to 
ip-input-nochecksum node instead of (ethernet-input node).  The proper way to 
do this would be to use VXLAN-GPE which include a protocol header to specify 
payload type.

BTW, your claim of UDP checksum on the outer packet would've already cover the 
inner payload including its IP header is not necessarily correct.  For IPv4, 
the UDP checksum is optional and often left as 0 so no

Re: [vpp-dev] one question IP checksum

[John Lo (loj) via Lists.Fd.Io]

Hi Yuwei,

I did not suggest one can create VXLAN tunnel and send the dcap packet directly 
to ip4-input or ip4-input-nochecksum.  It will not work because the VXLAN 
payload still have a MAC header before the IP header after decap.  That's why 
it only works if it is sent to ethernet-input.  You are getting checksum error, 
because ip4-input node is treating the MAC header as if it is an IP header.

I was suggesting you may be able to create VXLAN-GPE tunnel (with a different 
CLI to that of the VXLAN one) which is different to VXLAN tunnel.  With 
VXLAN-GPE, you can potentially send just IP packet without ethernet header, 
with the appropriate protocol field in the VXLAN-GPE header set accordingly.  
Then it is feasible to send the packet directly to ip4-input or 
ip4-input-nochecksum.  I am not sure how complete VXLAN-GPE handling is 
implemented in VPP so you may need to improve the code to handle it.

Note that big portion of performance gain you observed is because 
ethernet-input node is bypassed, in addition to saving from not calculating IP 
checksum.

As I described before, VXLAN is supposed to be used for L2 to carry ethernet 
packets.  If it is used for L3, it is not standard usage and will not 
interoperate properly with other devices. For L3, VXLAN-GPE should ideally be 
used as it is designed to handle encap/decap of various packet types, as GPE 
mean "generic protocol extension", including L2 and L3 protocols.

Regards,
John

From: Zhang, Yuwei1 
Sent: Monday, October 22, 2018 4:50 AM
To: John Lo (loj) ; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] one question IP checksum

Hi John, thanks for your instructions, I tried to use your method with below 
steps:

1)  Create tunnel: vppctl create vxlan tunnel src 10.0.0.1 dst 10.0.0.2 vni 
24 encap-vrf-id 0 decap-next node ip4-input-no-checksum;

2)  Send vxlan traffic without inner ip header;
I can see obvious performance gain. But if I set the decap-next node 
ipv4-input, the vpp will drop the packet after decapsulation cause of the wrong 
inner ip header checksum. But when I set the decap-next node Ethernet-input, 
the packet will not be dropped. I'm a little confuse about this.

BTW, could you give me some explanation about which scenario should use vxlan 
over l2 and which scenario should use vxlan over l3? Thanks for your kindly 
help again!

Regards,
Yuwei
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of John Lo (loj) via Lists.Fd.Io
Sent: Saturday, October 20, 2018 11:06 PM
To: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] one question IP checksum

Hi Yuwei,

I see that you are using VXLAN to carry L3 packets which seems to still have 
ethernet header.  This is not standard usage of VXLAN so I am not aware of a 
way to achieve what you desired via some kind of configuration of VPP.  A more 
optimal (also not standard) way may be to just send IP payload in VXLLAN tunnel 
without Ethernet header.  Then on decap, you can send the packet directly to 
ip-input-nochecksum node instead of (ethernet-input node).  The proper way to 
do this would be to use VXLAN-GPE which include a protocol header to specify 
payload type.

BTW, your claim of UDP checksum on the outer packet would've already cover the 
inner payload including its IP header is not necessarily correct.  For IPv4, 
the UDP checksum is optional and often left as 0 so not calculated.  VPP VXLAN 
encap would leave UDP checksum as 0 to save clocks, if the underlay is IPv4. If 
underlay is IPv6, then UDP checksum would be required and VPP would set it on 
VXLAN encap.

Regards,
John

From: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>
Sent: Saturday, October 20, 2018 9:58 AM
To: John Lo (loj) mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: Yang, Zhiyong mailto:zhiyong.y...@intel.com>>
Subject: RE: [vpp-dev] one question IP checksum

Thanks a lot for your detail reply, John. My scenario is vxlan over l3 network, 
which means after decapsulation, vpp will use ip header to execute the forward 
function. I use this command to create the tunnel: "vppctl create vxlan tunnel 
src 10.0.0.1 dst 10.0.0.2 vni 24 encap-vrf-id 0 decap-next node 
ethernet-input". I found that vpp will calculate the inner ip header checksum 
and verify it. So I wonder if it is possible to skip the inner ip header 
calculation because the outer udp checksum can cover the inner packet. 
Expecting your reply, thanks a lot.

Regards,
Yuwei

From: John Lo (loj) [mailto:l...@cisco.com]
Sent: Friday, October 19, 2018 11:04 PM
To: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] one question IP checksum

The IP path after receiving a VXLAN packet is processing the 

Re: [vpp-dev] one question IP checksum

[John Lo (loj) via Lists.Fd.Io]

Hi Yuwei,

I see that you are using VXLAN to carry L3 packets which seems to still have 
ethernet header.  This is not standard usage of VXLAN so I am not aware of a 
way to achieve what you desired via some kind of configuration of VPP.  A more 
optimal (also not standard) way may be to just send IP payload in VXLLAN tunnel 
without Ethernet header.  Then on decap, you can send the packet directly to 
ip-input-nochecksum node instead of (ethernet-input node).  The proper way to 
do this would be to use VXLAN-GPE which include a protocol header to specify 
payload type.

BTW, your claim of UDP checksum on the outer packet would've already cover the 
inner payload including its IP header is not necessarily correct.  For IPv4, 
the UDP checksum is optional and often left as 0 so not calculated.  VPP VXLAN 
encap would leave UDP checksum as 0 to save clocks, if the underlay is IPv4. If 
underlay is IPv6, then UDP checksum would be required and VPP would set it on 
VXLAN encap.

Regards,
John

From: Zhang, Yuwei1 
Sent: Saturday, October 20, 2018 9:58 AM
To: John Lo (loj) ; vpp-dev@lists.fd.io
Cc: Yang, Zhiyong 
Subject: RE: [vpp-dev] one question IP checksum

Thanks a lot for your detail reply, John. My scenario is vxlan over l3 network, 
which means after decapsulation, vpp will use ip header to execute the forward 
function. I use this command to create the tunnel: "vppctl create vxlan tunnel 
src 10.0.0.1 dst 10.0.0.2 vni 24 encap-vrf-id 0 decap-next node 
ethernet-input". I found that vpp will calculate the inner ip header checksum 
and verify it. So I wonder if it is possible to skip the inner ip header 
calculation because the outer udp checksum can cover the inner packet. 
Expecting your reply, thanks a lot.

Regards,
Yuwei

From: John Lo (loj) [mailto:l...@cisco.com]
Sent: Friday, October 19, 2018 11:04 PM
To: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] one question IP checksum

The IP path after receiving a VXLAN packet is processing the outer IP header 
and not the inner one.  The payload of VXLAN packet is expected to be an 
ethernet packet.  After VXLAN decap, the payload ethernet packet will be 
processed in L2 forwarding path where no IP processing is involved.

If you want to speed up VXLAN decap processing, there is a vxlan-bypass feature 
you can enable on the underlay interface which will look for VXLAN packet and 
bypass IP lookup to speed up processing:

vpp# set interface ip vxlan-bypass ?
  set interface ip vxlan-bypassset interface ip vxlan-bypass 
 [del]

Enabling this feature on IP forwarding would add slight overhead for non-VXLAN 
IP packets but speed up VXLAN decap performance as IP lookup is not done.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Zhang Yuwei
Sent: Thursday, October 18, 2018 11:26 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] one question IP checksum

Hi Guys and VPP maintainers,
 When I run VPP in vxlan scenario, I found that when VPP receive a 
vxlan packets, after decapsulation, the packet will go into ip-input node 
instead of ip-input-nochecksum which means vpp will re-calculate the checksum 
and verify it. I think the outer UDP checksum has already include the inner 
packet as payload, so can we skip the ip header checksum calculation for inner 
ip header? This part is done by software which will cause some CPU cycles 
consumption and I tried if skip the checksum calculation it will have a obvious 
performance gain. Can anybody give me some instructions? Thanks a lot for your 
kindly help.

Regards,
Yuwei

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

View/Reply Online (#10887): https://lists.fd.io/g/vpp-dev/message/10887
Mute This Topic: https://lists.fd.io/mt/27412224/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] one question IP checksum

[John Lo (loj) via Lists.Fd.Io]

The IP path after receiving a VXLAN packet is processing the outer IP header 
and not the inner one.  The payload of VXLAN packet is expected to be an 
ethernet packet.  After VXLAN decap, the payload ethernet packet will be 
processed in L2 forwarding path where no IP processing is involved.

If you want to speed up VXLAN decap processing, there is a vxlan-bypass feature 
you can enable on the underlay interface which will look for VXLAN packet and 
bypass IP lookup to speed up processing:

vpp# set interface ip vxlan-bypass ?
  set interface ip vxlan-bypassset interface ip vxlan-bypass 
 [del]

Enabling this feature on IP forwarding would add slight overhead for non-VXLAN 
IP packets but speed up VXLAN decap performance as IP lookup is not done.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Zhang Yuwei
Sent: Thursday, October 18, 2018 11:26 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] one question IP checksum

Hi Guys and VPP maintainers,
 When I run VPP in vxlan scenario, I found that when VPP receive a 
vxlan packets, after decapsulation, the packet will go into ip-input node 
instead of ip-input-nochecksum which means vpp will re-calculate the checksum 
and verify it. I think the outer UDP checksum has already include the inner 
packet as payload, so can we skip the ip header checksum calculation for inner 
ip header? This part is done by software which will cause some CPU cycles 
consumption and I tried if skip the checksum calculation it will have a obvious 
performance gain. Can anybody give me some instructions? Thanks a lot for your 
kindly help.

Regards,
Yuwei

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

View/Reply Online (#10880): https://lists.fd.io/g/vpp-dev/message/10880
Mute This Topic: https://lists.fd.io/mt/27412224/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] PPPoE plugin config #vpp #vpp

[John Lo (loj) via Lists.Fd.Io]

I have no idea what you are trying to do with PPPoE.  From an L2 forwarding 
point of view, however, you need to put interfaces into the same bridge domain 
(BD) so they can forward packets to each other.  If you have only two 
interfaces to send packets to each other, you can L2 cross connect them instead 
of using a BD.   -John

From: vpp-dev@lists.fd.io  On Behalf Of berk...@gmail.com
Sent: Tuesday, October 16, 2018 3:04 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin config #vpp #vpp

Switching to l2 mode with bridge-domain gives another trace, but anyway frame 
is not going to pppoe_cp_dispatch.

02:02:10:942877: tapcli-rx
  tapcli-0
02:02:10:942881: ethernet-input
  PPPOE_DISCOVERY: 2e:0d:e3:67:3e:bf -> 52:54:00:ea:ca:a5
02:02:10:942882: l2-input
  l2-input: sw_if_index 3 dst 52:54:00:ea:ca:a5 src 2e:0d:e3:67:3e:bf
02:02:10:942883: l2-learn
  l2-learn: sw_if_index 3 dst 52:54:00:ea:ca:a5 src 2e:0d:e3:67:3e:bf bd_index 1
02:02:10:942884: l2-fwd
  l2-fwd:   sw_if_index 3 dst 52:54:00:ea:ca:a5 src 2e:0d:e3:67:3e:bf bd_index 1
02:02:10:942885: l2-flood
  l2-flood: sw_if_index 3 dst 52:54:00:ea:ca:a5 src 2e:0d:e3:67:3e:bf bd_index 1
02:02:10:942885: error-drop
  l2-flood: L2 replication complete
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] L2TP dummy tx

[John Lo (loj) via Lists.Fd.Io]

Hi Jeff,

It was not intentional.  The commit you mentioned was addressing tunnel 
implementations in VPP which uses similar encap/decap approach with 
vnet/src/vxlan as the model or “template”.  L2TP uses different encap/decap 
approach so was not included.

With respect to the dummy tx function, I do see it used in L2TP 
VNET_DEVICE_CLASS init for l2tpv3_device_class:

VNET_DEVICE_CLASS (l2tpv3_device_class,static) = {
  .name = "L2TPv3",
  .format_device_name = format_l2tpv3_name,
  .name_renumber = l2tpv3_name_renumber,
  .tx_function = dummy_interface_tx,
};

That line specifying tx_function should be removed to avoid scalability issues. 
 If large number of L2TP tunnels are created, this line would cause multiple 
instances of the dummy_terface_tx nodes to be created, one per tunnel, even 
though these nodes will never be used.

Thanks for noticing this.  Please feel free to submit a patch to address it.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Jeff
Sent: Tuesday, October 16, 2018 12:59 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] L2TP dummy tx

Regarding this commit: 
https://git.fd.io/vpp/commit/?id=e5453d0fa29f39a7f78a7e22815566a7f4c9e5ef

I noticed that L2TP still has its dummy interface tx function and is not 
mentioned in the commit message.  Wanted to check if this was intentional or 
not.

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

View/Reply Online (#10840): https://lists.fd.io/g/vpp-dev/message/10840
Mute This Topic: https://lists.fd.io/mt/27371304/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] PPPoE plugin config #vpp #vpp

[John Lo (loj) via Lists.Fd.Io]

The interface is in L3 mode.  Thus, VPP will only allow packets whose 
destination MAC is the same as the interface MAC or bcast/mcast MAC.   The 
error “l3 mac mismatch” means the DMAC here “52:54:00:ea:ca:a5“ is not the same 
as the MAC of the interface.   -John

From: vpp-dev@lists.fd.io  On Behalf Of berk...@gmail.com
Sent: Tuesday, October 16, 2018 7:41 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin config #vpp #vpp

Sorry, PADO came from tap trace, but anyway i not understand reason of drop.

00:10:24:106524: tapcli-rx
  tapcli-0
00:10:24:106529: ethernet-input
  PPPOE_DISCOVERY: ae:24:05:0d:4c:e9 -> 52:54:00:ea:ca:a5
00:10:24:106531: error-drop
  ethernet-input: l3 mac mismatch

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

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

Re: [vpp-dev]vlan interface support?

[John Lo (loj) via Lists.Fd.Io]

If there is a BVI in a BD with sub-interfaces in the same BD which get packets 
with VLAN tags, it is best to configure a tag-rewrite operation on the 
sub-interfaces to pop their VLAN tags.  Then all packets are forwarded in BD 
without VLAN tags.  The CLI is “set interface l2 tag-rewrite  
pop 1” if the sub-interface has one VLAN tag.–John

From: saint_sun 孙 
Sent: Monday, October 15, 2018 2:42 AM
To: John Lo (loj) 
Cc: vpp-dev@lists.fd.io
Subject: Re: RE: [vpp-dev]vlan interface support?

I am very grateful to you for your advice！
I have tested it，But there is something wrong. when I receive an arp or ICMP 
packet from a l2 subif  that joins to bd 200 and encapsulates vlan 200，the 
reply packet that send from the subif does not have the vlan tag 200. Any more 
other configurations should I set？



可用于iOS的myMail发送


2018年10月14日 星期日 +0800 04:58 发件人 l...@cisco.com<mailto:l...@cisco.com> 
mailto:l...@cisco.com>>:

The equivalent of VLAN on a switch in VPP is a bridge domain or BD for short.  
One can put interfaces or VLAN sub-interfaces in a BD to form a L2 network 
among all interfaces in it.  One can also create a loopback interface, put it 
in a BD as its BVI (Bridge Virtual Interface) and assign IP addresses to it.  
Then packet can be IP forwarded into a BD through its BVI.



Following is the VPP CLI sequence to create a loopback (resulting in interface 
name loop0), put it in BD 13 as a BVI, and put an IP address on it:



loopback create mac 1a:2b:3c:4d:5e:6f

set interface l2 bridge loop0 13 bvi

set interface state loop0 up

set interface ip address loop0 6.0.0.250/16



Regards,

John



From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of saint_sun ? via 
Lists.Fd.Io
Sent: Friday, October 12, 2018 3:52 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev]vlan interface support?



I have a question:

Does vpp has the function like the configuration example:

interface f0/1

switchport access vlan 10



Interface vlan 10

ip address 10.0.0.1 255.255.255.0



If vpp has the function, where can I find the command and the source code?



Another question, does vpp support superVLAN?



anyone who knows please tell me, appreciate for your reply very much!


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

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

Re: [vpp-dev] question about L2VPN/EVPN

[John Lo (loj) via Lists.Fd.Io]

Hi Xue,

L2VPN/EVPN is a pretty generic area including many things.  You need to be more 
specific about what additional things you expect VPP to do for your usage of 
L2VPN/EVPN.  Note that if you are thing of protocol related handling for 
L2VPN/EVPN, then it won’t be supported as VPP is really just a dataplane 
forwarder.  You will need an external VPP client to act as its controller for 
protocol related handling.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of xyxue
Sent: Friday, October 12, 2018 3:54 AM
To: vpp-dev 
Subject: [vpp-dev] question about L2VPN/EVPN


Hi guys,

I'm testing the EVPN. By the configuration on 
https://wiki.fd.io/view/VPP/Using_VPP_as_a_VXLAN_Tunnel_Terminator , the 
VXLAN/EVPN function tests ok.
Is the vpp support L2VPN/EVPN？What's the configuration of L2VPN/EVPN?

Thanks，
Xue

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

View/Reply Online (#10809): https://lists.fd.io/g/vpp-dev/message/10809
Mute This Topic: https://lists.fd.io/mt/27268202/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]vlan interface support?

[John Lo (loj) via Lists.Fd.Io]

The equivalent of VLAN on a switch in VPP is a bridge domain or BD for short.  
One can put interfaces or VLAN sub-interfaces in a BD to form a L2 network 
among all interfaces in it.  One can also create a loopback interface, put it 
in a BD as its BVI (Bridge Virtual Interface) and assign IP addresses to it.  
Then packet can be IP forwarded into a BD through its BVI.

Following is the VPP CLI sequence to create a loopback (resulting in interface 
name loop0), put it in BD 13 as a BVI, and put an IP address on it:

loopback create mac 1a:2b:3c:4d:5e:6f
set interface l2 bridge loop0 13 bvi
set interface state loop0 up
set interface ip address loop0 6.0.0.250/16

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of saint_sun ? via 
Lists.Fd.Io
Sent: Friday, October 12, 2018 3:52 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev]vlan interface support?

I have a question:
Does vpp has the function like the configuration example:
interface f0/1
switchport access vlan 10

Interface vlan 10
ip address 10.0.0.1 255.255.255.0

If vpp has the function, where can I find the command and the source code?

Another question, does vpp support superVLAN?

anyone who knows please tell me, appreciate for your reply very much!

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

View/Reply Online (#10808): https://lists.fd.io/g/vpp-dev/message/10808
Mute This Topic: https://lists.fd.io/mt/27268189/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] Verification always fail with stable/1801

[John Lo (loj) via Lists.Fd.Io]

Thanks Marco.  I noticed your patch for extrenal/MakeFile on stable/1801 was 
merged.  I suppose we need to rebase all the outstanding patches for 1801 and 
verification should work now.  I will do it for the patches I am involved.   
-John

From: vpp-dev@lists.fd.io  On Behalf Of Marco Varlese
Sent: Thursday, October 11, 2018 11:29 AM
To: John Lo (loj) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Verification always fail with stable/1801

Yes, there's troubles with 2 things:
1) package naming
2) packagecloud bionic "repo"

Both things are getting addressed.

HTH,
Marco

On Thu, 2018-10-11 at 15:00 +0000, John Lo (loj) via Lists.Fd.Io wrote:
It seems verifications are always failing for patches on stable/1801 branch.  
Does anyone know why?
The following patch with a simple one line change is an example which fails all 
3 verification attempts:
https://gerrit.fd.io/r/#/c/15222/

Regards,
John

-=-=-=-=-=-=-=-=-=-=-=-

Links: You receive all messages sent to this group.



View/Reply Online (#10799): https://lists.fd.io/g/vpp-dev/message/10799

Mute This Topic: https://lists.fd.io/mt/27242615/675056

Group Owner: vpp-dev+ow...@lists.fd.io<mailto:vpp-dev+ow...@lists.fd.io>

Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[mvarl...@suse.de<mailto:mvarl...@suse.de>]

-=-=-=-=-=-=-=-=-=-=-=-



--
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Verification always fail with stable/1801

[John Lo (loj) via Lists.Fd.Io]

It seems verifications are always failing for patches on stable/1801 branch.  
Does anyone know why?
The following patch with a simple one line change is an example which fails all 
3 verification attempts:
https://gerrit.fd.io/r/#/c/15222/

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

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

Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged sub-interface

[John Lo (loj) via Lists.Fd.Io]

When a sub-interface is created, matching of tags on the packet to the 
sub-interface can be specified as “exact-match”.  With exact-match, packet must 
have the same number of tags with values matching that specified for the 
sub-interface.  Otherwise, packets will belong to the best matched 
sub-interface.  A sub-interface to be used for L3 must be created with 
exact-match.  Otherwise, IP forwarding cannot get a proper L2 header rewrite 
for output on the sub-interface.

As for a main interface,  I suppose when it is in L2 mode, packets received 
with no tags or with tags without any specific sub-interface match is 
considered as on the main interface.  When the main interface is in L3 mode, it 
will only get untagged packets because of the exact match requirement.  I think 
this is why the default sub-interface starts to get non-matching tagged packets 
when main interface is in L3 mode, as observed.  Packets received on the main 
interface in L3 mode can be IP forwarded or be dropped.

It is a good question – what is the expected sub-interface classification 
behavior with untagged or default sub-interface?  I think this is the area of 
VPP that has not been used much and thus we have little knowledge of how it 
behaves without studying the code (hence lack of response to this thread of 
questions so far).  When I get a chance, I can take look into this issue – how 
VLAN match should work for default/untagged sub-interface and why untagged 
sub-interface creation fails.  I don’t know how soon I will get to it.  So, if 
anyone is willing to contribute and submit a patch to fix the issue, I will be 
happy to review and/or merge the patch as appropriate.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Edward Warnicke
Sent: Thursday, September 20, 2018 1:25 PM
To: vpp-dev@lists.fd.io; Bly, Mike 
Subject: Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

Guys,
  Anyone have any thoughts on this?

Ed



On September 20, 2018 at 12:01:05 PM, Bly, Mike 
(m...@ciena.com) wrote:
Ed/Keith, et al,

What Vijay is digging into is trying to understand how to provide the following 
sub-interface setup on a common/single physical NIC. I am hoping you can shed 
some light on the feasibility of this, given the current code to date.

Our goal is to provide proper separation of untagged vs. explicit-vlan (EVPL) 
vs. default (all remaining vlans) vs. EPL as needed on a given NIC, independent 
of any choice of forwarding mode (L2 vs L3).

GigabitEthernet5/0/0 --> “not used to forward traffic” (see next three 
sub-if’s), calling it sub_if_0 for reference below (seen as possible EPL path, 
but not covered here, since already “working”)
GigabitEthernet5/0/0.untagged --> all untagged traffic on this port goes to 
sub_if_1
GigabitEthernet5/0/0.vid1 --> all traffic arriving with outer tag == 1 goes to 
sub_if_2
GigabitEthernet5/0/0.default --> all other tagged traffic goes to sub_if_3

The only way we seem to be able to get sub_if_3 to process traffic is to 
disable sub_if_0 (set mode to l3).

Additionally, the current configuration checking in src/vnet/ethernet/node.c 
does not seem amenable to allowing the actual configuration and support of 
untagged vs default as two distinct sub-if’s processing traffic at the same 
time (my sub_if_1 and sub_if_3 above). Are we missing something here in how 
this is supposed to work? We would be fine with letting “sub_if_0” carry the 
untagged traffic (in place of sub_if_1), but we have yet to figure out how to 
do that while still having sub_if_3 processing “all other tagged frames”. We 
can say in all of our testing that we in fact do correctly see sub_if_2 working 
as expected.

Here is a simple configuration showing our current efforts in this area:

create bridge-domain 1
create bridge-domain 2
create bridge-domain 3

set interface l2 bridge GigabitEthernet5/0/0 1
set interface l2 bridge GigabitEthernet5/0/1 1

create sub-interfaces GigabitEthernet5/0/0 4095 default
create sub-interfaces GigabitEthernet5/0/1 4095 default
set interface l2 bridge GigabitEthernet5/0/0.4095 2
set interface l2 bridge GigabitEthernet5/0/1.4095 2

create sub-interfaces GigabitEthernet5/0/0 1
create sub-interfaces GigabitEthernet5/0/1 1
set interface l2 bridge GigabitEthernet5/0/1.1 3
set interface l2 bridge GigabitEthernet5/0/0.1 3


set interface state GigabitEthernet5/0/0 up
set interface state GigabitEthernet5/0/1 up
set interface state GigabitEthernet5/0/0.4095 up
set interface state GigabitEthernet5/0/1.4095 up
set interface state GigabitEthernet5/0/0.1 up
set interface state GigabitEthernet5/0/1.1 up

As noted above, the only way to get GigabitEthernet5/0/0.4095 to process frames 
is to do the following, but doing so drops all untagged traffic.

set interface l3 GigabitEthernet5/0/0

Let us know next steps in resolving this.

Best Regards,
Mike

-- Forwarded message --
From: Chandra Mohan, Vijay Mohan 

Re: [vpp-dev] question about l2vpn with sr mpls

[John Lo (loj) via Lists.Fd.Io]

Hi Xue,

VPP does support L2VPN with SR-MPLS in latest master, possibly the just 
released 18.07.1 point release.  I only verified it on master and not 18.07.1 
myself.

Assume we created an SR-MPLS policy:
sr mpls policy add bsid 993 next 104 next 105 next 106

We can then create a MPLS tunnel for L2 forwarding via the policy:
mpls tunnel l2-only via via-label 993 out-labels 33
where label 33 will be the local label that marks the L2VPN packets sent over 
the just created tunnel (with interface name "mpls-tunnel0" if it is the first 
one).  Assuming the other side also created the corresponding MPLS tunnel with 
the same local label value 33, then we need to associate the label with packet 
received via the MPLS tunnel:
mpls local-label add 33 eos via l2-input-on mpls-tunnel0

Now we just need to set the MPLS tunnel state up and put it in the desired 
bridge domain with SHG 1:
set int l2 bridge mpls-tunnel0 13 1
set int state mpls-tunnel0 up

Hope this helps,
John

From: vpp-dev@lists.fd.io  On Behalf Of xyxue
Sent: Tuesday, September 18, 2018 10:01 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] question about l2vpn with sr mpls


Hi guys,

I'm testing the sr mpls. I found the  example show of l3vpn with sr mpls in 
https://wiki.fd.io/view/VPP/Segment_Routing_for_MPLS.


Is there any example show about l2vpn with sr mpls? Is the vpp support l2vpn 
with sr mpls?

Thanks,
Xue

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

View/Reply Online (#10573): https://lists.fd.io/g/vpp-dev/message/10573
Mute This Topic: https://lists.fd.io/mt/25752317/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] Increase in main core CPU usage between 17.10 and 18.04

[John Lo (loj) via Lists.Fd.Io]

VPP has supported IPv6 NA/NS for a while. I believe this process was added for 
VPP to support RS/RA.

Ole, Can you confirm if my understanding is correct?

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of sheckman
Sent: Tuesday, September 18, 2018 6:29 PM
To: John Lo (loj) ; Dave Barach (dbarach) ; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Increase in main core CPU usage between 17.10 and 18.04

John,

>From looking at the changes, it seems it also addresses some ipv6 neighbor 
>discovery issues?

Thanks,
Steve

On 09/18/2018 06:13 PM, John Lo (loj) wrote:
In 1804 the rd-cp-process would run frequently in the main thread to cause your 
observation of CPU usage.  It can be observed in your "show run" output under 
main thread that this process went through suspend/run cycle many times 
(highlighted in bold red below).

This was fixed under Jira ticket VPP-1256 and available in 18.07.  The patch is 
- 
https://gerrit.fd.io/r/#/c/12521/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.fd.io%2Fr%2F%23%2Fc%2F12521%2F=01%7C01%7CSteve.Heckman%40arris.com%7Cdbdd5a34772c4e53b64908d61db3e778%7Cf27929ade5544d55837ac561519c3091%7C1=BPjWXnz%2BTDmcgTOcRXDaGEuR%2BfS4cIRMU%2BvzhMSBtqo%3D=0>

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
<mailto:vpp-dev@lists.fd.io> On Behalf Of sheckman
Sent: Tuesday, September 18, 2018 5:55 PM
To: Dave Barach (dbarach) <mailto:dbar...@cisco.com>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Increase in main core CPU usage between 17.10 and 18.04

Dave,

That isn't our real application, which does run higher PPS rates:
vpp# show run
Thread 0 vpp_main (lcore 30)
Time 50182.3, average vectors/node 1.00, last 128 main loops 0.00 per node 0.00
  vector rates in 6.7225e-1, out 6.8335e-1, drop 5.9782e-3, punt 0.e0

Thread 1 vpp_wk_0 (lcore 12)
Time 50182.3, average vectors/node 1.97, last 128 main loops 0.00 per node 0.00
  vector rates in 2.2826e5, out 8.6201e4, drop 2.6843e0, punt 4.6188e-1

Thread 2 vpp_wk_1 (lcore 32)
Time 50182.3, average vectors/node 2.18, last 128 main loops 0.00 per node 0.00
  vector rates in 6.1042e5, out 1.6054e5, drop 1.5624e0, punt 0.e0
The workers run on isolated tickless cores and the main runs on a regular linux 
core.


What I sent below is a plain vanilla vpp run to investigate whether our code 
caused the main core CPU usage increase or if it was due to a change in vpp 
(which it appears to be).

As I said, in 17.10, we observed much lower CPU usage on vpp_main (0.3%). We 
were just curious what the design change was in 18.0x that bumped the main core 
CPU usage up to 85%. (In 17.10 and 18.04, the workers always run at 100%).

(BTW: This is the change we back-merged: 
https://github.com/FDio/vpp/commit/85aa49019f4b4b2b7a4fce4313fdc0f2de65c277<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFDio%2Fvpp%2Fcommit%2F85aa49019f4b4b2b7a4fce4313fdc0f2de65c277=01%7C01%7CSteve.Heckman%40arris.com%7Cdbdd5a34772c4e53b64908d61db3e778%7Cf27929ade5544d55837ac561519c3091%7C1=SreOLPLt%2FAK%2F%2BDYNN7uBBlCqj32kpcOg%2B1IZrTljWQc%3D=0>)

Thanks,
Steve


On 09/18/2018 05:27 PM, Dave Barach (dbarach) wrote:

At that PPS rate, you don't need two worker threads. The worker threads burn a 
bunch of cycles - poll-wait or not - doing next-to-nothing. Try running the 
main thread all by itself...



D.



-Original Message-

From: Heckman, Steve <mailto:steve.heck...@arris.com>

Sent: Tuesday, September 18, 2018 5:15 PM

To: Dave Barach (dbarach) <mailto:dbar...@cisco.com>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>

Subject: Re: Increase in main core CPU usage between 17.10 and 18.04



We back-merged the unix poll wait timeout and a 100 usec delay gets us down to 
maybe 15%. Just wondering why the change originally.



top -H:



top - 17:09:45 up 19 days,  2:07,  7 users,  load average: 5.72, 5.85, 5.69

Threads: 491 total,   7 running, 484 sleeping,   0 stopped,   0 zombie

%Cpu(s):  8.9 us,  0.0 sy,  0.0 ni, 91.0 id,  0.0 wa,  0.0 hi,  0.1 si,

0.0 st

KiB Mem : 26409392+total, 10683445+free, 15314609+used,  4113380 buff/cache

KiB Swap: 26830848+total, 26830848+free,0 used. 10981197+avail Mem



  PID USER  PR  NIVIRTRESSHR S %CPU %MEM TIME+

COMMAND

 7621 root -51   0 11.789g 119608  17500 R 99.7  0.0  39:21.32

vpp_wk_0

 7622 root -51   0 11.789g 119608  17500 R 99.7  0.0  39:21.32

vpp_wk_1

 7615 root -51   0 11.789g 119608  17500 R 83.8  0.0  34:24.68

vpp_main



sudo strace -p 7615:



epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0







Thread 0 vpp_main (lcore 16)

Re: [vpp-dev] Increase in main core CPU usage between 17.10 and 18.04

[John Lo (loj) via Lists.Fd.Io]

In 1804 the rd-cp-process would run frequently in the main thread to cause your 
observation of CPU usage.  It can be observed in your "show run" output under 
main thread that this process went through suspend/run cycle many times 
(highlighted in bold red below).

This was fixed under Jira ticket VPP-1256 and available in 18.07.  The patch is 
- https://gerrit.fd.io/r/#/c/12521/

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of sheckman
Sent: Tuesday, September 18, 2018 5:55 PM
To: Dave Barach (dbarach) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Increase in main core CPU usage between 17.10 and 18.04

Dave,

That isn't our real application, which does run higher PPS rates:
vpp# show run
Thread 0 vpp_main (lcore 30)
Time 50182.3, average vectors/node 1.00, last 128 main loops 0.00 per node 0.00
  vector rates in 6.7225e-1, out 6.8335e-1, drop 5.9782e-3, punt 0.e0

Thread 1 vpp_wk_0 (lcore 12)
Time 50182.3, average vectors/node 1.97, last 128 main loops 0.00 per node 0.00
  vector rates in 2.2826e5, out 8.6201e4, drop 2.6843e0, punt 4.6188e-1

Thread 2 vpp_wk_1 (lcore 32)
Time 50182.3, average vectors/node 2.18, last 128 main loops 0.00 per node 0.00
  vector rates in 6.1042e5, out 1.6054e5, drop 1.5624e0, punt 0.e0
The workers run on isolated tickless cores and the main runs on a regular linux 
core.


What I sent below is a plain vanilla vpp run to investigate whether our code 
caused the main core CPU usage increase or if it was due to a change in vpp 
(which it appears to be).

As I said, in 17.10, we observed much lower CPU usage on vpp_main (0.3%). We 
were just curious what the design change was in 18.0x that bumped the main core 
CPU usage up to 85%. (In 17.10 and 18.04, the workers always run at 100%).

(BTW: This is the change we back-merged: 
https://github.com/FDio/vpp/commit/85aa49019f4b4b2b7a4fce4313fdc0f2de65c277)

Thanks,
Steve


On 09/18/2018 05:27 PM, Dave Barach (dbarach) wrote:

At that PPS rate, you don't need two worker threads. The worker threads burn a 
bunch of cycles - poll-wait or not - doing next-to-nothing. Try running the 
main thread all by itself...



D.



-Original Message-

From: Heckman, Steve 

Sent: Tuesday, September 18, 2018 5:15 PM

To: Dave Barach (dbarach) ; 
vpp-dev@lists.fd.io

Subject: Re: Increase in main core CPU usage between 17.10 and 18.04



We back-merged the unix poll wait timeout and a 100 usec delay gets us down to 
maybe 15%. Just wondering why the change originally.



top -H:



top - 17:09:45 up 19 days,  2:07,  7 users,  load average: 5.72, 5.85, 5.69

Threads: 491 total,   7 running, 484 sleeping,   0 stopped,   0 zombie

%Cpu(s):  8.9 us,  0.0 sy,  0.0 ni, 91.0 id,  0.0 wa,  0.0 hi,  0.1 si,

0.0 st

KiB Mem : 26409392+total, 10683445+free, 15314609+used,  4113380 buff/cache

KiB Swap: 26830848+total, 26830848+free,0 used. 10981197+avail Mem



  PID USER  PR  NIVIRTRESSHR S %CPU %MEM TIME+

COMMAND

 7621 root -51   0 11.789g 119608  17500 R 99.7  0.0  39:21.32

vpp_wk_0

 7622 root -51   0 11.789g 119608  17500 R 99.7  0.0  39:21.32

vpp_wk_1

 7615 root -51   0 11.789g 119608  17500 R 83.8  0.0  34:24.68

vpp_main



sudo strace -p 7615:



epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0

epoll_pwait(5, [], 256, 0, [], 8)   = 0







Thread 0 vpp_main (lcore 16)

Time 2234.4, average vectors/node 1.07, last 128 main loops 0.00 per node 0.00

  vector rates in 0.e0, out 1.6111e-2, drop 2.2377e-2, punt 0.e0

 Name State Calls

VectorsSuspends Clocks   Vectors/Call

TenGigabitEthernet5/0/0-output   active  3

3   0  4.35e31.00

TenGigabitEthernet5/0/1-output   active 17

17   0  3.45e31.00

TenGigabitEthernet8/0/0-output   active 18

18   0  1.84e31.00

TenGigabitEthernet8/0/0-tx   active 18

18   0  7.47e31.00

TenGigabitEthernet8/0/1-output   active 18

18   0  1.62e31.00

TenGigabitEthernet8/0/1-tx   active 18

18   0  6.92e31.00

acl-plugin-fa-cleaner-process  event wait0

0   1  7.96e30.00

admin-up-down-process  event wait0

0   1  1.70e30.00

api-rx-from-ringany wait 0

0 119  7.05e40.00

avf-processevent wait0

0 

Re: [vpp-dev] cmake is on

[John Lo (loj) via Lists.Fd.Io]

Since qsort.c from vppinfra has the buffer overflow issue, shall we delete this 
file to avoid causing more confusion in the future? -John

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
Lists.Fd.Io
Sent: Friday, September 07, 2018 4:30 AM
To: Damjan Marion 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] cmake is on


I just did it:

https://gerrit.fd.io/r/#/c/14711/


--
Damjan


On 7 Sep 2018, at 09:25, Damjan Marion via Lists.Fd.Io 
mailto:dmarion=me@lists.fd.io>> wrote:


Dear Kingwei,

That should be easy to fix. Can you just remove it and submit patch, so i can 
merge it?

Thanks,

--
Damjan


On 7 Sep 2018, at 02:39, Kingwel Xie 
mailto:kingwel@ericsson.com>> wrote:

Hi Damijan,

Thanks for the great job done. It is now much faster.

We noticed a difference between using cmake and automake in the latest code:

Vppinfra/qsort.c is included in vppinfra/CMakefile.txt but not in vppinfra.am, 
which creates a situation that cmake image would be linked to the qsort.c but 
automake linked to glibc.

The reason why we noticed is there is a buffer overrun bug in qsort.c that 
causes cli crashed occasionally.

Please comment how to fix. Personally I’d like to remove qsort.c, like before.

Regards,
Kingwel

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Damjan Marion 
via Lists.Fd.Io
Sent: Sunday, September 02, 2018 8:48 PM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] cmake is on


Dear all,

We just switched from autotools to cmake and retired all autotools related 
files in src/.

All verify jobs are ok, and we also tried it on 3 different x86 and 2 different 
ARM Aarch64 machines.

Due to blast radius, i will not be surprised that some small issues pop out, 
but i don't expect anything hard to fix.

Let us know if you hit something...

PS As a part of this change, CentOS 7 build are now using devtoolset-7, so they 
are compiled with gcc-7, which also means images have support for Skylake 
Servers (AVX512).

--
Damjan

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

View/Reply Online (#10420): https://lists.fd.io/g/vpp-dev/message/10420
Mute This Topic: https://lists.fd.io/mt/25155374/675642
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[dmar...@me.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#10421): https://lists.fd.io/g/vpp-dev/message/10421
Mute This Topic: https://lists.fd.io/mt/25155374/675642
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[dmar...@me.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#10433): https://lists.fd.io/g/vpp-dev/message/10433
Mute This Topic: https://lists.fd.io/mt/25155374/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] vnet_feature_enable_disable disable option is broken

[John Lo (loj) via Lists.Fd.Io]

Disabling a feature on an interface will not change the graph arcs, as stated 
by Dave. The more relevant CLI is to use “show interface features 
” to check whether a particular feature is enabled on an 
interface or not.–John

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Tuesday, September 04, 2018 3:05 PM
To: Andrew Yourtchenko ; .ılı.D'p@k.ılı. 

Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vnet_feature_enable_disable disable option is broken

No, there isn’t. There isn’t much of a point in deleting graph arcs. If the 
feature is reenabled, the existing arc from A to B will be reused.

D.

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Andrew 
Yourtchenko
Sent: Tuesday, September 4, 2018 2:50 PM
To: .ılı.D'p@k.ılı. mailto:deepak@gmail.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vnet_feature_enable_disable disable option is broken

Hi Deepak,

Not, as far as my quick code browse suggests.

—a

On 4 Sep 2018, at 20:25, .ılı.D'p@k.ılı. 
mailto:deepak@gmail.com>> wrote:
Hi Andrew,

Is there a similar delete call for the "vlib_node_add_next"  function?

Regards
Deepak Kumar Ch


On Tue, Sep 4, 2018 at 11:54 PM, .ılı.D'p@k.ılı. 
mailto:deepak@gmail.com>> wrote:
Hi Andrew,

I was expecting the delete command to remove acl from the ip4 arc and also the 
node graph of acl wont have ip4-lookup listed in its next nodes.
The current delete command is not doing a revert to old state.

Is there a way to make the node-graph go back to the init state?

Regards,
Deepak Kumar Ch








On Tue, Sep 4, 2018 at 10:46 PM, Andrew  Yourtchenko 
mailto:ayour...@gmail.com>> wrote:
Deepak,

If the feature enable/disable (or its usage) is broken, the trace for the 
traffic via thar interface with removed acl would still show the acl plugin 
node in the path, could you send the trace for a packet with acl and without 
acl to see whether it is the case ?

I don’t make any efforts to “nullify” the egress graph from the acl plugin 
nodes because 99% of the time after you remove the acl you will apply it back 
or apply a different acl, in my experience. Could you explain a bit more why 
you expect it differently ?

--a

On 4 Sep 2018, at 18:36, .ılı.D'p@k.ılı. 
mailto:deepak@gmail.com>> wrote:
Hi ,

When i remove acl from interface, its node graph doesnt revert back to original 
state.

#vppctl show vlib graph acl-plugin-in-ip4-fa
   Name  NextPrevious
acl-plugin-in-ip4-faerror-drop [0]

//ADD ACl
vat# acl_add_replace ipv4 permit
vl_api_acl_add_replace_reply_t_handler:108: ACL index: 0

//ATTACH to interface
vat# acl_interface_add_del sw_if_index 2  add input acl 0

//CHECK if acl's vpp node graph has changed
#vppctl show vlib graph acl-plugin-in-ip4-fa
   Name  NextPrevious
acl-plugin-in-ip4-faerror-drop [0]  ip4-mpls-label-disposition
ip4-lookup [1]  ip4-mpls-label-disposition
   ip4-input-no-checksum
 ip4-input

//DEL ACL
vat# acl_interface_add_del sw_if_index 2 del input acl 0

//CHECK if acl's vpp node graph has reverted back
#vppctl show vlib graph acl-plugin-in-ip4-fa
   Name  NextPrevious
acl-plugin-in-ip4-faerror-drop [0]  ip4-mpls-label-disposition
ip4-lookup [1]  ip4-mpls-label-disposition
   ip4-input-no-checksum
 ip4-input

Regards,
Deepak Kumar Ch
--


Regards,
Deepak Kumar Ch

“We judge ourselves by our intentions and others by their actions.”- Stephen 
M.R. Covey
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10352): https://lists.fd.io/g/vpp-dev/message/10352
Mute This Topic: https://lists.fd.io/mt/25178343/675608
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[ayour...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-



--


Regards,
Deepak Kumar Ch

“We judge ourselves by our intentions and others by their actions.”- Stephen 
M.R. Covey



--


Regards,
Deepak Kumar Ch

“We judge ourselves by our intentions and others by their actions.”- Stephen 
M.R. Covey
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10364): https://lists.fd.io/g/vpp-dev/message/10364
Mute This Topic: https://lists.fd.io/mt/25178343/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] query regarding L2 xconnect feature

[John Lo (loj) via Lists.Fd.Io]

VPP interface by default is in L3 mode and has to be set into L2 mode for 
either bridging or cross connect.  The reason, setting up an interface cross 
connected to the 2nd interface only does not work, is that the second interface 
is not in L2 mode.  Thus, L2 forwarding cannot output packets on the 2nd 
interface.  If you do not want the 2nd interface sending its packets back to 
the 1st interface, I believe (have not tried it) you can xconnect it to the 
local0 interface.  Then input packet on the 2nd interface should be dropped.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Manjunath Munavalli
Sent: Saturday, August 11, 2018 5:20 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] query regarding L2 xconnect feature

Hi,

I want to use the L2 xconnect feature only in one direction, i.e suppose i have 
2 ports x and y,
i want to only do "set interface l2 xconnect X Y" so that all traffic from port 
X is sent to port Y.

If I do this only one direction it is not working. It works only if i do it 
both the direction X->Y and Y->X.

May i know why it doesn't work if we set l2 xconnect only in one direction.

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

View/Reply Online (#10107): https://lists.fd.io/g/vpp-dev/message/10107
Mute This Topic: https://lists.fd.io/mt/24471742/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] vpls bridge mac learning

[John Lo (loj) via Lists.Fd.Io]

When you have a full mesh of tunnels among PE routers, the split horizon group 
(SHG) of these tunnels should be set to a non-zero value, e.g. 1, to prevent 
loops. Thus, packets received from an interface with a non-zero SHG will not be 
replicated or broadcasted to another interface in the bridge with the same SHG 
value.  The SHG of an interface in a bridge can be set when you put an 
interface in a bridge:

DBGvpp# set int l2 bri ?
  set interface l2 bridge  set interface l2 bridge  
 [bvi] [shg]

If SHG is not specified, it defaults to 0.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Gulakh
Sent: Monday, July 16, 2018 9:05 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vpls bridge mac learning

Hi,
I have configured a scenario in which I have 3 routers that they form a full 
mesh network i.e. each of which connected directly to others.

Now each router have one bridge to which one physical interface and two mpls 
tunnels are connected.

Now I connect a PC to the physical interface of one router and then use "show 
l2fib verbose" to see the learnt MACs.

As far as I know, this command should have displayed that the PC's MAC is 
learnt from the physical interface, but to my surprise it is alternating 
between mpls_tunnel0 and mpls_tunnel1
here is the log:

DBGvpp# sh l2fib verbose
Mac-Address BD-Idx If-Idx BSN-ISN Age(min) static filter bvi 
Interface-Name
 3c:07:71:5f:2d:f51  10 3/3  -   -  - -   
mpls-tunnel0
L2FIB total/learned entries: 1/1  Last scan time: 1.8002e-3sec  Learn limit: 
4194304

DBGvpp# sh l2fib verbose
Mac-Address BD-Idx If-Idx BSN-ISN Age(min) static filter bvi 
Interface-Name
 3c:07:71:5f:2d:f51  11 3/3  -   -  - -   
mpls-tunnel1

I guess that when PC is connected to router, It first sends an ARP message that 
is broadcasted in the network, in other words, the two other router's bridge 
are receiving this ARP message from their corresponding mpls_tunnel and then 
they broadcast it again.
Finnaly I think that router is receiving its own ARP packet from other bridges 
and shows that PC's MAC address is being learnt from those connected tunnels 
alternately.

My scenario is somehow like the attached image but I have only one customer 
e.g. the Yellow customer.

Q1: Am I right?? If yes, How to solve this problem?? If no, What is the 
problem??

When I ping two PCs of the customer using this VPLS, most of the ICMP packets 
are dropped. I think that this is the effect of the above mentioned ARP problem.
Q2: Am I right??

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

View/Reply Online (#9850): https://lists.fd.io/g/vpp-dev/message/9850
Mute This Topic: https://lists.fd.io/mt/23531739/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] First packet is lost when ARP resolution occurs

[John Lo (loj) via Lists.Fd.Io]

Packet drop with unresolved IP neighbor adjacency is the expected behavior.  As 
the packet will trigger an ARP request to resolve the adjacency, subsequent 
packets with the same destination address will start to flow if the adjacency 
is resolved on receiving a reply.   -John

From: vpp-dev@lists.fd.io  On Behalf Of berengerf via 
Lists.Fd.Io
Sent: Thursday, June 21, 2018 12:17 PM
To: vpp-dev 
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] First packet is lost when ARP resolution occurs

Hello,

I noticed that some packets were lost during IKEv2 negotiation with VPP. After 
investigation it seems that it is related to ARP resolution.

When the ARP cache is empty and a packetX needs to be sent, VPP will send an 
ARP request (which is right), but the packetX won't be sent afterwards. A 
mitigation that I found is to fill the ARP cache manually, but it is not very 
convenient.

Thus I was wondering  : is it the expected behavior or should it be patched ?

Best regards.

Berenger


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

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

Re: [**EXTERNAL**] Re: [vpp-dev] GET/SET support for each feature entity from VPP client

[John Lo (loj) via Lists.Fd.Io]

See src/vnet/interface.api and src/vnet/ip/ip.api for interface and IP 
forwarding related dump and details APIs.  I am not sure there is dump/details 
for all entities a VPP client may need.  Contributions for any missing ones are 
always welcomed ☺.   –John

From: Gudimetla, Leela Sankar 
Sent: Thursday, June 14, 2018 4:40 PM
To: John Lo (loj) ; vpp-dev@lists.fd.io
Subject: Re: [**EXTERNAL**] Re: [vpp-dev] GET/SET support for each feature 
entity from VPP client

Thanks John. Are these “dump” and “details” defined for all the different 
entities that a VPP client configure? Like Interfaces, VRFs, Sub-interfaces, 
etc..
So that I can do “dump” and get the corresponding “details”, and call 
appropriate SET API for updating specific attribute.

Thanks,
Leela sankar

From: mailto:vpp-dev@lists.fd.io>> on behalf of "John Lo 
(loj) via Lists.Fd.Io" 
mailto:loj=cisco@lists.fd.io>>
Reply-To: "l...@cisco.com<mailto:l...@cisco.com>" 
mailto:l...@cisco.com>>
Date: Thursday, June 14, 2018 at 1:29 PM
To: Leela Gudimetla mailto:lgudi...@ciena.com>>, 
"vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Subject: [**EXTERNAL**] Re: [vpp-dev] GET/SET support for each feature entity 
from VPP client

You can find L2 bridging related APIs from the file src/vnet/l2/l2.api.  The 
API to get bridge domain state is bridge_domain_dump and the response info 
provided is bridge_domain_details.  The API to change bridge domain attributes 
is bridge_flags.  The API to set bridge domain aging interval is 
bridge_domain_set_mac_age.

Following are the spec of these APIs from the file l2.api:

/** \brief L2 bridge domain request operational state details
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param bd_id - the bridge domain id desired or ~0 to request all bds
*/
define bridge_domain_dump
{
  u32 client_index;
  u32 context;
  u32 bd_id;
};

/** \brief L2 bridge domain sw interface operational state response
@param bd_id - the bridge domain id
@param sw_if_index - sw_if_index in the domain
@param shg - split horizon group for the interface
*/
typeonly manual_print manual_endian define bridge_domain_sw_if
{
  u32 context;
  u32 sw_if_index;
  u8 shg;
};

/** \brief L2 bridge domain operational state response
@param bd_id - the bridge domain id
@param flood - bcast/mcast flooding state on all interfaces in the bd
@param uu_flood - uknown unicast flooding state on all interfaces in the bd
@param forward - forwarding state on all interfaces in the bd
@param learn - learning state on all interfaces in the bd
@param arp_term - arp termination state on all interfaces in the bd
@param mac_age - mac aging time in min, 0 for disabled
@param bd_tag - optional textual tag for the bridge domain
@param n_sw_ifs - number of sw_if_index's in the domain
*/
manual_print manual_endian define bridge_domain_details
{
  u32 context;
  u32 bd_id;
  u8 flood;
  u8 uu_flood;
  u8 forward;
  u8 learn;
  u8 arp_term;
  u8 mac_age;
  u8 bd_tag[64];
  u32 bvi_sw_if_index;
  u32 n_sw_ifs;
  vl_api_bridge_domain_sw_if_t sw_if_details[n_sw_ifs];

/** \brief Set interface L2 flags (such as L2_LEARN, L2_FWD,
L2_FLOOD, L2_UU_FLOOD, or L2_ARP_TERM bits). This can be used
to disable one or more of the features represented by the
flag bits on an interface to override what is set as default
for all interfaces in the bridge domain
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param sw_if_index - interface
@param is_set - if non-zero, set the bits, else clear them
@param feature_bitmap - non-zero bits (as above) to set or clear
*/
define l2_flags
{
  u32 client_index;
  u32 context;
  u32 sw_if_index;
  u8 is_set;
  u32 feature_bitmap;
};

/** \brief Set interface L2 flags response
@param context - sender context, to match reply w/ request
@param retval - return code for the set l2 bits request
@param resulting_feature_bitmap - the internal l2 feature bitmap after the 
request is implemented
*/
define l2_flags_reply
{
  u32 context;
  i32 retval;
  u32 resulting_feature_bitmap;
};

/** \brief L2 bridge domain set mac age
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param bd_id - the bridge domain to create
@param mac_age - mac aging time in min, 0 for disabled
*/
autoreply define bridge_domain_set_mac_age
{
  u32 client_index;
  u32 context;
  u32 bd_id;
  u8 mac_age;
};

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Gudimetla, Leela 
Sankar
Sent: 

Re: [vpp-dev] GET/SET support for each feature entity from VPP client

[John Lo (loj) via Lists.Fd.Io]

You can find L2 bridging related APIs from the file src/vnet/l2/l2.api.  The 
API to get bridge domain state is bridge_domain_dump and the response info 
provided is bridge_domain_details.  The API to change bridge domain attributes 
is bridge_flags.  The API to set bridge domain aging interval is 
bridge_domain_set_mac_age.

Following are the spec of these APIs from the file l2.api:

/** \brief L2 bridge domain request operational state details
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param bd_id - the bridge domain id desired or ~0 to request all bds
*/
define bridge_domain_dump
{
  u32 client_index;
  u32 context;
  u32 bd_id;
};

/** \brief L2 bridge domain sw interface operational state response
@param bd_id - the bridge domain id
@param sw_if_index - sw_if_index in the domain
@param shg - split horizon group for the interface
*/
typeonly manual_print manual_endian define bridge_domain_sw_if
{
  u32 context;
  u32 sw_if_index;
  u8 shg;
};

/** \brief L2 bridge domain operational state response
@param bd_id - the bridge domain id
@param flood - bcast/mcast flooding state on all interfaces in the bd
@param uu_flood - uknown unicast flooding state on all interfaces in the bd
@param forward - forwarding state on all interfaces in the bd
@param learn - learning state on all interfaces in the bd
@param arp_term - arp termination state on all interfaces in the bd
@param mac_age - mac aging time in min, 0 for disabled
@param bd_tag - optional textual tag for the bridge domain
@param n_sw_ifs - number of sw_if_index's in the domain
*/
manual_print manual_endian define bridge_domain_details
{
  u32 context;
  u32 bd_id;
  u8 flood;
  u8 uu_flood;
  u8 forward;
  u8 learn;
  u8 arp_term;
  u8 mac_age;
  u8 bd_tag[64];
  u32 bvi_sw_if_index;
  u32 n_sw_ifs;
  vl_api_bridge_domain_sw_if_t sw_if_details[n_sw_ifs];

/** \brief Set interface L2 flags (such as L2_LEARN, L2_FWD,
L2_FLOOD, L2_UU_FLOOD, or L2_ARP_TERM bits). This can be used
to disable one or more of the features represented by the
flag bits on an interface to override what is set as default
for all interfaces in the bridge domain
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param sw_if_index - interface
@param is_set - if non-zero, set the bits, else clear them
@param feature_bitmap - non-zero bits (as above) to set or clear
*/
define l2_flags
{
  u32 client_index;
  u32 context;
  u32 sw_if_index;
  u8 is_set;
  u32 feature_bitmap;
};

/** \brief Set interface L2 flags response
@param context - sender context, to match reply w/ request
@param retval - return code for the set l2 bits request
@param resulting_feature_bitmap - the internal l2 feature bitmap after the 
request is implemented
*/
define l2_flags_reply
{
  u32 context;
  i32 retval;
  u32 resulting_feature_bitmap;
};

/** \brief L2 bridge domain set mac age
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param bd_id - the bridge domain to create
@param mac_age - mac aging time in min, 0 for disabled
*/
autoreply define bridge_domain_set_mac_age
{
  u32 client_index;
  u32 context;
  u32 bd_id;
  u8 mac_age;
};

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Gudimetla, Leela 
Sankar
Sent: Thursday, June 14, 2018 3:32 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] GET/SET support for each feature entity from VPP client

Hello,

We are writing a client for VPP to configure it over the shared-memory 
interface (similar to what VAT does).
We are trying to find the GET for each entity so that we can handle ‘UPDATE’ of 
an existing configuration inside VPP.

For example, we have created a bridge-domain with id say ‘10’  by using 
“BRIDGE_DOMAIN_ADD_DEL”.
And if I want to modify some attribute of the same bridge-domain, I need to be 
able to get the entry from VPP so that I can modify the attribute and set it.

But I don’t see the specific GET/SET client calls from VPP.
Please let me know how to handle this.

Thanks,
Leela sankar


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

View/Reply Online (#9616): https://lists.fd.io/g/vpp-dev/message/9616
Mute This Topic: https://lists.fd.io/mt/22189926/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] Query on mac learning - VLAN

[John Lo (loj)]

On VPP, packets with VLANs does not imply it go into a separate bridge domains 
(BDs).  For your case, your sub-interfaces for VLAN 100 and 200 on your host 
interface should be put into separate bridge domains, e.g. you can use BD IDs 
100 and 200, and have the correct behavior.  As I described in an earlier email 
thread on this mailing list, all packets in a BD are expected to have their 
first VLAN tag with the same ID.  You currently have both sub-interfaces in the 
same BD so is not the correct setup. Your "expected output" example is not 
correct as the MACs on different sub-interfaces should be in different BDs thus 
different BD-Idx.

DBGvpp# set int l2 bridge ?
  set interface l2 bridge  set interface l2 bridge  
 [bvi] [shg]
DBGvpp# show bridge-domain ?
  show bridge-domain   show bridge-domain [bridge-domain-id 
[detail|int|arp|bd-tag]]

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Subramanya Bhatkal 
Nagesh
Sent: Monday, June 04, 2018 8:00 AM
To: vpp-dev@lists.fd.io
Cc: Padmavathy Ramakrishnan 
Subject: [vpp-dev] Query on mac learning - VLAN

Hi,

We are interested in understanding if we can learn mac address on a per VLAN 
basis in VPP.

If an interface 'X' is part of VLAN 100, and interface 'Y' is part of VLAN 200
A host 'H' with mac "00:10:94:00:00:33" is behind a switch, ports of which are 
part of both VLAN 100 and VLAN 200.
Mac should be learnt for host 'H' on both VLAN's 100 and 200.

Traffic shall be forwarded to host based on the VLAN.

In the current implementation, by default the mac is learnt on the last learnt 
interface

DBGvpp# show l2fib verbose
Mac-Address BD-Idx If-Idx BSN-ISN Age(min) static filter bvi 
Interface-Name
 08:00:27:aa:bb:211  4  0/1  -   -  - - 
GigabitEthernet0/8/0.100
L2FIB total/learned entries: 1/1  Last scan time: 0.e0sec  Learn limit: 
4194304

DBGvpp# l2fib add 08:00:27:aa:bb:21 100 GigabitEthernet0/9/0.100

DBGvpp# show l2fib verbose
Mac-Address BD-Idx If-Idx BSN-ISN Age(min) static filter bvi 
Interface-Name
 08:00:27:aa:bb:211  3  0/0  -   -  - - 
GigabitEthernet0/9/0.100
L2FIB total/learned entries: 1/0  Last scan time: 0.e0sec  Learn limit: 
4194304

Expected Table:
Table shall look something like below
Mac-Address BD-Idx If-Idx BSN-ISN Age(min) static filter bvi 
Interface-Name
 00:10:94:00:00:331  4  0/0  -   -  - - 
GigabitEthernet0/8/0.100
00:10:94:00:00:331  3  0/0  -   -  - - 
GigabitEthernet0/9/0.200
L2FIB total/learned entries: 2/2  Last scan time: 0.e0sec  Learn limit: 
4194304


Regards,
Subramanya
Radisys

Re: [vpp-dev] dot1ad tag

[John Lo (loj)]

With L2 bridging, all packets being forwarded in a bridge domain (BD) is 
expected to have the same 1st VLAN tag (or no VLAN tag).  This also applies to 
QinQ packets being forwarded in a service provider bridge where the top dot1ad 
tag is expected to have the same ID while the 2nd dot1q tag can be any value.  
Thus, putting dot1ad tags with different tag IDs on packets in the same BD is 
not a proper way to send packets in a provider bridge .

If packets are coming into a bridge domain with a VLAN tag, one would typically 
create a sub-interface match that of the VLAN tag and put the sub-interface in 
the BD.  If you really want to mix packets with different VLAN tags in the 
bridge domain while limit L2 forwarding to the same VLAN tags only, one can put 
the efp-filter on a sub-interface in the BD so that it will drop packet output 
on a sub-interface if a packet’s top tag, including after VTR output operation 
if one exist, does not match that of the sub-interface.  Again, this is not 
typical usage and an expensive way to do bridging because of the efp filtering 
and flooding in the BD to all sub-interfaces and rely on efp filter to drop 
packets with non-matching VLAN.  It would be much more efficient to use a 
separate BD for sub-interfaces with the same VLAN tag ID.

With Your VPLS setup, the MPLS tunnel connects user BDs and there isn’t really 
a provider bridge.  Thus it does not make sense to be to push dot1ad provider 
bridge tag as it is not used for forwarding anyway.  If you have users coming 
in with different VLAN tags into this BD but are supposed to bridge to each 
other irrespective of the VLAN tag IDs, typical set up will create a 
sub-interface for each VLAN tag ID, put these into the BD, and put a 
tag-rewrite operation of pop-1 on each sub-interface.  Then packets will have 
their VLAN tag poped on input and forwarded in the BD and sent over VPLS tunnel 
with no VLAN tags.  On output, the proper VLAN tag for each sub-interface will 
be pushed on each untagged packet before output.

I hope my explanation help with how bridging is supposed to work,
John

From: Mehran Memarnejad <memarnejad...@gmail.com>
Sent: Sunday, May 27, 2018 9:04 PM
To: John Lo (loj) <l...@cisco.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: dot1ad tag

Does the efp-filter work base on the second tag??
As far as I experiment, I realized that each subinterface recieves packets with 
tags equal to their subinterface number, e.g. GigabitEthernet1/0/0.200 will 
receieves packets with inner tags(802.1q) of 200, which is customer' vlan tag.
I think that I should not consider customer's 802.1q tag in PE.

On Monday, May 28, 2018, Mehran Memarnejad 
<memarnejad...@gmail.com<mailto:memarnejad...@gmail.com>> wrote:
Hi,
According to Wikipedia's page for 802.1ad:

"A tag stack creates a mechanism for Internet Service 
Providers<https://en.m.wikipedia.org/wiki/Internet_Service_Providers> to 
encapsulate customer single-tagged 802.1Q traffic with a single tag, the final 
frame being a QinQ frame. The outer tag is used to identify and segregate 
traffic from different customers; the inner tag is preserved from the original 
frame."

Here I want to add the second tag to segregate customer's traffic. In other 
words, I want to consider each customer in PEs as if it is a vlan.
So their traffic is isolated from each other, even though they are both 
connected to the same VPP's bridge.
I think that to segregate customer's traffic, we can use:
1- Different VPP bridges for each customer
2- Use second tag (802.1ad tag) to differentiate customers when they are 
connected to the same VPP bridge.

I don't know that is it a reasonable and common to connect two customers to the 
same VPP bridge??

But altogether, base on my understanding from Wikipedia's page on 802.1ad, in 
my scenario the traffics tagged 120 must not be recieved by the Interface with 
tag 200. Is that right??


On Monday, May 28, 2018, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> 
wrote:
What you observed is the expected behavior.  Adding such a check will add an 
overhead on l2-output with VTR configured and affect the packet forwarding 
efficiency.   I still don’t understand the purpose of pushing dot1ad tag on 
packet at customer interface input in your VPLS test setup.  It just make L2 
forwarding slower because of the VLAN tag push/pop overhead on each packet and 
does not serve any purpose, AFAIK.   -John

From: Mehran Memarnejad 
<memarnejad...@gmail.com<mailto:memarnejad...@gmail.com>>
Sent: Sunday, May 27, 2018 8:56 AM
To: John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: dot1ad tag

Hi,
The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
But I think there is another bug here.
First scenario:
PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
PE2 : 

Re: [vpp-dev] dot1ad tag

[John Lo (loj)]

Forgot to mention, if you are willing to accept the overhead of checking the 
right VLAN tag is present before VTR, there is an L2 output feature called 
efp-filter you can enable on an interface:
set interface l2 efp-filter GigabitEthernet0/8/0.200

This is typically done on a sub-interface so the efp-filter would also check 
the packet after VTR operation contain VLAN tag matching that of the output 
sub-interface.

Regards,
John

From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of John Lo (loj)
Sent: Sunday, May 27, 2018 8:30 PM
To: Mehran Memarnejad <memarnejad...@gmail.com>; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] dot1ad tag

What you observed is the expected behavior.  Adding such a check will add an 
overhead on l2-output with VTR configured and affect the packet forwarding 
efficiency.   I still don’t understand the purpose of pushing dot1ad tag on 
packet at customer interface input in your VPLS test setup.  It just make L2 
forwarding slower because of the VLAN tag push/pop overhead on each packet and 
does not serve any purpose, AFAIK.   -John

From: Mehran Memarnejad 
<memarnejad...@gmail.com<mailto:memarnejad...@gmail.com>>
Sent: Sunday, May 27, 2018 8:56 AM
To: John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: dot1ad tag

Hi,
The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
But I think there is another bug here.
First scenario:
PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200
Everything works perfect. the first PE adds the 802.1ad tag of 200 and the 
second PE removes it.
Second scenario:
PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 120
I expect the second PE does not pass the packet, since its tag(120) is 
different from the received tag(200), (Or in other words they are in different 
service provider's vlan. Am I right?)
But unfortunately, the second PE passes it.
I think that the source code is just considering the number of tags, not the 
number of tags and their value. I think this is the bug. Am I right??


On Sun, May 27, 2018 at 5:18 PM, Mehran Memarnejad 
<memarnejad...@gmail.com<mailto:memarnejad...@gmail.com>> wrote:
Hi,
The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
But I think there is another bug here.
First scenario:
PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200

On Sat, May 26, 2018 at 5:51 AM, John Lo (loj) 
<l...@cisco.com<mailto:l...@cisco.com>> wrote:
I just submitted a patch. Can you give it a try if this resolve the problem?  
-John
https://gerrit.fd.io/r/#/c/12750/

From: Mehran Memarnejad 
<memarnejad...@gmail.com<mailto:memarnejad...@gmail.com>>
Sent: Friday, May 25, 2018 1:24 PM

To: John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: dot1ad tag

Without tag-rewrite configuration, everything works well. But I want to 
activate QinQ feature, so I need to add service provider tag (sp-tag) by using 
dot1ad tag.

Any more idea to solve the problem??

On Friday, May 25, 2018, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> 
wrote:
The tag-rewrite (VTR) configuration looks right.  I looked at the 
l2_vtr_process() function in l2_vtr.h to check how it checks for errors. This 
is the error drop path:

  /* if not enough tags to pop then drop packet */
  if (PREDICT_FALSE ((vnet_buffer (b0)->l2.l2_len - 12) < config->pop_bytes))
{
  return 1;
}

My guess is that interface-rx-dpo-l2 node did not setup l2_len field in the 
vnet buffer properly before passing the packet to l2-input node. That’s why 
tag-rewrite  operation on l2-output node does not function properly.  If you 
remove the tag rewrite config from these GigabitEthernet5/0/0 customer ports on 
both PEs, I suppose it should start to work.  Any reason you want to have the 
additional dot1ad tag on the packets for forwarding in the BD and MPLS tunnel?

Regards,
John

From: Mehran Memarnejad 
<memarnejad...@gmail.com<mailto:memarnejad...@gmail.com>>
Sent: Friday, May 25, 2018 4:40 AM
To: John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: dot1ad tag

Sw_if_index 6 is the mpls tunnel0 and sw_if_index 3 is the GigabitEthernet5/0/0 
on which I have set interface tag-rewrite push dot1ad 12  (both of them are 
attached to bridge1)

Gigabitethernet5/0/0 is the PE's interface toward customer, meaning that I 
guess if it does not drop the packet, VPLS will work.

The packet is sent to the interfa

Re: [vpp-dev] dot1ad tag

[John Lo (loj)]

What you observed is the expected behavior.  Adding such a check will add an 
overhead on l2-output with VTR configured and affect the packet forwarding 
efficiency.   I still don’t understand the purpose of pushing dot1ad tag on 
packet at customer interface input in your VPLS test setup.  It just make L2 
forwarding slower because of the VLAN tag push/pop overhead on each packet and 
does not serve any purpose, AFAIK.   -John

From: Mehran Memarnejad <memarnejad...@gmail.com>
Sent: Sunday, May 27, 2018 8:56 AM
To: John Lo (loj) <l...@cisco.com>; vpp-dev@lists.fd.io
Subject: Re: dot1ad tag

Hi,
The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
But I think there is another bug here.
First scenario:
PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200
Everything works perfect. the first PE adds the 802.1ad tag of 200 and the 
second PE removes it.

Second scenario:
PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 120
I expect the second PE does not pass the packet, since its tag(120) is 
different from the received tag(200), (Or in other words they are in different 
service provider's vlan. Am I right?)
But unfortunately, the second PE passes it.
I think that the source code is just considering the number of tags, not the 
number of tags and their value. I think this is the bug. Am I right??


On Sun, May 27, 2018 at 5:18 PM, Mehran Memarnejad 
<memarnejad...@gmail.com<mailto:memarnejad...@gmail.com>> wrote:
Hi,
The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
But I think there is another bug here.
First scenario:
PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200

On Sat, May 26, 2018 at 5:51 AM, John Lo (loj) 
<l...@cisco.com<mailto:l...@cisco.com>> wrote:
I just submitted a patch. Can you give it a try if this resolve the problem?  
-John
https://gerrit.fd.io/r/#/c/12750/

From: Mehran Memarnejad 
<memarnejad...@gmail.com<mailto:memarnejad...@gmail.com>>
Sent: Friday, May 25, 2018 1:24 PM

To: John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: dot1ad tag

Without tag-rewrite configuration, everything works well. But I want to 
activate QinQ feature, so I need to add service provider tag (sp-tag) by using 
dot1ad tag.

Any more idea to solve the problem??

On Friday, May 25, 2018, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> 
wrote:
The tag-rewrite (VTR) configuration looks right.  I looked at the 
l2_vtr_process() function in l2_vtr.h to check how it checks for errors. This 
is the error drop path:

  /* if not enough tags to pop then drop packet */
  if (PREDICT_FALSE ((vnet_buffer (b0)->l2.l2_len - 12) < config->pop_bytes))
{
  return 1;
}

My guess is that interface-rx-dpo-l2 node did not setup l2_len field in the 
vnet buffer properly before passing the packet to l2-input node. That’s why 
tag-rewrite  operation on l2-output node does not function properly.  If you 
remove the tag rewrite config from these GigabitEthernet5/0/0 customer ports on 
both PEs, I suppose it should start to work.  Any reason you want to have the 
additional dot1ad tag on the packets for forwarding in the BD and MPLS tunnel?

Regards,
John

From: Mehran Memarnejad 
<memarnejad...@gmail.com<mailto:memarnejad...@gmail.com>>
Sent: Friday, May 25, 2018 4:40 AM
To: John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: dot1ad tag

Sw_if_index 6 is the mpls tunnel0 and sw_if_index 3 is the GigabitEthernet5/0/0 
on which I have set interface tag-rewrite push dot1ad 12  (both of them are 
attached to bridge1)

Gigabitethernet5/0/0 is the PE's interface toward customer, meaning that I 
guess if it does not drop the packet, VPLS will work.

The packet is sent to the interface attached to bridge (gigabitethernet5/0/0) 
by mupls tunnel0.
But then the packet drops.


On Friday, May 25, 2018, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> 
wrote:
Hi Mehran,

The packet trace shows drop is cause by l2-output node when the packet is sent 
on the interface with sw_if_index 3 where the output tag-rewrite operation is 
not expecting packet with a dot1ad tag of 12.  What is the interface with 
sw_if_index of 3 on that PE?  Is this the same interface where you have 
tag-rewrite of “push dot1ad 12” applied?

Can you provide the output of “show bridge 1 detail” (assuming bridge domain ID 
of 1 is used for bd_index 1, otherwise, substitute with the ID used) on that 
PE, please?  The output will show all interf

Re: [vpp-dev] dot1ad tag

[John Lo (loj)]

I just submitted a patch. Can you give it a try if this resolve the problem?  
-John
https://gerrit.fd.io/r/#/c/12750/

From: Mehran Memarnejad <memarnejad...@gmail.com>
Sent: Friday, May 25, 2018 1:24 PM
To: John Lo (loj) <l...@cisco.com>; vpp-dev@lists.fd.io
Subject: Re: dot1ad tag

Without tag-rewrite configuration, everything works well. But I want to 
activate QinQ feature, so I need to add service provider tag (sp-tag) by using 
dot1ad tag.

Any more idea to solve the problem??

On Friday, May 25, 2018, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> 
wrote:
The tag-rewrite (VTR) configuration looks right.  I looked at the 
l2_vtr_process() function in l2_vtr.h to check how it checks for errors. This 
is the error drop path:

  /* if not enough tags to pop then drop packet */
  if (PREDICT_FALSE ((vnet_buffer (b0)->l2.l2_len - 12) < config->pop_bytes))
{
  return 1;
}

My guess is that interface-rx-dpo-l2 node did not setup l2_len field in the 
vnet buffer properly before passing the packet to l2-input node. That’s why 
tag-rewrite  operation on l2-output node does not function properly.  If you 
remove the tag rewrite config from these GigabitEthernet5/0/0 customer ports on 
both PEs, I suppose it should start to work.  Any reason you want to have the 
additional dot1ad tag on the packets for forwarding in the BD and MPLS tunnel?

Regards,
John

From: Mehran Memarnejad 
<memarnejad...@gmail.com<mailto:memarnejad...@gmail.com>>
Sent: Friday, May 25, 2018 4:40 AM
To: John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: dot1ad tag

Sw_if_index 6 is the mpls tunnel0 and sw_if_index 3 is the GigabitEthernet5/0/0 
on which I have set interface tag-rewrite push dot1ad 12  (both of them are 
attached to bridge1)

Gigabitethernet5/0/0 is the PE's interface toward customer, meaning that I 
guess if it does not drop the packet, VPLS will work.

The packet is sent to the interface attached to bridge (gigabitethernet5/0/0) 
by mupls tunnel0.
But then the packet drops.


On Friday, May 25, 2018, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> 
wrote:
Hi Mehran,

The packet trace shows drop is cause by l2-output node when the packet is sent 
on the interface with sw_if_index 3 where the output tag-rewrite operation is 
not expecting packet with a dot1ad tag of 12.  What is the interface with 
sw_if_index of 3 on that PE?  Is this the same interface where you have 
tag-rewrite of “push dot1ad 12” applied?

Can you provide the output of “show bridge 1 detail” (assuming bridge domain ID 
of 1 is used for bd_index 1, otherwise, substitute with the ID used) on that 
PE, please?  The output will show all interfaces in the bridge domain with 
sw_if_index and tag-rewrite operation configured on each interface.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Mehran Memarnejad
Sent: Thursday, May 24, 2018 8:12 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] dot1ad tag

Hi,
I have configured VPLS in VPP somehow like this 
link<https://lists.fd.io/g/vpp-dev/message/9112?p=,,,20,0,0,0::Created,,vpls,20,2,0,18122864>.

In addition to the above configurations, I want to add a second vlan tag i.e. 
802.1ad (QinQ).
To achieve this, I entered following command in both PEs:
  "Set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 12"

Tracking what's going on, I found that the first PE adds the QinQ tag (12), but 
the second PE will not remove this tag and afterward it goes to error node with 
this message:
"l2-output: L2 output tag rewrite drops"

Here is what show trace shows in the second PE:

Packet 1

00:31:10:348251: dpdk-input
  TenGigabitEthernet4/0/0 rx queue 0
  buffer 0x21b6f: current data 14, length 114, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 
l3-hdr-offset 14
  PKT MBUF: port 1, nb_segs 1, pkt_len 128
buf_len 2176, data_len 128, ol_flags 0x180, data_off 128, phys_addr 
0x4ce6dc40
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_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet

  MPLS: 00:25:90:97:fa:10 -> a0:36:9f:23:aa:78
  label 60 exp 0, s 0, ttl 63
00:31:10:348260: mpls-input
  MPLS: next mpls-lookup[1]  label 60 ttl 63 exp 0
00:31:10:348265: mpls-lookup
  MPLS: next [7], lookup fib index 0, LB index 23 hash 0 label 60 eos 0
00:31:10:348268: lookup-mpls-dst
 fib-index:0 hdr:[33:64:0:eos] load-balance:21
00:31:10:348270

Re: [vpp-dev] dot1ad tag

[John Lo (loj)]

The tag-rewrite (VTR) configuration looks right.  I looked at the 
l2_vtr_process() function in l2_vtr.h to check how it checks for errors. This 
is the error drop path:

  /* if not enough tags to pop then drop packet */
  if (PREDICT_FALSE ((vnet_buffer (b0)->l2.l2_len - 12) < config->pop_bytes))
{
  return 1;
}

My guess is that interface-rx-dpo-l2 node did not setup l2_len field in the 
vnet buffer properly before passing the packet to l2-input node. That’s why 
tag-rewrite  operation on l2-output node does not function properly.  If you 
remove the tag rewrite config from these GigabitEthernet5/0/0 customer ports on 
both PEs, I suppose it should start to work.  Any reason you want to have the 
additional dot1ad tag on the packets for forwarding in the BD and MPLS tunnel?

Regards,
John

From: Mehran Memarnejad <memarnejad...@gmail.com>
Sent: Friday, May 25, 2018 4:40 AM
To: John Lo (loj) <l...@cisco.com>; vpp-dev@lists.fd.io
Subject: Re: dot1ad tag

Sw_if_index 6 is the mpls tunnel0 and sw_if_index 3 is the GigabitEthernet5/0/0 
on which I have set interface tag-rewrite push dot1ad 12  (both of them are 
attached to bridge1)

Gigabitethernet5/0/0 is the PE's interface toward customer, meaning that I 
guess if it does not drop the packet, VPLS will work.

The packet is sent to the interface attached to bridge (gigabitethernet5/0/0) 
by mupls tunnel0.
But then the packet drops.


On Friday, May 25, 2018, John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>> 
wrote:
Hi Mehran,

The packet trace shows drop is cause by l2-output node when the packet is sent 
on the interface with sw_if_index 3 where the output tag-rewrite operation is 
not expecting packet with a dot1ad tag of 12.  What is the interface with 
sw_if_index of 3 on that PE?  Is this the same interface where you have 
tag-rewrite of “push dot1ad 12” applied?

Can you provide the output of “show bridge 1 detail” (assuming bridge domain ID 
of 1 is used for bd_index 1, otherwise, substitute with the ID used) on that 
PE, please?  The output will show all interfaces in the bridge domain with 
sw_if_index and tag-rewrite operation configured on each interface.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Mehran Memarnejad
Sent: Thursday, May 24, 2018 8:12 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] dot1ad tag

Hi,
I have configured VPLS in VPP somehow like this 
link<https://lists.fd.io/g/vpp-dev/message/9112?p=,,,20,0,0,0::Created,,vpls,20,2,0,18122864>.

In addition to the above configurations, I want to add a second vlan tag i.e. 
802.1ad (QinQ).
To achieve this, I entered following command in both PEs:
  "Set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 12"

Tracking what's going on, I found that the first PE adds the QinQ tag (12), but 
the second PE will not remove this tag and afterward it goes to error node with 
this message:
"l2-output: L2 output tag rewrite drops"

Here is what show trace shows in the second PE:

Packet 1

00:31:10:348251: dpdk-input
  TenGigabitEthernet4/0/0 rx queue 0
  buffer 0x21b6f: current data 14, length 114, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 
l3-hdr-offset 14
  PKT MBUF: port 1, nb_segs 1, pkt_len 128
buf_len 2176, data_len 128, ol_flags 0x180, data_off 128, phys_addr 
0x4ce6dc40
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_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet

  MPLS: 00:25:90:97:fa:10 -> a0:36:9f:23:aa:78
  label 60 exp 0, s 0, ttl 63
00:31:10:348260: mpls-input
  MPLS: next mpls-lookup[1]  label 60 ttl 63 exp 0
00:31:10:348265: mpls-lookup
  MPLS: next [7], lookup fib index 0, LB index 23 hash 0 label 60 eos 0
00:31:10:348268: lookup-mpls-dst
 fib-index:0 hdr:[33:64:0:eos] load-balance:21
00:31:10:348270: interface-rx-dpo-l2
 sw_if_index:6

00:31:10:348272: l2-input
  l2-input: sw_if_index 6 dst 30:85:a9:f2:23:12 src 3c:07:71:5f:2d:f5
00:31:10:348275: l2-learn
  l2-learn: sw_if_index 6 dst 30:85:a9:f2:23:12 src 3c:07:71:5f:2d:f5 bd_index 1
00:31:10:348277: l2-fwd
  l2-fwd:   sw_if_index 6 dst 30:85:a9:f2:23:12 src 3c:07:71:5f:2d:f5 bd_index 1

00:31:10:348280: l2-output
  l2-output: sw_if_index 3 dst 30:85:a9:f2:23:12 src 3c:07:71:5f:2d:f5 data 88 
a8 00 0c 81 00 00 06 08 00 45 00

00:31:10:348282: error-drop
  l2-output: L2 output tag rewrite drops

Colors: Packet reception , MPLS tag handling, L2 handling, Error


If you notice red underlined trace, 802.1ad tag 12 (in hex 0C) and 802.

Re: [vpp-dev] dot1ad tag

[John Lo (loj)]

Hi Mehran,

The packet trace shows drop is cause by l2-output node when the packet is sent 
on the interface with sw_if_index 3 where the output tag-rewrite operation is 
not expecting packet with a dot1ad tag of 12.  What is the interface with 
sw_if_index of 3 on that PE?  Is this the same interface where you have 
tag-rewrite of “push dot1ad 12” applied?

Can you provide the output of “show bridge 1 detail” (assuming bridge domain ID 
of 1 is used for bd_index 1, otherwise, substitute with the ID used) on that 
PE, please?  The output will show all interfaces in the bridge domain with 
sw_if_index and tag-rewrite operation configured on each interface.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Mehran Memarnejad
Sent: Thursday, May 24, 2018 8:12 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] dot1ad tag

Hi,
I have configured VPLS in VPP somehow like this 
link.

In addition to the above configurations, I want to add a second vlan tag i.e. 
802.1ad (QinQ).
To achieve this, I entered following command in both PEs:
  "Set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 12"

Tracking what's going on, I found that the first PE adds the QinQ tag (12), but 
the second PE will not remove this tag and afterward it goes to error node with 
this message:
"l2-output: L2 output tag rewrite drops"

Here is what show trace shows in the second PE:

Packet 1

00:31:10:348251: dpdk-input
  TenGigabitEthernet4/0/0 rx queue 0
  buffer 0x21b6f: current data 14, length 114, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 
l3-hdr-offset 14
  PKT MBUF: port 1, nb_segs 1, pkt_len 128
buf_len 2176, data_len 128, ol_flags 0x180, data_off 128, phys_addr 
0x4ce6dc40
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_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet

  MPLS: 00:25:90:97:fa:10 -> a0:36:9f:23:aa:78
  label 60 exp 0, s 0, ttl 63
00:31:10:348260: mpls-input
  MPLS: next mpls-lookup[1]  label 60 ttl 63 exp 0
00:31:10:348265: mpls-lookup
  MPLS: next [7], lookup fib index 0, LB index 23 hash 0 label 60 eos 0
00:31:10:348268: lookup-mpls-dst
 fib-index:0 hdr:[33:64:0:eos] load-balance:21
00:31:10:348270: interface-rx-dpo-l2
 sw_if_index:6

00:31:10:348272: l2-input
  l2-input: sw_if_index 6 dst 30:85:a9:f2:23:12 src 3c:07:71:5f:2d:f5
00:31:10:348275: l2-learn
  l2-learn: sw_if_index 6 dst 30:85:a9:f2:23:12 src 3c:07:71:5f:2d:f5 bd_index 1
00:31:10:348277: l2-fwd
  l2-fwd:   sw_if_index 6 dst 30:85:a9:f2:23:12 src 3c:07:71:5f:2d:f5 bd_index 1

00:31:10:348280: l2-output
  l2-output: sw_if_index 3 dst 30:85:a9:f2:23:12 src 3c:07:71:5f:2d:f5 data 88 
a8 00 0c 81 00 00 06 08 00 45 00

00:31:10:348282: error-drop
  l2-output: L2 output tag rewrite drops

Colors: Packet reception , MPLS tag handling, L2 handling, Error


If you notice red underlined trace, 802.1ad tag 12 (in hex 0C) and 802.1q tag 6 
(in hex 06) has been added to packet.


I inspected the code in /src/vnet/l2/l2_vtr.h   l2_vtr_process() function  
and /src/vnet/l2/l2_input.h   vnet_update_l2_len() function,   but I couldn't 
find any problem.


MY QUESTION: Is it a bug in code that the 802.1ad tag is not removed?? Or 
should I have entered more commands?

Thanks in advance

Re: [vpp-dev] L2fib entry not updating for BVI

[John Lo (loj)]

The MAC for a loopback is added to the L2FIB only when the loopback interface 
is added to a BD as BVI.  If loopback MAC of a BVI is changed subsequently, 
there is no mechanism to automatically update its MAC in the L2FIB.   -John

From: vpp-dev@lists.fd.io  On Behalf Of Gudimetla, Leela 
Sankar
Sent: Thursday, May 17, 2018 9:38 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] L2fib entry not updating for BVI

Hi,

I have created a loopback interface (with MAC address and instance ) and added 
it to a bridge as BVI. I see the interface MAC address is getting added to 
l2fib since it is a BVI.
But when I change the interface MAC address (loopback’s), I don’t see the 
corresponding l2fib entry is not getting updated whereas the interface MAC is 
getting updated.
Is the l2fib entry not-getting-updated for BVI upon changing the interface-MAC, 
expected?
If yes, could you explain why?

Thanks,
Leela sankar

Re: [vpp-dev] problem in xcrw testing

[John Lo (loj)]

Hi Xyxue,

I have not used xcrw before to know how it is supposed to work, to cross 
connect a layer 2 interface to a layer 3 stack.  My suggestion was based on the 
error shown by the packet trace you provided, that l2-output node found GRE 
tunnel not to be set to L2 mode.  If a GRE tunnel is created in TEB mode, it is 
an L2 interface and thus can be put into L2 mode to work with L2 xconnect.  If 
you have a “normal” L2 xconnect config like the following I would expect it to 
work:

set interface l2 xconnect host-eth5 gre0
set interface l2 xconnect gre0 host-eth5

BTW, in older version of VPP, GRE tunnel in TEB mode has the name pattern 
teb-greN while with later version just greN, where N is the tunnel instance 
number.

I don’t know what are your intended usage or expectation of xcrw is and hoping 
someone with proper knowledge of xcrw can help.

Regards,
John


From: 薛欣颖 <xy...@fiberhome.com>
Sent: Wednesday, May 16, 2018 8:07 AM
To: John Lo (loj) <l...@cisco.com>; Neale Ranns (nranns) <nra...@cisco.com>; 
vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] problem in xcrw testing

Hi John，

I changed my configuration to that 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 l3 host-eth1
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 gre-output  rw 
4558fd2fa5720b0101020b0101016558
create bridge-domain 1
set interface l2 bridge teb-gre0 1
set interface l2 bridge xcrw0 1

There is an assert :
Program received signal SIGSEGV, Segmentation fault.
0x76f30e72 in gre_interface_tx_inline (vm=0x7791d1a0 
, node=0x7fffb6c87600, frame=0x7fffb676fbc0) at 
/home/vpp/build-data/../src/vnet/gre/gre.c:366
366   hw = vnet_get_hw_interface (vnm, sw->hw_if_index);
(gdb) bt
#0  0x76f30e72 in gre_interface_tx_inline (vm=0x7791d1a0 
, node=0x7fffb6c87600, frame=0x7fffb676fbc0) at 
/home/vpp/build-data/../src/vnet/gre/gre.c:366
#1  0x76f3126b in gre_interface_tx (vm=0x7791d1a0 
, node=0x7fffb6c87600, frame=0x7fffb676fbc0) at 
/home/vpp/build-data/../src/vnet/gre/gre.c:412
#2  0x7769b2aa in dispatch_node (vm=0x7791d1a0 , 
node=0x7fffb6c87600, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING,
frame=0x7fffb676fbc0, last_time_stamp=35926090675277) at 
/home/vpp/build-data/../src/vlib/main.c:1010
#3  0x7769b88d in dispatch_pending_node (vm=0x7791d1a0 
, pending_frame_index=4, last_time_stamp=35926090675277)
at /home/vpp/build-data/../src/vlib/main.c:1160
#4  0x7769daa4 in vlib_main_or_worker_loop (vm=0x7791d1a0 
, is_main=1) at /home/vpp/build-data/../src/vlib/main.c:1630
#5  0x7769db53 in vlib_main_loop (vm=0x7791d1a0 ) 
at /home/vpp/build-data/../src/vlib/main.c:1649
#6  0x7769e2ad in vlib_main (vm=0x7791d1a0 , 
input=0x7fffb5704fb0) at /home/vpp/build-data/../src/vlib/main.c:1806
#7  0x776e0d64 in thread0 (arg=140737346916768) at 
/home/vpp/build-data/../src/vlib/unix/main.c:617
#8  0x76927560 in clib_calljmp () at 
/home/vpp/build-data/../src/vppinfra/longjmp.S:128
#9  0x7fffd350 in ?? ()
#10 0x776e1223 in vlib_unix_main (argc=31, argv=0x653800) at 
/home/vpp/build-data/../src/vlib/unix/main.c:682
#11 0x00406202 in main (argc=31, argv=0x653800) at 
/home/vpp/build-data/../src/vpp/vnet/main.c:241
(gdb)

Is there any examples about xcrw ? Is there any configuration I missed？

Thanks，
Xyxue
From: John Lo (loj)<mailto:l...@cisco.com>
Date: 2018-05-16 16:02
To: 薛欣颖<mailto:xy...@fiberhome.com>; Neale Ranns 
(nranns)<mailto:nra...@cisco.com>; vpp-dev<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] problem in xcrw testing
Hi Xyxue,

The L2 cross connect CLI via either xconnect or xcrw would put the source/input 
interface into L2 mode and setup an one-directional cross connect to the 
specified peer/output interface.  The expectation is there should be a 
xcrw/cross connect CLI for the other direction specifying the other interface 
as source/input so it will also be in L2 mode.

Hope this help, with regards,
John

From: 薛欣颖 <xy...@fiberhome.com<mailto:xy...@fiberhome.com>>
Sent: Wednesday, May 16, 2018 3:46 AM
To: John Lo (loj) <l...@cisco.com<mailto:l...@cisco.com>>; Neale Ranns (nranns) 
<nra...@cisco.com<mailto:nra...@cisco.com>>; vpp-dev 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: Re: Re: [vpp-dev] problem in xcrw testing

Hi John,

The description of 'set interface l2 xcrw' in docs is that 'Add or delete a 
Layer 2 to Layer 3 rewrite cross-connect'.
After put the gre tunnel in l2 mode , there is a 'Layer 2 to Layer 2 rewrite 
cross-connect'. Is there anything wrong in my comprehension?



Thanks,
Xyxue


From: Joh

Re: [vpp-dev] problem in xcrw testing

[John Lo (loj)]

Hi Xyxue,

The L2 cross connect CLI via either xconnect or xcrw would put the source/input 
interface into L2 mode and setup an one-directional cross connect to the 
specified peer/output interface.  The expectation is there should be a 
xcrw/cross connect CLI for the other direction specifying the other interface 
as source/input so it will also be in L2 mode.

Hope this help, with regards,
John

From: 薛欣颖 <xy...@fiberhome.com>
Sent: Wednesday, May 16, 2018 3:46 AM
To: John Lo (loj) <l...@cisco.com>; Neale Ranns (nranns) <nra...@cisco.com>; 
vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] problem in xcrw testing

Hi John,

The description of 'set interface l2 xcrw' in docs is that 'Add or delete a 
Layer 2 to Layer 3 rewrite cross-connect'.
After put the gre tunnel in l2 mode , there is a 'Layer 2 to Layer 2 rewrite 
cross-connect'. Is there anything wrong in my comprehension?


Thanks,
Xyxue
________

From: John Lo (loj)<mailto:l...@cisco.com>
Date: 2018-05-15 20:32
To: 薛欣颖<mailto:xy...@fiberhome.com>; Neale Ranns 
(nranns)<mailto:nra...@cisco.com>; vpp-dev<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] problem in xcrw testing
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<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of xyxue
Sent: Tuesday, May 15, 2018 8:10 AM
To: Neale Ranns (nranns) <nra...@cisco.com<mailto:nra...@cisco.com>>; vpp-dev 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
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<mailto:nra...@cisco.com>
Date: 2018-05-15 15:58
To: 薛欣颖<mailto:xy...@fiberhome.com>; 
vpp-dev@lists.fd.io<mailto: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: <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> on behalf of xyxue 
<xy...@fiberhome.com<mailto:xy...@fiberhome.com>>
Date: Tuesday, 15 May 2018 at 08:50
To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
<vpp-dev@lists.fd.io<mailto: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-ou

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 <j...@netgate.com>
Sent: Friday, May 11, 2018 12:09 PM
To: John Lo (loj) <l...@cisco.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Static ARP Flag Question

On Thu, May 10, 2018 at 7:28 PM, John Lo (loj) 
<l...@cisco.com<mailto:l...@cisco.com>> 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

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] Static ARP Flag Question

[John Lo (loj)]

Hi Jon,

This is not the right behavior.  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;

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?

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Jon Loeliger
Sent: Wednesday, May 09, 2018 2:04 PM
To: vpp-dev 
Subject: [vpp-dev] Static ARP Flag Question

VPP-ers,

Is this expected behavior for the Flags here?

Thanks,
jdl


vpp# set int ip address TenGigabitEthernet6/0/0 
10.10.20.1/24
vpp# set interface state TenGigabitEthernet6/0/0 up
vpp# set ip arp TenGigabitEthernet6/0/0 10.10.20.100 08:00:27:41:a7:56 static

vpp# show ip arp
Time   IP4   Flags  Ethernet  Interface
 53.7857  10.10.20.100 S08:00:27:41:a7:56 TenGigabitEthernet6/0/0

vpp# set ip arp del TenGigabitEthernet6/0/0 10.10.20.100 08:00:27:41:a7:56 
static
vpp# show ip arp
vpp# set ip arp TenGigabitEthernet6/0/0 10.10.20.100 08:00:27:41:a7:56

vpp# show ip arp
Time   IP4   Flags  Ethernet  Interface
 90.9054  10.10.20.100SD08:00:27:41:a7:56 TenGigabitEthernet6/0/0

Re: [vpp-dev] SPAN questions

[John Lo (loj)]

Hi Matt,

SPAN without L2 is putting the packet mirror on an interface (only main 
interface) input and/or output irrespectively of it in L2 or L3 mode.

SPAN with L2 means to perform packet mirror on L2 input and/or output on an 
interface or sub-interface which is in a bridge domain or cross connect.  One 
thing to note with L2 SPAN is that the output/destination interface used for 
mirrored packet must also be in L2 mode. Using L2 interface for output allows 
user to configure VLAN rewrite operation on that interface on mirrored packets.

If SPAN is configure on an interface with both L2 and without L2, you will get 
packet mirrored twice if the interface is set to L2 bridging or xconnect. 
Packet is replicated once on input at the interface and replicated again on 
L2-input to a BD/xconnect.  If interface is in L3 mode, L2 SPAN will not have 
any effect.

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Matthew Smith
Sent: Thursday, April 26, 2018 11:05 AM
To: vpp-dev 
Subject: [vpp-dev] SPAN questions


Is the L2 flag when adding a SPAN mirror intended to indicate that the source 
port is a member of a bridge domain?

I noticed that SPAN can be configured on a port with the L2 flag set and also 
with it unset. So configurations for L2 and ! L2 can both exist at the same 
time. E.g.:

vpp# set interface span TenGigabitEthernet2/0/1 destination 
TenGigabitEthernet2/0/0 both vpp# set interface span TenGigabitEthernet2/0/1 l2 
destination TenGigabitEthernet2/0/0 both vpp# show interface span
Source   Destination   Device   L2
TenGigabitEthernet2/ TenGigabitEthernet2/ (  both) (  both)

Are there cases where this would be necessary? Or do the graph nodes for only 
one of {L2, device} get used for a source interface at any given time?

Thanks,
-Matt





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

You receive all messages sent to this group.

View/Reply Online (#9081): https://lists.fd.io/g/vpp-dev/message/9081
View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/18098046
Mute This Topic: https://lists.fd.io/mt/18098046/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
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VLAN to VLAN

[John Lo (loj)]

One more comment - unless there are more VLAN 1 and VLAN 2 sub-interfaces you 
need to put into BDs 1 and 2, then you may just configure IP addresses on the 
sub-interfaces to route directly, as suggested by Andrew. It would be a lot 
more efficient than going through two BDs and route via BVIs.  -John

-Original Message-
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of John Lo (loj)
Sent: Thursday, April 19, 2018 4:48 PM
To: carlito nueno <carlitonu...@gmail.com>; Andrew Yourtchenko 
<ayour...@gmail.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VLAN to VLAN

The config looks correct and should work, assuming the following:
1. The devices connected to GigabitEthernet0/14/0.2 have IP addresses in the 
192.168.2.1/24 subnet with default gateway set to that of the BVI IP address of 
192.168.2.1.
2. The devices connected to GigabitEthernet0/14/0.3 have IP addresses in the 
192.168.3.1/24 subnet with default gateway set to that of the BVI IP address of 
192.168.3.1.

One improvement is to put the BVI interfaces into their own VRF by setting 
loop0 and loop1 into a specific ip table to not use the global routing table.  
For example, set the following before assigning IP address to loop0 and loop1:
   set int ip table loop0 4
   set int ip table loop1 4
This will make the routing between BD-VLANs 2 and 3 private and more secure.

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of carlito nueno
Sent: Thursday, April 19, 2018 4:15 PM
To: Andrew Yourtchenko <ayour...@gmail.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VLAN to VLAN

My current VLAN config:

loopback create
set int l2 bridge loop1 2 bvi
set int ip address loop1 192.168.2.1/24
set int state loop1 up

create sub GigabitEthernet0/14/0 2
set int l2 bridge GigabitEthernet0/14/0.2 2 set int l2 tag-rewrite 
GigabitEthernet0/14/0.2 pop 1 set int state GigabitEthernet0/14/0.2 up


loopback create
set int l2 bridge loop2 3 bvi
set int ip address loop2 192.168.3.1/24
set int state loop2 up

create sub GigabitEthernet0/14/0 3
set int l2 bridge GigabitEthernet0/14/0.3 3 set int l2 tag-rewrite 
GigabitEthernet0/14/0.3 pop 1 set int state GigabitEthernet0/14/0.3 up


So this should route traffic between VLAN 2 and VLAN 3, correct?

Thanks

On Thu, Apr 19, 2018 at 12:52 PM, Andrew Yourtchenko <ayour...@gmail.com> wrote:
>
> hi Carlito,
>
> you can configure subinterfaces with tags and assign the ip addresses 
> so the VPP does routing and then either use vnet ACLs or acl plugin to 
> restrict the traffic.
>
> —a
>
> On 19 Apr 2018, at 21:07, Dave Barach <dbar...@cisco.com> wrote:
>
> Begin forwarded message:
>
> From: Carlito Nueno <carlitonu...@gmail.com>
> Date: April 19, 2018 at 9:03:51 AM HST
> To: dbar...@cisco.com
> Subject: VLAN to VLAN
>
> Hi Dave,
>
> How can I enable VLAN to VLAN communication? I want to have devices on 
> one VLAN talk to devices on another VLAN, if possible constrain the 
> devices by MAC or IP address.
>
> For example, only device with MAC (aa:aa:bb:80:90) or IP address
> (192.168.2.20) on VLAN 100 can talk to devices on VLAN 200 
> (192.168.3.0/24).
>
> Thanks
>
> 







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

You receive all messages sent to this group.

View/Reply Online (#9003): https://lists.fd.io/g/vpp-dev/message/9003
View All Messages In Topic (5): https://lists.fd.io/g/vpp-dev/topic/17639114
Mute This Topic: https://lists.fd.io/mt/17639114/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
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VLAN to VLAN

[John Lo (loj)]

The config looks correct and should work, assuming the following:
1. The devices connected to GigabitEthernet0/14/0.2 have IP addresses in the 
192.168.2.1/24 subnet with default gateway set to that of the BVI IP address of 
192.168.2.1.
2. The devices connected to GigabitEthernet0/14/0.3 have IP addresses in the 
192.168.3.1/24 subnet with default gateway set to that of the BVI IP address of 
192.168.3.1.

One improvement is to put the BVI interfaces into their own VRF by setting 
loop0 and loop1 into a specific ip table to not use the global routing table.  
For example, set the following before assigning IP address to loop0 and loop1:
   set int ip table loop0 4
   set int ip table loop1 4
This will make the routing between BD-VLANs 2 and 3 private and more secure.

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of carlito nueno
Sent: Thursday, April 19, 2018 4:15 PM
To: Andrew Yourtchenko 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VLAN to VLAN

My current VLAN config:

loopback create
set int l2 bridge loop1 2 bvi
set int ip address loop1 192.168.2.1/24
set int state loop1 up

create sub GigabitEthernet0/14/0 2
set int l2 bridge GigabitEthernet0/14/0.2 2
set int l2 tag-rewrite GigabitEthernet0/14/0.2 pop 1
set int state GigabitEthernet0/14/0.2 up


loopback create
set int l2 bridge loop2 3 bvi
set int ip address loop2 192.168.3.1/24
set int state loop2 up

create sub GigabitEthernet0/14/0 3
set int l2 bridge GigabitEthernet0/14/0.3 3
set int l2 tag-rewrite GigabitEthernet0/14/0.3 pop 1
set int state GigabitEthernet0/14/0.3 up


So this should route traffic between VLAN 2 and VLAN 3, correct?

Thanks

On Thu, Apr 19, 2018 at 12:52 PM, Andrew Yourtchenko  wrote:
>
> hi Carlito,
>
> you can configure subinterfaces with tags and assign the ip addresses so the
> VPP does routing and then either use vnet ACLs or acl plugin to restrict the
> traffic.
>
> —a
>
> On 19 Apr 2018, at 21:07, Dave Barach  wrote:
>
> Begin forwarded message:
>
> From: Carlito Nueno 
> Date: April 19, 2018 at 9:03:51 AM HST
> To: dbar...@cisco.com
> Subject: VLAN to VLAN
>
> Hi Dave,
>
> How can I enable VLAN to VLAN communication? I want to have devices on
> one VLAN talk to devices on another VLAN, if possible constrain the
> devices by MAC or IP address.
>
> For example, only device with MAC (aa:aa:bb:80:90) or IP address
> (192.168.2.20) on VLAN 100 can talk to devices on VLAN 200
> (192.168.3.0/24).
>
> Thanks
>
> 




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

You receive all messages sent to this group.

View/Reply Online (#9002): https://lists.fd.io/g/vpp-dev/message/9002
View All Messages In Topic (4): https://lists.fd.io/g/vpp-dev/topic/17639114
Mute This Topic: https://lists.fd.io/mt/17639114/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
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vec_new() vs. vec_validate()

[John Lo (loj)]

As noted by Billy, vec_validate would call vec_resize and then call memset() to 
clear unused area to 0.  This call is required to make sure, if vector is 
expanded by vec_resize without having to allocate new memory, any unused memory 
with stale content is cleared.

For new vectors, calling vect_new should be faster as vec_resize would call 
vec_reszie_allocate_memory which would allocated memory and call memset() to 
clear it.  Thus, calling vec_validate() to create a new vector would end up 
calling memset() twice to clear allocated vector memory.

Regards,
John
From: vpp-dev@lists.fd.io  On Behalf Of Chris Luke
Sent: Thursday, April 12, 2018 4:01 PM
To: Bly, Mike ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vec_new() vs. vec_validate()

Vec_new always allocates storage, vec_validate ensures that an existing 
allocation is at least a certain size, or create a new one if the pointer is 
NULL. The latter is typically used when the storage will be used as an array 
and you want to make sure it's large enough to store element N.

See 
https://docs.fd.io/vpp/18.07/db/d65/vec_8h.html#a003a343880e8218b2398b72ae16c5163
 and 
https://docs.fd.io/vpp/18.07/db/d65/vec_8h.html#a3b2e25abfbea7eea806d37920ba769e3.

The other subtle difference is that you need to tell vec_new the type of the 
elements in the array (so it knows the size) whereas vec_validate can glean 
that from the type of the vector (possibly NULL) you pass in.

Chris.

From: vpp-dev@lists.fd.io 
> On Behalf Of Bly, Mike
Sent: Thursday, April 12, 2018 15:30
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vec_new() vs. vec_validate()

Hello,

After some digging, near as I can tell, for a new pointer to a new entity, it 
would seem that vec_new() is pretty much providing the same results as 
vec_validate(), albeit, with one less memset(bob, o, sizeof(*bob)) being 
performed. However, I see a 10:1 usage (preference?) of vec_validate() vs. 
vec_new() in the existing vpp src, so I was hoping someone could share some of 
the "why" here as to when one should use either.

-Mike

Re: [vpp-dev] Patches for 18.04

[John Lo (loj)]

Hi Tom,

On your gerrit page for these patches, you can just click the "Cherry Pick" 
bottom and choose stable/1804 branch.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Thomas F Herbert
Sent: Friday, April 06, 2018 2:38 PM
To: vpp-dev@lists.fd.io
Cc: vpp-dev ; Billy McFall 
Subject: [vpp-dev] Patches for 18.04


Chris,

I submitted two patches to master that should be in stable/18.04.

11556: Merged in Master: https://gerrit.fd.io/r/11556

11551: Submitted but not merged yet in master: https://gerrit.fd.io/r/11551

What should I do?

Should I resubmit both patches direct to stable/18.04?

--Tom
--
Thomas F Herbert
NFV and Fast Data Planes
Networking Group Office of the CTO
Red Hat

Re: [vpp-dev] My patch kept failing Ubuntu 16.04 verification

[John Lo (loj)]

Thanks for your help, Marek. That worked.   -John

From: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)
Sent: Friday, April 06, 2018 1:58 AM
To: John Lo (loj) <l...@cisco.com>; vpp-dev@lists.fd.io
Subject: RE: My patch kept failing Ubuntu 16.04 verification

Hi,

You need to rebase your patch on top of
https://gerrit.fd.io/r/#/c/11526/

At least it helped on my local machine.

Regards,
Marek

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of John Lo (loj)
Sent: 6 kwietnia 2018 06:23
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] My patch kept failing Ubuntu 16.04 verification

Hi all,

I submitted a patch https://gerrit.fd.io/r/#/c/11553/ which failed the verify 
job on Ubuntu 16.04 in 5 consecutive tries. 4 of the 5 failures all started 
similarly - not able to run "JVPP Core Test Case" where console output showed 
failure with temp dir in use and tracebacks.  These failed tests were attempted 
3 more times before final failure declared.  Does anyone know what may be the 
problem with the JVPP Core Test Case in Ubuntu 16.04 verify job and how to 
resolve it?

Appreciate any help,
John

Following is one such failure with JVPP:
22:35:31 
==
22:35:31 JVPP Core Test Case
22:35:31 
==
22:35:31 JVPP Acl Callback Api Test Case
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:31 22:35:31,536 [Errno 17] File exists
22:35:31 JVPP Acl Future Api Test Case  
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:31 22:35:31,792 [Errno 17] File exists
22:35:32 JVPP Core Callback Api Test Case   
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:32 22:35:32,022 [Errno 17] File exists
22:35:32 JVPP Core Future Api Test Case 
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:32 22:35:32,255 [Errno 17] File exists
22:35:32 JVPP Ioamexport Callback Api Test Case 
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:32 22:35:32,494 [Errno 17] File exists
22:35:32 JVPP Ioamexport Future Api Test Case   
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:32 22:35:32,712 [Errno 17] File exists
22:35:32 JVPP Ioampot Callback Api Test Case
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:32 22:35:32,940 [Errno 17] File exists
22:35:33 JVPP Ioampot Future Api Test Case  
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:33 22:35:33,207 [Errno 17] File exists
22:35:33 JVPP Ioamtrace Callback Api Test Case  
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:33 22:35:33,461 [Errno 17] File exists
22:35:33 JVPP Ioamtrace Future Api Test Case
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:33 22:35:33,688 [Errno 17] File exists
22:35:33 JVPP Snat Callback Api Test Case   
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:33 22:35:33,960 [Errno 17] File exists
22:36:39 JVPP Snat Future Api Test Case 
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]

[vpp-dev] My patch kept failing Ubuntu 16.04 verification

[John Lo (loj)]

Hi all,

I submitted a patch https://gerrit.fd.io/r/#/c/11553/ which failed the verify 
job on Ubuntu 16.04 in 5 consecutive tries. 4 of the 5 failures all started 
similarly - not able to run "JVPP Core Test Case" where console output showed 
failure with temp dir in use and tracebacks.  These failed tests were attempted 
3 more times before final failure declared.  Does anyone know what may be the 
problem with the JVPP Core Test Case in Ubuntu 16.04 verify job and how to 
resolve it?

Appreciate any help,
John

Following is one such failure with JVPP:
22:35:31 
==
22:35:31 JVPP Core Test Case
22:35:31 
==
22:35:31 JVPP Acl Callback Api Test Case
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:31 22:35:31,536 [Errno 17] File exists
22:35:31 JVPP Acl Future Api Test Case  
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:31 22:35:31,792 [Errno 17] File exists
22:35:32 JVPP Core Callback Api Test Case   
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:32 22:35:32,022 [Errno 17] File exists
22:35:32 JVPP Core Future Api Test Case 
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:32 22:35:32,255 [Errno 17] File exists
22:35:32 JVPP Ioamexport Callback Api Test Case 
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:32 22:35:32,494 [Errno 17] File exists
22:35:32 JVPP Ioamexport Future Api Test Case   
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:32 22:35:32,712 [Errno 17] File exists
22:35:32 JVPP Ioampot Callback Api Test Case
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:32 22:35:32,940 [Errno 17] File exists
22:35:33 JVPP Ioampot Future Api Test Case  
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:33 22:35:33,207 [Errno 17] File exists
22:35:33 JVPP Ioamtrace Callback Api Test Case  
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:33 22:35:33,461 [Errno 17] File exists
22:35:33 JVPP Ioamtrace Future Api Test Case
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:33 22:35:33,688 [Errno 17] File exists
22:35:33 JVPP Snat Callback Api Test Case   
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]
22:35:33 22:35:33,960 [Errno 17] File exists
22:36:39 JVPP Snat Future Api Test Case 
  FAIL [ temp dir used by test case: /tmp/vpp-unittest-TestJVpp-hqaV42 ]

Re: [vpp-dev] vpp bridge int

[John Lo (loj)]

It is described here:
https://wiki.fd.io/view/VPP/Using_VPP_as_a_VXLAN_Tunnel_Terminator#BVI_Interface_Creation_and_Setup

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of xulang
Sent: Monday, April 02, 2018 6:17 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vpp bridge int

Hi all,
My vpp version is 17.04.
Why there is no bridge int, how could I configure ip to one bridge domain?

Regards,
xulang

Re: [**EXTERNAL**] RE: [vpp-dev] Is IRB feature fully functional?

[John Lo (loj)]

I read your original email as adding a sub-interface on loopback into BD as 
BVI. I see now you are using loop0 main interface as BVI for BD 5 while adding 
a sub-interface GigabitEthernet5/0/0.50 in BD 5.

In this situation, it does not work because packets from sub-interface will 
send packets with VLAN 50 into BD 5 while BVI is not expecting packets with any 
VLAN tag.  If you add a config to pop the VLAN tag from 
GigabitEthernet5/0/0.50, it should allow the packet to be handled by BVI 
properly:

set interface l2 tag-rewrite GigabitEthernet5/0/0.50 pop 1

Regards,
John

From: Gudimetla, Leela Sankar <lgudi...@ciena.com>
Sent: Thursday, March 22, 2018 4:46 PM
To: John Lo (loj) <l...@cisco.com>; vpp-dev@lists.fd.io
Subject: Re: [**EXTERNAL**] RE: [vpp-dev] Is IRB feature fully functional?

Thanks John for quick response.
Yes. I placed sub-interface in the BD that the BVI is associated. My intention 
is to keep L2 functionality (vlan edits, etc) intact and add L3 to it.
So this is what I am doing.


vpp# loopback create-interface

loop0

vpp# set interface state loop0 up

vpp# set interface mac address loop0 .0b51.0001

vpp# set interface l2 bridge loop0 5 bvi

vpp# set interface ip table loop0 0

vpp# set interface l2 learn loop0 disable

vpp# set interface ip address loop0 10.10.10.44/24

vpp#

vpp#

vpp#

vpp# create sub-interfaces GigabitEthernet5/0/0 50

GigabitEthernet5/0/0.50

vpp# set interface state GigabitEthernet5/0/0.50 up

vpp# set interface l2 bridge GigabitEthernet5/0/0.50 5

vpp#


I have similar configuration on the other box with the ip address configured on 
the bvi in the same sub-net.
But the ping does not go through saying the below reason.



vpp# show errors

   CountNode  Reason

 5arp-input   Interface is not IP enabled

vpp#


I think the IP address is to be configured on the loop-back interface (as it is 
the bvi that connects the bridging domain and routing domain) and not on the 
sub-interface ‘GigabitEthernet5/0/0.50’.
The APR REQs are getting received on the physical interface 
‘GigabitEthernet5/0/0 and getting dropped on sub-interface.


vpp# show interface

  Name   Idx   State  Counter  Count

GigabitEthernet5/0/0  3 up   rx packets 
5

 rx bytes   
  300

 drops  
5

GigabitEthernet5/0/0.50   6 up

GigabitEthernet5/0/1  4 up

TenGigabitEthernet3/0/0   1down

TenGigabitEthernet3/0/1   2down

local00down

loop0 5 up

vpp#

Should there be any configuration to enable routing on the BD? Like ‘bridge 1 
route ip’ on cisco router.

Thanks,
Leela sankar


From: "John Lo (loj)" <l...@cisco.com<mailto:l...@cisco.com>>
Date: Thursday, March 22, 2018 at 1:19 PM
To: Leela Gudimetla <lgudi...@ciena.com<mailto:lgudi...@ciena.com>>, 
"vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: [**EXTERNAL**] RE: [vpp-dev] Is IRB feature fully functional?

In order to use a sub-interface on a loopback interface as BVI of a BD, the 
sub-interface should be placed in a BD and the IP address configured on the 
sub-interface (in your case, sub-interface with VLAN tag 50 and not the main 
interface).  The sub-interface must be configured as an exact match VLAN 
sub-interface (thus expect packets contain a VLAN tag of ID 50 in your case) 
and all packets received and forwarded in the BD must have one VLAN tag of ID 
50, matching that of the BVI sub-interface VLAN.   –John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Gudimetla, Leela 
Sankar
Sent: Thursday, March 22, 2018 3:35 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Is IRB feature fully functional?

Hi,

I am trying to configure IRB/BVI feature and see if it works.
I am doing the configuration as per the instructions given in 
‘https://wiki.fd.io/view/VPP/Command-line_Interface_(CLI)_Guide#IRB.2FBVI’.

Instead of configuring a route as per the link, I am configuring an IP address 
on BVI interface.
And I am configuring a sub-interface with vlan-id 50 and attaching it to the 
same bridge-domain.

I am doing the similar configuration on the other box and trying to ping.
But the ARP REQ packets are getting dropped saying that the ‘Interface is not 
IP enabled’. I see that the sub-interface is not in L3 mode since it is 
attached to the bridge. But since the bridge is ‘flood’ enabled, I expect the 
ARP REQ should get flooded and the loop-back interface

Re: [vpp-dev] Is IRB feature fully functional?

[John Lo (loj)]

In order to use a sub-interface on a loopback interface as BVI of a BD, the 
sub-interface should be placed in a BD and the IP address configured on the 
sub-interface (in your case, sub-interface with VLAN tag 50 and not the main 
interface).  The sub-interface must be configured as an exact match VLAN 
sub-interface (thus expect packets contain a VLAN tag of ID 50 in your case) 
and all packets received and forwarded in the BD must have one VLAN tag of ID 
50, matching that of the BVI sub-interface VLAN.   –John

From: vpp-dev@lists.fd.io  On Behalf Of Gudimetla, Leela 
Sankar
Sent: Thursday, March 22, 2018 3:35 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Is IRB feature fully functional?

Hi,

I am trying to configure IRB/BVI feature and see if it works.
I am doing the configuration as per the instructions given in 
‘https://wiki.fd.io/view/VPP/Command-line_Interface_(CLI)_Guide#IRB.2FBVI’.

Instead of configuring a route as per the link, I am configuring an IP address 
on BVI interface.
And I am configuring a sub-interface with vlan-id 50 and attaching it to the 
same bridge-domain.

I am doing the similar configuration on the other box and trying to ping.
But the ARP REQ packets are getting dropped saying that the ‘Interface is not 
IP enabled’. I see that the sub-interface is not in L3 mode since it is 
attached to the bridge. But since the bridge is ‘flood’ enabled, I expect the 
ARP REQ should get flooded and the loop-back interface should respond.

And I also see that there is no command similar to ‘bridge  route ip’ to 
enable routing and bridging.

Please let me know that attaching sub-interface to the bridge for IRB is 
supported.
And also please let me know if I am missing anything.

Thanks,
Leela sankar

Re: [vpp-dev] Very poor performance vm to vm via VPP vhostuser

[John Lo (loj)]

Hi Sara,

To address your question on “show err”, your output is displaying running 
counts for the l2-output, l2-learn and l2-input node wrt how many packets each 
node processed.  These are not error counts, unless the “Reason” column 
indicate some kind of error.  The CLI name “show err” is mis-leading in that it 
is showing stats kept by VPP nodes for various reasons, not just errors.  I 
typically tell people to use the CLI “show node counters” which is more 
appropriate and produce the same output.  The CLI “show err” was there for 
historical reasons and kept for backward compatibility.  You are welcome to 
keep on using “show err” as it is shorter and faster to type.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Sara Gittlin
Sent: Thursday, March 22, 2018 8:56 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Very poor performance vm to vm via VPP vhostuser

in the show err output i see that  l2-output  l2-learn l2-input counters are 
continuously  incremented :
show  err
   CountNode  Reason
11l2-output   L2 output packets
11l2-learnL2 learn packets
11l2-inputL2 input packets
 3l2-floodL2 flood packets
   8479644l2-output   L2 output packets
   8479644l2-learnL2 learn packets
   8479644l2-inputL2 input packets

On Thu, Mar 22, 2018 at 11:59 AM, Sara Gittlin 
> wrote:
Hello
i setup 2 vm connected to VPP as per the guide :
https://wiki.fd.io/view/VPP/Use_VPP_to_connect_VMs_Using_Vhost-User_Interface

The performance looks very bad very low pps and large latencies

udp pkt size 100B - throughput 500Mb
average latency  is 900us

i have  2 PMDs threads (200% cpu) in the host, in the VMs i see low
cpu load (10%)

Please can you tell me what is wrong with my setup ?

Thank you in advance
- Sara

Re: [vpp-dev] VPP As A Router Between Namespaces - 10ms latency

[John Lo (loj)]

The functions in the area you are interested may be the unformat functions 
unformat_vnet_sw_interface(), unformat_vnet_hw_interface() in 
src/vnet/interface_format.c used by VPP CLI to get sw_if_index or hw_if_index 
from user specified interface name.-John

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Sara Gittlin
Sent: Monday, March 12, 2018 11:22 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP As A Router Between Namespaces - 10ms latency

btw - is there (like in linux)  a vpp function helper 
"interface-name-to-if-index"  - which its input is interface-name and output  
is vpp-if-index ?

Thank you
-Sara

On Mon, Mar 12, 2018 at 5:16 PM, Sara Gittlin  wrote:
> Thank you Jon
> This indeed very helpful !
> Cheers
> -Sara
>
> On Mon, Mar 12, 2018 at 5:01 PM, Jon Loeliger  wrote:
>>
>>
>> On Mon, Mar 12, 2018 at 3:57 AM, Sara Gittlin 
>> 
>> wrote:
>>>
>>> Dear Florin,
>>>
>>> When using the command " create tap rx-ring-size 4096 tx-ring-size 4096 "
>>>  VPP create the devices with default names tap0, tap1, ..tapn.
>>>
>>> Is it possible for the user to set the name in the 'create' command line ?
>>>
>>> Thank you in advance
>>> -Sara
>>
>>
>> Hi Sara,
>>
>> Welcome to my battle!
>>
>> Luckily, there is a way to do as you wish!  If you set the "instance"
>> value  during the tap_create API call, or use "id " during the 
>> "create tap ..." CLI command, you will create an interface of the 
>> name "tap".  You may not use a different prefix than "tap", but at 
>> least you can know what the name will be when it is created.
>>
>> HTH,
>> jdl
>>
>> 




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

You receive all messages sent to this group.

View/Reply Online (#8509): https://lists.fd.io/g/vpp-dev/message/8509
View All Messages In Topic (14): https://lists.fd.io/g/vpp-dev/topic/14091118
Mute This Topic: https://lists.fd.io/mt/14091118/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
-=-=-=-=-=-=-=-=-=-=-=-