Hi Sun
If bridge datapath_type is netdev, the package is in userspace, tcpdump
may not take effect.
I used to mirror the packet to the linux logical port for tcpdump, You
can try:
ip link add name sytest type dummy
ip link set dev sytest up
ovs-vsctl add-port br-int sytest
ovs-vsctl -- set Bridge br-int mirrors=@m \
-- --id=@sytest get Port sytest \
-- --id=@ovn-df66f3-0 get Port ovn-df66f3-0 \
-- --id=@m create Mirror name=mymirror select-dst-port=@ovn-df66f3-0 \
select-src-port=@ovn-df66f3-0 output-port=@sytest
# capture
tcpdump -i snooper0
# clear
ovs-vsctl clear Bridge br-int mirrors
ip link delete dev sytest
Hi
I tried to create one more bridge on the host, and it seems GRE packet
can be propagated, but I am not able to capture the packet on the g1
bridge. I believed I gave issue on the command to create the tunnel,
any idea?
# ovs-vsctl show
9fe3ef4d-7f29-4a21-80ea-62a705f5d934
Bridge "mirror0"
Port "eth1"
Interface "eth1"
Port "mirror0"
Interface "mirror0"
type: internal
Bridge "g1"
Port "g1"
Interface "g1"
type: internal
Port "dpdk0"
Interface "dpdk0"
type: dpdk
options: {dpdk-devargs="0000:00:09.0"}
# ovs-vsctl add-port mirror0 gre0 -- set interface gre0 type=gre
options:remote_ip=192.1.2.243 -- --id=@p get port dpdk0 -- --id=@m
create mirror name=m0 select-all=true output-port=@p -- set bridge
mirror0 mirrors=@m
On Mon, Sep 25, 2017 at 3:43 PM, Guoshuai Li <[email protected]> wrote:
I have not tested the GRE tunnel, I used geneve Tunnel, I think they are
similar.
I mean that the tunnel encap ip uses the ovs bridge.
What is your tunnel source ip? Your source IP should be configured on an
ovs bridge, the physical out of this bridge uses dpdk
You can refer to
http://docs.openvswitch.org/en/latest/howto/userspace-tunneling/?highlight=tunnel
On host1, add a port for the VXLAN tunnel:
$ ovs-vsctl add-port br-int vxlan0 \
-- set interface vxlan0 type=vxlan options:remote_ip=172.168.1.2
Note
172.168.1.2 is the remote tunnel end point address. On the remote host this
will be 172.168.1.1
Create a br-phy bridge:
$ ovs-vsctl --may-exist add-br br-phy \
-- set Bridge br-phy datapath_type=netdev \
-- br-set-external-id br-phy bridge-id br-phy \
-- set bridge br-phy fail-mode=standalone \
other_config:hwaddr=<mac address of eth1 interface>
I am not sure whether the source ip using physical network with kernel will
be a problem.
sorry to overlook.
from your configuration, you have two bridges, one is with dpdk, and
the other is not which is on management subnet, right?
can you share the GRE tunnel command for reference?
On Mon, Sep 25, 2017 at 3:22 PM, Sun Paul <[email protected]> wrote:
do you mean I need to bridge the management interface to bridge as well?
On Mon, Sep 25, 2017 at 2:14 PM, Guoshuai Li <[email protected]> wrote:
You can catch packets on your management interface.
I guess your package sent to the userspace from vm by dpdk , and then
through the tunnel to return to the kernel.
I do not know if this will be a problem.
I suggest you can try your management interface using OVS bridge with dpdk,
such as "g1".
This is my configuration:
7: br-agg: <BROADCAST,PROMISC,UP,LOWER_UP> mtu 1600 qdisc pfifo_fast state
UP qlen 1000
link/ether 6c:92:bf:04:f9:18 brd ff:ff:ff:ff:ff:ff
inet 10.157.145.213/24 brd 10.157.145.255 scope global br-agg
valid_lft forever preferred_lft forever
inet6 fe80::6e92:bfff:fe04:f918/64 scope link
valid_lft forever preferred_lft forever
[root@gateway1 ~]# ovs-vsctl show
b99b043b-951b-4bc7-9fd7-329d60d443a5
Bridge br-agg
Port bond-agg
Interface "agg-dpdk-2"
type: dpdk
options: {dpdk-devargs="0000:02:00.1"}
Interface "agg-dpdk-1"
type: dpdk
options: {dpdk-devargs="0000:02:00.0"}
Bridge br-int
Port "ovn-d172cc-0"
Interface "ovn-d172cc-0"
type: geneve
options: {csum="true", key=flow, remote_ip="10.157.145.212"}
Port br-int
Interface br-int
type: internal
Port "ovn-d131e4-0"
Interface "ovn-d131e4-0"
type: geneve
options: {csum="true", key=flow, remote_ip="10.157.145.214"}
Port "ovn-844fcd-0"
Interface "ovn-844fcd-0"
type: geneve
options: {csum="true", key=flow, remote_ip="10.157.145.211"}
Hi
thank for your reply.
the 192.1.2.159 is actually on the same subnet of the management
interface, it is not part of the OVS bridge.
On Mon, Sep 25, 2017 at 1:37 PM, Guoshuai Li <[email protected]> wrote:
I think you may have caught the tunnel inner package.
Is the tunnel outbound from interface dpdk0? how about caught dpdk0 with
mirror?
Or use dpdk-pdump?
Hi
How do I configure mirroring of all traffic to a GRE tunnel on OVS+DPDK?
I have a OVS+DPDK setip as below.
# ovs-vsctl show
9fe3ef4d-7f29-4a21-80ea-62a705f5d934
Bridge "g1"
Port "g1"
Interface "g1"
type: internal
Port "dpdk0"
Interface "dpdk0"
type: dpdk
options: {dpdk-devargs="0000:00:09.0"}
I tried to create gre tunnel for packet mirroring
#ovs-vsctl add-port g1 gre0 -- set interface gre0 type=gre
options:remote_ip=192.1.2.159 -- --id=@p get port gre0 -- --id=@m
create mirror name=m0 select-all=true output-port=@p -- set bridge g1
mirrors=@m
I cannot find any packet arrive on 192.1.2.159, any idea?
I have tried to use the same command in an OVS setup without DPDK
enabled, it works.
please help
- RBK
On Mon, Sep 25, 2017 at 1:26 PM, Sun Paul <[email protected]> wrote:
Hi
How do I configure mirroring of all traffic to a GRE tunnel on
OVS+DPDK?
I have a OVS+DPDK setip as below.
# ovs-vsctl show
9fe3ef4d-7f29-4a21-80ea-62a705f5d934
Bridge "g1"
Port "g1"
Interface "g1"
type: internal
Port "dpdk0"
Interface "dpdk0"
type: dpdk
options: {dpdk-devargs="0000:00:09.0"}
I tried to create gre tunnel for packet mirroring
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
