Good. 
If we can send the packet in master device with src mac (virtual mac 
00:00:5e:00:01:01)?   Because the FDB learing is based on src mac address in 
swtich  
now the swtich broadcast  the packet(dst mac is 00:00:5e:00:01:01). So  the 
backup device will forward this packet to the master device , 
the master deive will receive two packet ,so reply two packets  to the peer 
devices.

the peer deivice : 
root@ipsec-client:~# tcpdump -nn -vv -i ens19 icmp -e
tcpdump: listening on ens19, link-type EN10MB (Ethernet), capture size 262144 
bytes
05:50:29.272396 8e:25:4e:85:a9:ac > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 22314, offset 0, flags [DF], proto ICMP (1), 
length 84)
    10.10.10.2 > 10.10.10.15: ICMP echo request, id 2107, seq 71, length 64
05:50:29.272724 5a:9b:03:80:93:cf > 8e:25:4e:85:a9:ac, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 21086, offset 0, flags [DF], proto ICMP (1), 
length 84)
    10.10.10.15 > 10.10.10.2: ICMP echo reply, id 2107, seq 71, length 64
05:50:29.272732 5a:9b:03:80:93:cf > 8e:25:4e:85:a9:ac, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 14429, offset 0, flags [DF], proto ICMP (1), 
length 84)
    10.10.10.15 > 10.10.10.2: ICMP echo reply, id 2107, seq 71, length 64

the backup device:
00:33:11:820714: dpdk-input
  GigabitEthernet0/14/0 rx queue 0
  buffer 0x4bb813: current data 0, length 98, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x1000000
                   ext-hdr-valid 
                   l4-cksum-computed l4-cksum-correct 
  PKT MBUF: port 0, nb_segs 1, pkt_len 98
    buf_len 2176, data_len 98, ol_flags 0x0, data_off 128, phys_addr 0xb96e0540
    packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 
    rss 0x0 fdir.hi 0x0 fdir.lo 0x0
  IP4: 8e:25:4e:85:a9:ac -> 00:00:5e:00:01:01
  ICMP: 10.10.10.2 -> 10.10.10.15
    tos 0x00, ttl 64, length 84, checksum 0x54a6 dscp CS0 ecn NON_ECN
    fragment id 0xbdde, flags DONT_FRAGMENT
  ICMP echo_request checksum 0xd330 id 2107
00:33:11:820721: ethernet-input
  frame: flags 0x1, hw-if-index 1, sw-if-index 1
  IP4: 8e:25:4e:85:a9:ac -> 00:00:5e:00:01:01
00:33:11:820726: ip4-input
  ICMP: 10.10.10.2 -> 10.10.10.15
    tos 0x00, ttl 64, length 84, checksum 0x54a6 dscp CS0 ecn NON_ECN
    fragment id 0xbdde, flags DONT_FRAGMENT
  ICMP echo_request checksum 0xd330 id 2107
00:33:11:820728: ip4-lookup
  fib 0 dpo-idx 6 flow hash: 0x00000000
  ICMP: 10.10.10.2 -> 10.10.10.15
    tos 0x00, ttl 64, length 84, checksum 0x54a6 dscp CS0 ecn NON_ECN
    fragment id 0xbdde, flags DONT_FRAGMENT
  ICMP echo_request checksum 0xd330 id 2107
00:33:11:820731: ip4-rewrite
  tx_sw_if_index 1 dpo-idx 6 : ipv4 via 10.10.10.15 GigabitEthernet0/14/0: 
mtu:9000 next:3 flags:[] 5a9b038093cf1e6fdb91d4a80800 flow hash: 0x00000000
  00000000: 5a9b038093cf1e6fdb91d4a8080045000054bdde40003f0155a60a0a0a020a0a
  00000020: 0a0f0800d330083b06f17821dd6100000000fe4c0300000000001011
00:33:11:820733: GigabitEthernet0/14/0-output
  GigabitEthernet0/14/0 
  IP4: 1e:6f:db:91:d4:a8 -> 5a:9b:03:80:93:cf
  ICMP: 10.10.10.2 -> 10.10.10.15
    tos 0x00, ttl 63, length 84, checksum 0x55a6 dscp CS0 ecn NON_ECN
    fragment id 0xbdde, flags DONT_FRAGMENT
  ICMP echo_request checksum 0xd330 id 2107
