Can't you just create multiple GRE tunnels to the multiple private networks? The physical interface connected to the private network does not need to be attached to the bridge.
--Justin On Apr 14, 2011, at 8:06 PM, benzwt benzwt wrote: > Thanks for you help. I have established a GRE tunnel across two > private networks. > > By the way, it is possible to create multiple GRE which across three > or more private networks ? > The first thing comes to my mind is I would have to create multiple bridge. > And the ovs-ifup script is another problem because it has only one bridge. > > Please give me some advise for creating multiple GRE tunnel > > > On Tue, Apr 12, 2011 at 1:29 PM, Justin Pettit <[email protected]> wrote: >> Based on your routing table, I'm guessing that you still have an IP address >> on eth0. Try clearing it on both sides with: >> >> ifconfig eth0 0 >> >> Your default route is still trying to go out eth0, so you may need to adjust >> that if removing the IP address from eth0 doesn't automatically do it. >> >> --Justin >> >> >> On Apr 11, 2011, at 10:13 PM, benzwt benzwt wrote: >> >>> Thank for you guys reply so quickly. After I receive your suggestion. >>> >>> I try to bind ip on br0 (or should i create a internal interface vifn >>> on br0 then bind ip on vif0??) >>> >>> ifconfig br0 192.168.200.5 on host2 >>> ifconfig br0 192.168.100.5 on host1 >>> but found that I can't ping these ip from other side!! >>> then create gre interface >>> ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre >>> options:remote_ip=192.168.200.5 on host1 >>> ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre >>> options:remote_ip=192.168.100.5 on host2 >>> I think remote_ip is the key point. how to define and setup remote_ip >>> is most import thing of gre tunnel. >>> I still not got it worked. Can anyone help me? >>> below is route -n >>> host1:(10.10.10.1) >>> Destination Gateway Genmask Flags Metric Ref Use >>> Iface >>> 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 >>> 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 >>> >>> >>> 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 >>> 0.0.0.0 192.168.100.254 0.0.0.0 UG 100 0 0 eth0 >>> host2:(10.10.10.2) >>> Destination Gateway Genmask Flags Metric Ref Use >>> Iface >>> 192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 >>> 192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 >>> >>> 10.129.7.0 0.0.0.0 255.255.255.0 U 2 0 0 >>> wlan0 >>> 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 >>> 0.0.0.0 192.168.200.254 0.0.0.0 UG 100 0 0 eth0 >>> >>> vm in host1: >>> Destination Gateway Genmask Flags Metric Ref Use >>> Iface >>> 10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 >>> >>> 0.0.0.0 10.10.10.254 0.0.0.0 UG 100 0 0 eth0 >>> vm in host2: >>> Destination Gateway Genmask Flags Metric Ref Use >>> Iface >>> >>> 10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 >>> 0.0.0.0 10.10.10.254 0.0.0.0 UG 100 0 0 eth0 >>> router: >>> Destination Gateway Genmask Flags Metric Ref Use >>> Iface >>> 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 >>> 192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 >>> 0.0.0.0 192.168.100.254 0.0.0.0 UG 100 0 0 eth0 >>> >>> >>> 0.0.0.0 192.168.200.254 0.0.0.0 UG 100 0 0 eth1 >>> >>> >>> On Mon, Apr 11, 2011 at 2:12 PM, Justin Pettit <[email protected]> wrote: >>>> My guess is that the IP addresses were on eth0 on the two hosts. Those >>>> aren't meaningful once you've attached them to the bridge. You probably >>>> want to assign the IP address to the bridge (br0) on the two hosts. >>>> Alternatively, if the VMs are only going to communicate over the tunnel, >>>> you could not attach the eth0 devices to the bridges; the hosts' IP stacks >>>> will take care of getting the packets to the physical NICs. >>>> >>>> --Justin >>>> >>>> >>>> On Apr 10, 2011, at 10:25 PM, benzwt benzwt wrote: >>>> >>>>> Dear openvswitch developers, >>>>> >>>>> we have 2 hosts, host1 is 192.168.100.1 the other is host2 192.168.200.2 >>>>> >>>>> host1 has a vm 10.10.10.1 >>>>> host2 has a vm 10.10.10.3 >>>>> between host1 and host2, I use quagga as a router(PC). >>>>> I can ping 192.168.100.1 from 192.168.200.2, also can ping >>>>> 192.168.200.2 from 192.168.100.1 >>>>> >>>>> I set the GRE tunnel as followings: >>>>> ********************************************************************************************* >>>>> on both hosts >>>>> a. rmmod bridge and insmod ovs module >>>>> b. start ovs >>>>> c. add br0 , add eth0 into br0 ( I found that after add eth0, I >>>>> can't do step 1.) >>>>> d. add tap0 into br0 >>>>> >>>>> 1. ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre >>>>> options:remote_ip=192.168.100.1 ( on host2) >>>>> 2. ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre >>>>> options:remote_ip=192.168.200.2 ( on host1) >>>>> ********************************************************************************************* >>>>> >>>>> Finally I can't ping host2's vm 10.10.10.3 from host1's vm 10.10.10.1 >>>>> or ping host1's vm 10.10.10.3 from host1's vm 10.10.10.1 >>>>> >>>>> If I connect these hosts in on a switch(physical) without going >>>>> through a router(PC), I can ping host2's vm 10.10.10.3 from host1's vm >>>>> 10.10.10.1 or ping host1's vm 10.10.10.3 from host1's vm 10.10.10.1 >>>>> Is anything steps that I have missed ? >>>>> >>>>> the ovs-ofctl show on host1: >>>>> root@panda109:~# ovs-ofctl show br0 >>>>> OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:000000bc305bbe9354 >>>>> n_tables:2, n_buffers:256 >>>>> features: capabilities:0x87, actions:0xfff >>>>> 1(eth0): addr:c6:b3:af:1d:4b:02, config: 0, state:0 >>>>> current: 1GB-FD COPPER AUTO_NEG >>>>> advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD AUTO_NEG >>>>> supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD COPPER >>>>> AUTO_NEG >>>>> 2(tap0): addr:bc:30:5b:be:93:54, config: 0, state:0 >>>>> current: 10MB-FD COPPER >>>>> 3(gre0): addr:00:23:20:bd:fd:e4, config: 0, state:0 >>>>> LOCAL(br0): addr:bc:30:5b:be:93:54, config: 0x1, state:0x1 >>>>> OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0 >>>>> >>>>> >>>>> the ovs-ofctl show on host2 : >>>>> >>>>> root@panda109:~# ovs-ofctl show br0 >>>>> OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:00000016d43b0127 >>>>> n_tables:2, n_buffers:256 >>>>> features: capabilities:0x87, actions:0xfff >>>>> 1(eth0): addr:00:16:d4:3b:01:27, config: 0, state:0 >>>>> current: 1GB-FD COPPER AUTO_NEG >>>>> advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD AUTO_NEG >>>>> supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD COPPER >>>>> AUTO_NEG >>>>> 2(tap0): addr:62:9f:88:ea:72:a9, config: 0, state:0 >>>>> current: 10MB-FD COPPER >>>>> 3(gre0): addr:00:23:20:f6:01:97, config: 0, state:0 >>>>> LOCAL(br0): addr:00:16:d4:3b:01:27, config: 0x1, state:0x1 >>>>> OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0 >>>>> >>>>> On Sat, Apr 9, 2011 at 12:58 AM, Ben Pfaff <[email protected]> wrote: >>>>>> On Fri, Apr 08, 2011 at 03:13:57PM +0800, benzwt benzwt wrote: >>>>>>> I have surfed an tutorial about create GRE using OVS. >>>>>> >>>>>> Can you direct us to this tutorial? Perhaps we can get it fixed. >>>>>> >>>>>>> The commands are as follows: >>>>>>> >>>>>>> ovs-vsctl create interface type=gre name =gre0 >>>>>>> option="remote_ip=x.x.x.x" >>>>>>> >>>>>>> But, the latest ovs-vsctl(build from lastest snapshot) doesn't have >>>>>>> the option "create". >>>>>> >>>>>> The "create" command is still there. I think that you must be >>>>>> misinterpreting an error message. >>>>>> >>>>>>> Where can I get the latest documentation about setting up GRE tunnel ? >>>>>> >>>>>> Here's a command that should work: >>>>>> ovs-vsctl -- add-port br0 gre0 \ >>>>>> -- set Interface gre0 type=gre options:remote_ip=1.2.3.4 >>>>>> >>>>> _______________________________________________ >>>>> discuss mailing list >>>>> [email protected] >>>>> http://openvswitch.org/mailman/listinfo/discuss >>>> >>>> >> >> _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
