Hi Guangming, I think the signaling between unicast peers should work if you do something like this:
device A: set int ip address GigabitEthernet0/14/0 10.10.10.10/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5 vrrp proto start GigabitEthernet0/14/0 vr_id 1 device B: set int ip address GigabitEthernet0/14/0 10.10.10.5/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 200 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.10 vrrp proto start GigabitEthernet0/14/0 vr_id 1 That ought to cause your two instances to elect device A as the master. It should send advertisements to device B while it's up. It should also reply to ARP requests for 10.10.10.15 if it receives them, but it will reply with a VRRP virtual MAC address, which may not be the correct behavior for a unicast scenario. I originally added the capability to send unicast advertisements because I thought it may be useful for cloud environments which do not support multicast (AWS, Azure). But replying to an ARP request with a VRRP virtual MAC address may not be valid for cloud environments. Or it might not matter because the ARP request may be handled by infrastructure in those cloud environments and never actually delivered to the VM where VPP runs, I'm not sure. Your original commands enabled accept mode on each VR and added the VR virtual IP address (10.10.10.10/24) on the interface where the VR was being configured. In general, when you use accept mode, you don't need to configure the VR virtual IP address on the interface. You should only configure the virtual IP address on an interface of a VR that has priority 255 (the "owner" of the virtual IP address). On VR's with priority lower than 255, the address will automatically be added when the VR transitions into the master state and removed when it transitions from master to backup. I don't recall whether enabling accept mode does anything if you're using unicast advertisements. As I mentioned, the functionality was intended for cloud environments and in those environments, it does not work to just add an IP address on an interface, there needs to be some outside action taken (use AWS/Azure API to remove address from one host/interface and add it on another). I have not tried to use unicast VRRP in production and I have not received any questions about it from users before, so YMMV. If you find something specific that is not working as expected, please let me know. Thanks, -Matt On Tue, Dec 28, 2021 at 3:37 AM zhangguangm...@baicells.com < zhangguangm...@baicells.com> wrote: > > Hi Matthew > I want to use two device that runing VPP as HA cluster. I found the vrrp > cli support unicast mode. > Can you give me a right vrrp unicast example ? > > My configure is as follow, > device A : > set int ip address GigabitEthernet0/14/0 10.10.10.10/24 > set int ip address GigabitEthernet0/14/0 10.10.10.15/24 > set int state GigabitEthernet0/14/0 up > > vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 accept_mode > 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5 > vrrp proto start GigabitEthernet0/14/0 vr_id 1 > > device B: > set int ip address GigabitEthernet0/14/0 10.10.10.5/24 > set int ip address GigabitEthernet0/14/0 10.10.10.15/24 > set int state GigabitEthernet0/14/0 up > > vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 200 accept_mode > 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.10 > vrrp proto start GigabitEthernet0/14/0 vr_id 1 > > > Thanks > Guangming > > > ------------------------------ > zhangguangm...@baicells.com >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20677): https://lists.fd.io/g/vpp-dev/message/20677 Mute This Topic: https://lists.fd.io/mt/87993023/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
