cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sheng Yang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-985) Different MAC address for RvR caused issue in short term network outrage
Date Mon, 20 May 2013 22:29:16 GMT

     [ 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

Mime
View raw message