Hi Abhishek and Justin,
Got it! Thanks for your kind help.
+
Best,
Hao
On Fri, Jul 17, 2015 at 9:51 PM, Abhishek Verma
wrote:
> Hao,
>
> OVS doesnt need ARP -- its L3 forwarding that needs it.
>
> When you ping, the kernel needs to know the destination MAC address that
> it
Hao,
OVS doesnt need ARP -- its L3 forwarding that needs it.
When you ping, the kernel needs to know the destination MAC address that it
needs to slap on to the packet. Unless it gets this the packet will not be
forwarded. When it sends out the ARP request, OVS must forward it so that
the other e
> On Jul 18, 2015, at 12:03 AM, Hao Wu wrote:
>
> Hi,
>
>I'm curious that why OVS forwarding also needs arp? I find if I add a flow
> in flow table as "idle_timeout=0,ip,dst_scr=10.0.0.2,actions=output:2", the
> packets can't be forwarded unless I also add the arp part:
> "idle_timeout=0
Hi,
I'm curious that why OVS forwarding also needs arp? I find if I add a
flow in flow table as
"idle_timeout=0,ip,dst_scr=10.0.0.2,actions=output:2", the packets can't be
forwarded unless I also add the arp part:
"idle_timeout=0,arp,dst_scr=10.0.0.2,actions=output:2". For OVS, I think it
can w
On Fri, Jul 17, 2015 at 10:53:05PM +0530, Abhishek Verma wrote:
> QUESTION: Can i assume that since tcpdump shows the 2nd output on the OVS
> bridge port, the packet is actually sent out from the OVS bridge port?
Yes, that's generally a safe assumption.
Thanks Ben. I was using the wrong port.
I added a flow-rule that changes the MAC address to the MAC of the nexthop
and pushed it on the interface that connects this VM to the destination
that i am trying to ping.
I see that packets are hitting this flow-rule, but the ICMP packets are NOT
going ou
Yes, we read it. :-) Thank you very much for the report! I assume that will
solve a lot of the questions people have been having. We're tracking down the
appropriate people to update the record, so it may take us a couple of days.
I'll follow up when I've heard something.
--Justin
> On J
Hi,
MAC addresses mentioned in the diagram are just for example.
MAC addresses used were as follows:
Client Program:
52:54:00:00:01:02
Server Program:
52:56:11:80:80:41
TAP1:
52:F3:12:E4:6D:A9
TAP2:
72:17:32:32:15:F8
Regards,
Shyam
From: ext Gurucharan Shetty [mailto:shet...@n
Hi,
On 2015年07月17日 06:40, Ben Pfaff wrote:
> On Thu, Jul 16, 2015 at 02:31:10PM +0900, Minoru TAKAHASHI wrote:
>> Maybe I’ve found a problem on "ofputil_encode_group_desc_request" of
>> ofp-util.c.
>> According to the OFspec v1.5, the last element of
>> ofp_group_multipart_request has to be fill
Thanks a lot!
But we hardly to upgrade the OVS in the env due to some restrict , is there any
other method to solve it? If possible, could I disable something to prevent
the error prompts in the log?
Or Who can explain here why this error occurs ? What possibly reason will
result in it? Does
Hi,
Can you tell me how to enable the mergeable feature in ovs?
BR
2015-07-17 11:04 GMT+08:00 Ouyang, Changchun :
>
>
> On 7/16/2015 9:45 PM, Traynor, Kevin wrote:
>
> (re-adding the ovs-discuss list)
>
>
>
> This might be better on the dpdk dev mailing list. For the OVS part, see
> this threa
On Fri, Jul 17, 2015 at 10:19:46PM +0530, Abhishek Verma wrote:
> Hi Ben,
>
> I understand its exasperating for you and other veterans to respond to
> questions like forwarding not working, etc. However, i did enough googling
> and i really couldnt, and am still unable to, figure out the real prob
Hi Ben,
I understand its exasperating for you and other veterans to respond to
questions like forwarding not working, etc. However, i did enough googling
and i really couldnt, and am still unable to, figure out the real problem.
I am trying to see why the L3 packet is not going out and i see this
On Fri, Jul 17, 2015 at 01:38:38PM +0900, Minoru TAKAHASHI wrote:
> For starters, I've created patches that fixes the following problem.
>
> >> I’ve checked the source code of "ofputil_encode_group_desc_request", such
> >> a process it could not find.
> >>
> >> * ofputil_encode_group_desc_reque
I'm noticing that *every* *single* *email* from this list gets dumped into
Google Mail's Spam folder, because of a typo in the SPF record.
Received-SPF: fail (google.com: domain of
discuss-boun...@openvswitch.org does not designate
2600:3c00::f03c:91ff:fe6e:bdf7 as permitted sender) client-ip=
>
On Mon, Jul 13, 2015 at 1:06 AM, David Reade wrote:
> Good morning all!
>
> I am using XenServer 6.5 SP1 with OpenVSwitch 2.1.3 and I need to mirror
> traffic from the source port (vif2.0) to the destination port (vif13.1). I
> have enabled promiscuous mode on the PIF and target VIF. Using the f
Anyone?
-Original Message-
From: David Reade
Sent: 13 July 2015 09:07
To: 'discuss@openvswitch.org'
Subject: Traffic Mirroring using XenServer and OpenVSwitch
Good morning all!
I am using XenServer 6.5 SP1 with OpenVSwitch 2.1.3 and I need to mirror
traffic from the source port (vif2.0
If the packets Mac address matches that of the ovs bridge, the packet would
be accepted by the bridge. Can you try the below
Create an SNAT rule using iptables and snat the packets with VM B's IP
address.
(Use -v option on iptables to see the rule hit counters) Use route command
and set a default r
### Q: I have a sophisticated network setup involving Open vSwitch, VMs or
multiple hosts, and other components. The behavior isn't what I
expect. Help!
A: To debug network behavior problems, trace the path of a packet,
hop-by-hop, from its origin in one host to a remote host. If
th
Nope. The code changes so fast that I think it is really hard to
maintain a manual.
On Fri, Jul 17, 2015 at 1:21 AM, Abhishek Verma
wrote:
> Hi,
>
> Is there a programmer's guide or some reference material that i could
> browse/read to get a handle on how open vswitch code has been organized and
I re-read your question properly again. The behavior that you see looks
correct to me. OVS is a switch and switch's ports don't have mac addresses.
It only cares about the mac addresses in the packet.
On Fri, Jul 17, 2015 at 12:13 AM, Pujar, Shyam (Nokia - IN/Bangalore) <
shyam.pu...@nokia.com> wr
I have set /proc/sys/net/ipv4/ip_forward=1 and have ensured that this is
set to 1 for all the participating ports.
I send the packet with the OVS bridge's MAC address. This means that when
the GRE header is popped off, the packet's dest MAC is the same as that of
the OVS bridge. I now expect the l
Hi,
I have installed OVS 2.3.2-1 on a Debian Wheezy(7.8) maschine. Two
interfaces (eth1 and eth2) are connected to bridge 0:
--- schnip ---
root@SOF:~# ovs-ofctl -O OpenFlow13 show br0
OFPT_FEATURES_REPLY (OF1.3) (xid=0x2): dpid:aa19
n_tables:254, n_buffers:256
capabilities: FLOW_STA
Hi,
Is there a programmer's guide or some reference material that i could
browse/read to get a handle on how open vswitch code has been organized and
works?
Thanks, Abhishek
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman
24 matches
Mail list logo
