1. The first problem, I have had many times now. The code did not have 
cleanup code to revert virtaul MAC, some signal handler function may be 
needed to fix this. But use random MAC is not what RFC want because RFC 
has restricted MAC format. If you use some random format there may be some 
router implementation which rejects to connect to you.
2. I am using virtual machines so I can not play with cables. But if I 
power off the master router, I did see the backup router is taking over 
like the following:

ad...@router-4> show vrrp 
Interface       eth1
Vif             eth1
VRID            100
State           backup
Master IP       10.0.0.5
ad...@router-4> show vrrp 
Interface       eth1
Vif             eth1
VRID            100
State           master
Master IP       10.0.0.4

After I power on the master, I can see the switch back:

ad...@router-4> show vrrp 
Interface       eth1
Vif             eth1
VRID            100
State           backup
Master IP       10.0.0.5

[r...@router-5 ~]# su admin
Welcome to XORP on router-5
ad...@router-5> show vrrp
Interface       eth1
Vif             eth1
VRID            100
State           master
Master IP       10.0.0.5

So according to RFC, if the master stops sending heart beats, the backup 
should take over immediately. I guess playing with cables should have the 
same effect.

--- On Sun, 3/21/10, Ben Greear <[email protected]> wrote:

> From: Ben Greear <[email protected]>
> Subject: [Xorp-hackers] More VRRP problems.
> To: "xorp" <[email protected]>
> Date: Sunday, March 21, 2010, 2:03 PM
> While testing VRRP I notice some more
> problems with the current code.
> I don't think these are something I introduced, but it's
> possible.
> 
> 1)  If xorp starts with the MAC of the vrrp interface
> as the 'real'
>    MAC on the network device (ie, if vrrp
> was running and then xorp
>    crashed or was killed hard and didn't
> revert the MAC), then the
>    code cannot remove the MAC.
> 
>    To fix this problem, I am thinking about
> just setting a random MAC
>    address in this case.
> 
> 2)  Perhaps related to 1:  If you have two VRRP
> processes connected by a switch,
>    network and disconnect cables (by leave
> link UP on the physical xorp ports), then
>    the system goes into split-brain problem
> (both think they are the master).
> 
>    When re-enabling the cabling, at least my
> code isn't resolving back to
>    a single master.  I need to read the
> RFC on this to see what is supposed
>    to happen...
> 
> 
> Anyway, I'll keep poking at this..but that is where I am
> currently.
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <[email protected]>
> Candela Technologies Inc  http://www.candelatech.com
> 
> _______________________________________________
> Xorp-hackers mailing list
> [email protected]
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> 


      

_______________________________________________
Xorp-hackers mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

Reply via email to