定位一个 ovs windows 2012 dhcpv6 无法获取 ip 的问题

1. 开启安全组时

windows 2012 无法拿到 kube-ovn 分配的 ipv6 地址，只能拿到一个假的 fe80 开头的 ipv6 地址

2. 关闭安全组后

3. 再次开启安全组后

最终原因是： windows 2012 没有使用基于 mac 生成 local ipv6 地址，而是直接使用了一个镜像中残留的 local ipv6 地址， 然后安全组就丢包了。kube-ovn 的 ovs 的 table 9 可以看到该 acl 对应的限制规则的流表有计数。

关于查流表

在 table0 到之后的 table 中，同一个包的处理都会带上同样的 metadata

在后续的过滤中，可以基于 matadata，直接逐跳 table 过滤

    
ovs-ofctl dump-flows br-int | grep "table=8" | grep -v " n_packets=0" | grep "metadata=0x14"
    

在每一跳 table，可以直接过滤掉 n_packets=0 的规则。

acl 的过滤首先应该考虑 mac 是否是正确的，其次应该看 协议和端口，最后看原 ip 地址，目标地址。

根据这些条件也可以加快检索流表的速度。

在定位过程中，我们在 28 表发现，dhcp 相关的规则，windows 在开启 acl 的时候，这个表是没有匹配到的，也就是说，在前面的表中已经发生了丢包。

``` bash

root@csy-wx-pm-os01-eis-node04:/kube-ovn# ovs-ofctl dump-flows br-int | grep userdata | grep -i 00:00:00:0c:f2:4b | grep udp6
cookie=0xe5ebee5e, duration=6802.293s, table=28, n_packets=2, n_bytes=348, idle_age=6356, priority=100,udp6,reg14=0x9b,metadata=0x14,dl_src=00:00:00:0c:f2:4b,ipv6_dst=ff02::1:2,tp_src=546,tp_dst=547 actions=controller(userdata=00.00.00.05.00.00.00.00.00.01.de.10.00.00.00.63.00.05.00.10.24.09.8c.20.18.33.20.00.00.00.00.00.0a.fb.af.44.00.02.00.06.00.00.00.68.53.ee,pause),resubmit(,29)
root@csy-wx-pm-os01-eis-node04:/kube-ovn#
root@csy-wx-pm-os01-eis-node04:/kube-ovn#
root@csy-wx-pm-os01-eis-node04:/kube-ovn#
root@csy-wx-pm-os01-eis-node04:/kube-ovn#
root@csy-wx-pm-os01-eis-node04:/kube-ovn#
root@csy-wx-pm-os01-eis-node04:/kube-ovn# ovs-ofctl dump-flows br-int | grep userdata | grep -i 00:00:00:0c:f2:4b | grep udp6
cookie=0xe5ebee5e, duration=6813.111s, table=28, n_packets=3, n_bytes=543, idle_age=3, priority=100,udp6,reg14=0x9b,metadata=0x14,dl_src=00:00:00:0c:f2:4b,ipv6_dst=ff02::1:2,tp_src=546,tp_dst=547 actions=controller(userdata=00.00.00.05.00.00.00.00.00.01.de.10.00.00.00.63.00.05.00.10.24.09.8c.20.18.33.20.00.00.00.00.00.0a.fb.af.44.00.02.00.06.00.00.00.68.53.ee,pause),resubmit(,29)
root@csy-wx-pm-os01-eis-node04:/kube-ovn#

以证明 没有 acl 的时候，这个 n_packets=3 有增加，有 acl 的时候没有增加

    
    
    
    
    关于 ovs 的 dhcp, 这个包是在宿主机上抓到的。 对于 dhcp 请求的包，以及 ping 网关的包，这种包是不会经过 br-int 的，而是在端口发出请求包时，经过 acl，最后触发 dhcp 的处理流表，然后直接响应回复包。
    
    
``` bash
    
    
 tcpdump -i any '(udp port 546 or port 547)' -netvvx



正常的

root@csy-wx-pm-os01-eis-node04:/kube-ovn# tcpdump -i any '(udp port 546 or port 547)' -netvvx
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes


b6f81882_net1_h M   ifindex 1862 00:00:00:0c:f2:4b ethertype IPv6 (0x86dd), length 159: (flowlabel 0xd9345, hlim 1, next-header UDP (17) payload length: 99) fe80::9c68:9453:3623:20d9.546 > ff02::1:2.547: [bad udp cksum 0x85b3 -> 0x10ee!] dhcp6 solicit (xid=7417d1 (elapsed-time 0) (client-ID hwaddr/time type 1 time 748103127 0000000cf24b) (IA_NA IAID:218103808 T1:0 T2:0) (Client-FQDN) (vendor-class) (option-request vendor-specific-info DNS-server DNS-search-list Client-FQDN))
	0x0000:  600d 9345 0063 1101 fe80 0000 0000 0000
	0x0010:  9c68 9453 3623 20d9 ff02 0000 0000 0000
	0x0020:  0000 0000 0001 0002 0222 0223 0063 85b3
	0x0030:  0174 17d1 0008 0002 0000 0001 000e 0001
	0x0040:  0001 2c97 25d7 0000 000c f24b 0003 000c
	0x0050:  0d00 0000 0000 0000 0000 0000 0027 000d
	0x0060:  000b 6863 632d 7769 6e32 3031 3900 1000
	0x0070:  0e00 0001 3700 084d 5346 5420 352e 3000
	0x0080:  0600 0800 1100 1700 1800 27
b6f81882_net1_h Out ifindex 1862 00:00:00:68:53:ee ethertype IPv6 (0x86dd), length 148: (flowlabel 0xd9345, hlim 1, next-header UDP (17) payload length: 88) fe80::200:ff:fe68:53ee.547 > fe80::9c68:9453:3623:20d9.546: [udp sum ok] dhcp6 advertise (xid=7417d1 (client-ID hwaddr/time type 1 time 748103127 0000000cf24b) (IA_NA IAID:218103808 T1:4294967295 T2:4294967295 (IA_ADDR 2409:8c20:1833:2000::afb:af44 pltime:4294967295 vltime:4294967295)) (server-ID hwaddr type 1 0000006853ee))
	0x0000:  600d 9345 0058 1101 fe80 0000 0000 0000
	0x0010:  0200 00ff fe68 53ee fe80 0000 0000 0000
	0x0020:  9c68 9453 3623 20d9 0223 0222 0058 bd81
	0x0030:  0274 17d1 0001 000e 0001 0001 2c97 25d7
	0x0040:  0000 000c f24b 0003 0028 0d00 0000 ffff
	0x0050:  ffff ffff ffff 0005 0018 2409 8c20 1833
	0x0060:  2000 0000 0000 0afb af44 ffff ffff ffff
	0x0070:  ffff 0002 000a 0003 0001 0000 0068 53ee
    
    
    
    
    

    ```
    
    
    
        ### 开启 acl 不正常的情况下，就只有 acl 请求包，这个请求包经过对比流表的命中计数（ watch 观察）发现确实是被丢包了