Hi,
I am facing a problem that is the following:
I have 2 hosts that I connect via gre tunnel.
On host 1:
I use mininet to connect 4 hosts to openvswitch bridge s1:
mininet> dump
# ovs-vsctl show
9eb8e438-e489-411f-bdde-b6075026d199
Bridge "s1"
Controller "ptcp:6634"
On Mon, Oct 09, 2017 at 04:08:24PM -0600, Sterdnot Shaken wrote:
> Just curious why, with igmp snooping enabled on the OVS bridge, I am still
> getting multicast traffic on other VM's (that shouldn't be getting it) on
> the same vlan?
>
> Here's how I'm enabling IGMP Snooping:
>
>
> *ovs-vsctl
OVS doesn't handle this case well. I don't think it will do what you
want.
On Mon, Oct 09, 2017 at 11:59:13PM +0200, Juraj Markotic wrote:
> yes, we are already using that one to send packet across 2 OVS connected
> via GRE tunnels and when switched out, will remove GRE header.
> Imagine
Just curious why, with igmp snooping enabled on the OVS bridge, I am still
getting multicast traffic on other VM's (that shouldn't be getting it) on
the same vlan?
Here's how I'm enabling IGMP Snooping:
*ovs-vsctl set Bridge ovs-br mcast_snooping_enable=trueovs-vsctl set Bridge
ovs-br
yes, we are already using that one to send packet across 2 OVS connected
via GRE tunnels and when switched out, will remove GRE header.
Imagine situation where SPAN traffic from some other switch is being sent
as replica traffic to OVS inport (one can be configured as GRE port for
that matter).
On Mon, Oct 09, 2017 at 11:25:05PM +0200, Mita Cokic wrote:
> I was executing following test case - on 30Mbps link limited OVSK instance
> data was pushed as two TCP flows:
> - Flow A: 200Kbps
> - Flow B: 300Mbps
>
> I have observed that Flow A bandwidth drops for around 10% but still manages
>
Greetings everyone,
I was executing following test case - on 30Mbps link limited OVSK instance
data was pushed as two TCP flows:
- Flow A: 200Kbps
- Flow B: 300Mbps
I have observed that Flow A bandwidth drops for around 10% but still manages
to keep constant rate at about 180Kbps.
When this
GRE and tunnels are implemented in terms of ports, so if you send a
packet received on a GRE port to a non-tunnel port, it strips the
header.
On Mon, Oct 09, 2017 at 10:45:10PM +0200, Juraj Markotic wrote:
> I will check on about GTP ongoing activities (I saw some actitvities on
> providing
I will check on about GTP ongoing activities (I saw some actitvities on
providing capabilities to match on GTP-C/GTP-U packets).
maybe dumb question, but any pointer on how to remove GRE header (or VXLAN
for that matter) when switching packet from IN port to OUT port and switch
out only internal
OVS doesn't support GTP yet, but I know that there's some ongoing work
on it.
GRE and VXLAN should be fine.
If you need GTP support, maybe the best thing to do would be to help out
the folks who are working on it.
On Mon, Oct 09, 2017 at 09:35:42PM +0200, Juraj Markotic wrote:
> Hello,
> thanks
Hello,
thanks for feedback.
I know OVS can truncate payload and that in can modify mac/IPs in header
(i.e. like doing NAT).
I also know OVS can deencapsulate GRE (of VXLAN) when packet is arriving on
tunnel OVS interface (done automatically).
But I was not aware that OVS can remove tunnel headers
I think libovn should be put in package ovn-common, but it is put in
openvswitch-common. Is there any specific reason?
# dpkg -S /usr/lib/libovn-2.so.7.0.0
openvswitch-common: /usr/lib/libovn-2.so.7.0.0
___
discuss mailing list
disc...@openvswitch.org
On Fri, Oct 06, 2017 at 07:24:15PM -0500, Prabhu wrote:
> I am evaluating openvswitch for implementing a load balancing based on Queue
> length.
>
> I know OVS can set queue to ports attached to the bridge using linux tc
> utility.
>
> I would like to know whether I can assign queues to Internal
On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> we would need some functionality on manipulating packets when packet is
> exiting outgoing OVS port.
> I.e. some actions could be: change/anonymize mac/IPs for src/dst, or remove
> some tunnel header (vxlan, gtp, gre), truncate the
On Sun, Oct 08, 2017 at 11:09:23PM -0300, Raymond Burkholder wrote:
> I've written some openflow controller code to submit openflow line-protocol
> based commands.
>
> In looking at the ovs-fields document, there appears to be OVS functions
> available which are not available via openflow
> On 10/03/2017 05:35 AM, Avi Cohen (A) wrote:
> > Hi,
> > These Intel NIC's: X540, 82599, I40E - supports IPsec offload But I
> > don't see that the drivers supplied by Intel - handle it (??) Also I
> > don't see any reference in the DPDK userspace drivers
> librte_pmd_ixgbe.c ..
> > Can
16 matches
Mail list logo
