Juniper Openstack

vcenter: VRRP packets are being dropped for AAP

  1. Series r3.2
  2. Bug #1669518
Bug #1669518 reported by Luke Bockelmann
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R3.1
New
Undecided
Hari Prasad Killi
R3.2
Fix Committed
Undecided
Hari Prasad Killi
Juniper Openstack r3.2.5.0
R4.0
Fix Committed
Undecided
Hari Prasad Killi
Juniper Openstack r4.0.1.0 "r4.0.1.0"
Trunk
Fix Committed
Undecided
Hari Prasad Killi
Juniper Openstack r4.1.0.0-fcs "r4.1"

Bug Description

vCenter-Only: 3.1.2B62

The source MAC of VRRP packet is not being handled correctly in vcenter-only Contrail vRouter VM. On the parent VIF(eth1) the sub interface chosen using the source mac of the packet and Vlan id. It looks like for VRRP packet, source mac changes as per VRRP group id and because of this we are not able to choose the sub interface properly. This is confirmed with a tcpdump. The source mac of Unicast is as registered with Vrouter and source MAC of VRRP is group mac.

Unicast:
18:07:54.339325 IP (tos 0x0, ttl 64, id 466, offset 0, flags [none], proto ICMP (1), length 84)
    10.1.1.6 > 10.1.1.3: ICMP echo request, id 44318, seq 2, length 64
 0x0000: 0050 56a6 76b0 0050 56a6 583b 8100 0065
 0x0010: 0800 4500 0054 01d2 0000 4001 62cd 0a01
 0x0020: 0106 0a01 0103 0800 7d1c ad1e 0002 58b7
 0x0030: 7fdf 0006 0a23 0809 0a0b 0c0d 0e0f 1011
 0x0040: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021
 0x0050: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031
 0x0060: 3233 3435 3637
18:07:54.342664 IP (tos 0x0, ttl 64, id 466, offset 0, flags [none], proto ICMP (1), length 84)
    10.1.1.3 > 10.1.1.6: ICMP echo reply, id 44318, seq 2, length 64
 0x0000: 0050 56a6 583b 0050 56a6 76b0 8100 0064
 0x0010: 0800 4500 0054 01d2 0000 4001 62cd 0a01
 0x0020: 0103 0a01 0106 0000 851c ad1e 0002 58b7
 0x0030: 7fdf 0006 0a23 0809 0a0b 0c0d 0e0f 1011
 0x0040: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021
 0x0050: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031
 0x0060: 3233 3435 3637

Vrrp:
18:07:52.534786 IP (tos 0xc0, ttl 255, id 2, offset 0, flags [none], proto VRRP (112), length 40)
    10.1.1.6 > 224.0.0.18: vrrp 10.1.1.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20, addrs: 10.1.1.10
 0x0000: 0100 5e00 0012 0000 5e00 0101 8100 0065
 0x0010: 0800 45c0 0028 0002 0000 ff70 cf8a 0a01
 0x0020: 0106 e000 0012 2101 6401 0001 6ff1 0a01
 0x0030: 010a 0000 0000 0000 0000 0000 0000 0000
18:07:53.329484 IP (tos 0xc0, ttl 255, id 2, offset 0, flags [none], proto VRRP (112), length 40)
    10.1.1.6 > 224.0.0.18: vrrp 10.1.1.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20, addrs: 10.1.1.10
 0x0000: 0100 5e00 0012 0000 5e00 0101 8100 0065
 0x0010: 0800 45c0 0028 0002 0000 ff70 cf8a 0a01
 0x0020: 0106 e000 0012 2101 6401 0001 6ff1 0a01
 0x0030: 010a 0000 0000 0000 0000 0000 0000 0000

This shows that for VRRP source MAC is 0000 5e00 0101 because of which we can’t associate this packet to Subinterface with vlan 0x0065, where as unicast mac is 0050 56a6 583b, which we associate properly to subinterface

See original description
Tags: vmware vrouter
Luke Bockelmann (h-luke)
description: updated
Changed in juniperopenstack:
assignee: nobody → Hari Prasad Killi (haripk)
Hari Prasad Killi (haripk)
tags: added: vrouter
Revision history for this message
Hari Prasad Killi (haripk) wrote :

The source MAC from the incoming packet is used to identify the source vif in the vcenter mode. The source MAC in this case was vMac which the vrouter is not aware of - this is the reason the VRRP control packets are getting dropped.

Solution for this case needs to be discussed further.

Ato (amonge)
information type: Proprietary → Public
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.2

