On Mon, Mar 31, 2014 at 9:35 AM, Shivaramakrishnan Vaidyanathan
<[email protected]> wrote:
> Thanks again,
> I didnt upload the ovs-vsctl output:
>
> Here is my output:
>
> root@compute1:~# ovs-vsctl show
>
> 024fd441-d809-4c1d-a023-08442afa9782
>
>     Bridge "virbr1"
>
>         Port "virbr1"
>
>             Interface "virbr1"
>
>                 type: internal
>
>         Port "eth0"
>
>             Interface "eth0"
>
>         Port "gre1"
>
>             Interface "gre1"
>
>                 type: gre
>
>                 options: {remote_ip="128.6.60.45"}
>
>         Port pubif
>
>             Interface pubif
>
>                 type: internal
>
>                 options: {link_speed="10M"}
>
>     Bridge "virbr3"
>
>         Port "vnet0"
>
>             Interface "vnet0"
>
>         Port "gre2"
>
>             Interface "gre2"
>
>                 type: gre
>
>                 options: {remote_ip="a.b.c.d"}
a.b.c.d is not a valid ip address.
>
>         Port "vnet1"
>
>             Interface "vnet1"
>
>         Port "virbr3"
>
>             Interface "virbr3"
>
>                 type: internal
>
>     Bridge "virbr2"
>
>         Port "virbr2"
>
>             Interface "virbr2"
>
>                 type: internal
>
>         Port "gre0"
>
>             Interface "gre0"
>
>                 type: gre
>
>                 options: {remote_ip="a.b.c.d"}
same here.
>
>     ovs_version: "1.10.2"
>
>
>
>
>
> On Mon, Mar 31, 2014 at 12:29 PM, Gurucharan Shetty <[email protected]>
> wrote:
>>
>> On Mon, Mar 31, 2014 at 9:20 AM, Shivaramakrishnan Vaidyanathan
>> <[email protected]> wrote:
>> > Thanks a lot Gurucharan.
>> > I am pretty new to openvswitch.Can you provide the command to achieve
>> > this?
>> > Looking forward to your reply.
>>
>> The man page says:
>> ....
>> ....
>> Tunnel Options:
>>        These options apply to interfaces with type of gre,  ipsec_gre,
>> gre64,
>>        ipsec_gre64, vxlan, and lisp.
>>
>>        Each  tunnel  must  be  uniquely identified by the combination of
>> type,
>>        options:remote_ip, options:local_ip, and options:in_key.  If two
>> ports
>>        are defined that are the same except one has an optional identifier
>> and
>>        the  other  does  not,  the  more  specific  one  is   matched
>> first.
>>        options:in_key  is  considered more specific than options:local_ip
>> if a
>>        port defines one and another port defines the other.
>> ....
>> ...
>> options : key: optional string
>>               Optional.  Shorthand to set in_key and out_key at the same
>> time.
>> ...
>> ...
>>
>> So you can do something like:
>> * If you create a new tunnel (the key should be same at both ends and
>> a different key at the other end):
>> ovs-vsctl add-port virbr3 gre2 -- set interface gre2 type=gre
>> options:remote_ip:p.q.r.s options:key=30
>>
>> (note that your command does not have a '=' and instead has a ':'.
>> Also your "ovs-vsctl show" does not print any o/p)
>>
>> * Or just add a key to a existing tunnel
>> ovs-vsctl set interface gre0 options:key=20
>>
>> If you can't debug well, start with a simpler configuration. i.e., a
>> single gre tunnel. Once you get that working, you can build on top of
>> it.
>>
>> >
>> >
>> > On Mon, Mar 31, 2014 at 12:15 PM, Gurucharan Shetty <[email protected]>
>> > wrote:
>> >>
>> >> On Mon, Mar 31, 2014 at 9:12 AM, Shivaramakrishnan Vaidyanathan
>> >> <[email protected]> wrote:
>> >> > So in that case,essentially we cant have multiple gre tunnels?
>> >> I think you can use unique keys to distinguish (Read "Tunnel Options"
>> >> in "man ovs-vswitchd.conf.db").
>> >>
>> >> > Though I have multiple bridges that vm's  to communicate between each
>> >> > other.
>> >> > The requirement is I need to have multiple internal bridges for vm's
>> >> > and
>> >> > just one external bridge.
>> >> > Is there any alternative?
>> >> >
>> >> >
>> >> > On Mon, Mar 31, 2014 at 11:44 AM, Gurucharan Shetty
>> >> > <[email protected]>
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Mar 31, 2014 at 8:36 AM, Shiva
>> >> >> <[email protected]>
>> >> >> wrote:
>> >> >> > Hello,
>> >> >> >
>> >> >> > I am setting up two gre tunnels between two hosts using the same
>> >> >> > external
>> >> >> > bridge.In this case (br1).I use virbr3 and virbr2 for internal
>> >> >> > communication.
>> >> >> >
>> >> >> > This is my config steps:
>> >> >> > Hypervisor 1:
>> >> >> > External communication
>> >> >> > ovs-vsctl add-br br1
>> >> >> > ovs-vsctl add-port eth0
>> >> >> > ifconfig br1 p.q.r.s netmask 255.255.255.0
>> >> >> >
>> >> >> > Internal bridge for vm communication
>> >> >> > Tunnel1 :
>> >> >> >
>> >> >> > ovs-vsctl add-br virbr3
>> >> >> > ovs-vsctl show
>> >> >> > ovs-vsctl add-port virbr3 gre2 -- set interface gre2 type=gre
>> >> >> > options:remote_ip:a.b.c.d
>> >> >> >
>> >> >> > Tunnel2:
>> >> >> >
>> >> >> > ovs-vsctl add-br virbr2
>> >> >> > ovs-vsctl show
>> >> >> > ovs-vsctl add-port virbr2 gre0 -- set interface gre0 type=gre
>> >> >> > options:remote_ip:a.b.c.d
>> >> >> Consider the case for the traffic coming into Hypervisor1. I don't
>> >> >> think it is possible to figure out which of the two end points the
>> >> >> packet needs to be delivered to because the 2 gre tunnels are not
>> >> >> unique.
>> >> >>
>> >> >> I think if you delete one of your virbr* in each of the machines,
>> >> >> you
>> >> >> should be able to communicate.
>> >> >>
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > Hypervisor 2:
>> >> >> > External communication
>> >> >> > ovs-vsctl add-br br1
>> >> >> > ovs-vsctl add-port eth0
>> >> >> > ifconfig br1 a.b.c.d netmask 255.255.255.0
>> >> >> >
>> >> >> > Internal bridge for vm communication
>> >> >> >
>> >> >> > Tunnel1:
>> >> >> >
>> >> >> >
>> >> >> > ovs-vsctl add-br virbr3
>> >> >> > ovs-vsctl show
>> >> >> > ovs-vsctl add-port virbr3 gre2 -- set interface gre2 type=gre
>> >> >> > options:remote_ip:p.q.r.s
>> >> >> >
>> >> >> > Tunnel2:
>> >> >> >
>> >> >> > ovs-vsctl add-br virbr2
>> >> >> > ovs-vsctl show
>> >> >> > ovs-vsctl add-port virbr3 gre0 -- set interface gre0 type=gre
>> >> >> > options:remote_ip:p.q.r.s
>> >> >> >
>> >> >> >
>> >> >> > I am not able to communicate outside world from the vm's.I am just
>> >> >> > able
>> >> >> > to
>> >> >> > reach the host on which vm resides and viceversa.Can you please
>> >> >> > let
>> >> >> > me
>> >> >> > know
>> >> >> > what am i missing here?
>> >> >> >
>> >> >> > Your help in this regard is greatly appreciated.
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > discuss mailing list
>> >> >> > [email protected]
>> >> >> > http://openvswitch.org/mailman/listinfo/discuss
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to