[ovs-discuss] disable datapath
Hi, Is there a way to send packets to userspace and stopping userspace from sending flows to datapath, because i want all my packets to be treated in userspace, because when i send the first packet it goes to userspace and after that it doesn't. so can you help me. Thank you and have a nice say, best regards ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] No flow table entries??why would the loop?
hi?? I create a virtual machine, the virtual machine has two pieces of card, the two pieces of card to use is bridging mode, and the two pieces of card connected to a OVS, in OVS without any flow table entries, why would the loop?___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] disable datapath
Hi Amrane, that’s the expected behavior. The 1st packet of a flow goes up to userspace – and there’s a context switch for that. After classification 1 cache entry will be added in the megaflow table and another cache entry into the microflow table, both these 2 caches are into the kernel. So hopefully future packets - similar to the one you received – will be matched against the kernel caches, avoiding to be processed in userspace. Worth having a look at https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-pfaff.pdf The other option you could consider is to use OVS with DPDK where all the datapath is at the userspace level. HTH Antonio From: discuss [mailto:discuss-boun...@openvswitch.org] On Behalf Of Amrane Ait Zeouay Sent: Monday, August 8, 2016 9:44 AM To: discuss@openvswitch.org Subject: [ovs-discuss] disable datapath Hi, Is there a way to send packets to userspace and stopping userspace from sending flows to datapath, because i want all my packets to be treated in userspace, because when i send the first packet it goes to userspace and after that it doesn't. so can you help me. Thank you and have a nice say, best regards ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] disable datapath
Thank you for your answer, but i want to know if i can disable sending the flow from userspace to datapath so that the datapath send all packets to the userspace, even it will be slow, because i implemented a new field in userspace and it's not implemented in datapath. Thank you. 2016-08-08 11:48 GMT+02:00 Fischetti, Antonio : > Hi Amrane, that’s the expected behavior. > > The 1st packet of a flow goes up to userspace – and there’s a context > switch for that. After classification 1 cache entry will be added in the > megaflow table and another cache entry into the microflow table, both > these 2 caches are into the kernel. So hopefully future packets - similar > to the one you received – will be matched against the kernel caches, > avoiding to be processed in userspace. > > > > Worth having a look at > > https://www.usenix.org/system/files/conference/nsdi15/ > nsdi15-paper-pfaff.pdf > > > > The other option you could consider is to use OVS with DPDK where all the > datapath is at the userspace level. > > > > HTH > > Antonio > > > > *From:* discuss [mailto:discuss-boun...@openvswitch.org] *On Behalf Of * > Amrane Ait Zeouay > *Sent:* Monday, August 8, 2016 9:44 AM > *To:* discuss@openvswitch.org > *Subject:* [ovs-discuss] disable datapath > > > > Hi, > > > > Is there a way to send packets to userspace and stopping userspace from > sending flows to datapath, because i want all my packets to be treated in > userspace, because when i send the first packet it goes to userspace and > after that it doesn't. so can you help me. > > > > Thank you and have a nice say, > > > > best regards > > > > > > > > > -- Amrane Ait Zeouay Engineer Student in The Development of Software and Systems University of Western Brittany Tel: +33 7 62 25 56 03 <+33+7+62+25+56+03> ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] Append output port to an existing flow
Hi, Want to check if there is an alternate way to append a output port to the existing flow. For example, Existing flow: cookie=0x0, duration=14279.412s, table=0, n_packets=0, n_bytes=0, idle_age=14316, dl_vlan=5 actions=output:2 If I want to add output:4 to the above flow, the only way I know is using mod-flow ovs-ofctl mod-flow bridge "dl_vlan=5, actions=output:2,4" But is there any other way that I can use to just append 4? i might have about 20 ports which have to be dynamically appended. Why I need this? I am testing VXLAN tunnels. They can be created/teared down dynamically. Each VXLAN can have same or different VLAN. Packets destined to a particular VLAN should be sent to all tunnels with that vlan. Since tunnel learning is dynamic, using mod-flows is little bit tricky. Any alternate solution for this? Regards Kapil. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] disable datapath
On Mon, Aug 08, 2016 at 12:51:06PM +0200, Amrane Ait Zeouay wrote: > Thank you for your answer, but i want to know if i can disable sending the > flow from userspace to datapath so that the datapath send all packets to > the userspace, even it will be slow, because i implemented a new field in > userspace and it's not implemented in datapath. > > Thank you. > Hi, Take a look at how the multicast snooping code sets the SLOW flag for IGMP and MLD packets at ofproto/ofproto-dpif-xlate.c:xlate_normal. And don't forget to set the wildcard masks as in is_igmp and is_mld. Cascardo. > 2016-08-08 11:48 GMT+02:00 Fischetti, Antonio : > > > Hi Amrane, that’s the expected behavior. > > > > The 1st packet of a flow goes up to userspace – and there’s a context > > switch for that. After classification 1 cache entry will be added in the > > megaflow table and another cache entry into the microflow table, both > > these 2 caches are into the kernel. So hopefully future packets - similar > > to the one you received – will be matched against the kernel caches, > > avoiding to be processed in userspace. > > > > > > > > Worth having a look at > > > > https://www.usenix.org/system/files/conference/nsdi15/ > > nsdi15-paper-pfaff.pdf > > > > > > > > The other option you could consider is to use OVS with DPDK where all the > > datapath is at the userspace level. > > > > > > > > HTH > > > > Antonio > > > > > > > > *From:* discuss [mailto:discuss-boun...@openvswitch.org] *On Behalf Of * > > Amrane Ait Zeouay > > *Sent:* Monday, August 8, 2016 9:44 AM > > *To:* discuss@openvswitch.org > > *Subject:* [ovs-discuss] disable datapath > > > > > > > > Hi, > > > > > > > > Is there a way to send packets to userspace and stopping userspace from > > sending flows to datapath, because i want all my packets to be treated in > > userspace, because when i send the first packet it goes to userspace and > > after that it doesn't. so can you help me. > > > > > > > > Thank you and have a nice say, > > > > > > > > best regards > > > > > > > > > > > > > > > > > > > > > > -- > > Amrane Ait Zeouay > > Engineer Student in The Development of Software and Systems > > University of Western Brittany > > Tel: +33 7 62 25 56 03 <+33+7+62+25+56+03> > ___ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] Port Mirroring on XenCenter 7
Dear all, although there are few blogs on the web regarding this matter my problem cannot be resolved following them. My setup: XenServer 7.0 with 2 NICs onboard. NIC1 (eth1) is connected to my Juniper switch (EX-4200-48T). At this Juniper-Port all traffic in my network is being mirrored to. What I want to do: Forward all that traffic from eth1 to my VM's interface. I assigned the interface eth1 to the vm as secondary interface. In XenServer itself I also put all the network interfaces (physical ones as well as the virtual ones) to promisc mode. Following this blog article: http://blog.manula.org/2014/02/port-mirroring-with-openvswitch.html I configured OVS to mirror all that traffic from eth1 to vif1.1 (which is the virtual interface of the physical interface eth1 inside the VM) +++ ovs-vsctl -- set Bridge xenbr1 mirrors=@m -- --id=@eth1 get Port eth1 -- --id=@vif1.1 get Port vif1.1 -- --id=@m create Mirror name=mirror1 select-dst-port=@eth1 select-src-port=@eth1 output-port=@vif1.1 +++ Then I am able to see some traffic on eth1 in my VM. But it seems to be not all traffic. I am using pmacct to collect data, this data is being stored to a mysql database and from there being handled further by own scripts. I did a download of a 10GB file. So I should see 10GB downloaded, but I only see around 400MB. When starting pmacct on the xenserver host itself, I see the whole 10GB thing. So I assume that not all traffic is forwarded from eth1 to vif1.1? What am I doing wrong? Anybody here that can help? Thank you very much, Jerome ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Append output port to an existing flow
On Mon, Aug 08, 2016 at 04:49:49PM +0530, Kapil Adhikesavalu wrote: > Want to check if there is an alternate way to append a output port to the > existing flow. > > > > For example, > > > > Existing flow: > > cookie=0x0, duration=14279.412s, table=0, n_packets=0, n_bytes=0, > idle_age=14316, dl_vlan=5 actions=output:2 > > > > If I want to add output:4 to the above flow, the only way I know is using > mod-flow > > > > ovs-ofctl mod-flow bridge "dl_vlan=5, actions=output:2,4" > > > > But is there any other way that I can use to just append 4? i might have > about 20 ports which have to be dynamically appended. You could use the OF1.1+ "groups" feature. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Append output port to an existing flow
Hi Ben, I did a brief trial with 'groups' before mailing the list. Wanted to check if there are other alternatives specific to vxlan. Thanks for confirming. Will there be any overhead in using 1 group for each tunnel in a scaled environment. Regards Kapil Thanks Kapil On 08-Aug-2016 9:54 PM, "Ben Pfaff" wrote: On Mon, Aug 08, 2016 at 04:49:49PM +0530, Kapil Adhikesavalu wrote: > Want to check if there is an alternate way to append a output port to the > existing flow. > > > > For example, > > > > Existing flow: > > cookie=0x0, duration=14279.412s, table=0, n_packets=0, n_bytes=0, > idle_age=14316, dl_vlan=5 actions=output:2 > > > > If I want to add output:4 to the above flow, the only way I know is using > mod-flow > > > > ovs-ofctl mod-flow bridge "dl_vlan=5, actions=output:2,4" > > > > But is there any other way that I can use to just append 4? i might have > about 20 ports which have to be dynamically appended. You could use the OF1.1+ "groups" feature. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Append output port to an existing flow
No, there's nothing special about VXLAN. There should no measurable overhead. On Mon, Aug 08, 2016 at 11:08:53PM +0530, Kapil Adhikesavalu wrote: > Hi Ben, > > I did a brief trial with 'groups' before mailing the list. Wanted to check > if there are other alternatives specific to vxlan. > > Thanks for confirming. Will there be any overhead in using 1 group for each > tunnel in a scaled environment. > > Regards > Kapil > > Thanks > Kapil > > On 08-Aug-2016 9:54 PM, "Ben Pfaff" wrote: > > On Mon, Aug 08, 2016 at 04:49:49PM +0530, Kapil Adhikesavalu wrote: > > Want to check if there is an alternate way to append a output port to the > > existing flow. > > > > > > > > For example, > > > > > > > > Existing flow: > > > > cookie=0x0, duration=14279.412s, table=0, n_packets=0, n_bytes=0, > > idle_age=14316, dl_vlan=5 actions=output:2 > > > > > > > > If I want to add output:4 to the above flow, the only way I know is using > > mod-flow > > > > > > > > ovs-ofctl mod-flow bridge "dl_vlan=5, actions=output:2,4" > > > > > > > > But is there any other way that I can use to just append 4? i might have > > about 20 ports which have to be dynamically appended. > > You could use the OF1.1+ "groups" feature. ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [ovs-dev] OVN: Limiting the impact of a compromised chassis
On Fri, Jul 15, 2016 at 1:53 PM, Lance Richardson wrote: > I've been doing some investigation into the "Limiting the impact of > a compromised chassis" issue described in ovn/TODO. These are some initial > thoughts, posting here for feedback and any other ideas folks might have > about how we should go about solving this part of the issue. > > The fact that we're heading towards using etcd for OVN might make some > of this moot, on the other hand it might be some time before that happens > and this security issue will need to be addressed in order for OVN to be > viable in some use cases. > I've been thinking about whether it still makes sense to work on this before migrating to etcd. Since the etcd timeline is unclear, and this issue is a blocker for some people in the meantime, I think it's worth proceeding, at least with scoping the work. If we can come up with a detailed proposal, we can hopefully get a better idea of how much work it would be and if it's worth the short term effort. > One problem that needs to be solved for any potential solution to the > compromised chassis issue is how to determine the identity of clients > connecting to the OVN southbound DB server. For example, it would be > desirable for ovn-northd and ovn-sbctl to have one set of access privileges > for reading and updating the SB database while ovn-controller and > ovn-controller-vtep have a different and more limited set of access > privileges. In order to implement this it would be necessary to know for > each transaction the type of client attempting it. For more fine-grained > access control, it will also be necessary to determine the actual identity > (e.g. chassis name or UUID) of each connected client. > > Since ovsdb-server already has support for SSL client authentication, one > semi-obvious approach might be to: >- Configure the SB ovsdb-server to only accept unix and SSL connections > (ovn-northd and ovn-sbctl would likely use unix:file connections, > where > access can be controlled via file system permissions, whereas > ovn-controller > instances would use SSL). >- Generate signed client certificates for each chassis/gateway, > encoding the > chassis/gateway name in the certificate's "organizational unit" field. >- In cases where ovn-northd or ovn-sbctl might have to connect to the SB > database server over a network, client certificates could be generated > with e.g. the OU field set to "ovn-northd" or "ovn-sbctl" as > appropriate. >- For each new SSL connection, ovsdb-server would record the client type > and name contained in the client-provided certificate. >- The recorded client type and name could then be used in a (to be > defined > separately) ACL implementation. > > Some questions: > > - Will this work, and are there any obvious holes? > - Might PKI management be too burdensome in large deployments? > - Is there a better way? > If we need identify for each chassis, this does seem like a good approach. I was imagining we'd do it with SSL, but hadn't thought through details yet. The other option is if we can change ovn-controller to where it is only a read-only client of the southbound database. In that case, perhaps ovsdb-server wouldn't need to know identity, and instead could have a port open that only accepts connections with read-only access to the database. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] ovsdb - synching from a non-existing database
When synching from a database that doesn't exist, the entire database will wipe. This is obviously very bad, because synching is typically used to handle scenarios where a service is unreachable.
Actions:1. Start ovn-central via 'service ovn-central start'2. Add an item to the database via 'ovn-nbctl ls-add'3. Start synching by the running the synch commands below. Make sure the IP/PORT combination you choose does NOT point to an ovsdb instance.ovs-appctl -t /var/run/openvswitch/ovnnb_db.ctl ovsdb-server/set-remote-ovsdb-server tcp:{IP}:{PORT}ovs-appctl -t /var/run/openvswitch/ovnnb_db.ctl ovsdb-server/connect-remote-ovsdb-server4. Run 'ovn-nbctl show'
Expected result:View the switch that was added
Actual result:The database is empty, and the command takes longer then expected to return.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Why all of the packets are dropped at the dpdkvhostuser port?
Hi Mauricio, After applying the patch, the packets are flowing to the VM now. However, even at lower bandwidth, it always has a small percentage of frame loss. Is this expected behavior? Thanks, Charlie On Fri, Aug 5, 2016 at 9:22 AM, Charlie Li wrote: > Thanks Mauricio, > > I will try the patch first. > > Regards, > Charlie > > On Fri, Aug 5, 2016 at 4:56 AM, Mauricio Vasquez < > mauricio.vasq...@polito.it> wrote: > >> Hello Charlie, >> >> On 08/04/2016 09:22 PM, Charlie Li wrote: >> >> Hi All, >> >> I set up a bridge with 2 dpdk ports and 2 dpdkvhostuser ports. And 4 >> flows are configured as the follows >> >> PHY0 -> dpdk port0 -> dpdkvhostuser port0 -> VM eth-ens3 >> PHY0 <- dpdk port0 <- dpdkvhostuser port0 <- VM eth-ens3 >> >> -- >> PHY1 -> dpdk port1 -> dpdkvhostuser port1 -> VM eth-ens4 >> PHY1 <- dpdk port1 <- dpdkvhostuser port1 <- VM eth-ens4 >> >> All of the packets from the VM are passed to the PHY. No problem. >> >> But all of the packets from the PHY are dropped at the dpdkvhostuser >> port, and cannot be passed to the VM. >> >> Why one direction does not work while the other direction works fine? >> >> Any help is appreciated! >> >> Thanks, >> >> Charlie >> >> >> --- >> More details >> >> --- >> DPDK 2.2.0; OVS 2.5.0; Both host and VM is Fedora 23 >> >> >> It is a known problem in OVS 2.5.0, please refer to: >> http://openvswitch.org/pipermail/dev/2016-March/068282.html >> >> The possible solutions are: >> - Use a newer version of OVS (If you use master you have to use DPDK >> 16.07) >> - Apply this patch to ovs 2.5.0: https://patchwork.ozlabs.org/p >> atch/602752/ >> - Use a qemu version greater or equal to 2.5 >> >> Bridge and port config >> >> $ sudo ./ovs-vsctl show >> fa6781bf-0204-4593-ad99-bf6a3843c6c8 >> Bridge "br0" >> Port "vhost0" >> Interface "vhost0" >> type: dpdkvhostuser >> Port "vhost1" >> Interface "vhost1" >> type: dpdkvhostuser >> Port "br0" >> Interface "br0" >> type: internal >> Port "dpdk0" >> Interface "dpdk0" >> type: dpdk >> Port "dpdk1" >> Interface "dpdk1" >> type: dpdk >> >> $ sudo ./ovs-vsctl list-ports br0 >> dpdk0 >> dpdk1 >> vhost0 >> vhost1 >> >> Before sending traffic to PHY >> >> $ sudo ./ovs-ofctl dump-flows br0 >> NXST_FLOW reply (xid=0x4): >> cookie=0x0, duration=260.837s, table=0, n_packets=0, n_bytes=0, >> idle_age=260, in_port=1 actions=output:3 >> cookie=0x0, duration=260.817s, table=0, n_packets=0, n_bytes=0, >> idle_age=260, in_port=2 actions=output:4 >> cookie=0x0, duration=260.799s, table=0, n_packets=48, n_bytes=7968, >> idle_age=6, in_port=3 actions=output:1 >> cookie=0x0, duration=260.781s, table=0, n_packets=48, n_bytes=7968, >> idle_age=7, in_port=4 actions=output:2 >> >> $ sudo ./ovs-ofctl dump-ports br0 >> OFPST_PORT reply (xid=0x2): 5 ports >> port 4: rx pkts=48, bytes=7968, drop=?, errs=0, frame=?, over=?, crc=? >>tx pkts=0, bytes=0, drop=0, errs=?, coll=? >> port 2: rx pkts=0, bytes=0, drop=0, errs=0, frame=?, over=?, crc=? >>tx pkts=48, bytes=7968, drop=0, errs=0, coll=? >> port 1: rx pkts=0, bytes=0, drop=0, errs=0, frame=?, over=?, crc=? >>tx pkts=48, bytes=7968, drop=0, errs=0, coll=? >> port 3: rx pkts=48, bytes=7968, drop=?, errs=0, frame=?, over=?, crc=? >>tx pkts=0, bytes=0, drop=0, errs=?, coll=? >> port LOCAL: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0 >>tx pkts=0, bytes=0, drop=0, errs=0, coll=0 >> >> >> After sending traffic to PHY >> >> $ sudo ./ovs-ofctl dump-flows br0 >> NXST_FLOW reply (xid=0x4): >> cookie=0x0, duration=330.842s, table=0, n_packets=29069777, >> n_bytes=1802326154, idle_age=32, in_port=1 actions=output:3 >> cookie=0x0, duration=330.822s, table=0, n_packets=29069777, >> n_bytes=1802326154, idle_age=32, in_port=2 actions=output:4 >> cookie=0x0, duration=330.804s, table=0, n_packets=50, n_bytes=8652, >> idle_age=56, in_port=3 actions=output:1 >> cookie=0x0, duration=330.786s, table=0, n_packets=50, n_bytes=8652, >> idle_age=52, in_port=4 actions=output:2 >> >> $ sudo ./ovs-ofctl dump-ports br0 >> OFPST_PORT reply (xid=0x2): 5 ports >> port 4: rx pkts=50, bytes=8652, drop=?, errs=0, frame=?, over=?, crc=? >>tx pkts=0, bytes=0, drop=29069777, errs=?, coll=? >> port 2: rx pkts=29069777, bytes=1802326154, drop=0, errs=0, frame=?, >> over=?, crc=? >>tx pkts=50, bytes=8652, drop=0, errs=0, coll=? >> port 1: rx pkts=29069777, bytes=1802326154, drop=0, errs=0, frame=?, >> over=?, c
Re: [ovs-discuss] ovsdb - synching from a non-existing database
On Mon, Aug 8, 2016 at 2:23 PM, Daniel Levy wrote:
> When synching from a database that doesn't exist, the entire database will
> wipe. This is obviously very bad, because synching is typically used to
> handle scenarios where a service is unreachable.
>
> Actions:
> 1. Start ovn-central via 'service ovn-central start'
> 2. Add an item to the database via 'ovn-nbctl ls-add'
> 3. Start synching by the running the synch commands below. Make sure the
> IP/PORT combination you choose does NOT point to an ovsdb instance.
> ovs-appctl -t /var/run/openvswitch/ovnnb_db.ctl
> ovsdb-server/set-remote-ovsdb-server tcp:{IP}:{PORT}
> ovs-appctl -t /var/run/openvswitch/ovnnb_db.ctl
> ovsdb-server/connect-remote-ovsdb-server
> 4. Run 'ovn-nbctl show'
>
> Expected result:
> View the switch that was added
>
> Actual result:
> The database is empty, and the command takes longer then expected to
> return.
>
Is this in the context of HA for OVN? If yes, I am not sure the behavior is
unreasonable.
For active-backup HA, an OVSDB server should either be an active server or
an backup server. The backup
server should not be allowed to accept any "write" transactions. (I have
sent patches for this feature). The
active and backup server are to be managed by a HA manager, such as
heartbeat, In case heartbeat misconfigures the backup server. I am not
sure if retaining older database will help that much, although it
is defiantly implementable.
Do you another use case in mind?
>
>
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] No flow table entries，why would the loop?
> On Aug 8, 2016, at 2:27 AM, 破冰者 <852187...@qq.com> wrote: > > hi， > I create a virtual machine, the virtual machine has two pieces of card, > the two pieces of card to use is bridging mode, and the two pieces of card > connected to a OVS, in OVS without any flow table entries, why would the loop? By default, OVS acts as a layer-2 switch. If you don't want that behavior, you can configure the "fail_mode" to "secure" as described in the ovs-vswitchd.conf.db man page. --Justin ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Port Mirroring on XenCenter 7
> On Aug 8, 2016, at 4:45 AM, Jerome Eichler wrote: > > Dear all, > > although there are few blogs on the web regarding this matter my problem > cannot be resolved following them. > > My setup: > XenServer 7.0 with 2 NICs onboard. NIC1 (eth1) is connected to my Juniper > switch (EX-4200-48T). At this Juniper-Port all traffic in my network is being > mirrored to. > > What I want to do: > Forward all that traffic from eth1 to my VM's interface. I assigned the > interface eth1 to the vm as secondary interface. > > In XenServer itself I also put all the network interfaces (physical ones as > well as the virtual ones) to promisc mode. > Following this blog article: > http://blog.manula.org/2014/02/port-mirroring-with-openvswitch.html I > configured OVS to mirror all that traffic from eth1 to vif1.1 (which is the > virtual interface of the physical interface eth1 inside the VM) > > +++ > ovs-vsctl -- set Bridge xenbr1 mirrors=@m -- --id=@eth1 get Port eth1 -- > --id=@vif1.1 get Port vif1.1 -- --id=@m create Mirror name=mirror1 > select-dst-port=@eth1 select-src-port=@eth1 output-port=@vif1.1 > +++ > > Then I am able to see some traffic on eth1 in my VM. But it seems to be not > all traffic. > I am using pmacct to collect data, this data is being stored to a mysql > database and from there being handled further by own scripts. > > I did a download of a 10GB file. So I should see 10GB downloaded, but I only > see around 400MB. > > When starting pmacct on the xenserver host itself, I see the whole 10GB > thing. So I assume that not all traffic is forwarded from eth1 to vif1.1? > What am I doing wrong? Anybody here that can help? I'm not familiar with pmacct, but a quick look at the documentation makes it look like by default it captures 4KB per packet. It could also be dropping packets. There are a lot of variables here. You may want to check the interface statistics in both the guest and dom0 to make sure those are right. --Justin ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Port Mirroring on XenCenter 7
Hi Justin, thank you for replying! > I'm not familiar with pmacct, but a quick look at the documentation makes it look like by default it captures 4KB per packet. It could also be dropping packets. There are a lot of variables here. You may want to check the > interface statistics in both the guest and dom0 to make sure those are right. pmacct itself is not the problem. Both pmacct configuration (the one in the VM and the one on the XenServer host) are the same. Just one of them (the on in the VM) seems not to get all traffic data. I tried to do some more analysis. Doing a tcpdump for the same time for around 15 seconds on the VM and the xenserver host gives very different results: +++ VM: [root@xen04 ~]# tcpdump -i eth1 -n not port 22 (...) 1374 packets captured 1637 packets received by filter 0 packets dropped by kernel +++ +++ XenServer Host: root@trafficmirror:~# tcpdump -i eth1 -n not port 22 (...) 68272 packets captured 81960 packets received by filter 13663 packets dropped by kernel +++ As we can see the VM only has a small amount of packets which arrive on eth1 interface in total. Could this have to do with VLAN tagging? When reviewing the tcpdump it looks like that I only see traffic inside that VLAN in which the VM is hosted in. Traffic outside this VLAN is not available, although eth1/vif1.1 is not in a VLAN. Only vif1.0 (the VM's network interface to connect to the server) is inside a VLAN. How can I get the rest of all the other VLAN traffic to my vif1.1? Thank you, Jerome -Ursprüngliche Nachricht- Von: Justin Pettit [mailto:jpet...@ovn.org] Gesendet: Dienstag, 9. August 2016 07:05 An: Jerome Eichler Cc: discuss@openvswitch.org Betreff: Re: [ovs-discuss] Port Mirroring on XenCenter 7 > On Aug 8, 2016, at 4:45 AM, Jerome Eichler wrote: > > Dear all, > > although there are few blogs on the web regarding this matter my problem cannot be resolved following them. > > My setup: > XenServer 7.0 with 2 NICs onboard. NIC1 (eth1) is connected to my Juniper switch (EX-4200-48T). At this Juniper-Port all traffic in my network is being mirrored to. > > What I want to do: > Forward all that traffic from eth1 to my VM's interface. I assigned the interface eth1 to the vm as secondary interface. > > In XenServer itself I also put all the network interfaces (physical ones as well as the virtual ones) to promisc mode. > Following this blog article: http://blog.manula.org/2014/02/port-mirroring-with-openvswitch.html I configured OVS to mirror all that traffic from eth1 to vif1.1 (which is the virtual interface of the physical interface eth1 inside the VM) > > +++ > ovs-vsctl -- set Bridge xenbr1 mirrors=@m -- --id=@eth1 get Port eth1 -- --id=@vif1.1 get Port vif1.1 -- --id=@m create Mirror name=mirror1 select-dst-port=@eth1 select-src-port=@eth1 output-port=@vif1.1 > +++ > > Then I am able to see some traffic on eth1 in my VM. But it seems to be not all traffic. > I am using pmacct to collect data, this data is being stored to a mysql database and from there being handled further by own scripts. > > I did a download of a 10GB file. So I should see 10GB downloaded, but I only see around 400MB. > > When starting pmacct on the xenserver host itself, I see the whole 10GB thing. So I assume that not all traffic is forwarded from eth1 to vif1.1? What am I doing wrong? Anybody here that can help? I'm not familiar with pmacct, but a quick look at the documentation makes it look like by default it captures 4KB per packet. It could also be dropping packets. There are a lot of variables here. You may want to check the interface statistics in both the guest and dom0 to make sure those are right. --Justin ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
