Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E6060DA86 for ; Tue, 4 Sep 2012 21:47:29 +0000 (UTC) Received: (qmail 83571 invoked by uid 500); 4 Sep 2012 21:47:29 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 83540 invoked by uid 500); 4 Sep 2012 21:47:29 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 83519 invoked by uid 99); 4 Sep 2012 21:47:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Sep 2012 21:47:29 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.210.47] (HELO mail-pz0-f47.google.com) (209.85.210.47) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Sep 2012 21:47:22 +0000 Received: by daks35 with SMTP id s35so4793990dak.6 for ; Tue, 04 Sep 2012 14:47:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=WBbxgqqOCuok0+64xKl/xJl+ePZV7EH0km6NuzHddRY=; b=G+t4ATQJuSpb6gD4mMNK/hDz47Ryv6ElG6flhq4ltN9/nIbHSgMyFFP7YdHhxBnGyI hUTM8wBh5bw58aYJcW6+nZQPUHfWzZ91iHcBUyfBUE2JKKulH+tyHWIXld3Lr0AbKSAU RyWv3Klign+1tCkeWgXJr5emfM8UvIOvlD/Zd1fUztPBlO3tk0oujVynEVPJW852PlkC ZaK9/zJWFRQUXD8eA8vNQ880FRyy4HoQOGnglWQIe37i7aanYNouusXrY+UJ/bgndKED pqJrt/yT4JGkaHVG6EjO1KkTRPQcpNnU+7vR44+X3Ths0f7sm3s2uCPiZZesVIQas1Qy z9jA== MIME-Version: 1.0 Received: by 10.66.78.73 with SMTP id z9mr44464460paw.9.1346795221360; Tue, 04 Sep 2012 14:47:01 -0700 (PDT) Received: by 10.68.189.197 with HTTP; Tue, 4 Sep 2012 14:47:01 -0700 (PDT) X-Originating-IP: [63.110.51.11] In-Reply-To: References: Date: Tue, 4 Sep 2012 14:47:01 -0700 Message-ID: Subject: Re: Status of VPC From: Sheng Yang To: cloudstack-dev@incubator.apache.org Cc: Sheng Yang , Anthony Xu Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmB9eoP+2CPbccMY6nphwuJSiCuZRMTjpuD5YivgKSTOz0C0Zg/qvWTNudmgQdGH8v7okI+ On Tue, Sep 4, 2012 at 1:47 PM, Alena Prokharchyk wrote: > On 9/4/12 1:11 PM, "Marcus Sorensen" wrote: > >>Thanks for replying. >> >>On Tue, Sep 4, 2012 at 1:41 PM, Alena Prokharchyk >> wrote: >>> On 9/4/12 10:21 AM, "Marcus Sorensen" wrote: >>> >>>>I've been working on bringing KVM up to speed on the VPC stuff, and >>>>there are a few things I've come across that seem to be incomplete for >>>>Xen as well. I'd just like to get some feedback on the current state >>>>of VPC. I believe these are not specific issues to my implementation, >>>>but if they should be working please say something so I can find my >>>>problem. >>>> >>>>static routes - currently there doesn't seem to be anything creating >>>>ip rules to point to the static_route table, nor does there seem to be >>>>anything creating the static_route table, although vpc_staticroute.sh >>>>attempts to modify it >>> >>> Anthony, do we add static_route table automatically when the private >>> gateway is created? >>> >> >>I grepped through the code, and the only thing I could find adding ip >>rules was ipassoc.sh (the Table_eth* tables) and the only thing I >>could find doing stuff with a static_route routing table was >>vpc_staticroute.sh (which complains that table static_route doesn't >>exist). >> >>> >>>> >>>>vpn - there is a script vpc_vpn_l2tp.sh, but I can't find anything >>>>actually utilizing it. I assume there is no working vpn support in any >>>>platform's Vpc implementation. >>> >>> There is no RemoteAccessVPN support in VPC. We support S2S VPN only. >>> >> >>So that vpc_vpn_l2tp.sh is to be ignored/removed? I do see that there >>are existing Site2Site commands in both the Citrix resouce and the KVM >>one, I believe they are the existing ones that call ipsectunnel.sh, >>this will work with VPC without modification, or is the Xen stuff just >>not that far along yet? Or perhaps better stated, please tell me what >>VPN support Xen currently has with VPC and the associated commands so >>I may emulate them for KVM. > > It will be ignored. We are not removing it because remote access vpn is > supported in regular Isolated networks' Virtual Router. As we use the same > template for VPC/Regular Virtual router, we are just going to maintain 2 > sets of scripts, and call them based on context (based on the fact if > router belongs to VPC network or regular network) > > At the moment, We block Remote Access VPN commands to be executed against > vpc guest networks, on API level. Sheng, please confirm. I think we just blocked them from UI now. Need to block it from API as well. --Sheng > > -Alena. > >> >>>> >>>>password - I've seen some emails regarding this, that the password >>>>server doesn't seem to be set up for the various private nics >>> >>> I'll put the fix to master branch today. >>> >>>> >>>>network ACLs - The functional spec states that all outgoing traffic >>>>for guest networks is allowed, however I don't see any acls whatsoever >>>>when creating new tiers >>> >>> >>> I suspect it wasn't merged to master branch yet. Anthony, please do it. >>>> >>> >>> >> > >