You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cloudstack.apache.org by "Jeffrey McGovern (JIRA)" <ji...@apache.org> on 2013/02/13 16:56:12 UTC

[jira] [Created] (CLOUDSTACK-1258) Enhance the CloudStack API to support DHCP options per subnet.

Jeffrey McGovern created CLOUDSTACK-1258:
--------------------------------------------

             Summary: Enhance the CloudStack API to support DHCP options per subnet.
                 Key: CLOUDSTACK-1258
                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1258
             Project: CloudStack
          Issue Type: Improvement
      Security Level: Public (Anyone can view this level - this is the default.)
          Components: API
            Reporter: Jeffrey McGovern
            Priority: Minor


Description taken from discussion on user list: 

Problem: 
I am trying to solve the problem that occurs when you want to egress from a VDC to some place that is not the Internet. So as an example  if you have a VDC within a CloudStack managed environment with Internet access which will also connect to another physical environment within the same datacenter (or not) that is layer 3 separated from the virtualized environment. 

I can see two options for solving this issue. One would be to get a second external interface configured on the CloudStack managed gateway that would route me to a private VRF somewhere on the provider core while the second way which is the one  that spawned this question would be to bring up a separate gateway (This now involves having two routers/firewalls within the same VDC). With the second gateway we can now add routes directly to the VMs themselves using option 121 (or 33/249 pending some of the OS differences) on the DHCP server to control what egress point the VM would choose. 

The Virtual Private gateway may be one way to solve this but I can foresee a few other examples where being able to pass DHCP options will be very useful. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira