subject:"\[vpp\-dev\] Observing multiple VRRP Routers acting as master while testing Master\/Back\-up functionality using vrrp plugin"

Re: [vpp-dev] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

2020-06-15 Thread Matthew Smith

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  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
> 0x102
>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: 0x
>   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
> 
>
> Accept_ModeControls 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
> 
>

Re: [vpp-dev] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

2020-06-13 Thread Amit Mehra

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
0x102
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: 0x
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_ModeControls 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 (#16720): https://lists.fd.io/g/vpp-dev/message/16720
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

2020-06-13 Thread Muthu Raj

Hello Amit,

   state Master flags: preempt yes accept *no* unicast no


Your clue lies here.
Check https://vpp.flirble.org/master/d7/d40/vrrp_8c_source.html#l00182
and
https://vpp.flirble.org/master/dc/dfb/vrrp__cli_8c.html#a2fd76fa6d5cd9ddfef75af8f0d12e016

HTH.

Muthu

On Sat, Jun 13, 2020 at 2:01 PM Amit Mehra  wrote:

> Hi,
>
> I am trying to test Master/Backup functionality on 2 VPP nodes, each
> running it's own VRRP plugin and I am observing 2 VRRP routers acting as
> Masters at the same time. Please find below the configuration that i am
> using for my testing:-
>
> On VVP Node 1:-
> set interface mtu 1500 GigabitEthernet13/0/0
> set interface ip address GigabitEthernet13/0/0 10.20.37.118/24
> set interface state GigabitEthernet13/0/0 up
> vrrp vr add GigabitEthernet13/0/0 vr_id 1 priority 255 10.20.37.118
> vrrp proto start GigabitEthernet13/0/0 vr_id 1
>
> This becomes a Master, as it is the address owner and has the priority as
> 255.
>
> On VPP Node2:-
> set interface mtu 1500 GigabitEthernet13/0/0
> set interface ip address GigabitEthernet13/0/0 10.20.37.109/24
> set interface state GigabitEthernet13/0/0 up
> vrrp vr add GigabitEthernet13/0/0 vr_id 1 priority 200 accept_mode
> 10.20.37.118
> vrrp proto start GigabitEthernet13/0/0 vr_id 1
>
> This becomes a back-up and has priority 200.
>
> Note:- 10.20.37.118 is the IP that will be pinged from external
> machine(which would be having same subnet as 10.20.37.xx) and that is why
> have configured this IP on VR (VVP instance 2) with "accept_mode" ON.
>
> So, VR on VPP-1 comes up as Master and VR on VPP-2 comes up as Back-up.
> Now, if i kill VPP-1, then VR on VPP-2 becomes a Master and IP 10.20.37.118
> also gets added to the VPP interface. Please find the output of show int
> addr below
>
> vpp# show int addr
> GigabitEthernet13/0/0 (up):
>   L3 10.20.37.109/24
>   L3 10.20.37.118/24
> GigabitEthernet1b/0/0 (dn):
> local0 (dn):
>
> vpp# show vrrp vr
> [0] sw_if_index 1 VR ID 1 IPv4
>state Master flags: preempt yes accept yes 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
>
> Now, if i bring VPP-1 up, the VR on VVP-1 also becomes a Master and VR on
> VPP-2 also remains in Master State.At this moment, both the VRs i.e on
> VPP-1 and VPP-2 are acting as Masters. Please find the output of show vrrp
> vr from both the VPP instances:-
>
> From VPP-1
> vpp# show vrrp vr
> [0] sw_if_index 1 VR ID 1 IPv4
>state Master flags: preempt yes accept no unicast no
>priority: configured 255 adjusted 255
>timers: adv interval 100 master adv 0 skew 0 master down 0
>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.118/24
> GigabitEthernet1b/0/0 (dn):
> local0 (dn):
>
> On VPP-2
> vpp# show vrrp vr
> [0] sw_if_index 1 VR ID 1 IPv4
>state Master flags: preempt yes accept yes 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
>   L3 10.20.37.118/24
> GigabitEthernet1b/0/0 (dn):
> local0 (dn):
>
> Is this a known issue or am i missing something in my configuration? How
> to overcome this issue of multiple VRRP routers acting as Master at the
> same time?
>
> Regards
> Amit
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16719): https://lists.fd.io/g/vpp-dev/message/16719
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]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

2020-06-13 Thread Amit Mehra

Hi,

I am trying to test Master/Backup functionality on 2 VPP nodes, each running 
it's own VRRP plugin and I am observing 2 VRRP routers acting as Masters at the 
same time. Please find below the configuration that i am using for my testing:-

On VVP Node 1:-
set interface mtu 1500 GigabitEthernet13/0/0
set interface ip address GigabitEthernet13/0/0 10.20.37.118/24
set interface state GigabitEthernet13/0/0 up
vrrp vr add GigabitEthernet13/0/0 vr_id 1 priority 255 10.20.37.118
vrrp proto start GigabitEthernet13/0/0 vr_id 1

This becomes a Master, as it is the address owner and has the priority as 255.

On VPP Node2:-
set interface mtu 1500 GigabitEthernet13/0/0
set interface ip address GigabitEthernet13/0/0 10.20.37.109/24
set interface state GigabitEthernet13/0/0 up
vrrp vr add GigabitEthernet13/0/0 vr_id 1 priority 200 accept_mode 10.20.37.118
vrrp proto start GigabitEthernet13/0/0 vr_id 1

This becomes a back-up and has priority 200.

Note:- 10.20.37.118 is the IP that will be pinged from external machine(which 
would be having same subnet as 10.20.37.xx) and that is why have configured 
this IP on VR (VVP instance 2) with "accept_mode" ON.

So, VR on VPP-1 comes up as Master and VR on VPP-2 comes up as Back-up. Now, if 
i kill VPP-1, then VR on VPP-2 becomes a Master and IP 10.20.37.118 also gets 
added to the VPP interface. Please find the output of show int addr below

vpp# show int addr
GigabitEthernet13/0/0 (up):
L3 10.20.37.109/24
L3 10.20.37.118/24
GigabitEthernet1b/0/0 (dn):
local0 (dn):

vpp# show vrrp vr
[0] sw_if_index 1 VR ID 1 IPv4
state Master flags: preempt yes accept yes 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

Now, if i bring VPP-1 up, the VR on VVP-1 also becomes a Master and VR on VPP-2 
also remains in Master State.At this moment, both the VRs i.e on VPP-1 and 
VPP-2 are acting as Masters. Please find the output of show vrrp vr from both 
the VPP instances:-

>From VPP-1
vpp# show vrrp vr
[0] sw_if_index 1 VR ID 1 IPv4
state Master flags: preempt yes accept no unicast no
priority: configured 255 adjusted 255
timers: adv interval 100 master adv 0 skew 0 master down 0
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.118/24
GigabitEthernet1b/0/0 (dn):
local0 (dn):

On VPP-2
vpp# show vrrp vr
[0] sw_if_index 1 VR ID 1 IPv4
state Master flags: preempt yes accept yes 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
L3 10.20.37.118/24
GigabitEthernet1b/0/0 (dn):
local0 (dn):

Is this a known issue or am i missing something in my configuration? How to 
overcome this issue of multiple VRRP routers acting as Master at the same time?

Regards
Amit
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16718): https://lists.fd.io/g/vpp-dev/message/16718
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

Re: [vpp-dev] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

Re: [vpp-dev] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

[vpp-dev] Observing multiple VRRP Routers acting as master while testing Master/Back-up functionality using vrrp plugin

4 matches

Site Navigation

Mail list logo

Footer information