If you take a close look at these two bridges (ovs-vsctl show), you'll see that they are connected to each other using a 'virtual' patch port. The reason why both exist (and are virtually connected) becomes clearer when you dump the openflow table on one of the hypervisors (ovs-ofctl dump-flows br-tun). Depending on the number of VM's you are running on this compute host, there will be corresponding openflow rules to translate VLAN ID's to GRE tunnels. This would look something like:

cookie=0x0, duration=422.357s, table=0, n_packets=82, n_bytes=10443, idle_age=31, priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x2,NORMAL

For return traffic, you'll see another openflow rule that ensures that the GRE to br-int (local) VLAN mapping can be performed as well. The patch cable is again used to ensure the now VLAN tagged traffic arrives back at the guest. The following OpenFlow entry ensures that ingress traffic with the specified destination MAC will get tagged with VLAN 1 before getting patched to br-int.

 cookie=0x0, duration=421.948s, table=0, n_packets=64, n_bytes=8337, idle_age=31, priority=3,tun_id=0x2,dl_dst=fa:16:3e:dd:c1:62 actions=mod_vlan_vid:1,NORMAL

For further information, check out this excellent document (my examples came from here):

http://openstack.redhat.com/Networking_in_too_much_detail (http://openstack.redhat.com/Networkin...)

And for further details on ovs patch ports:

http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-patch-ports/ (http://blog.scottlowe.org/2012/11/27/...)