[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] Re :  Re : Re : ip_gre_mod.ko module
From:       darkbls () yahoo ! com (DarkBls)
Date:       2010-06-29 6:43:18
Message-ID: 855089.4905.qm () web23705 ! mail ! ird ! yahoo ! com
[Download RAW message or body]

Hi.

My need is more complex than that.

I have several set of VM per hypervisor with several VLAN per VM set (data, app, \
admin, cluster ...).

What I plan to do :

Having a central server with a bridge. 
Each hypervisor own two bridges per VM set (for primary and secondary links path in \
VM through kernel bonding like on ther physical counterpart). Each of thoses bridges \
are GRE connected to the central bridge with their own GRE key.

With this "star" topology, a physical server need exactly 2 hop to reach any other \
physical servers.

I tried for now with just two servers with 802.1Q and GRE with key and it works. Need \
to try a full star architecture now.





________________________________
De : Dan Wendlandt <dan at nicira.com>
? : DarkBls <darkbls at yahoo.com>
Cc : discuss <discuss at openvswitch.org>
Envoy? le : Mar 29 juin 2010, 1h 53min 49s
Objet : Re: [ovs-discuss] Re : Re : ip_gre_mod.ko module




On Fri, Jun 25, 2010 at 6:03 AM, DarkBls <darkbls at yahoo.com> wrote:

Il fix the problem, thank you for your help. I gave another IP / physical interface \
for the tunnel.
> 
> I still have some questions about GRE Tunneling.
> 
> For now I have:
> 
> On phosphorus (eth0:192.168.93.201 / eth1:172.16.0.201)
> br0 (tap0 + gre0 -> 172.16.0.202)
> 
> On sulphur: (eth0:192.168.93.202 / eth1:172.16.0.202)
> br0 (tap0 + gre0 -> 172.16.0.201)
> 
> A VM on phosphorus can ping a Vm on sulphur through the GRE tunnel.
> 
> What if I want to make several br (br1, br2 and br3) on phosphorus and I want them \
> to be connected through their own GRE tunnel on their sulphur counterpart (br1, br2 \
> and br3) only ? 


Do you want to have multiple bridges on each server just to isolate one set of VMs \
from another set of VMs?  If so, you could just have a single bridge on each server \
joined by a single tunnel (like your initial example) but place each set of VMs on a \
different VLAN for isolation.  The GRE tunnel will carry the VLAN tagged traffic \
between the two bridges and the switch at either end will enforce the VLAN isolation.

dan  
 

> 
> 
> 
> 
> 
________________________________
 De : Jesse Gross <jesse at nicira.com>
> 
> ? : DarkBls <darkbls at yahoo.com>
> Cc : Justin Pettit <jpettit at nicira.com>; discuss at openvswitch.org
> Envoy? le : Mar 22 juin 2010, 0h 01min 22s
> Objet : Re: [ovs-discuss] Re : ip_gre_mod.ko module
> 
> 
> 
> On Mon, Jun 21, 2010 at 3:47 AM, DarkBls <darkbls at yahoo.com> wrote:
> > > 
> > 
> > ovs-vsctl --db=tcp:192.168.93.201:1977 create interface name=gre0 type=gre \
> > options:remote_ip=192.168.93.204
> > > > e29c391b-2e07-4a2e-95de-99cf6f23158d
> > > > ovs-vsctl --db=tcp:192.168.93.201:1977 create port name=gre0 \
> > > > interfaces=[e29c391b-2e07-4a2e-95de-99cf6f23158d] \
> > > > 01c689e2-ecab-4ee6-8902-6aba2efe2deb ovs-vsctl --db=tcp:192.168.93.201:1977 \
> > > > add bridge br0 ports 01c689e2-ecab-4ee6-8902-6aba2efe2deb
> > 
> 
> 
> All this looks fine.
> > 
> 
> > > > I must have missed something since I don't see any port 47 opened on any \
> > > > server
> > 
> 
> 
> GRE runs over IP protocol 47, not TCP or UDP port 47 so you won't see it listed  in \
> netstat -l. 
> 
> Since a flow is being setup that is sending traffic to the GRE port the \
> configuration should be fine.  Can you do a tcpdump on the physical interface to \
> see if there is GRE traffic?  Is it possible that something like iptables is \
> blocking GRE traffic? 
> _______________________________________________
> > discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
> 
> 


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/discuss/attachments/20100629/8cb124ae/attachment.htm>



[prev in list] [next in list] [prev in thread] [next in thread]