Thanks a lot Reid. That was one awesome explanation. Few more questions:
1) In the first figure VMs can not communicate with the outside world (except
using NAT) ?
2) (Sorry if this is very basic stuff) Do the ports have any addresses (like
MAC or IP) in either physical or real bridges/switche
I drew a little ascii art, does this clarify things?
Hypervisor
++
| |
+-- | -- iface <--+
Sent from my iPhone
On May 19, 2012, at 19:02, faicker mo wrote:
>
> On 2012-5-19, at 下午11:11, Ben Pfaff wrote:
>
>> On Sat, May 19, 2012 at 09:30:40PM +0800, faicker mo wrote:
>>> I have viewed the ovs-ofctl man page, I found that the arp match has
>>> only arp_sha and arp_dha. It can't mat
On 2012-5-19, at 下午11:11, Ben Pfaff wrote:
> On Sat, May 19, 2012 at 09:30:40PM +0800, faicker mo wrote:
>> I have viewed the ovs-ofctl man page, I found that the arp match has
>> only arp_sha and arp_dha. It can't match the source ip in arp(SPA) and
>> destination ip(DPA) in arp. Without this, t
On Sat, May 19, 2012 at 09:30:40PM +0800, faicker mo wrote:
> I have viewed the ovs-ofctl man page, I found that the arp match has
> only arp_sha and arp_dha. It can't match the source ip in arp(SPA) and
> destination ip(DPA) in arp. Without this, the arp spoofing can't be
> prevented.
Use nw_src
I have viewed the ovs-ofctl man page, I found that the arp match has only
arp_sha and arp_dha. It can't match the source ip in arp(SPA) and destination
ip(DPA) in arp. Without this, the arp spoofing can't be prevented.
OVS replaces the bridge default in kernel. Ebtables can't work. But no
