On Apr 30, 2013, at 7:09 PM, Ahmad Emneina <aemne...@gmail.com> wrote:

> What version cloudstack are you running. First time hearing of this issue, 
> I'd imagine its a bug.

4.0.1 from Ubuntu package. 

Hosts are XS 6.0.2 fully patched up. Don't know if it makes a difference but I 
don't recall having this problem when I did not use network bonds. 

> 
> Ahmad
> 
> On Apr 30, 2013, at 6:32 PM, Carlos Reategui <create...@gmail.com> wrote:
> 
>> I decided to stop iptables on the host and now the SSVM works and is able
>> to get to DNS and download the default Centos template.  Is this a known
>> issue?
>> 
>> This is what it looked like before I stopped it:
>> 
>> [root@srvengxen01 ~]# iptables -L
>> Chain INPUT (policy ACCEPT)
>> target     prot opt source               destination
>> RH-Firewall-1-INPUT  all  --  anywhere             anywhere
>> 
>> Chain FORWARD (policy ACCEPT)
>> target     prot opt source               destination
>> RH-Firewall-1-INPUT  all  --  anywhere             anywhere
>> 
>> Chain OUTPUT (policy ACCEPT)
>> target     prot opt source               destination
>> 
>> Chain RH-Firewall-1-INPUT (2 references)
>> target     prot opt source               destination
>> ACCEPT     all  --  anywhere             anywhere
>> ACCEPT     icmp --  anywhere             anywhere            icmp any
>> ACCEPT     esp  --  anywhere             anywhere
>> ACCEPT     ah   --  anywhere             anywhere
>> ACCEPT     udp  --  anywhere             224.0.0.251         udp dpt:mdns
>> ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipp
>> ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ipp
>> ACCEPT     udp  --  anywhere             anywhere            udp dpt:bootps
>> ACCEPT     all  --  anywhere             anywhere            state
>> RELATED,ESTABLISHED
>> ACCEPT     udp  --  anywhere             anywhere            state NEW udp
>> dpt:ha-cluster
>> ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp
>> dpt:ssh
>> ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp
>> dpt:http
>> ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp
>> dpt:https
>> REJECT     all  --  anywhere             anywhere            reject-with
>> icmp-host-prohibited
>> 
>> 
>> 
>> On Tue, Apr 30, 2013 at 6:19 PM, Carlos Reategui <create...@gmail.com>wrote:
>> 
>>> Looks like my previous email only went to Ahmad...
>>> 
>>> To add to my below response.  I also installed bind9 on my management
>>> server and set it up as a caching dns to rule out issues with our corporate
>>> MS dns servers and still does not work.
>>> 
>>> 
>>> 
>>> On Tue, Apr 30, 2013 at 3:41 PM, Carlos Reategui <car...@reategui.com>wrote:
>>> 
>>>> 
>>>> On Tue, Apr 30, 2013 at 3:18 PM, Ahmad Emneina <aemne...@gmail.com>wrote:
>>>> 
>>>>> looks like you cant route out to the internet. can you ping 8.8.8.8
>>>>> directly from the ssvm?
>>>> 
>>>> Network connectivity appears fine.  As you can see from the test script
>>>> it is able to ping the internal DNS server.  I am also able to ping
>>>> Google's DNS:
>>>> 
>>>> root@s-1-VM:~# ping 8.8.8.8
>>>> PING 8.8.8.8 (8.8.8.8): 56 data bytes
>>>> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=45 time=30.694 ms
>>>> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=45 time=23.546 ms
>>>> 
>>>> However I just recalled our corporate network does not allow external dns
>>>> so I need to stick to the internal one that the SSVM is already configured
>>>> for.
>>>> 
>>>> The odd thing is if I try to telnet to port 53 it says no route to host
>>>> (Is there a similar way to test a udp connection?):
>>>> root@s-1-VM:~# telnet 172.30.20.176 53
>>>> Trying 172.30.20.176...
>>>> telnet: Unable to connect to remote host: No route to host
>>>> 
>>>> But yet a ping works.
>>>> 
>>>> root@s-1-VM:~# ping 172.30.20.176
>>>> PING 172.30.20.176 (172.30.20.176): 56 data bytes
>>>> 64 bytes from 172.30.20.176: icmp_seq=0 ttl=127 time=0.690 ms
>>>> 64 bytes from 172.30.20.176: icmp_seq=1 ttl=127 time=0.674 ms
>>>> 64 bytes from 172.30.20.176: icmp_seq=2 ttl=127 time=0.674 ms
>>>> 
>>>> Traceroute looks ok:
>>>> root@s-1-VM:~# traceroute -n 172.30.20.176
>>>> traceroute to 172.30.20.176 (172.30.20.176), 30 hops max, 60 byte packets
>>>> 1  172.30.45.32  0.273 ms !X  0.235 ms !X  0.211 ms !X
>>>> 
>>>> any other ideas?
>>> 

Reply via email to