Because it results in the suppression of the initial ARP request to the gateway. This is how the Linux network stack reports an ARP issue.
-- Chiradeep On Jun 12, 2012, at 16:31, "David Nalley" <da...@gnsa.us> wrote: > > > > > On Jun 12, 2012, at 7:09 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> > wrote: > >> You might need to add the host ip of the web server where the templates >> are hosted to >> "secstorage.allowed.internal.sites" in the global configuration. > > Why would lack of this result in no route to host. Firewall issues would die > silently without that error. It isn't even trying. > > >> >> On 6/12/12 3:50 PM, "Lu Heng" <h...@anytimechinese.com> wrote: >> >>> Hi >>> >>> Thanks for reply >>> >>> First, the SSVM can mount the secondary storage, and the ssvm-check.sh is >>> passed without error. the "no route to the host" problem still exsits. >>> >>> second, what should we fill in the vlan in the public network setup while >>> the IP is simply in the access port? >>> >>> and the iptable rule on the ssvm host: >>> Chain INPUT (policy ACCEPT) >>> target prot opt source destination >>> ACCEPT gre -- anywhere anywhere >>> 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 tcp -- anywhere anywhere tcp >>> dpts:5900:6099 >>> 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 >>> >>> Output of ip route on ssvm: >>> >>> 204.13.152.2 via 46.136.128.1 dev eth1 >>> 10.2.0.0/24 dev eth3 proto kernel scope link src 10.2.0.189 >>> 123.123.123.0/24 dev eth1 proto kernel scope link src 123.123.123.9 >>> 111.111.111.0/24 dev eth2 proto kernel scope link src 111.111.111.18 >>> 169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.2.83 >>> default via 46.136.132.1 dev eth2 >>> >>> On Wed, Jun 13, 2012 at 12:42 AM, Frank Zhang >>> <frank.zh...@citrix.com>wrote: >>> >>>> >>>> >>>>> Hi >>>>> >>>>> We have following setup >>>>> >>>>> management network(public IP range, 123.123.123.0/24) storage >>>>> network(private IP range 10.2.0.0/24) public network(public IP range >>>>> 111.111.111.0/24) >>>>> >>>>> 1 CP >>>>> 1 Nic on management network >>>>> 1 Nic on storage network >>>>> >>>>> 2*Host >>>>> 1 Nic on management network >>>>> 1 Nic on storage network >>>>> 1 Nic on public network >>>>> >>>>> 1 storage >>>>> 1 Nic on management network >>>>> 1 nic on storage network >>>>> >>>>> Management server has an NFS share which mounted on the storage >>>>> network as secondary storage. >>>>> >>>>> So two questions: >>>>> >>>>> 1. for the public network, there is no vlan setup, the IP is direct >>>> routed to >>>>> both host server(they are on access point), the question is, while I >>>> config the >>>>> public network and guest network, it always ask for vlan number, >>>> which we >>>>> don't have. >>>> >>>> When you create zone, the vlan of public network is optional you should >>>> be >>>> able to >>>> Safely ignore it. What's exact error you suffered? >>>> >>>>> >>>>> 2. We saw "no route to the host" error in all the template, ISOs, in >>>> which we >>>>> can not create any instance on. >>>>> >>>>> Please, if any one have good suggestion in this network setup, how >>>> can we >>>>> do it. >>>> >>>> Do this: >>>> 1. login your SSVM >>>> 1.a go to the host where the SSVM is running >>>> 1.b ssh -i /root/.ssh/ id_rsa.cloud -p 30922 >>>> link_local_ip_address >>>> The link local ip address can be grabbed from SSVM page on >>>> UI which starts with 169 >>>> 1.c try to mount your secondary storage to somewhere in your SSVM >>>> 1.d if 1.c won't work, check if you can mount secondary storage >>>> on >>>> the host where SSVM running. If failed, then it's your network issue >>>> 1.e. if it works on your host, try to figure out any ip table >>>> rules >>>> in host blocking NFS traffic >>>> 1.h check routes of SSVM by 'ip route', the traffic to secondary >>>> storage should go thru storage network which is (private IP range >>>> 10.2.0.0/24) in you case >>>> >>>>> >>>>> -- >>>>> -- >>>>> Kind regards. >>>>> Lu >>>>> >>>>> This transmission is intended solely for the addressee(s) shown above. >>>>> It may contain information that is privileged, confidential or >>>> otherwise >>>>> protected from disclosure. Any review, dissemination or use of this >>>>> transmission or its contents by persons other than the intended >>>> addressee(s) >>>>> is strictly prohibited. If you have received this transmission in >>>> error, >>>> please >>>>> notify this office immediately and e-mail the original at the sender's >>>> address >>>>> above by replying to this message and including the text of the >>>> transmission >>>>> received. >>>> >>> >>> >>> >>> -- >>> -- >>> Kind regards. >>> Lu >>> >>> This transmission is intended solely for the addressee(s) shown above. >>> It may contain information that is privileged, confidential or >>> otherwise protected from disclosure. Any review, dissemination or use >>> of this transmission or its contents by persons other than the >>> intended addressee(s) is strictly prohibited. If you have received >>> this transmission in error, please notify this office immediately and >>> e-mail the original at the sender's address above by replying to this >>> message and including the text of the transmission received. >>