00:33:11:820736: GigabitEthernet0/14/0-tx
  GigabitEthernet0/14/0 tx queue 1
  buffer 0x4bb813: current data 0, length 98, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x1000000
                   ext-hdr-valid 
                   l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 
l3-hdr-offset 14 
  PKT MBUF: port 0, nb_segs 1, pkt_len 98
    buf_len 2176, data_len 98, ol_flags 0x0, data_off 128, phys_addr 0xb96e0540
    packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 
    rss 0x0 fdir.hi 0x0 fdir.lo 0x0
  IP4: 1e:6f:db:91:d4:a8 -> 5a:9b:03:80:93:cf
  ICMP: 10.10.10.2 -> 10.10.10.15
    tos 0x00, ttl 63, length 84, checksum 0x55a6 dscp CS0 ecn NON_ECN
    fragment id 0xbdde, flags DONT_FRAGMENT
  ICMP echo_request checksum 0xd330 id 2107

the master device:

14:26:28.861832 8e:25:4e:85:a9:ac > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 36110, offset 0, flags [DF], proto ICMP (1), 
length 84)
    10.10.10.2 > 10.10.10.15: ICMP echo request, id 2107, seq 2180, length 64
14:26:28.861892 5a:9b:03:80:93:cf > 8e:25:4e:85:a9:ac, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 54080, offset 0, flags [DF], proto ICMP (1), 
length 84)
    10.10.10.15 > 10.10.10.2: ICMP echo reply, id 2107, seq 2180, length 64
14:26:28.861893 1e:6f:db:91:d4:a8 > 5a:9b:03:80:93:cf, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 63, id 36110, offset 0, flags [DF], proto ICMP (1), 
length 84)
    10.10.10.2 > 10.10.10.15: ICMP echo request, id 2107, seq 2180, length 64
14:26:28.861927 5a:9b:03:80:93:cf > 8e:25:4e:85:a9:ac, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 18089, offset 0, flags [DF], proto ICMP (1), 
length 84)
    10.10.10.15 > 10.10.10.2: ICMP echo reply, id 2107, seq 2180, length 64




zhangguangm...@baicells.com
 
From: Matthew Smith via lists.fd.io
Date: 2022-01-11 01:22
To: Guangming
CC: vpp-dev
Subject: Re: [vpp-dev] how to config vrrp unicast mode

Hi Guangming,

I merged https://gerrit.fd.io/r/c/vpp/+/34768. It allows the virtual address to 
be added when accept mode is enabled on a VR which sends unicast advertisements.

Thanks,
-Matt


On Mon, Jan 3, 2022 at 10:07 PM Guangming <zhangguangm...@baicells.com> wrote:
Hi,Matt
    Thanks for your detail reply.  Maybe I was wrong about VRRP in VPP.
    My expected behavior is that the master and backup  have a virtual  ip and 
virtual  mac. The virtual ip and mac are  used to connected with the other 
device. 
They are removed when device switch to backup and are  added when switch to 
master. Or they are always exist on the two device, but only the mater device 
can send and 
recieve the packet  which destination ip address  is the virtual ip.  

     The reason is  i want to use unicast is remote  disaster recovey scenario 
, not only cloud. The other is reduce the multicast packet in LAN. 

     From  the code , I think the device may drop the packet which dst address 
is virtual,  because the virtual ip is not the second address of the interface 
with your proposal configure. My vpp version is 2110.1
 Now my test environment is not ready because  our lab is removal. I will 
verify your configure  when test environment is ready . 

     I aslo found the other issue about VRRP.  One is the source ethenet  
address in  gratuitous ARP  is not the virtual MAC, so the the virtaul MAC in 
switch is unkonwn unicast . 
The other is the  MAC is not same that master device used when it handle the 
send and recieve packet. One is virtual MAC , the other is real MAC.  I think  
both are virtual mac is more 
friendly to peer device.



Thanks
Guangming






zhangguangm...@baicells.com
From: Matthew Smith
Date: 2022-01-04 03:02
To: zhangguangm...@baicells.com
CC: vpp-dev
Subject: Re: how to config vrrp unicast mode
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 (#20695): https://lists.fd.io/g/vpp-dev/message/20695
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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to