# CR VRRP packets are not reaching the other CR, as the two Spines are not sending EVPN routes / L2 traffic to each other:
cmooney@re0.cr1-eqiad> show vrrp summary | match et-1/0/5
et-1/0/5.1003 up 3 master Active lcl 208.80.154.66
et-1/0/5.1003 up 3 master Active lcl 2620:0:861:3:fe00::1
et-1/0/5.1004 up 4 master Active lcl 208.80.155.98
et-1/0/5.1004 up 4 master Active lcl 2620:0:861:4:fe00::1
et-1/0/5.1019 up 19 master Active lcl 10.64.32.2
et-1/0/5.1019 up 19 master Active lcl 2620:0:861:103:fe00::1
et-1/0/5.1020 up 20 master Active lcl 10.64.48.2
et-1/0/5.1020 up 20 master Active lcl 2620:0:861:107:fe00::1
et-1/0/5.1022 up 22 master Active lcl 10.64.36.2
et-1/0/5.1022 up 22 master Active lcl 2620:0:861:106:fe00::1
et-1/0/5.1023 up 23 master Active lcl 10.64.53.2
et-1/0/5.1023 up 23 master Active lcl 2620:0:861:108:fe00::1
cmooney@re0.cr2-eqiad> show vrrp summary | match et-1/0/5
et-1/0/5.1003 up 3 master Active lcl 208.80.154.67
et-1/0/5.1003 up 3 master Active lcl 2620:0:861:3:fe00::2
et-1/0/5.1004 up 4 master Active lcl 208.80.155.99
et-1/0/5.1004 up 4 master Active lcl 2620:0:861:4:fe00::2
et-1/0/5.1019 up 19 master Active lcl 10.64.32.3
et-1/0/5.1019 up 19 master Active lcl 2620:0:861:103:fe00::2
et-1/0/5.1020 up 20 master Active lcl 10.64.48.3
et-1/0/5.1020 up 20 master Active lcl 2620:0:861:107:fe00::3
et-1/0/5.1022 up 22 master Active lcl 10.64.36.3
et-1/0/5.1022 up 22 master Active lcl 2620:0:861:106:fe00::2
et-1/0/5.1023 up 23 master Active lcl 10.64.53.3
et-1/0/5.1023 up 23 master Active lcl 2620:0:861:108:fe00::2
# The Spines actually don't care about this though, each of them learns the VRRP virtual MAC on it's directly connected CR port. Because they are not learning the remote one over BGP they don't complain about a duplicate MAC:
A:ssw1-d1-eqiad# show network-instance * bridge-table mac-table mac 00:00:5E:00:01:14