[Openstack] Help With Quantum Networking - Interesting Use Case

Geraint Jones geraint at koding.com
Sat Aug 24 00:07:45 UTC 2013


I have checked the routes where I think it makes sense.

I.e Server A can reach Server B and vice versa (otherwise OSPF would not
work)

It is like the packet it exiting Server B's eth0 and is then being
suppressed..

Server A knows where the LXC is as I can see the packet leave Server A and
arrive on Server B, I can then see the reply leave Server B but it never
reaches Server A.

On 23/08/13 5:04 PM, "Victor Palma" <palma.victor at gmail.com> wrote:

>This might be a bit silly, but have you checked your routes?
>
>Regards,
>Victor Palma
>
>
>On Aug 23, 2013, at 6:28 PM, Geraint Jones <geraint at koding.com> wrote:
>
>> Hi
>> 
>> I have an interesting use case for quantum networking
>> 
>> This is the example :
>> 
>> Server A eth0 10.1.1.1 (http proxy)
>> Server B eth0 10.1.1.2 (runs LXC VM's)
>> Server B lxc-br 10.1.2.0/24 (the LXC's get addresses here)
>> 
>> Server A and B run OSPF so server A knows 10.1.2.0/24 is behind
>>10.1.1.2. (We have more than just A and B hence the useage of OSPF)
>> 
>> If I ping 10.1.2.1 from Server A it fails.
>> If I ping Server A from a VM with IP 10.1.2.1 then it works, however
>>looking at the tcpdump the source of the VM's ICMP is rewritten to
>>Server B's eth0 address.
>> 
>> Digging a bit deeper I see this on Server B when pinging from Server A
>>to an LXC
>> 
>> tcpdump -i eth0 host 10.1.2.1
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>> 13:49:52.850764 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 25672,
>>seq 387, length 64
>> 13:49:52.850878 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 25672, seq
>>387, length 64
>> 13:49:53.850600 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 25672,
>>seq 388, length 64
>> 13:49:53.850710 IP 10.1.2.1 > 10.1.1.1: ICMP echo reply, id 25672, seq
>>388, length 64
>> 
>> And this is what I see on Server A
>> 
>> tcpdump -i eth0 icmp
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>> 13:53:41.852613 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 25672,
>>seq 616, length 64
>> 13:53:42.852603 IP 10.1.1.1 > 10.1.2.1: ICMP echo request, id 25672,
>>seq 617, length 64
>> 
>> So the ICMP is getting to the VM without being rewritten, and the reply
>>is being sent to Server A but something is dropping it in transit - I
>>suspect its Open vSwitch GRE...
>> 
>> If anyone can shed any light on this and if there is something I can do
>>to stop this that would be awesome, We have been doing the on AWS
>>however we have had to create GRE tunnels there inside the instances to
>>make it work, We would love it if we didnt have to do that :)
>> _______________________________________________
>> Mailing list: 
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : 
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack






More information about the Openstack mailing list