Review in progress for https://review.opencontrail.org/34748
Submitter: jayaramsatya (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/34864
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.0

Review in progress for https://review.opencontrail.org/34867
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.2

Review in progress for https://review.opencontrail.org/34869
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/34864
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.0

Review in progress for https://review.opencontrail.org/34867
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R3.2

Review in progress for https://review.opencontrail.org/34869
Submitter: Divakar Dharanalakota (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] R4.0

Review in progress for https://review.opencontrail.org/35044
Submitter: jayaramsatya (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/35045
Submitter: jayaramsatya (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/34748
Committed: http://github.com/Juniper/contrail-controller/commit/74a4f04d744ec75dc50729a05a74d3e57460b3ee
Submitter: Zuul (<email address hidden>)
Branch: R3.2

commit 74a4f04d744ec75dc50729a05a74d3e57460b3ee
Author: jayaramsatya <email address hidden>
Date: Mon Aug 21 15:07:57 2017 +0530

Problem:
The source MAC from the incoming packet is used to identify the source
vif in the vcenter mode. The source MAC in this case was vMac which the
vrouter is not aware of - this is the reason the VRRP control packets
are getting dropped.
Solution:
Vrouter is programmed with Source mac along with allowed address pair
mac's
partial-bug: #1669518

Change-Id: I03d8628f14035ddad514c76bb9b5e4fd9fd08400

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/34869
Committed: http://github.com/Juniper/contrail-vrouter/commit/bccda7a96f188385e22ef87facfc3d61fdcc8f32
Submitter: Zuul (<email address hidden>)
Branch: R3.2

commit bccda7a96f188385e22ef87facfc3d61fdcc8f32
Author: Divakar D <email address hidden>
Date: Thu Aug 24 10:08:38 2017 +0530

Subinterface selection based on Multiple Macs

As of now, in Vcenter mode, when a packet is received on physical
interface with Vlan tag, it is assigned to subinterface based on the
Source Mac of the packet and Vlan tag. This does not work incase of Vrrp
protocol, as Vrrp enabled VM's send packets with source Mac as Vrrp
group MAc. To ensure that even these packets are assigned to right
subinterface, more than one MAc is added to parent interface which
results in same subinterface.

drv_add and drv_add_sub_interface routines are manipulated to ensure
that they parent interface's db is manipulated multiple times, rather
once.

Change-Id: Ia050264e1eea425560614c37867211a64e069813
closes-bug: #1669518

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/34867
Committed: http://github.com/Juniper/contrail-vrouter/commit/a2b6a9951b72229fb069d5aa2c2033d1ddf25553
Submitter: Zuul (<email address hidden>)
Branch: R4.0

commit a2b6a9951b72229fb069d5aa2c2033d1ddf25553
Author: Divakar D <email address hidden>
Date: Thu Aug 24 10:08:38 2017 +0530

Subinterface selection based on Multiple Macs

As of now, in Vcenter mode, when a packet is received on physical
interface with Vlan tag, it is assigned to subinterface based on the
Source Mac of the packet and Vlan tag. This does not work incase of Vrrp
protocol, as Vrrp enabled VM's send packets with source Mac as Vrrp
group MAc. To ensure that even these packets are assigned to right
subinterface, more than one MAc is added to parent interface which
results in same subinterface.

drv_add and drv_add_sub_interface routines are manipulated to ensure
that they parent interface's db is manipulated multiple times, rather
once.

Change-Id: Id3111dddd8e931b640740ef9b471c105dc1e63cf
closes-bug: #1669518

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/35044
Committed: http://github.com/Juniper/contrail-controller/commit/32bcf21976d14f24d2055b49d60749fe3e2c0df4
Submitter: Zuul (<email address hidden>)
Branch: R4.0

commit 32bcf21976d14f24d2055b49d60749fe3e2c0df4
Author: jayaramsatya <email address hidden>
Date: Tue Aug 29 19:21:46 2017 +0530

Problem: The source MAC from the incoming packet is used to identify the
source vif in the vcenter mode. The source MAC in this case was vMac
which the vrouter is not aware of - this is the reason the VRRP control
packets are getting dropped. Solution: Vrouter is programmed with Source
mac along with allowed address pair mac's
partial-bug: #1669518

Change-Id: I6c57dacfc3e70b6b35410d58cf6c9a6a8a969da6

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/34864
Committed: http://github.com/Juniper/contrail-vrouter/commit/f80cfdf58cee85b1ca5f7d14ef031e9d6d9f14ef
Submitter: Zuul (<email address hidden>)
Branch: master

commit f80cfdf58cee85b1ca5f7d14ef031e9d6d9f14ef
Author: Divakar D <email address hidden>
Date: Thu Aug 24 10:08:38 2017 +0530

Subinterface selection based on Multiple Macs

As of now, in Vcenter mode, when a packet is received on physical
interface with Vlan tag, it is assigned to subinterface based on the
Source Mac of the packet and Vlan tag. This does not work incase of Vrrp
protocol, as Vrrp enabled VM's send packets with source Mac as Vrrp
group MAc. To ensure that even these packets are assigned to right
subinterface, more than one MAc is added to parent interface which
results in same subinterface.

drv_add and drv_add_sub_interface routines are manipulated to ensure
that they parent interface's db is manipulated multiple times, rather
once.

Change-Id: Id3111dddd8e931b640740ef9b471c105dc1e63cf
closes-bug: #1669518

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote :

Reviewed: https://review.opencontrail.org/35045
Committed: http://github.com/Juniper/contrail-controller/commit/75c46e917af65c08e81b980973155805c3eef53c
Submitter: Zuul (<email address hidden>)
Branch: master

commit 75c46e917af65c08e81b980973155805c3eef53c
Author: jayaramsatya <email address hidden>
Date: Tue Aug 29 19:21:46 2017 +0530

Problem: The source MAC from the incoming packet is used to identify the
source vif in the vcenter mode. The source MAC in this case was vMac
which the vrouter is not aware of - this is the reason the VRRP control
packets are getting dropped. Solution: Vrouter is programmed with Source
mac along with allowed address pair mac's
partial-bug: #1669518

Change-Id: I6c57dacfc3e70b6b35410d58cf6c9a6a8a969da6

Luke Bockelmann (h-luke)
tags: added: vmware
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.