HI Amit,

Here's a patch which I think will fix the problem:
https://gerrit.fd.io/r/c/vpp/+/27563. If you are able to build with the
patch applied and test it, that would be very helpful.

Thanks,
-Matt



On Sun, Jun 14, 2020 at 12:51 AM Amit Mehra <amito...@gmail.com> wrote:

> Thanks Muthu Raj for the Response.
>
> When i am setting "accept_mode" to NO while configuring VRRP router on VPP
> instance-2 (refer my configurations for VPP inst1 and inst 2 in initial
> mail) and when i kill VPP instance-1, then VRRP router running on VPP
> instance-2 is becoming the Master (IP 10.20.37.118 is not added to vpp
> interface this time, as accept_mode was NO) but when i am trying to ping
> 10.20.37.118 from external machine(having same subnet as 10.20.37.xx) then
> ping is not successful. I tried capturing the trace on vpp interface, as is
> being as shown as packets getting dropped.
>
> vpp# show vrrp vr
> [0] sw_if_index 1 VR ID 1 IPv4
>    state Master flags: preempt yes accept no unicast no
>    priority: configured 200 adjusted 200
>    timers: adv interval 100 master adv 100 skew 21 master down 321
>    virtual MAC 00:00:5e:00:01:01
>    addresses 10.20.37.118
>    peer addresses
>    tracked interfaces
>
> vpp# show int addr
> GigabitEthernet13/0/0 (up):
>   L3 10.20.37.109/24
> GigabitEthernet1b/0/0 (dn):
> local0 (dn):
>
> vpp# show trace
> 00:03:38:573635: dpdk-input
>   GigabitEthernet13/0/0 rx queue 1
>   buffer 0x1e3492: current data 0, length 98, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle
> 0x1000002
>                    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 0x82, data_off 128, phys_addr
> 0x88cd2500
>     packet_type 0x91 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
>     rss 0xe0a3989 fdir.hi 0x0 fdir.lo 0xe0a3989
>     Packet Offload Flags
>       PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
>       PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>     Packet Types
>       RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>       RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without
> extension headers
>   IP4: 00:50:56:9b:e8:ab -> 00:00:5e:00:01:01
>   ICMP: 10.20.37.21 -> 10.20.37.118
>     tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
>     fragment id 0x7b52, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0xdf6e
> 00:03:38:573648: ethernet-input
>   frame: flags 0x1, hw-if-index 1, sw-if-index 1
>   IP4: 00:50:56:9b:e8:ab -> 00:00:5e:00:01:01
> 00:03:38:573653: ip4-input
>   ICMP: 10.20.37.21 -> 10.20.37.118
>     tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
>     fragment id 0x7b52, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0xdf6e
> 00:03:38:573656: ip4-lookup
>   fib 0 dpo-idx 0 flow hash: 0x00000000
>   ICMP: 10.20.37.21 -> 10.20.37.118
>     tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
>     fragment id 0x7b52, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0xdf6e
> 00:03:38:573659: ip4-glean
>     ICMP: 10.20.37.21 -> 10.20.37.118
>       tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
>       fragment id 0x7b52, flags DONT_FRAGMENT
>     ICMP echo_request checksum 0xdf6e
> 00:03:38:573664: ip4-drop
>     ICMP: 10.20.37.21 -> 10.20.37.118
>       tos 0x00, ttl 64, length 84, checksum 0x60a4 dscp CS0 ecn NON_ECN
>       fragment id 0x7b52, flags DONT_FRAGMENT
>     ICMP echo_request checksum 0xdf6e
> 00:03:38:573675: error-drop
>   rx:GigabitEthernet13/0/0
> 00:03:38:573676: drop
>   ip4-glean: ARP requests sent
>
> Moreover, as per RFC-5798(https://tools.ietf.org/html/rfc5798), sec 6.1
> <https://tools.ietf.org/html/rfc5798>
>
> Accept_Mode                    Controls whether a virtual router in
>                                Master state will accept packets
>                                addressed to the address owner's IPvX
>                                address as its own if it is not the IPvX
>                                address owner.  The default is False.
>                                Deployments that rely on, for example,
>                                pinging the address owner's IPvX address
>                                may wish to configure Accept_Mode to
>                                True.
>
> And also sec 6.4.3, when VRRP router acting as Master
> (650) - MUST accept packets addressed to the IPvX address(es)
>       associated with the virtual router if it is the IPvX address owner
>       or if Accept_Mode is True.  Otherwise, MUST NOT accept these
>       packets.
>
> So, as per my understanding I need to set "accept_mode" to YES as per my
> use-case. My usecase is that IP 10.20.37.118 should always be pingable from
> outside machine (having same subnet as 10.20.37.118)
>
> Please let me know if my understanding is correct or whether I am missing
> anything in my configuration?
>
> Regards
> Amit
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16732): https://lists.fd.io/g/vpp-dev/message/16732
Mute This Topic: https://lists.fd.io/mt/74854562/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