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.vic...@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 <gera...@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@lists.openstack.org >> Unsubscribe : >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack