Public bug reported:

get_subnet_for_dvr should return proper gateway mac address in order for ovs 
agent to add proper flows for dvr interface on br-int.
commit e82b0e108332964c90e9d2cfaf3d334a92127155 added 'fixed_ips' parameter to 
the handler to filter gateway port of the subnet. However actual filtering was 
applied improperly which leads to wrong gateway mac being returned:
           
            if fixed_ips:
                filter = fixed_ips[0]
            else:
                filter = {'fixed_ips': {'subnet_id': [subnet],
                                        'ip_address':
                                        [subnet_info['gateway_ip']]}}

            internal_gateway_ports = self.plugin.get_ports(
                context, filters=filter)

            internal_port = internal_gateway_ports[0]
            subnet_info['gateway_mac'] = internal_port['mac_address']

get_ports() here actually returns _all_ ports so mac address of a random
port is returned as 'gateway_mac'. In most cases it doesn't lead to any
noticeable side effects but in some cases it may cause very weird
behavior.

The case that we faced was:
 root@node-9:~# ovs-ofctl dump-flows br-int
 ...
 cookie=0x971c69a135b8ce1f, duration=23023.412s, table=2, n_packets=1339, 
n_bytes=131234, idle_age=19050, 
priority=4,dl_vlan=3556,dl_dst=fa:16:3e:da:53:f1 
actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:6
 cookie=0x971c69a135b8ce1f, duration=31946.414s, table=2, n_packets=25320, 
n_bytes=2481408, idle_age=1, priority=4,dl_vlan=3556,dl_dst=fa:16:3e:2c:24:86 
actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:5
 ...

fa:16:3e:2c:24:86 is mac address of a vm port and it was returned as
gateway mac due to the bug. This vm was unreachable from other subnets
connected to the same dvr router. However another vm on the same host
and the same subnet was ok. It took a while to find out what was wrong
:)

** Affects: neutron
     Importance: Medium
     Assignee: Oleg Bondarev (obondarev)
         Status: New


** Tags: l3-dvr-backlog

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1530179

Title:
  get_subnet_for_dvr() returns wrong gateway mac

Status in neutron:
  New

Bug description:
  get_subnet_for_dvr should return proper gateway mac address in order for ovs 
agent to add proper flows for dvr interface on br-int.
  commit e82b0e108332964c90e9d2cfaf3d334a92127155 added 'fixed_ips' parameter 
to the handler to filter gateway port of the subnet. However actual filtering 
was applied improperly which leads to wrong gateway mac being returned:
             
              if fixed_ips:
                  filter = fixed_ips[0]
              else:
                  filter = {'fixed_ips': {'subnet_id': [subnet],
                                          'ip_address':
                                          [subnet_info['gateway_ip']]}}

              internal_gateway_ports = self.plugin.get_ports(
                  context, filters=filter)

              internal_port = internal_gateway_ports[0]
              subnet_info['gateway_mac'] = internal_port['mac_address']

  get_ports() here actually returns _all_ ports so mac address of a
  random port is returned as 'gateway_mac'. In most cases it doesn't
  lead to any noticeable side effects but in some cases it may cause
  very weird behavior.

  The case that we faced was:
   root@node-9:~# ovs-ofctl dump-flows br-int
   ...
   cookie=0x971c69a135b8ce1f, duration=23023.412s, table=2, n_packets=1339, 
n_bytes=131234, idle_age=19050, 
priority=4,dl_vlan=3556,dl_dst=fa:16:3e:da:53:f1 
actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:6
   cookie=0x971c69a135b8ce1f, duration=31946.414s, table=2, n_packets=25320, 
n_bytes=2481408, idle_age=1, priority=4,dl_vlan=3556,dl_dst=fa:16:3e:2c:24:86 
actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:5
   ...

  fa:16:3e:2c:24:86 is mac address of a vm port and it was returned as
  gateway mac due to the bug. This vm was unreachable from other subnets
  connected to the same dvr router. However another vm on the same host
  and the same subnet was ok. It took a while to find out what was wrong
  :)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1530179/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to     : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Reply via email to