Hi, The developer has updated this issue: "Just to mention: our machines are back again, altough network connectivity isn't as good as it should be. I have opened a service request (ticket #93 <http://techsupport.creatifi.eu/issues/93>) I was thinking on the issue... How is the floating IP assigned to the node? doing a simple ifconfig does not show the public IP on the node. So there must be an upper layer (OpenStack Neuron, I guess) who redirects the traffic from the public floating to the inner private... We are surely needing some port redirection on our project, and we should know if we are going to face any kind of restrictions this way to rethink our strategy. Thank you," 2015-02-27 10:34 GMT+01:00 Xavier Carol Rossell <xavier.carol at i2cat.net>: > The developer i s working on the Budapest node. > > KR > > 2015-02-27 9:18 GMT+01:00 Xavier Carol Rossell <xavier.carol at i2cat.net>: > >> Hi, >> >> Developer added more information to this issue. >> >> >> This afternoon machines were accessible again, but after doing some >> iptables operations, servers are unavailable again. This is what we've done: >> >> 1. We have one server, lb.alquimia.io, with a floating IP and a public >> internal >> 2. We have a couple of backend servers with public internal >> 3. We pass on traffic to some ports on the frontend to the backend >> servers. To simulate this behavior, we are redirecting some ssh traffic on >> the head to the ssh on the backends. >> 4. This is what we do: >> >> root at sf-appserver1:~# echo "1" > /proc/sys/net/ipv4/ip_forward >> root at sf-appserver1:~# iptables -t nat -A PREROUTING -p tcp --dport 22022 >> -j DNAT --to-destination 10.10.13.102:22 >> root at sf-appserver1:~# iptables -t nat -A PREROUTING -p tcp --dport 22023 >> -j DNAT --to-destination 10.10.13.105:22 >> root at sf-appserver1:~# iptables -t nat -A POSTROUTING -j MASQUERADE >> >> where 10.10.13.102 and 105 are the backends. >> >> I have been able to work for five minutes on the servers, but then ssh >> client has became unresponsive, and servers are NOT appearing again on the >> cloud.lab webpage. In fact, NOTHING is being displayed on the cloud.lab >> portal: no images, no floating IPs, no keypairs, no security groups. >> >> I would say that there is a link between the 'iptables' commands and the >> connectivity problems, but I cannot even imagine what is the problem. I >> have done this 'iptables' trick in other virtualized environments without >> problems :/ >> >> Thanks, >> >> i- >> >> >> >> >> 2015-02-26 9:21 GMT+01:00 Xavier Carol Rossell <xavier.carol at i2cat.net>: >> >>> Hello, >>> >>> We are experiencing difficulties in accessing our machines via SSH. >>> It is returning a time out "no route to host" error. We tried accessing >>> from three different computers using different connections. >>> >>> We checked them in FiwareLab interface and they are there, running. >>> However, the interface itself took some time to display the machines >>> (something that didn't happen before). >>> >>> Regards. >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-creatifi-coaching/attachments/20150302/83dd8c60/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy