bug in DestinationMapper

I tried pinging from the instance on the remote/compute-1 node (20.1.1.3) to the instance on the local/control node (10.1.1.3). Pings weren't working.

On the remote node, we're hitting the following (L3) flow in the Destination Mapper table (table 3):

 cookie=0x0, duration=1718.148s, table=3, n_packets=1569, n_bytes=153762, priority=132,ip,reg6=0xb,dl_dst=fa:16:3e:01:b0:a1,nw_dst=10.1.1.3 actions=load:0xc0a83214->NXM_NX_TUN_IPV4_DST[],load:0xc->NXM_NX_
REG2[],load:0x1->NXM_NX_REG3[],load:0x3->NXM_NX_REG7[],set_field:fa:16:3e:f2:08:17->eth_src,set_field:fa:16:3e:04:4a:32->eth_dst,dec_ttl,goto_table:4

The matcher of the flow-mod is matching on the router MAC, which is correct. However, note that it's setting the Ethernet Destination address to fa:16:3e:04:4a:32, which is the MAC address of 10.1.1.3 (more on this below).

On the local node, these are the flow-mods the ping packets are hitting:

Port Security (table 0):
 cookie=0x0, duration=2221.677s, table=0, n_packets=1702, n_bytes=166740, priority=200,in_port=3 actions=goto_table:2

Source Mapper (table 2):
 cookie=0x0, duration=2221.677s, table=2, n_packets=1702, n_bytes=166740, priority=150,tun_id=0xf,in_port=3 actions=load:0xc->NXM_NX_REG0[],load:0xffffff->NXM_NX_REG1[],load:0x8->NXM_NX_REG4[],load:0x9->N
XM_NX_REG5[],load:0xb->NXM_NX_REG6[],goto_table:3

Destination Mapper (table 3):
 cookie=0x0, duration=2221.677s, table=3, n_packets=1702, n_bytes=166796, priority=1 actions=drop

We should be hitting this flow-mod on Destination Mapper (table 3):
 cookie=0x0, duration=1905.349s, table=3, n_packets=0, n_bytes=0, priority=132,ip,reg6=0xb,dl_dst=fa:16:3e:01:b0:a1,nw_dst=10.1.1.3 actions=load:0xc->NXM_NX_REG2[],load:0x1->NXM_NX_REG3[],load:0x5->NXM_NX_REG7[],set_field:fa:16:3e:f2:08:17->eth_src,set_field:fa:16:3e:04:4a:32->eth_dst,dec_ttl,goto_table:4

The match above is against the router's MAC address, which is fa:16:3e:01:b0:a1. Note that the destination address was set on the local node to fa:16:3e:04:4a:32, which is the MAC address for 10.1.1.3, which is why this flow-mod never matches.

I believe the bug is in DestinationMapper.java, in createRemoteL3RoutedFlow. Specifically, this:

        MacAddress matcherMac = routerPortMac(destL3c, srcSubnet.getVirtualRouterIp());
        MacAddress epDestMac = destEp.getMacAddress();

Note that the matcherMac is the router MAC, which is correct. However, the destination MAC used is the Endpoint, and not the router. This should probably be set to the router MAC (i.e. same as matcherMac), as final destination of the endpoint MAC is set on the flow-mod that we should be matching against.