Question

我已经通过以下方式设置了一些虚拟IP：

~# ip link add link eth0 name eth0.1 address 11:22:33:44:55:66 type macvlan
~# ifconfig eth0.1 10.10.0.0/24

我使用以下代码从中进行连接：

sTCP = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sTCP.setsockopt(socket.SOL_SOCKET, IN.SO_BINDTODEVICE, IFACE)
print "PORT s_TCP:" + str(HOST) +":" +str(TCP_PORT)
sTCP.connect((HOST, TCP_PORT))
print "Connected"

如果IFACE是eth0，这样可以正常工作，但它不会从eth0.1通过sTCP.connect并且在eth0.2上的bindtodevice（如预期）中失败。

为什么eth0.1不起作用？这是一个python问题，还是linux网络实现中的一些东西？

Answer 1

我刚在我的Fedora 13系统上试过这个并且它有效。我确实需要进行一些修改才能使它在我的系统上运行，希望这会给你提供线索。使用的代码：

### in shell
# Used 00 for first MAC octet to avoid issues with multicast addressing
ip link add link eth0 name eth0.1 address 00:22:33:44:55:66 type macvlan
ifconfig eth0.1 10.1.23.6/25

# python
import socket
HOST = "10.1.23.30"
TCP_PORT = 80
IFACE = "eth0.1"
sTCP = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# switched to socket.SO_BINDTODEVICE since I'm not sure what "IN" referred to
# EDIT: figured out there's another module called IN, but the value is the same (25)
sTCP.setsockopt(socket.SOL_SOCKET, socket.SO_BINDTODEVICE, IFACE)
print "PORT s_TCP:" + str(HOST) +":" +str(TCP_PORT)
sTCP.connect((HOST, TCP_PORT))
print "Connected"

我使用tcpdump向自己证明数据包来自eth0.1。也许您遇到了VLAN问题？在客户端和服务器上运行数据包捕获，以查看线路上实际发生的情况。

python socket.connect似乎不适用于虚拟IP

1 个答案: