Re: Volunteers to Complete the 4.2 Release Notes
I have added a public filters for known issues and fixed issues that we can put in release notes. This way the data is dynamic and up to date Thanks Animesh On Sep 13, 2013, at 8:53 AM, "Radhika Puthiyetath" wrote: > Who is volunteering to provide the list of Fixed issues for the RN? > > -Original Message- > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > Sent: Wednesday, August 28, 2013 4:40 AM > To: d...@cloudstack.apache.org; users@cloudstack.apache.org > Subject: RE: Volunteers to Complete the 4.2 Release Notes > > Community help is needed to fix up the release notes, any volunteers > > Animesh > >> -Original Message- >> From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com] >> Sent: Tuesday, August 13, 2013 1:01 AM >> To: d...@cloudstack.apache.org; users@cloudstack.apache.org >> Subject: Volunteers to Complete the 4.2 Release Notes >> >> Hi, >> >> Looking for volunteers to help me with the 4.2 Release Notes. >> >> I have started filling in the new feature section, and checked in to the >> 4.2 branch. >> >> A defect is filed https://issues.apache.org/jira/browse/CLOUDSTACK-4245. >> >> Thanks for the help >> -Radhika
RE: Advanced Network - SNAT not working
I have that Marty. I see the http outbound request coming in on the guest interface of the VR,and see the http request being sent out on the public interface of the VR. The traffic is flowing fine from guest to the outbound i/f of the VR. This is tcpdump on the public i/f while guest is doing wget to 6x.xxx.xxx.xxx 19:17:58.834932 06:e3:3a:00:01:0a > 00:0c:86:4e:fe:00, ethertype IPv4 (0x0800), length 74: 10.11.79.178.39074 > 6x.xxx.xxx.xx.80: Flags [S], seq 1859313238, win 14600, options [mss 1460,sackOK,TS val 27489348 ecr 0,nop,wscale 4], length 0 0x: 4500 003c ad1d 4000 3f06 2d13 0a0b 4fb20x0010: 416e c660 98a2 0050 6ed2 de56 0x0020: a002 3908 516c 0204 05b4 0402 080a0x0030: 01a3 7444 0103 0304 > Date: Sat, 14 Sep 2013 19:29:53 +0100 > Subject: Re: Advanced Network - SNAT not working > From: msweet@gmail.com > To: users@cloudstack.apache.org > > Hi Noel, > > Can you run a tcpdump on both VR interfaces, this should make it apparent > what is happening? > > Thanks, > Marty > > > On Sat, Sep 14, 2013 at 6:41 PM, Noel Kendall wrote: > > > http://pastebin.com/3FZmFnvZ > > Many thanks Marty. > > Noel > > > Date: Sat, 14 Sep 2013 18:07:55 +0100 > > > Subject: Re: Advanced Network - SNAT not working > > > From: msweet@gmail.com > > > To: users@cloudstack.apache.org > > > > > > Hi Noel, > > > > > > Could you put the IP tables on pastebin? GMail has collapsed the lines > > > horrifically. > > > Have you also tried a tcpdump on both interfaces on the VR? > > > tcpdump -i eth0 <--- Or whatever it may be called > > > > > > I would expect worse connectivity if it was a pure NAT issue, but I will > > > review the tables later. > > > > > > Thanks, > > > Marty > > > > > > > > > On Sat, Sep 14, 2013 at 5:55 PM, Noel Kendall > >wrote: > > > > > > > Not seeing return packets on VR. Suspect, therefore, that SNAT is > > fouled > > > > up in some way.I have been doing wget to from guest, can see the > > outgoing > > > > request fine, both in the guest andthe VR. > > > > Could it be that the SNAT table entries from the 10.11.0.0/16 subnet > > to > > > > dpt www are interfering withthe SNAT to public ip?? (wild guess) - not > > an > > > > iptables expert by any stretch of the imagination > > > > 67.xxx.xxx.56 is the guest public IP10.11.79.178 is the guest IP on > > guest > > > > network > > > > iptables _L -t nat on the VR shows... > > > > Chain PREROUTING (policy ACCEPT)target prot opt source > > > > destination DNAT tcp -- anywhere anywhere > > > > tcp dpt:domain to:10.11.0.1 DNAT tcp -- anywhere > > > > 67.xxx.xxx.56tcp dpt:www to:10.11.79.178:80 DNAT tcp -- > > > > anywhere 67.xxx.xxx.56tcp dpt:www > > to:10.11.79.178:80DNAT tcp -- anywhere 67.xxx.xxx.56 > >tcp dpt:https > > > > to:10.11.79.178:443 DNAT tcp -- anywhere > > > > 67.xxx.xxx.56tcp dpt:https to:10.11.79.178:443 DNAT tcp > > -- > > > > anywhere 67.xxx.xxx.56tcp dpt:ssh > > to:10.11.79.178:22DNAT tcp -- anywhere 67.xxx.xxx.56 > >tcp dpt:ssh > > > > to:10.11.79.178:22 DNAT tcp -- anywhere > > 67.xxx.xxx.56 > > > >tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere > > > > 67.xxx.xxx.56tcp dpt:ftp to:10.11.79.178:21 DNAT > > tcp > > > > -- anywhere 67.xxx.xxx.56tcp dpt:5901 to: > > > > 10.11.79.178:5901 DNAT tcp -- anywhere > > 67.xxx.xxx.56 > > > >tcp dpt:5901 to:10.11.79.178:5901 > > > > Chain POSTROUTING (policy ACCEPT)target prot opt source > > > > destination SNAT all -- anywhere anywhere > > > > to:67.xxx.xxx.56 SNAT all -- anywhere > > anywhere > > > > to:67.xxx.xxx.56 SNAT all -- anywhere > > > > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > > > > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > > > > anywhereto:67.xxx.xxx.56SNAT all -- anywhere > > > > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > > > > anywhereto:67.xxx.xxx.56 SNAT all -- > > anywhere > > > > anywhereto:67.xxx.xxx.56 SNAT tcp -- > > > > 10.11.0.0/16 myguest tcp dpt:www to:10.11.0.1 SNAT > > > > tcp -- 10.11.0.0/16 myguest tcp dpt:https > > > > to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest > > > > tcp dpt:ssh to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 > > myguest > > > > tcp dpt:ftp to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 > > > > myguest tcp dpt:5901 to:10.11.0.1 SNAT all -- > > > > anywhere anywhereto:67.xxx.xxx.56 > > > > Chain OUTPUT (policy ACCEPT)target prot opt source > > > > destination DNAT
Re: Advanced Network - SNAT not working
Hi Noel, Can you run a tcpdump on both VR interfaces, this should make it apparent what is happening? Thanks, Marty On Sat, Sep 14, 2013 at 6:41 PM, Noel Kendall wrote: > http://pastebin.com/3FZmFnvZ > Many thanks Marty. > Noel > > Date: Sat, 14 Sep 2013 18:07:55 +0100 > > Subject: Re: Advanced Network - SNAT not working > > From: msweet@gmail.com > > To: users@cloudstack.apache.org > > > > Hi Noel, > > > > Could you put the IP tables on pastebin? GMail has collapsed the lines > > horrifically. > > Have you also tried a tcpdump on both interfaces on the VR? > > tcpdump -i eth0 <--- Or whatever it may be called > > > > I would expect worse connectivity if it was a pure NAT issue, but I will > > review the tables later. > > > > Thanks, > > Marty > > > > > > On Sat, Sep 14, 2013 at 5:55 PM, Noel Kendall >wrote: > > > > > Not seeing return packets on VR. Suspect, therefore, that SNAT is > fouled > > > up in some way.I have been doing wget to from guest, can see the > outgoing > > > request fine, both in the guest andthe VR. > > > Could it be that the SNAT table entries from the 10.11.0.0/16 subnet > to > > > dpt www are interfering withthe SNAT to public ip?? (wild guess) - not > an > > > iptables expert by any stretch of the imagination > > > 67.xxx.xxx.56 is the guest public IP10.11.79.178 is the guest IP on > guest > > > network > > > iptables _L -t nat on the VR shows... > > > Chain PREROUTING (policy ACCEPT)target prot opt source > > > destination DNAT tcp -- anywhere anywhere > > > tcp dpt:domain to:10.11.0.1 DNAT tcp -- anywhere > > > 67.xxx.xxx.56tcp dpt:www to:10.11.79.178:80 DNAT tcp -- > > > anywhere 67.xxx.xxx.56tcp dpt:www > to:10.11.79.178:80DNAT tcp -- anywhere 67.xxx.xxx.56 >tcp dpt:https > > > to:10.11.79.178:443 DNAT tcp -- anywhere > > > 67.xxx.xxx.56tcp dpt:https to:10.11.79.178:443 DNAT tcp > -- > > > anywhere 67.xxx.xxx.56tcp dpt:ssh > to:10.11.79.178:22DNAT tcp -- anywhere 67.xxx.xxx.56 >tcp dpt:ssh > > > to:10.11.79.178:22 DNAT tcp -- anywhere > 67.xxx.xxx.56 > > >tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere > > > 67.xxx.xxx.56tcp dpt:ftp to:10.11.79.178:21 DNAT > tcp > > > -- anywhere 67.xxx.xxx.56tcp dpt:5901 to: > > > 10.11.79.178:5901 DNAT tcp -- anywhere > 67.xxx.xxx.56 > > >tcp dpt:5901 to:10.11.79.178:5901 > > > Chain POSTROUTING (policy ACCEPT)target prot opt source > > > destination SNAT all -- anywhere anywhere > > > to:67.xxx.xxx.56 SNAT all -- anywhere > anywhere > > > to:67.xxx.xxx.56 SNAT all -- anywhere > > > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > > > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > > > anywhereto:67.xxx.xxx.56SNAT all -- anywhere > > > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > > > anywhereto:67.xxx.xxx.56 SNAT all -- > anywhere > > > anywhereto:67.xxx.xxx.56 SNAT tcp -- > > > 10.11.0.0/16 myguest tcp dpt:www to:10.11.0.1 SNAT > > > tcp -- 10.11.0.0/16 myguest tcp dpt:https > > > to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest > > > tcp dpt:ssh to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 > myguest > > > tcp dpt:ftp to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 > > > myguest tcp dpt:5901 to:10.11.0.1 SNAT all -- > > > anywhere anywhereto:67.xxx.xxx.56 > > > Chain OUTPUT (policy ACCEPT)target prot opt source > > > destination DNAT tcp -- anywhere > 67.xxx.xxx.56 > > > tcp dpt:www to:10.11.79.178:80 DNAT tcp -- anywhere > > > 67.xxx.xxx.56 tcp dpt:https to:10.11.79.178:443 DNAT > tcp > > > -- anywhere 67.xxx.xxx.56 tcp dpt:ssh to: > > > 10.11.79.178:22 DNAT tcp -- anywhere 67.xxx.xxx.56 > > > tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere > > > 67.xxx.xxx.56 tcp dpt:5901 to:10.11.79.178:5901 > > > > > > > Date: Sat, 14 Sep 2013 17:25:14 +0100 > > > > Subject: Re: Advanced Network - SNAT not working > > > > From: msweet@gmail.com > > > > To: users@cloudstack.apache.org > > > > > > > > Hi Noel, > > > > > > > > Can you try using telnet to connect to an external webserver? telnet > > > > www.google.com 80 > > > > Can you also clarify: do you see the response packets reach the VR > and/or > > > > on what interfaces? > > > > > > > > Thanks, > > > > Marty > > > > > > > > On Saturday, September 14, 2013, Noel Kendall wrote: > > > > > > > > > Guest OS cannot receive responses to http GETs from resources on > the > > > > > Internet. > > > > > Net
RE: Advanced Network - SNAT not working
http://pastebin.com/3FZmFnvZ Many thanks Marty. Noel > Date: Sat, 14 Sep 2013 18:07:55 +0100 > Subject: Re: Advanced Network - SNAT not working > From: msweet@gmail.com > To: users@cloudstack.apache.org > > Hi Noel, > > Could you put the IP tables on pastebin? GMail has collapsed the lines > horrifically. > Have you also tried a tcpdump on both interfaces on the VR? > tcpdump -i eth0 <--- Or whatever it may be called > > I would expect worse connectivity if it was a pure NAT issue, but I will > review the tables later. > > Thanks, > Marty > > > On Sat, Sep 14, 2013 at 5:55 PM, Noel Kendall wrote: > > > Not seeing return packets on VR. Suspect, therefore, that SNAT is fouled > > up in some way.I have been doing wget to from guest, can see the outgoing > > request fine, both in the guest andthe VR. > > Could it be that the SNAT table entries from the 10.11.0.0/16 subnet to > > dpt www are interfering withthe SNAT to public ip?? (wild guess) - not an > > iptables expert by any stretch of the imagination > > 67.xxx.xxx.56 is the guest public IP10.11.79.178 is the guest IP on guest > > network > > iptables _L -t nat on the VR shows... > > Chain PREROUTING (policy ACCEPT)target prot opt source > > destination DNAT tcp -- anywhere anywhere > > tcp dpt:domain to:10.11.0.1 DNAT tcp -- anywhere > > 67.xxx.xxx.56tcp dpt:www to:10.11.79.178:80 DNAT tcp -- > > anywhere 67.xxx.xxx.56tcp dpt:www > > to:10.11.79.178:80DNAT tcp -- anywhere 67.xxx.xxx.56 > > tcp dpt:https > > to:10.11.79.178:443 DNAT tcp -- anywhere > > 67.xxx.xxx.56tcp dpt:https to:10.11.79.178:443 DNAT tcp -- > > anywhere 67.xxx.xxx.56tcp dpt:ssh > > to:10.11.79.178:22DNAT tcp -- anywhere 67.xxx.xxx.56 > > tcp dpt:ssh > > to:10.11.79.178:22 DNAT tcp -- anywhere 67.xxx.xxx.56 > >tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere > > 67.xxx.xxx.56tcp dpt:ftp to:10.11.79.178:21 DNAT tcp > > -- anywhere 67.xxx.xxx.56tcp dpt:5901 to: > > 10.11.79.178:5901 DNAT tcp -- anywhere 67.xxx.xxx.56 > >tcp dpt:5901 to:10.11.79.178:5901 > > Chain POSTROUTING (policy ACCEPT)target prot opt source > > destination SNAT all -- anywhere anywhere > > to:67.xxx.xxx.56 SNAT all -- anywhere anywhere > > to:67.xxx.xxx.56 SNAT all -- anywhere > > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > > anywhereto:67.xxx.xxx.56SNAT all -- anywhere > > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > > anywhereto:67.xxx.xxx.56 SNAT tcp -- > > 10.11.0.0/16 myguest tcp dpt:www to:10.11.0.1 SNAT > > tcp -- 10.11.0.0/16 myguest tcp dpt:https > > to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest > > tcp dpt:ssh to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest > > tcp dpt:ftp to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 > > myguest tcp dpt:5901 to:10.11.0.1 SNAT all -- > > anywhere anywhereto:67.xxx.xxx.56 > > Chain OUTPUT (policy ACCEPT)target prot opt source > > destination DNAT tcp -- anywhere 67.xxx.xxx.56 > > tcp dpt:www to:10.11.79.178:80 DNAT tcp -- anywhere > > 67.xxx.xxx.56 tcp dpt:https to:10.11.79.178:443 DNAT tcp > > -- anywhere 67.xxx.xxx.56 tcp dpt:ssh to: > > 10.11.79.178:22 DNAT tcp -- anywhere 67.xxx.xxx.56 > > tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere > > 67.xxx.xxx.56 tcp dpt:5901 to:10.11.79.178:5901 > > > > > Date: Sat, 14 Sep 2013 17:25:14 +0100 > > > Subject: Re: Advanced Network - SNAT not working > > > From: msweet@gmail.com > > > To: users@cloudstack.apache.org > > > > > > Hi Noel, > > > > > > Can you try using telnet to connect to an external webserver? telnet > > > www.google.com 80 > > > Can you also clarify: do you see the response packets reach the VR and/or > > > on what interfaces? > > > > > > Thanks, > > > Marty > > > > > > On Saturday, September 14, 2013, Noel Kendall wrote: > > > > > > > Guest OS cannot receive responses to http GETs from resources on the > > > > Internet. > > > > Network is advanced, VLAN isolated. > > > > What is working: > > > > - can browse guest website from internet- can ssh to guest from > > internet- > > > > can VPN to guest network from internet > > > > - network VR can access internet sites no problem > > > > What is not working: > > > > - guest http traffic
Re: Advanced Network - SNAT not working
Hi Noel, Could you put the IP tables on pastebin? GMail has collapsed the lines horrifically. Have you also tried a tcpdump on both interfaces on the VR? tcpdump -i eth0 <--- Or whatever it may be called I would expect worse connectivity if it was a pure NAT issue, but I will review the tables later. Thanks, Marty On Sat, Sep 14, 2013 at 5:55 PM, Noel Kendall wrote: > Not seeing return packets on VR. Suspect, therefore, that SNAT is fouled > up in some way.I have been doing wget to from guest, can see the outgoing > request fine, both in the guest andthe VR. > Could it be that the SNAT table entries from the 10.11.0.0/16 subnet to > dpt www are interfering withthe SNAT to public ip?? (wild guess) - not an > iptables expert by any stretch of the imagination > 67.xxx.xxx.56 is the guest public IP10.11.79.178 is the guest IP on guest > network > iptables _L -t nat on the VR shows... > Chain PREROUTING (policy ACCEPT)target prot opt source > destination DNAT tcp -- anywhere anywhere > tcp dpt:domain to:10.11.0.1 DNAT tcp -- anywhere > 67.xxx.xxx.56tcp dpt:www to:10.11.79.178:80 DNAT tcp -- > anywhere 67.xxx.xxx.56tcp dpt:www to:10.11.79.178:80DNAT > tcp -- anywhere 67.xxx.xxx.56tcp dpt:https > to:10.11.79.178:443 DNAT tcp -- anywhere > 67.xxx.xxx.56tcp dpt:https to:10.11.79.178:443 DNAT tcp -- > anywhere 67.xxx.xxx.56tcp dpt:ssh to:10.11.79.178:22DNAT > tcp -- anywhere 67.xxx.xxx.56tcp dpt:ssh > to:10.11.79.178:22 DNAT tcp -- anywhere 67.xxx.xxx.56 >tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere > 67.xxx.xxx.56tcp dpt:ftp to:10.11.79.178:21 DNAT tcp > -- anywhere 67.xxx.xxx.56tcp dpt:5901 to: > 10.11.79.178:5901 DNAT tcp -- anywhere 67.xxx.xxx.56 >tcp dpt:5901 to:10.11.79.178:5901 > Chain POSTROUTING (policy ACCEPT)target prot opt source > destination SNAT all -- anywhere anywhere > to:67.xxx.xxx.56 SNAT all -- anywhere anywhere > to:67.xxx.xxx.56 SNAT all -- anywhere > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > anywhereto:67.xxx.xxx.56SNAT all -- anywhere > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > anywhereto:67.xxx.xxx.56 SNAT all -- anywhere > anywhereto:67.xxx.xxx.56 SNAT tcp -- > 10.11.0.0/16 myguest tcp dpt:www to:10.11.0.1 SNAT > tcp -- 10.11.0.0/16 myguest tcp dpt:https > to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest > tcp dpt:ssh to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest > tcp dpt:ftp to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 > myguest tcp dpt:5901 to:10.11.0.1 SNAT all -- > anywhere anywhereto:67.xxx.xxx.56 > Chain OUTPUT (policy ACCEPT)target prot opt source > destination DNAT tcp -- anywhere 67.xxx.xxx.56 > tcp dpt:www to:10.11.79.178:80 DNAT tcp -- anywhere > 67.xxx.xxx.56 tcp dpt:https to:10.11.79.178:443 DNAT tcp > -- anywhere 67.xxx.xxx.56 tcp dpt:ssh to: > 10.11.79.178:22 DNAT tcp -- anywhere 67.xxx.xxx.56 > tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere > 67.xxx.xxx.56 tcp dpt:5901 to:10.11.79.178:5901 > > > Date: Sat, 14 Sep 2013 17:25:14 +0100 > > Subject: Re: Advanced Network - SNAT not working > > From: msweet@gmail.com > > To: users@cloudstack.apache.org > > > > Hi Noel, > > > > Can you try using telnet to connect to an external webserver? telnet > > www.google.com 80 > > Can you also clarify: do you see the response packets reach the VR and/or > > on what interfaces? > > > > Thanks, > > Marty > > > > On Saturday, September 14, 2013, Noel Kendall wrote: > > > > > Guest OS cannot receive responses to http GETs from resources on the > > > Internet. > > > Network is advanced, VLAN isolated. > > > What is working: > > > - can browse guest website from internet- can ssh to guest from > internet- > > > can VPN to guest network from internet > > > - network VR can access internet sites no problem > > > What is not working: > > > - guest http traffic to external website gets to VR on internal NIC, > > > packets forwarded to external site via external NIC > > > > > > Response traffic is not seen. Appears to be dropped. > > > Have been looking hard at IPTABLES rules, doing tcpdumps, etc. > > > Am at this point stumped. > > > Any ideas on what could be wrong, or how to determine what could be > wrong? > > > Thanks in advance everyone who tries to help! >
RE: Advanced Network - SNAT not working
Not seeing return packets on VR. Suspect, therefore, that SNAT is fouled up in some way.I have been doing wget to from guest, can see the outgoing request fine, both in the guest andthe VR. Could it be that the SNAT table entries from the 10.11.0.0/16 subnet to dpt www are interfering withthe SNAT to public ip?? (wild guess) - not an iptables expert by any stretch of the imagination 67.xxx.xxx.56 is the guest public IP10.11.79.178 is the guest IP on guest network iptables _L -t nat on the VR shows... Chain PREROUTING (policy ACCEPT)target prot opt source destination DNAT tcp -- anywhere anywhere tcp dpt:domain to:10.11.0.1 DNAT tcp -- anywhere 67.xxx.xxx.56tcp dpt:www to:10.11.79.178:80 DNAT tcp -- anywhere 67.xxx.xxx.56tcp dpt:www to:10.11.79.178:80 DNAT tcp -- anywhere 67.xxx.xxx.56tcp dpt:https to:10.11.79.178:443 DNAT tcp -- anywhere 67.xxx.xxx.56 tcp dpt:https to:10.11.79.178:443 DNAT tcp -- anywhere 67.xxx.xxx.56tcp dpt:ssh to:10.11.79.178:22 DNAT tcp -- anywhere 67.xxx.xxx.56tcp dpt:ssh to:10.11.79.178:22 DNAT tcp -- anywhere 67.xxx.xxx.56tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere 67.xxx.xxx.56 tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere 67.xxx.xxx.56tcp dpt:5901 to:10.11.79.178:5901 DNAT tcp -- anywhere 67.xxx.xxx.56tcp dpt:5901 to:10.11.79.178:5901 Chain POSTROUTING (policy ACCEPT)target prot opt source destination SNAT all -- anywhere anywhere to:67.xxx.xxx.56 SNAT all -- anywhere anywhere to:67.xxx.xxx.56 SNAT all -- anywhere anywhere to:67.xxx.xxx.56 SNAT all -- anywhere anywhere to:67.xxx.xxx.56 SNAT all -- anywhere anywhere to:67.xxx.xxx.56SNAT all -- anywhere anywhere to:67.xxx.xxx.56 SNAT all -- anywhere anywhere to:67.xxx.xxx.56 SNAT all -- anywhere anywhere to:67.xxx.xxx.56 SNAT tcp -- 10.11.0.0/16 myguest tcp dpt:www to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest tcp dpt:https to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest tcp dpt:ssh to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest tcp dpt:ftp to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest tcp dpt:5901 to:10.11.0.1 SNAT all -- anywhere anywhereto:67.xxx.xxx.56 Chain OUTPUT (policy ACCEPT)target prot opt source destination DNAT tcp -- anywhere 67.xxx.xxx.56 tcp dpt:www to:10.11.79.178:80 DNAT tcp -- anywhere 67.xxx.xxx.56 tcp dpt:https to:10.11.79.178:443 DNAT tcp -- anywhere 67.xxx.xxx.56 tcp dpt:ssh to:10.11.79.178:22 DNAT tcp -- anywhere 67.xxx.xxx.56 tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere 67.xxx.xxx.56 tcp dpt:5901 to:10.11.79.178:5901 > Date: Sat, 14 Sep 2013 17:25:14 +0100 > Subject: Re: Advanced Network - SNAT not working > From: msweet@gmail.com > To: users@cloudstack.apache.org > > Hi Noel, > > Can you try using telnet to connect to an external webserver? telnet > www.google.com 80 > Can you also clarify: do you see the response packets reach the VR and/or > on what interfaces? > > Thanks, > Marty > > On Saturday, September 14, 2013, Noel Kendall wrote: > > > Guest OS cannot receive responses to http GETs from resources on the > > Internet. > > Network is advanced, VLAN isolated. > > What is working: > > - can browse guest website from internet- can ssh to guest from internet- > > can VPN to guest network from internet > > - network VR can access internet sites no problem > > What is not working: > > - guest http traffic to external website gets to VR on internal NIC, > > packets forwarded to external site via external NIC > > > > Response traffic is not seen. Appears to be dropped. > > Have been looking hard at IPTABLES rules, doing tcpdumps, etc. > > Am at this point stumped. > > Any ideas on what could be wrong, or how to determine what could be wrong? > > Thanks in advance everyone who tries to help! > > N. > >
Re: Advanced Network - SNAT not working
Hi Noel, Can you try using telnet to connect to an external webserver? telnet www.google.com 80 Can you also clarify: do you see the response packets reach the VR and/or on what interfaces? Thanks, Marty On Saturday, September 14, 2013, Noel Kendall wrote: > Guest OS cannot receive responses to http GETs from resources on the > Internet. > Network is advanced, VLAN isolated. > What is working: > - can browse guest website from internet- can ssh to guest from internet- > can VPN to guest network from internet > - network VR can access internet sites no problem > What is not working: > - guest http traffic to external website gets to VR on internal NIC, > packets forwarded to external site via external NIC > > Response traffic is not seen. Appears to be dropped. > Have been looking hard at IPTABLES rules, doing tcpdumps, etc. > Am at this point stumped. > Any ideas on what could be wrong, or how to determine what could be wrong? > Thanks in advance everyone who tries to help! > N. >
Advanced Network - SNAT not working
Guest OS cannot receive responses to http GETs from resources on the Internet. Network is advanced, VLAN isolated. What is working: - can browse guest website from internet- can ssh to guest from internet- can VPN to guest network from internet - network VR can access internet sites no problem What is not working: - guest http traffic to external website gets to VR on internal NIC, packets forwarded to external site via external NIC Response traffic is not seen. Appears to be dropped. Have been looking hard at IPTABLES rules, doing tcpdumps, etc. Am at this point stumped. Any ideas on what could be wrong, or how to determine what could be wrong? Thanks in advance everyone who tries to help! N.
Re: Post instalaltion script for virtual routers
On 12-Sep-2013, at 7:56 PM, Dean Kamali wrote: > Hello everyone > > Just wondering if it is possible to add a simple Perl or Bash script to run > after virtual routers get deployed ?? > > Maybe download a php page to show performance graphs? something like that > :) The hypervisor should already be exposing these stats. XenServer certainly seems to do so for all running VMs. http://community.citrix.com/display/xs/Using+XenServer+RRDs It would be nice to have SNMPD running on all the SystemVMs however. :) -- @shankerbalan M: +91 98860 60539 | O: +91 (80) 67935867 shanker.ba...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue ShapeBlue Services India LLP, 22nd floor, Unit 2201A, World Trade Centre, Bangalore - 560 055 This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: Cloustack 4.1.0 + GlusterFS
On 13-Sep-2013, at 9:31 PM, John Skinner wrote: > Sure I could look at writing up a howto for gluster. It is pretty straight > forward. > > As for the other questions; yes I am using XFS as the underlying filesystem > for gluster. For KVM, I love it. I haven't really noticed any significant > issues, what are these issues regarding HA and snapshotting? In 4.1 I haven't > had any issues creating a snapshot of a KVM VM, turning it into a template, > and launching it again. Live migration seems to work pretty good as well on > KVM, however, I haven't tested failing KVM nodes yet to see how CloudStack > deals with the outage... I assume that it will just restart the VM on an > available KVM node in the cluster. I would be very interested in your experience with GlusterFS and fault tolerance. Have you had a chance to simulate a GlusterFS brick/node failure? FWIW, I ran into issues with self healing but that was over 18 months ago. http://gluster.org/community/documentation/index.php/Gluster_3.2:_Triggering_Self-Heal_on_Replicate -- @shankerbalan M: +91 98860 60539 | O: +91 (80) 67935867 shanker.ba...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue ShapeBlue Services India LLP, 22nd floor, Unit 2201A, World Trade Centre, Bangalore - 560 055 This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: How to reset admin password of CloudStack WebUI?
Hi Diggy, The passwords are stored in the user_view table. With the way the authentication works we can just insert a plain text password for the reset and then change it via the user panel once logged in. Find your user: select username, password from user_view; Set a password of password for that user: update user_view set password = 'password' where username='admin'; Login to Cloudstack with admin/password navigate over to accounts, admin, view users, admin, change password. On 14 September 2013 04:15, Diggy Shuvy wrote: > Hello All, > > I got problem on login page of CS 4.1.1 web management. > How to reset admin password of CloudStack 4.1.1 web management? > > Thank a lot. > Diggy >
Re: Basic Networking - 4.0.2 - Same CIDR for all networks (vmware)
Hi Stíofán, On 21-Aug-2013, at 2:47 PM, Stíofán Ó Miadhacháin wrote: > Hi All, > > I have installed CS 4.0.2 against VMware, using basic networking and used > the same address space, a /23, for guest and management. > > My SSVM fails to mount NFS based SS, I have since read on a thread in this > mailing list that this is because the guest and management networks need to > be on unique CIDRs. You can certainly use the same CIDR for management, storage and guest on Basic networks. Its a supported configuration for as long as I can remember. > > Can someone confirm this? Is there anyway to have them live on the same > space as long as the addresses don't overlap? > Have you had a chance to run /usr/local/cloud/systemvm/ssvm-check.sh from the SSVM VM? https://cwiki.apache.org/CLOUDSTACK/ssvm-templates-secondary-storage-troubleshooting.html should help in debugging the issue further. Regards. -- @shankerbalan M: +91 98860 60539 | O: +91 (80) 67935867 shanker.ba...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue ShapeBlue Services India LLP, 22nd floor, Unit 2201A, World Trade Centre, Bangalore - 560 055 This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: Re: CS Mgmt Server can't connect to virtual router by management network
This is a new installation, and the vRouter is the first vrouter of the first shared network. I confirm that the vrouter only have a default gateway in guest network, and the IP address in the management network have no gateway at all. From: Kirk Kosinski Date: 2013-09-14 15:45 To: users CC: caowei Subject: Re: CS Mgmt Server can't connect to virtual router by management network Is this a new or existing installation? If there are existing functional virtual routers, how does the routing table compare to the broken one? Does the broken virtual router at least have a management IP in the correct range (the range configured for the pod)? Did you try a stop/start of the virtual router, or destroy/recreate it? System VMs on shared networks will use the guest network as the default gateway, but IIRC they will also be configured with a static route on the management network to the network of the management server. Is the "host" parameter in Global Settings correctly configured to the IP of the management server or a load balancer for a cluster of management servers? Best regards, Kirk On 09/13/2013 05:01 PM, caowei wrote: > I confirmed that my VLAN B can reach VLAN C, and VLAN C also can reach VLAN > B .But the problem is that there is no gateway be set for VLAN B in vRouter, > there is only a default gateway for VLAN A, So the VLAN B ip address can't be > reached from VLAN C and any other VLANs. > > You know if the management server can't connect to vrouter's management ip > address(in VLAN B), the vrouter can't be running status. > > > > > > > From: Sanjeev Neelarapu > Date: 2013-09-13 13:33 > To: users@cloudstack.apache.org; caow > Subject: RE: CS Mgmt Server can't connect to virtual router by management > network > Hi, > > In shared network VR does not act as a gateway for any of the network. So > your network infrastructure has to take care of the reachability from one > vlan to another vlan. i.e. on your gateway make sure that you have a route to > reach from Vlan B to Vlan C > > Thanks, > Sanjeev > > -Original Message- > From: caowei [mailto:c...@travelsky.com] > Sent: Thursday, September 12, 2013 8:33 PM > To: users > Subject: CS Mgmt Server can't connect to virtual router by management network > > In cloudstack 4.0.1 with vmware vsphere 5 as the hypervisor, I create a > shared network use default shared network offering. > > when I create a vm in this shared network , the vrouter be created at first, > and the vrouter will be assigned 2 IP address . The firtst is in the VLAN A > which is for guest network, and the second is in the VLAN B which is for the > management network( locallink network) , and my CS management server is in > the VLAN C. Then I find that the mgmt server cannot communicate with the > vrouter by the management network. The vrouter is in a starting status and > the VM cannot be created. > > Then I login the vrouter and I find that the default gateway is set the VLAN > A's gateway, and the VLAN B's IP address not have a gateway. So my mgmt > server can't connect to the vrouter. > > So what can I do to let my mgmt server connect to the vrouter? >
How to reset admin password of CloudStack WebUI?
Hello All, I got problem on login page of CS 4.1.1 web management. How to reset admin password of CloudStack 4.1.1 web management? Thank a lot. Diggy
Re: CS Mgmt Server can't connect to virtual router by management network
Is this a new or existing installation? If there are existing functional virtual routers, how does the routing table compare to the broken one? Does the broken virtual router at least have a management IP in the correct range (the range configured for the pod)? Did you try a stop/start of the virtual router, or destroy/recreate it? System VMs on shared networks will use the guest network as the default gateway, but IIRC they will also be configured with a static route on the management network to the network of the management server. Is the "host" parameter in Global Settings correctly configured to the IP of the management server or a load balancer for a cluster of management servers? Best regards, Kirk On 09/13/2013 05:01 PM, caowei wrote: > I confirmed that my VLAN B can reach VLAN C, and VLAN C also can reach VLAN > B .But the problem is that there is no gateway be set for VLAN B in vRouter, > there is only a default gateway for VLAN A, So the VLAN B ip address can't be > reached from VLAN C and any other VLANs. > > You know if the management server can't connect to vrouter's management ip > address(in VLAN B), the vrouter can't be running status. > > > > > > > From: Sanjeev Neelarapu > Date: 2013-09-13 13:33 > To: users@cloudstack.apache.org; caow > Subject: RE: CS Mgmt Server can't connect to virtual router by management > network > Hi, > > In shared network VR does not act as a gateway for any of the network. So > your network infrastructure has to take care of the reachability from one > vlan to another vlan. i.e. on your gateway make sure that you have a route to > reach from Vlan B to Vlan C > > Thanks, > Sanjeev > > -Original Message- > From: caowei [mailto:c...@travelsky.com] > Sent: Thursday, September 12, 2013 8:33 PM > To: users > Subject: CS Mgmt Server can't connect to virtual router by management network > > In cloudstack 4.0.1 with vmware vsphere 5 as the hypervisor, I create a > shared network use default shared network offering. > > when I create a vm in this shared network , the vrouter be created at first, > and the vrouter will be assigned 2 IP address . The firtst is in the VLAN A > which is for guest network, and the second is in the VLAN B which is for the > management network( locallink network) , and my CS management server is in > the VLAN C. Then I find that the mgmt server cannot communicate with the > vrouter by the management network. The vrouter is in a starting status and > the VM cannot be created. > > Then I login the vrouter and I find that the default gateway is set the VLAN > A's gateway, and the VLAN B's IP address not have a gateway. So my mgmt > server can't connect to the vrouter. > > So what can I do to let my mgmt server connect to the vrouter? >
