Ask Your Question
0

Floating IP interface (fg) in FIP namespace duplicates packets [closed]

asked 2016-01-16 12:04:48 -0600

Hi guys, I haven't been able to get my head around this for a few days now. I am using Openvswitch networking with ML2 plugin, ARP responder and L2population are on, setup is DVR. Maybe I should also point out the kernel version (3.19.0-42) and network interface kernel module (i40e), because at this point I have no clue what's going on.

The symptomps were unreachable floating IP addressed of the instances and intermittent outside connectivity from inside the instances. First round of debugging led to an interesting result: the bridge I use to connect to external network (br-ex) had the fg- interface MAC address on the wrong side - that is, in the port connecting to the outside world instead of the phy-br-ex port connected to integration bridge (br-int):

(dev) root@computenode:~$ ovs-ofctl show br-ex
OFPT_FEATURES_REPLY (xid=0x2): dpid:00001c40242b758a
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
 2(vlan420): addr:1c:40:24:2b:75:8a
     config:     0
     state:      0
     current:    10GB-FD
     speed: 10000 Mbps now, 0 Mbps max
 5(phy-br-ex): addr:7a:04:1f:e5:f2:90
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-ex): addr:1c:40:24:2b:75:8a
     config:     PORT_DOWN
     state:      LINK_DOWN
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

(dev) root@computenode:~$ ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    2     0  fa:16:3e:33:9b:4b    2
    2     0  00:08:e3:ff:fd:90    2

(dev) root@computenode:~$ ip netns
fip-8b87c295-c6f0-46d4-b6b1-a13b6f50a1fa
qrouter-ef83504d-d07b-4bf3-9245-dd0231d8b331

(dev) root@computenode:~$ ip netns exec fip-8b87c295-c6f0-46d4-b6b1-a13b6f50a1fa ifconfig
fg-bd6cc674-ab Link encap:Ethernet  HWaddr fa:16:3e:33:9b:4b
          inet addr:37.9.173.202  Bcast:37.9.173.223  Mask:255.255.255.224
          inet6 addr: fe80::f816:3eff:fe33:9b4b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7885 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1604 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:524844 (524.8 KB)  TX bytes:138281 (138.2 KB)

Note: vlan420 is the interface with access to external network.

As you can see, the fg port's MAC (fa:16:3e:33:9b:4b) is on FDB port 2 of br-ex as opposed to expected port 5. Thus, no packet destined to the floating IP makes it past this point, as its destination MAC is to be found on the port that the packet came from (which results in the packet being dropped).

So I speculated further; something must have looped back a packet going out from FIP namespace through br-ex and vlan420 and forward it back to br-ex - and the poor bridge learned that fg's MAC is on the other side. I started shutting down any redundancy networking and other compute nodes until there was nothing but a switch, one patch cable and the server ... (more)

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by Peter Slovak
close date 2018-03-13 14:19:08.401645

1 answer

Sort by ยป oldest newest most voted
0

answered 2016-01-17 07:04:23 -0600

This strange behavior has been solved by downgrading kernel to 3.13.0-35-generic and compiling the latest stable i40e driver, which is 1.3.47. It was either one of those things or their combination.

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2016-01-15 20:18:34 -0600

Seen: 354 times

Last updated: Jan 17 '16