-- Forwarded message --
From: Daan Hoogland
Date: Wed, Jan 15, 2014 at 2:51 PM
Subject: Re: rvr4vpc
To: Karl Harris
Cc: Christopher Litsinger
H Karl,
Thanks for sharing. I didn't want to initiate this but I encourage you
to share this on the dev list (not in jira) as things ar
All,
I have made changes to the shell scripts within the CloudStack system
virtual machines that implement virtual routers for virtual private cloud.
Question:
What is the best way to test these scripts at the command line level?
I want to test my changes directly with a image of the vm which
hey Karl,
A colleague at Schuberg Philis does tests in vbox as well so this must
be feasilble. I don't know what the initial implementers at citrix did
but it can't be to far off. As for unit tests for shell scripts look
for one of two sh-unit framework I know. And look further, there might
be mor
Daan,
So looking at what is available today for guest network, the Redundant VR
can be enabled only for the source nat service. I guess the mention of the
source nat router is in relation to that. I could be wrong though. It
appears that the other services like vpn, dhcp, dns do not benefit much
f
Saurav, I don't see why you can't benefit from having other services
redundant as well. Vpn might be a problem as the source ip of a
redundant router pair on a vpn might give a problem (maybe there is an
implementation) but why wouldn't you want redundant dhcp or dns
services? As I understand it th
Daan,
I was wondering if you had not shared your thoughts, but looks like I had
missed your mail.
I agree that redundant dhcp or dns would be good to have. What I meant was,
it appears that by just enabling RVR there is no way to auto sync
configuration between the master and slave nodes with
Saurav,
Not sure how this happens now, but it is definateluy something we
want. For the static conf files it won't be much of a problem. The
firewall/loadbalences won't be much of a problem, they are fire and
forget configurations of the ms that can just be sent to both. The
dhcp is a challange. I
All,
At first redundant DHCP seemed like a good idea. I did some cursory
research and the more I read the more I'm convinced it may be
more trouble than its worth for the first implementation. I'll talk
with some of our Systems Engineer's here and get a broader
perspective.
There seems to be only
good reason to skip it for a next version, let's look into it anyway,
as we don't want to burn any of our ships.
On Mon, Jan 27, 2014 at 4:53 PM, Karl Harris wrote:
> All,
>
> At first redundant DHCP seemed like a good idea. I did some cursory
> research and the more I read the more I'm convinced
After discussion with my colleagues questions about initial
configuration of the open network redundant routers and the
applicability of the existing bash scripts (cloud-early-config) to the
setup of VPC redundant routers have generated.
Some setup first: In the bash script cloud-early-config th
On 03 Feb 2014, at 18:03, Karl Harris wrote:
> After discussion with my colleagues questions about initial
> configuration of the open network redundant routers and the
> applicability of the existing bash scripts (cloud-early-config) to the
> setup of VPC redundant routers have generated.
>
>
On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland wrote:
>
> On 03 Feb 2014, at 18:03, Karl Harris wrote:
>
> > After discussion with my colleagues questions about initial
> > configuration of the open network redundant routers and the
> > applicability of the existing bash scripts (cloud-early-con
On 03 Feb 2014, at 19:45, Karl Harris wrote:
> On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland wrote:
>
>>
>> On 03 Feb 2014, at 18:03, Karl Harris wrote:
>>
>>> After discussion with my colleagues questions about initial
>>> configuration of the open network redundant routers and the
>>> ap
On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland wrote:
>
> On 03 Feb 2014, at 19:45, Karl Harris wrote:
>
> > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland >wrote:
> >
> >>
> >> On 03 Feb 2014, at 18:03, Karl Harris wrote:
> >>
> >>> After discussion with my colleagues questions about initial
>
On Mon, Feb 3, 2014 at 9:03 AM, Karl Harris wrote:
> After discussion with my colleagues questions about initial
> configuration of the open network redundant routers and the
> applicability of the existing bash scripts (cloud-early-config) to the
> setup of VPC redundant routers have generated.
On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris wrote:
> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland >wrote:
>
> >
> > On 03 Feb 2014, at 19:45, Karl Harris wrote:
> >
> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >wrote:
> > >
> > >>
> > >> On 03 Feb 2014,
On Mon, Feb 3, 2014 at 8:50 PM, Sheng Yang wrote:
> On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris wrote:
>
>> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland > >wrote:
>>
>> >
>> > On 03 Feb 2014, at 19:45, Karl Harris wrote:
>> >
>> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
>> daan.hoogl
Would implementing a VPC Redundant Router Network Guru using the an
extension of the NetworkGuru interface be an appropriate way to create a
VPC network with redundant routers. It seems that extending Network Guru
interface or extending one of it's children eg the abstract class
GuestNetworkGuru wo
On Wed, Feb 12, 2014 at 9:38 AM, Karl Harris wrote:
> Would implementing a VPC Redundant Router Network Guru using the an
> extension of the NetworkGuru interface be an appropriate way to create a
> VPC network with redundant routers. It seems that extending Network Guru
> interface or extending o
H Karl,
I wouldn't say so. The network is redundant by instantiation and not
by design I would say. Maybe you are thinking of an other
implementation then you are. I haven't read any recent docs by you so
maybe I lack context. I would say that the network(s) are plain (sdn)
networks and the redund
Hi Karl,
>From Network Guru part of view, there is no VPC or isolated network guru.
Guru is per network type, e.g. public network, guest network, control
network, mgmt network. So VPC contained one public and multiple guest
network, which would be created by each guru accordingly. By this means,
V
All,
Here's what I've got so far with partitioning the problem.
There are 3 main areas I've found so far along with a proposal for
implementation.
Keepalived:
As Is:
Current VRR network configuration setup is assumed by the existing code to
be static. A single Keepalived config template file
Hi Karl,
An separate way to VR to configure keepalived/conntrackd besides
cloud-early-setup is a must without doubt.
But a separate API may not be necessary.
So here is the question: can keepalived/conntrackd used independently
regardless of network setup?
I think the answer for now is no. I be
23 matches
Mail list logo
