RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1571248 - [RFE] OpenVSwitch ifup-ovs does not update ARP cache of neighbouring computers
Summary: [RFE] OpenVSwitch ifup-ovs does not update ARP cache of neighbouring computers
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openvswitch
Version: 7.4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: pre-dev-freeze
: 7.5
Assignee: Matteo Croce
QA Contact: Ofer Blaut
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-24 11:56 UTC by Madhur Gupta
Modified: 2021-09-09 13:50 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-11 10:39:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Madhur Gupta 2018-04-24 11:56:02 UTC
Description of problem:
Like the file "ifup-eth" the "ifup-ovs" does not update the ARP cache of neighbouring computers, as in the network cannot observe GARP requests sent from br-ex made upon OVS.

As reported in of my customer's ticket, During the 2nd openstack overcloud deployment(if the first overcloud deployment fails due to any reason) then it is required to send GARP before setting ip of the bridge.

As it does not send the GARP requests in the network, the firewall/gateway in the network keeps the older ARP entries with older mac address and ip.

If the same ip used from the previous failed deployment gets used again in next overcloud deployment then it cases failure to reach the node on which same ip has been assigned which was used in the previous failed overcloud deployment.

The workaround for this issue is to flush the ARP table on the firewall but I am looking if it is possible that ifup-ovs could make gratuitous arp while the IP gets assigned to it so that it will update the firewall for the new Macaddress on that IP.

The ifup-eth does update the arp while it assign the ip but in the ifup-ovs's case it does not.


~~~~~~~~~~~~
 
file -> initscripts-9.49.41/sysconfig/network-scripts/ifup-eth

 # set IP address(es)
        for idx in {0..256} ; do
            if [ -z "${ipaddr[$idx]}" ]; then
                break
            fi

            if ! LC_ALL=C ip addr ls ${REALDEVICE} | LC_ALL=C grep -q "${ipaddr[$idx]}/${prefix[$idx]}" ; then
                if [ "${REALDEVICE}" != "lo" ] && [ "${arpcheck[$idx]}" != "no" ] ; then
                    ARPING=$(/sbin/arping -c 2 -w ${ARPING_WAIT:-3} -D -I ${REALDEVICE} ${ipaddr[$idx]})
                    if [ $? = 1 ]; then
                        ARPINGMAC=$(echo $ARPING |  sed -ne 's/.*\[\(.*\)\].*/\1/p')
                        net_log $"Error, some other host ($ARPINGMAC) already uses address ${ipaddr[$idx]}."
                        exit 1
                    fi
                fi

                if ! ip addr add ${ipaddr[$idx]}/${prefix[$idx]} \
                    brd ${broadcast[$idx]:-+} dev ${REALDEVICE} ${SCOPE} label ${DEVICE}; then
                    net_log $"Error adding address ${ipaddr[$idx]} for ${DEVICE}."
                fi
            fi

            if [ -n "$SRCADDR" ]; then
                sysctl -w "net.ipv4.conf.${SYSCTLDEVICE}.arp_filter=1" >/dev/null 2>&1
            fi

# update ARP cache of neighboring computers
            if ! is_false "${arpupdate[$idx]}" && [ "${REALDEVICE}" != "lo" ]; then
                /sbin/arping -q -A -c 1 -I ${REALDEVICE} ${ipaddr[$idx]}
                ( sleep 2;
                /sbin/arping -q -U -c 1 -I ${REALDEVICE} ${ipaddr[$idx]} ) > /dev/null 2>&1 < /dev/null &
            fi

~~~~~~~~~~~~

But the same as above is not called in the ifup-ovs.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 4 Matteo Croce 2018-05-11 09:01:12 UTC
Hi,

I see in ifup-ovs that the following is done:

OTHERSCRIPT="/etc/sysconfig/network-scripts/ifup-eth"
...
${OTHERSCRIPT} ${CONFIG}

which should call ifup-eth and update the neighbours if a static IP is set

Comment 5 Matteo Croce 2018-05-11 10:39:40 UTC
Indeed initscripts already advertize the IP to neighbours

root@rhel7:~# strace -feexecve ifup ovsbr0 2>&1 |grep arping
[  914.376268] device ovs-netdev entered promiscuous mode
[  914.379838] device ovsbr0 entered promiscuous mode
[pid 11311] execve("/sbin/arping", ["/sbin/arping", "-c", "2", "-w", "3", "-D", "-I", "ovsbr0", "192.168.240.1"], [/* 20 vars */]) = 0
[pid 11313] execve("/sbin/arping", ["/sbin/arping", "-q", "-A", "-c", "1", "-I", "ovsbr0", "192.168.240.1"], [/* 20 vars */]) = 0
[pid 11381] execve("/sbin/arping", ["/sbin/arping", "-q", "-U", "-c", "1", "-I", "ovsbr0", "192.168.240.1"], [/* 20 vars */]) = 0

I close the bug for now, reopen if you have evidence that gARP are not sent.


Note You need to log in before you can comment on or make changes to this bug.