[
https://issues.apache.org/jira/browse/CLOUDSTACK-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sheng Yang updated CLOUDSTACK-985:
----------------------------------
Description:
The different MAC address for a pair of redundant router have issues when
short
time network outrage happened. When this happened:
1. BACKUP(r-2) cannot receive the broadcast from MASTER(r-1).
2. Then r-2 would announce it's MASTER after 3 seconds, and send gratuitous
ARP
to the gateway of public ip(usually a rack router).
3. The gateway of public ip would update it's ARP cache to associate the
public
ip of the network to the MAC of r-2.
4. In the meantime, r-1 still sending out VRRP broadcast(due to network
issue,
the broadcast never arrived at r-2), and acting as MASTER.
5. After network outrage, r-2 would receive the higher priority VRRP
broadcast
from MASTER again, then receded as BACKUP.
6. But the public gateway would still associate public ip with MAC of r-2,
thus
caused the issue. r-1 would no longer able to receive any packets from
public
network.
And there is no way for r-1 to send gratuitous ARP again, because it's
always
consider itself as MASTER, no state changed, and no hook existed for
receiving
lower priority broadcast.
I would introduce duplicate MAC address for RvR again.
was:
The different MAC address for a pair of redundant router have issues when
short
time network outrage happened. When this happened:
1. BACKUP(r-2) cannot receive the broadcast from MASTER(r-1).
2. Then r-2 would announce it's MASTER after 3 seconds, and send gratuitous
ARP
to the gateway of public ip(usually a rack router).
3. The gateway of public ip would update it's ARP cache to associate the
public
ip of the network to the MAC of r-2.
4. In the meantime, r-1 still sending out VRRP broadcast(due to network
issue,
the broadcast never arrived at r-2), and acting as MASTER.
5. After network outrage, r-2 would receive the higher priority VRRP
broadcast
from MASTER again, then receded as BACKUP.
6. But the public gateway would still associate public ip with MAC of r-2,
thus
caused the issue. r-1 would no longer able to receive any packets from
public
network.
And there is no way for r-1 to send gratuitous ARP again, because it's
always
consider itself as MASTER, no state changed, and no hook existed for
receiving
lower priority broadcast.
I would introduce duplicate MAC address for RvR again.
> Different MAC address for RvR caused issue in short term network outrage
> ------------------------------------------------------------------------
>
> Key: CLOUDSTACK-985
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-985
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Reporter: Sheng Yang
> Assignee: Sheng Yang
> Fix For: 4.1.0
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> The different MAC address for a pair of redundant router have issues
> when short
> time network outrage happened. When this happened:
>
> 1. BACKUP(r-2) cannot receive the broadcast from MASTER(r-1).
> 2. Then r-2 would announce it's MASTER after 3 seconds, and send
> gratuitous ARP
> to the gateway of public ip(usually a rack router).
> 3. The gateway of public ip would update it's ARP cache to associate the
> public
> ip of the network to the MAC of r-2.
> 4. In the meantime, r-1 still sending out VRRP broadcast(due to network
> issue,
> the broadcast never arrived at r-2), and acting as MASTER.
> 5. After network outrage, r-2 would receive the higher priority VRRP
> broadcast
> from MASTER again, then receded as BACKUP.
> 6. But the public gateway would still associate public ip with MAC of
> r-2, thus
> caused the issue. r-1 would no longer able to receive any packets from
> public
> network.
>
> And there is no way for r-1 to send gratuitous ARP again, because it's
> always
> consider itself as MASTER, no state changed, and no hook existed for
> receiving
> lower priority broadcast.
> I would introduce duplicate MAC address for RvR again.
--
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
