Re: [vpp-dev] VRRP issue when using VRs in different VLANs
Hi Mechthild, It looks like you are running version 21.06 of VPP. This patch was merged last month and may resolve the issue - https://gerrit.fd.io/r/c/vpp/+/34815. Can you try applying that patch to your build? Let me know if that helps. Thanks, -Matt On Fri, Feb 18, 2022 at 3:06 PM Mechthild Buescher via lists.fd.io wrote: > Hi all, > > > > We are using VPP on two nodes and run VRRP on them. This works fine as > long as we use one VLAN. But if we configure VRs in different VLANs we see > strange behavior: Every 4 seconds, the backup VRRP VR shortly changes to > master and sends an advertisement message to the master and then it changes > back to master. > > The symptom: > # while true; do date; vppctl show vrrp vr | grep state; echo; sleep 1; > done > > Fri Feb 18 20:33:15 UTC 2022 > >state Backup flags: preempt no accept yes unicast no > >state Backup flags: preempt no accept yes unicast no > > > > Fri Feb 18 20:33:16 UTC 2022 > >state Backup flags: preempt no accept yes unicast no > >state Backup flags: preempt no accept yes unicast no > > > > Fri Feb 18 20:33:17 UTC 2022 > >state Backup flags: preempt no accept yes unicast no > >state Backup flags: preempt no accept yes unicast no > > > > Fri Feb 18 20:33:18 UTC 2022 > >state Backup flags: preempt no accept yes unicast no > >state Master flags: preempt no accept yes unicast no > > > > Fri Feb 18 20:33:19 UTC 2022 > >state Backup flags: preempt no accept yes unicast no > >state Backup flags: preempt no accept yes unicast no > > > > Fri Feb 18 20:33:20 UTC 2022 > >state Backup flags: preempt no accept yes unicast no > >state Backup flags: preempt no accept yes unicast no > > > > Fri Feb 18 20:33:21 UTC 2022 > >state Backup flags: preempt no accept yes unicast no > >state Backup flags: preempt no accept yes unicast no > > > > Fri Feb 18 20:33:22 UTC 2022 > >state Backup flags: preempt no accept yes unicast no > >state Master flags: preempt no accept yes unicast no > > > > Fri Feb 18 20:33:23 UTC 2022 > >state Backup flags: preempt no accept yes unicast no > >state Backup flags: preempt no accept yes unicast no > > > > # tcpdump -nve -r /tmp/my_vppExt0_2vrid_2vlan.pcap | grep -B1 "vrid 232” > > 00:02:25.805841 00:00:5e:00:01:e8 > 01:00:5e:00:00:12, ethertype 802.1Q > (0x8100), length 50: vlan 102, p 0, ethertype IPv4, (tos 0x0, ttl 255, id > 0, offset 0, flags [none], proto VRRP (112), length 32) > > 172.17.2.2 > 224.0.0.18: vrrp 172.17.2.2 > 224.0.0.18: VRRPv3, > Advertisement, vrid 232, prio 100, intvl 100cs, length 12, addrs: 172.17.2.3 > > -- > > 00:02:26.190168 00:00:5e:00:01:e8 > 01:00:5e:00:00:12, ethertype 802.1Q > (0x8100), length 60: vlan 102, p 0, ethertype IPv4, (tos 0x0, ttl 255, id > 0, offset 0, flags [none], proto VRRP (112), length 32) > > 172.17.2.3 > 224.0.0.18: vrrp 172.17.2.3 > 224.0.0.18: VRRPv3, > Advertisement, vrid 232, prio 200, intvl 100cs, length 12, addrs: 172.17.2.3 > > -- > > 00:02:27.194227 00:00:5e:00:01:e8 > 01:00:5e:00:00:12, ethertype 802.1Q > (0x8100), length 60: vlan 102, p 0, ethertype IPv4, (tos 0x0, ttl 255, id > 0, offset 0, flags [none], proto VRRP (112), length 32) > > 172.17.2.3 > 224.0.0.18: vrrp 172.17.2.3 > 224.0.0.18: VRRPv3, > Advertisement, vrid 232, prio 200, intvl 100cs, length 12, addrs: 172.17.2.3 > > > > The configuration: > BACKUP system: > ip table add 26 > > ip table add 27 > > set interface state Ext-0 up > > create sub-interfaces Ext-0 101 > > create sub-interfaces Ext-0 102 > > set interface state Ext-0.101 up > > set interface state Ext-0.102 up > > > > set interface ip table Ext-0.101 26 > > set interface ip table Ext-0.102 27 > > set interface ip address Ext-0.101 172.17.1.2/25 > > set interface ip address Ext-0.102 172.17.2.2/25 > > vrrp vr add Ext-0.101 vr_id 231 priority 100 no_preempt accept_mode > 172.17.1.3 > > vrrp vr add Ext-0.102 vr_id 232 priority 100 no_preempt accept_mode > 172.17.2.3 > > > > MASTER system: > ip table add 26 > > ip table add 27 > > set interface state Ext-0 up > > create sub-interfaces Ext-0 101 > > create sub-interfaces Ext-0 102 > > set interface state Ext-0.101 up > > set interface state Ext-0.102 up > > > > set interface ip table Ext-0.101 26 > > set interface ip table Ext-0.102 27 > > set interface ip address Ext-0.101 172.17.1.1/25 > > set interface ip address Ext-0.102 172.17.2.1/25 > > vrrp vr add Ext-0.101 vr_id 231 priority 200 no_preempt accept_mode > 172.17.1.3 > > vrrp vr add Ext-0.102 vr_id 232 priority 200 no_preempt accept_mode > 172.17.2.3 > > > > Running BACKUP config: > > # vppctl show vrrp vr > > [0] sw_if_index 2 VR ID 231 IPv4 > >state Backup flags: preempt no accept yes unicast no > >priority: configured 100 adjusted 100 > >timers: adv interval 100 master adv 100 skew 60 master down 360 > >virtual MAC 00:00:5e:00:01:e7 > >addresses 172.17.1.3 > >peer addresses > >tracked interfaces > > [1] sw_if_index 3 VR ID 232 IPv4 > >
[vpp-dev] VRRP issue when using VRs in different VLANs
Hi all, We are using VPP on two nodes and run VRRP on them. This works fine as long as we use one VLAN. But if we configure VRs in different VLANs we see strange behavior: Every 4 seconds, the backup VRRP VR shortly changes to master and sends an advertisement message to the master and then it changes back to master. The symptom: # while true; do date; vppctl show vrrp vr | grep state; echo; sleep 1; done Fri Feb 18 20:33:15 UTC 2022 state Backup flags: preempt no accept yes unicast no state Backup flags: preempt no accept yes unicast no Fri Feb 18 20:33:16 UTC 2022 state Backup flags: preempt no accept yes unicast no state Backup flags: preempt no accept yes unicast no Fri Feb 18 20:33:17 UTC 2022 state Backup flags: preempt no accept yes unicast no state Backup flags: preempt no accept yes unicast no Fri Feb 18 20:33:18 UTC 2022 state Backup flags: preempt no accept yes unicast no state Master flags: preempt no accept yes unicast no Fri Feb 18 20:33:19 UTC 2022 state Backup flags: preempt no accept yes unicast no state Backup flags: preempt no accept yes unicast no Fri Feb 18 20:33:20 UTC 2022 state Backup flags: preempt no accept yes unicast no state Backup flags: preempt no accept yes unicast no Fri Feb 18 20:33:21 UTC 2022 state Backup flags: preempt no accept yes unicast no state Backup flags: preempt no accept yes unicast no Fri Feb 18 20:33:22 UTC 2022 state Backup flags: preempt no accept yes unicast no state Master flags: preempt no accept yes unicast no Fri Feb 18 20:33:23 UTC 2022 state Backup flags: preempt no accept yes unicast no state Backup flags: preempt no accept yes unicast no # tcpdump -nve -r /tmp/my_vppExt0_2vrid_2vlan.pcap | grep -B1 "vrid 232" 00:02:25.805841 00:00:5e:00:01:e8 > 01:00:5e:00:00:12, ethertype 802.1Q (0x8100), length 50: vlan 102, p 0, ethertype IPv4, (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto VRRP (112), length 32) 172.17.2.2 > 224.0.0.18: vrrp 172.17.2.2 > 224.0.0.18: VRRPv3, Advertisement, vrid 232, prio 100, intvl 100cs, length 12, addrs: 172.17.2.3 -- 00:02:26.190168 00:00:5e:00:01:e8 > 01:00:5e:00:00:12, ethertype 802.1Q (0x8100), length 60: vlan 102, p 0, ethertype IPv4, (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto VRRP (112), length 32) 172.17.2.3 > 224.0.0.18: vrrp 172.17.2.3 > 224.0.0.18: VRRPv3, Advertisement, vrid 232, prio 200, intvl 100cs, length 12, addrs: 172.17.2.3 -- 00:02:27.194227 00:00:5e:00:01:e8 > 01:00:5e:00:00:12, ethertype 802.1Q (0x8100), length 60: vlan 102, p 0, ethertype IPv4, (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto VRRP (112), length 32) 172.17.2.3 > 224.0.0.18: vrrp 172.17.2.3 > 224.0.0.18: VRRPv3, Advertisement, vrid 232, prio 200, intvl 100cs, length 12, addrs: 172.17.2.3 The configuration: BACKUP system: ip table add 26 ip table add 27 set interface state Ext-0 up create sub-interfaces Ext-0 101 create sub-interfaces Ext-0 102 set interface state Ext-0.101 up set interface state Ext-0.102 up set interface ip table Ext-0.101 26 set interface ip table Ext-0.102 27 set interface ip address Ext-0.101 172.17.1.2/25 set interface ip address Ext-0.102 172.17.2.2/25 vrrp vr add Ext-0.101 vr_id 231 priority 100 no_preempt accept_mode 172.17.1.3 vrrp vr add Ext-0.102 vr_id 232 priority 100 no_preempt accept_mode 172.17.2.3 MASTER system: ip table add 26 ip table add 27 set interface state Ext-0 up create sub-interfaces Ext-0 101 create sub-interfaces Ext-0 102 set interface state Ext-0.101 up set interface state Ext-0.102 up set interface ip table Ext-0.101 26 set interface ip table Ext-0.102 27 set interface ip address Ext-0.101 172.17.1.1/25 set interface ip address Ext-0.102 172.17.2.1/25 vrrp vr add Ext-0.101 vr_id 231 priority 200 no_preempt accept_mode 172.17.1.3 vrrp vr add Ext-0.102 vr_id 232 priority 200 no_preempt accept_mode 172.17.2.3 Running BACKUP config: # vppctl show vrrp vr [0] sw_if_index 2 VR ID 231 IPv4 state Backup flags: preempt no accept yes unicast no priority: configured 100 adjusted 100 timers: adv interval 100 master adv 100 skew 60 master down 360 virtual MAC 00:00:5e:00:01:e7 addresses 172.17.1.3 peer addresses tracked interfaces [1] sw_if_index 3 VR ID 232 IPv4 state Backup flags: preempt no accept yes unicast no priority: configured 100 adjusted 100 timers: adv interval 100 master adv 100 skew 60 master down 360 virtual MAC 00:00:5e:00:01:e8 addresses 172.17.2.3 peer addresses tracked interfaces Running MASTER config: # vppctl show vrrp vr [0] sw_if_index 2 VR ID 231 IPv4 state Master flags: preempt no 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:e7 addresses 172.17.1.3 peer addresses tracked interfaces [1] sw_if_index 3 VR ID 232 IPv4 state Master flags: preempt no accept yes unicast no priority: configured
Re: [vpp-dev] VxLAN set MTU
Thanks guys!
I've prepared a patch just to restore the previous functionality for
several interfaces: https://gerrit.fd.io/r/c/vpp/+/35362
Please take a look, if you have a chance
чт, 17 февр. 2022 г. в 22:23, Damjan Marion :
>
>
> vxlan code is missing max_frame_size callback which is now mandatory if
> you want to be able to do the change.
> If vxlan code doesn’t care about that change, it can be as simple as:
>
> vxlan_set_max_frame_size (vnet_main_t *vnm, vnet_hw_interface_t *hw, u32
> frame_size)
> {
> return 0;
> }
>
> and:
>
> eir.cb.set_max_frame_size = vxlan_set_max_frame_size;
>
> right before call to vnet_eth_register_interface (vnm, );
>
> However right solution will be to allow/disallow change based on
> underlying MTU…..
>
> —
> Damjan
>
>
>
> > On 17.02.2022., at 12:11, Pim van Pelt wrote:
> >
> > Hoi Artyom,
> >
> > Not an authoritative answer, although perhaps Damjan can confirm:
> > Is the semantic difference between max frame size (==device will reject
> frames larger than that on Rx, and never Tx frames larger than that) and
> mtu (L3 IP/IP6/MPLS packets will not be larger than that) with an
> implication that MTU can bever be larger than max_frame_size.
> >
> > Regardless, Artyom, here's how I manipulate the MTU of VXLAN tunnels -
> the trick is to use the 'mtu packet' rather than 'mtu' option (see the CLI
> call in bold):
> >
> > create vxlan tunnel instance 10 src $A dst $B vni 320501 decap-next l2
> > set interface state vxlan_tunnel10 up
> > set interface mtu packet 1522 vxlan_tunnel10
> > set interface l2 xconnect TenGigabitEthernet5/0/0.50 vxlan_tunnel10
> > set interface l2 xconnect vxlan_tunnel10 TenGigabitEthernet5/0/0.50
> >
> > pim@ddln1:~$ vppctl show ver
> > vpp v22.06-rc0~93-g360aee3e0 built by pim on dellr610 at
> 2022-02-13T11:56:07
> >
> > pim@ddln1:~$ vppctl show int vxlan_tunnel10
> > Name IdxState MTU (L3/IP4/IP6/MPLS)
> Counter Count
> > vxlan_tunnel1017 up 1522/0/0/0 rx
> packets209408
> > rx
> bytes81834552
> > tx
> packets 1616124
> > tx
> bytes 2471872228
> >
> > Does that help for you? I actually noticed that it doesn't prevent
> vxlan_tunnel10 from emitting larger frames, so I'm not quite sure what
> benefit it brings.
> >
> > On Thu, Feb 17, 2022 at 11:38 AM Artyom Glazychev <
> artyom.glazyc...@xored.com> wrote:
> > Hello,
> >
> > There is a problem with setting MTU for VxLAN. I see, that there was a
> change related to MTU and Max_frame_size -
> https://gerrit.fd.io/r/c/vpp/+/34928
> >
> > I don't know, what VxLAN configuration is right (I've asked about it
> here
> https://lists.fd.io/g/vpp-dev/topic/vxlan_l3_mode/89205942?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,89205942,previd=1645090589967474984,nextid=1643993575016104745=1645090589967474984=1643993575016104745
> )
> >
> > But neither this:
> > DBGvpp# create vxlan tunnel src 10.0.3.1 dst 10.0.3.3 vni 55 l3
> > vxlan_tunnel0
> > DBGvpp# set interface mtu 1400 vxlan_tunnel0
> > set interface mtu: Unsupported (underlying driver doesn't support
> changing Max Frame Size)
> >
> > Nor this:
> > DBGvpp# create vxlan tunnel src 10.0.3.1 dst 10.0.3.3 vni 55
> > vxlan_tunnel0
> > DBGvpp# set interface mtu 1400 vxlan_tunnel0
> > set interface mtu: not supported
> > is not working.
> >
> > So, my final question is how to configure the VxLAN L2-tunnel and set
> MTU?
> > Thank you.
> >
> >
> >
> >
> >
> >
> > --
> > Pim van Pelt
> > PBVP1-RIPE - http://www.ipng.nl/
> >
> >
> >
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20879): https://lists.fd.io/g/vpp-dev/message/20879
Mute This Topic: https://lists.fd.io/mt/89206535/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Community call topics proposal
Hi, Happy Friday! We have 2 proposed VPP changes want to be discussed during the coming community call, they are: 1. Generic flow pattern 1. Introducing a new way to add raw flow pattern and mask to VPP, the RFC patch is here https://gerrit.fd.io/r/c/vpp/+/34802 2. Since the raw flow pattern may be not so user-friendly, we want to discuss a human-readable way to generate raw flow pattern altogether. 3. Hence the topics we want to cover are * Introduce the background and purpose of generic flow, parser library and packetforge. * Our plan and current status of enabling generic flow in VPP dpdk-plugins, native AVF and VAPI. * How we create a user friendly naming API with packetforge. Introduce the spec to build and maintain the parsegraph. 1. ~15 minutes 1. Improved IPsec SP adding and lookup * Currently IPsec SP adding and lookup do not scale well in VPP. * We want to use either bihash or Toeplitz hash to accelerate both (will choose the one better performed in the end). * The goal is to upgrading existing IPsec flow cache to a "fast path" IPsec SP lookup and adding way. * The result shall help resolving or easing the slow flow adding, lookup collision, and flow table flushing problems. * Also ~15 minutes. Hopefully they are interesting enough :). Regards, Fan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20878): https://lists.fd.io/g/vpp-dev/message/20878 Mute This Topic: https://lists.fd.io/mt/89231635/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
