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地址同步。

OpenFastPath（1）：快平面接口是否支持多ip