<div dir="ltr">Thanks, Rayson.<div><br></div><div>Explicitly associating the subnet to the main route table did the trick. All of our other VPCs are set up with an explicit association, which explains the difference.</div><div><br></div><div>The requirement *not* to use the main route table would be a great addition to the docs.</div><div><br></div><div>Cheers!</div><div><br></div><div>Chad</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 10:02 PM, Rayson Ho <span dir="ltr"><<a href="mailto:raysonlogin@gmail.com" target="_blank">raysonlogin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Chad,<div><br></div><div>What you've shown is a "Main" route table, which is implicitly associated with all subnets without route table association in the VPC.<br><br>The quickest way to fix it is to go to the VPC "Subnets" page of the AWS console, then "Route Table", "Edit", and select the main route table again so that it changes from implicit to *explicit* route table association.<br><br>The StarCluster code can be changed to handle implicit route table association when it is validating the subnet for IGW & <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> route accesses. However, in general it is a good practice to not have IGW access by default for all subnets without route table association. (That is, it is better to NOT have access and the VPC admin gives the subnet IGW access rather than taking away access when security is needed.)</div><div><br>Rayson<br><br>==================================================<br>Open Grid Scheduler - The Official Open Source Grid Engine<br><a href="http://gridscheduler.sourceforge.net/" target="_blank">http://gridscheduler.sourceforge.net/</a><br><a href="http://gridscheduler.sourceforge.net/GridEngine/GridEngineCloud.html" target="_blank">http://gridscheduler.sourceforge.net/GridEngine/GridEngineCloud.html</a><div><div class="h5"><br><br><br>On Thu, Apr 21, 2016 at 2:18 PM, Chad Nicely <<a href="mailto:chad.nicely@helix.com" target="_blank">chad.nicely@helix.com</a>> wrote:<br>><br>> I'm trying to launch starcluster instances into a subnet in a non-default VPC which satisfies the documented requirements (internet gateway attached to the VPC and a route to <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>), but I'm still getting the error "No route to <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> found for subnet".<br>><br>> The associated route table looks like this, and I've triple checked all ids and associations:<br>><br>> {<br>> "RouteTables": [<br>> {<br>> "Associations": [<br>> {<br>> "RouteTableAssociationId": "rtbassoc-xxxxxxxx", <br>> "Main": true, <br>> "RouteTableId": "rtb-yyyyyyyy"<br>> }<br>> ], <br>> "RouteTableId": "rtb-yyyyyyyy", <br>> "VpcId": "vpc-aaaaaaaa", <br>> "PropagatingVgws": [], <br>> "Tags": [], <br>> "Routes": [<br>> ...<br>> {<br>> "GatewayId": "igw-bbbbbbbb", <br>> "DestinationCidrBlock": "<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>", <br>> "State": "active", <br>> "Origin": "CreateRoute"<br>> }<br>> ]<br>> }<br>> ]<br>> }<br>><br>> I'm running starcluster v0.95.6. Any ideas?<br>><br></div></div>> _______________________________________________<br>> StarCluster mailing list<br>> <a href="mailto:StarCluster@mit.edu" target="_blank">StarCluster@mit.edu</a><br>> <a href="http://mailman.mit.edu/mailman/listinfo/starcluster" target="_blank">http://mailman.mit.edu/mailman/listinfo/starcluster</a><br>><br></div></div>
</blockquote></div><br></div>