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> routeDestination        Gateway         Iface  FlagsVRF: 0192.168.56.0/24    0.0.0.0         fp0    gateway192.168.56.33/32   0.0.0.0         fp0    local192.168.57.0/24    0.0.0.0         fp0    gateway192.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地址同步。