Hi,
I've opened request based on our discussion and comments by Chiradeep:
http://bugs.cloudstack.org/browse/CS-16131
And in a slightly related topic on VRR; VRR in basic zone:
http://bugs.cloudstack.org/browse/CS-16132
Please post your comments/suggestion/design/behaviour. Thanks.
Regards,
R
Yes, conntrackd, vrrp are being used. They don't handle the actual
provisioning of the iptables rules though.
There is also non-connection tracking-related configuration (state) that
needs to be beamed down to a freshly started router.
That happens if the router is started by CloudStack (via the AP
We are already using an up tables solution I thought: contrackt
Sent from my iPhone
On Aug 21, 2012, at 2:05 AM, Matthew Patton wrote:
> Please let's not reinvent the wheel. See pfsense, vrrp/carp, and pfsync.
>
> A redundant iptables solution doesn't spring to mind but it already exists no
>
Please let's not reinvent the wheel. See pfsense, vrrp/carp, and pfsync.
A redundant iptables solution doesn't spring to mind but it already exists no
doubt.
Hi Chiradeep,
On 21-Aug-2012, at 2:50 AM, Chiradeep Vittal
wrote:
> On 8/16/12 2:41 AM, "Rohit Yadav" wrote:
>>
>>
>> 1. Async Callback:
>> With bug http://bugs.cloudstack.org/browse/CS-15970 fixed, the
>> management server knows when router's redundant changed and CS re-applies
>> iptables r
On 8/16/12 2:41 AM, "Rohit Yadav" wrote:
>Hi,
>
>At present the redundancy of the virtual redundant routers, VRRP [3],
>operates outside the scope of CloudStack [2]. And any event that happens
>outside of CS, like rebooting by ssh-ing into the router vms or a
>crash/start, is not know by the ma
Hi,
At present the redundancy of the virtual redundant routers, VRRP [3], operates
outside the scope of CloudStack [2]. And any event that happens outside of CS,
like rebooting by ssh-ing into the router vms or a crash/start, is not know by
the management server (Sheng's comment[1]).
Therefore