Bug 1556852 - ping to floating IPs of VMs start working only after pinging from within VM to the outside first
Summary: ping to floating IPs of VMs start working only after pinging from within VM t...
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: opendaylight
Version: 13.0 (Queens)
Hardware: x86_64
OS: Linux
Target Milestone: beta
: 13.0 (Queens)
Assignee: Aswin Suryanarayanan
QA Contact: Tomas Jamrisko
Depends On:
TreeView+ depends on / blocked
Reported: 2018-03-15 11:30 UTC by Waldemar Znoinski
Modified: 2018-10-18 07:25 UTC (History)
8 users (show)

Fixed In Version: opendaylight-8.0.0-4.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-06-27 13:46:53 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
OpenDaylight Bug NETVIRT-1158 None None None 2018-03-20 15:23:55 UTC
OpenDaylight gerrit 69685 None None None 2018-03-20 15:28:54 UTC
Red Hat Product Errata RHEA-2018:2086 None None None 2018-06-27 13:47:44 UTC

Description Waldemar Znoinski 2018-03-15 11:30:23 UTC
Description of problem:
Pinging floating IP of a VM on overcloud from an external machine doesn't work straight away. It starts working only after pinging from within VM to the outside/external world first.

Version-Release number of selected component (if applicable):
puddle 2018-02-14.1

How reproducible:

Steps to Reproduce:
1. deploy overcloud with odl
2. create a VM, assign a floating IP to it
3. test ping from a machine on external network (i.e.: - undercloud) to this VM's floating IP (i.e.: doesn't work. After logging in to the VM and pinging (note first few packets with no reply):
[redhat@waldek1 ~]$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=4 ttl=64 time=1.28 ms
64 bytes from icmp_seq=5 ttl=64 time=1.04 ms
64 bytes from icmp_seq=6 ttl=64 time=0.598 ms
64 bytes from icmp_seq=7 ttl=64 time=0.581 ms

the originally failing ping undercloud-0 -> VM starts to work as well.

Actual results:
ping to VM's floating IP fail

Expected results:
ping to work

Additional info:

Comment 1 Aswin Suryanarayanan 2018-03-15 13:26:13 UTC
When the ping happens from undercloud to the vm the controller is not able to learn the external PNF and insert a flow in table21 .

The below exception is seen in the logs

2018-03-15 17:40:01,682 | WARN  | entLoopGroup-9-4 | MatchExtensionHelper             | 370 - org.opendaylight.openflowplugin - 0.7.0.SNAPSHOT | Convertor for MatchEntry [_matchEntryValue=NshNpCaseValue [_nshNpValues=NshNpValues [_value=192, augmentation=[]], augmentation=[]], _oxmClass=class org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.oxm.rev150225.Nxm1Class, _oxmMatchField=class org.opendaylight.yang.gen.v1.urn.opendaylight.openflowjava.nx.match.rev140421.NxmNxNshNp, _hasMask=false, augmentation=[]] for version 4 with match path PACKET_IN_MESSAGE_MATCH not found.
2018-03-15 17:40:01,682 | WARN  | entLoopGroup-9-4 | OFDecoder                        | 392 - org.opendaylight.openflowplugin.openflowjava.openflow-protocol-impl - 0.7.0.SNAPSHOT | Message deserialization failed
java.lang.NullPointerException: null

But when vm ping the undercloud the learning happens , table 21 flow is programmed and traffic is successful.

This table 21 flow is used when undercloud to vm ping is tried later, and hence it is successful.

Comment 7 Itzik Brown 2018-03-30 14:15:30 UTC
Verified with:

Comment 11 errata-xmlrpc 2018-06-27 13:46:53 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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