[NETVIRT-151] ARP Replies Intermittent for Floating IP Addresses Created: 16/Sep/16 Updated: 25/Sep/16 Resolved: 25/Sep/16 |
|
| Status: | Resolved |
| Project: | netvirt |
| Component/s: | General |
| Affects Version/s: | Boron |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Andre Fredette | Assignee: | Koby Aizer |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 6732 |
| Description |
|
Seen when pinging external addresses using floating IP's and an external gateway. Initial pings work, and they will keep working as long as you keep sending them. However, if you stop the pings. Wait a while (a few minutes). Then try to ping again, it won't work. The problem is that we stop answering ARP requests. Then, after a few minutes, we'll answer again. [0] is a log is showing the time from when I sent the first ping to when it started working again. [0] https://gist.github.com/anfredette/3048034b2a520db46ccea1613a20bd69 While it's not working, I see logs like this: Then, after I see this log: It starts working again. |
| Comments |
| Comment by Ravit Peretz [ 18/Sep/16 ] |
|
I wasn't able to reproduce it with a single node (control+compute) with carbon's build distribution-karaf-0.6.0-20160918.140517-691 |
| Comment by Andre Fredette [ 18/Sep/16 ] |
|
This was seen on Master. I was using 2 openstack nodes. One was control+compute. The other was compute. I had an external ODL controller. |
| Comment by Andre Fredette [ 18/Sep/16 ] |
|
I think a key factor is that the ARP entry on the external gateway times out, and then can't be refreshed because there's a period where the controller won't answer the requests. The ARP time-out on my external gatway is 1 minute, which is pretty short. As a work-around, I'm going to increase the time-out on my gateway, but even if that works, this is still an issue. |
| Comment by Periyasamy Palanisamy [ 19/Sep/16 ] |
|
Is the following MAC Entry for floating IP address ? MacEntry [expiryTime=1474032745864, vpnName=c543f7d0-16d1-4155-ba68-4a0104bf6c86, macAddress=MacAddress [_value=fa:16:3e:04:b1:38], ipAddress=/192.168.56.10, interfaceName=53750758692350:eth2:flat] Actually this ip address (192.168.56.10) is going under ARP timout in controller which shouldn't happen if it is floating ip address. This could lead to controller not to respond for ARP requests on this ip address. The intent of having ARP timeout is only for learned ip addresses on the data plane (example: non-neutron VM's). |
| Comment by Periyasamy Palanisamy [ 19/Sep/16 ] |
|
Assigning to Alon to have further look with following details: From the log [0], I see 192.168.56.10 is floating IP address and there is an entry created for this IP address in VpnPortipToPort DS when there is an ARP response for this IP address. 2016-09-16 09:32:26,660 | TRACE | pool-16-thread-1 | ArpNotificationHandler | 341 - org.opendaylight.netvirt.vpnmanager-impl - 0.4.0.SNAPSHOT | ArpNotification Response Received from interface 53750758692350:eth2:flat and IP 192.168.56.10 having MAC FA:16:3E:04:B1:38 And also seeing following log message from alivenessmonitor module. Is there a scenario ARP request is sent from 192.168.56.10(floating IP) to 192.168.56.1(VM) ? When VM responds with ARP response, then VPN module adds entry for floating IP into VpnPortipToPort DS. [0] https://gist.github.com/anfredette/3048034b2a520db46ccea1613a20bd69 |