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):
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.: 10.0.0.50 - undercloud) to this VM's floating IP (i.e.: 10.0.0.211) doesn't work. After logging in to the VM and pinging 10.0.0.50 (note first few packets with no reply):
[redhat@waldek1 ~]$ ping 10.0.0.50
PING 10.0.0.50 (10.0.0.50) 56(84) bytes of data.
64 bytes from 10.0.0.50: icmp_seq=4 ttl=64 time=1.28 ms
64 bytes from 10.0.0.50: icmp_seq=5 ttl=64 time=1.04 ms
64 bytes from 10.0.0.50: icmp_seq=6 ttl=64 time=0.598 ms
64 bytes from 10.0.0.50: icmp_seq=7 ttl=64 time=0.581 ms
the originally failing ping undercloud-0 -> VM starts to work as well.
ping to VM's floating IP fail
ping to work
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
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.
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.