On Jun 26, 2012, at 10:25 PM, Weifeng Zhang wrote:
> I DO notice that OVS uses kernel route to forward the packets. But generally
> the host OS will only maintain host route and default route. On a server
> which OVS is embedded, it may be enough.
> But we are implementing a independent switch dev
Hi Justin, thanks for the reply.
I DO notice that OVS uses kernel route to forward the packets. But generally
the host OS will only maintain host route and default route. On a server
which OVS is embedded, it may be enough.
But we are implementing a independent switch device with ASIC chip, which
s
In the Linux kernel module, the packet is given to the host OS, which uses its
native routing table. OVS, itself, doesn't have any knowledge of the L3
network. Presumably, if you're using OpenFlow, the system has some concept of
L3 connectivity in order to connect to the controller over TCP.
On an OVS and openflow enabled switch, GRE-tunnel is supported. Let's assume
one packet comes in and hits a flow entry,
the action is forwarded to a GRE tunnel. After GRE tunnel encapsulation, a
new tunnel header is added. How should the encapsulated packet
be forwarded? By route or by manually s
I have setup a simple ovs scenario like this:
VirtualBox Linux in bare-metal
__ _
VM1 - eth0 | --br0p0---|-port5port0 |-- (br0 internal)
| | br0 bridge |
VM2 - eth1 | --b
On Tue, Jun 26, 2012 at 03:01:20PM -0300, Lucas Brasilino wrote:
> I'm trying to setup a trunk port to send VLAN's tagged frames from
> OVS to a VM, so inside the VM I gonna use
> VLAN Linux support (8021q kernel module along with vconfig tool).
Did you read the FAQ? It has an extensive section
Hi All:
I'm trying to setup a trunk port to send VLAN's tagged frames from
OVS to a VM, so inside the VM I gonna use
VLAN Linux support (8021q kernel module along with vconfig tool).
I'm facing a very strange behaviour which I'm investigating without
much success, even after a lot of googling.
I
On Tue, Jun 26, 2012 at 02:43:54PM +, Ed Maste wrote:
> On FreeBSD sig_atomic_t is long, which causes the comparison in
> fatal_signal_run to be true when no signal has been reported.
>
> Signed-off-by: Ed Maste
Thank you! I pushed this to master and branch-1.[765432].
_
On FreeBSD sig_atomic_t is long, which causes the comparison in
fatal_signal_run to be true when no signal has been reported.
Signed-off-by: Ed Maste
---
lib/fatal-signal.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/fatal-signal.c b/lib/fatal-signal.c
index ff
