1、配置环境
fp0接口上配置两个IP地址：
fp0 Link encap:Ethernet HWaddr 00:0c:29:30:38:db
inet addr:192.168.56.33 Bcast:192.168.56.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe30:38db/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:51791 errors:0 dropped:0 overruns:0 frame:0
TX packets:196 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4412183 (4.4 MB) TX bytes:38552 (38.5 KB)
fp0:0 Link encap:Ethernet HWaddr 00:0c:29:30:38:db
inet addr:192.168.57.33 Bcast:192.168.57.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
2、测试现象
启动example/udpecho程序（udp回显，bind的port为2048）。测试现象如下:
1）pc上ping 192.168.56.33，可以ping通；pc上启动udp客户端，向目的ip 192.168.56.33发送udp报文，回显功能正常；
2）pc上ping 192.168.57.34，可以ping通；pc上启动udp客户端，向目的ip 192.168.57.33发送udp报文，回显功能不可用。
3、对测试现象的分析
pc上针对ip地址192.168.56.33发起的ping操作、发送udp报文，均是FP进行处理，这里不再分析。下文只分析针对192.168.57.33地址的操作。
3.1 pc上向ip 192.168.57.34发起的arp请求,是fp回应的，还是sp回应的？
[0] ODP to FP: 627.417
50:7b:9d:a1:ce:27 -> ff:ff:ff:ff:ff:ff
ARP 1 192.168.57.34 -> 192.168.57.33 [0] FP to ODP: 627.418
00:0c:29:30:38:db -> 50:7b:9d:a1:ce:27
ARP 2 192.168.57.33 -> 192.168.57.34
从packet.txt调试信息来看，是FP回应的。
代码确认：
ofp_eth_vlan_processing -> ofp_arp_processing：
当接收到ARP请求后，检查ARP请求的目的IP是否为本机的？如果是，则进行ARP回应。
再看ofp_ifnet_ip_find的具体实现，是检查接口的所有IP，只要有一个匹配，则认为是本机应该回应的。
结论：pc上向ip 192.168.57.34发起的arp请求，是fp回应的。
3.2 pc上ping 192.168.57.34,icmp响应是fp回应的？还是sp回应的？
[0] ODP to FP: 627.418
50:7b:9d:a1:ce:27 -> 00:0c:29:30:38:db
IP ICMP: echo 192.168.57.34 -> 192.168.57.33 id=256 seq=7424
[0] FP to ODP: 627.419
00:0c:29:30:38:db -> 50:7b:9d:a1:ce:27
IP ICMP: echo reply 192.168.57.33 -> 192.168.57.34 id=256 seq=7424
从packet.txt调试信息来看，是FP回应的。
代码确认：
ofp_eth_vlan_processing -> ofp_ipv4_processing：
这段代码的逻辑：判断报文的目的ip是不是接口上的第一个ip，如果是，则需要FP继续处理；如果不是接口上的第一个ip，则查找路由表，如果能查找到路由项，且路由项的flag为OFP_RTF_LOCAL，则需要FP继续处理。
telnet localhost 2345
> route
Destination Gateway Iface Flags
VRF: 0
192.168.56.0/24 0.0.0.0 fp0 gateway
192.168.56.33/32 0.0.0.0 fp0 local
192.168.57.0/24 0.0.0.0 fp0 gateway
192.168.57.33/32 0.0.0.0 fp0 local
通过查找快平面的路由表，发现对应的Local路由存在
结论：pc上ping 192.168.57.34，是FP回应的。
3.3 pc上启动udp客户端，向目的ip 192.168.57.33发送udp报文，此udp报文是进入fp处理，还是sp处理？
[0] ODP to FP: 4198.938
50:7b:9d:a1:ce:27 -> 00:0c:29:30:38:db
IP UDP PKT len=1478 192.168.57.34:52512 -> 192.168.57.33:2048
[0] FP to SP: 4198.940
50:7b:9d:a1:ce:27 -> 00:0c:29:30:38:db
IP UDP PKT len=1478 192.168.57.34:52512 -> 192.168.57.33:2048
[0] SP to ODP: 4198.940
00:0c:29:30:38:db -> 50:7b:9d:a1:ce:27
IP ICMP: dest unreachable 192.168.57.33 -> 192.168.57.34
从packet.txt调试信息来看，udp报文由于FP平面不能处理，进入SP平面，但SP平面也不能处理（没有监听2048端口），所以SP回应ICMP端口不可达报文
代码确认：
ofp_eth_vlan_processing -> ofp_ipv4_processing:
与3.3的流程相同，查找路由后，发现需要本地处理。
ofp_ipv4_processing中调用ipv4_transport_classifier（功能类似于BSD中的协议开关表），进入udp处理，但发现处理不了，返回continue将此报文从FP转发到SP中。SP同样无法处理，回应icmp目的不可达报文。
疑问：example/udpecho程序为什么不能处理针对接口第二个IP的UDP报文？
通过查看代码，socket绑定ip地址时，ofp_port_get_ipv4_addr函数只取下标0对应的IP，即接口上的第一个ip。所以，example/udpecho程序不能处理针对接口第二个IP的UDP报文。
4、结论
OpenFastPath 3.0.0版本已经支持多IP。（说明：2018年1月份的版本是不支持的）
5、SP平面配置的接口ip如何同步到FP平面
通过netlink机制进行同步。
代码线索：start_netlink_nl_server –> route_recv –> route_read
当接收到RTM_NEWADDR/RTM_DELADDR消息时，调用handle_ipv4v6_addr函数进行IP地址同步。