On 22/06/2018 10:08, Nélio Laranjeiro wrote:
On Fri, Jun 22, 2018 at 09:51:15AM +0100, Mohammad Abdul Awal wrote:
On 22/06/2018 09:31, Nélio Laranjeiro wrote:
On Fri, Jun 22, 2018 at 08:42:10AM +0100, Mohammad Abdul Awal wrote:
Hi Nelio,
On 21/06/2018 08:13, Nelio Laranjeiro wrote:
This series adds an easy and maintainable configuration version support for
those two actions for 18.08 by using global variables in testpmd to store the
necessary information for the tunnel encapsulation. Those variables are used
in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily
the action for flows.
A common way to use it:
set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22
flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
This way we can define only one tunnel for all the flows. This is not a
convenient for testing a scenario (e.g. mutiport or switch) with multiple
tunnels. Isn't it?
Hi Awal.
The "set vxlan" command will just configure the outer VXLAN tunnel to be
used, when the "flow" command is invoked, it will use the VXLAN tunnel
information and create a valid VXLAN_ENCAP action. For instance:
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index
0 / end
testpmd> set vxlan ipv6 4 34 42 ::1 ::2222 80:12:13:14:15:16
22:22:22:22:22:22
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index
0 / end
will create two VLXAN_ENCAP flow one with IPv4 tunnel the second one
with an IPv6. Whereas:
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.2.3.4 / end
actions vxlan_encap / queue index 0 / end
testpmd> flow create 0 ingress pattern eth / ipv4 src is 20.2.3.4 / end
actions vxlan_encap / queue index 0 / end
will encapsulate the packets having as IPv4 source IP 10.2.3.4 and
20.2.3.4 with the same VXLAN tunnel headers.
I understand that the same IPv4 tunnel will be used for both flows in your
example above. I have the following questions.
1) How can we create two or more IPv4 (or IPv6) tunnel?
1) How can we make the flows to use different IPv4 tunnels?
As an example,
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33
44:44:44:44:44:44
testpmd> flow create 0 ingress pattern end actions vxlan_encap <first
tunnel?> / queue index 0 / end
testpmd> flow create 0 ingress pattern end actions vxlan_encap <second
tunnel?> / queue index 0 / end
Doing this, the flows will use the same tunnel, you must do:
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> flow create 0 ingress pattern end actions vxlan_encap <first
tunnel?> / queue index 0 / end
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33
44:44:44:44:44:44
testpmd> flow create 0 ingress pattern end actions vxlan_encap <second
tunnel?> / queue index 0 / end
to have what you want.
OK, thanks for the clarification. So, since there will be only one
global instance of the tunnel, for any subsequent "set vxlan"
operations, the tunnel created from the last last operation will be
used. May be it should be cleared in the description/documentation?
Is it possible?
Regards,
