|
Hi,
I think I've found a bug in the setup-vif-rules script. I have configured locking mode on one VM:
locking-mode ( RW): locked
ipv4-allowed (SRW): 192.168.1.13
ipv6-allowed (SRW):
However I found out that even after I change the IP on the VM it's still available on the network.
I've checked the logs on the server and I found this for example:
python: /opt/xensource/libexec/setup-vif-rules[18647] -
['/usr/bin/ovs-ofctl', 'add-flow', 'xenbr0', 'in_port=3,priority=8000,dl_type=0x
0800,nw_proto=0x11,tp_dst=67,dl_src=96:7e:2b:1c:45:81,idle_timeout=0,action="">al']
Notice the xenbr0 interface.
ovs-ofctl dump-flows xenbr0
ovs-ofctl: xenbr0 is not a bridge or a socket
xenbr0 doesn't even exist, instead it should be applied to xapi2 in this case.
The problem seems to be in the handle_vswitch definition in the setup-vif-rules script:
def handle_vswitch(vif_type, domid, devid, action):
if (action == "clear") or (action == "filter"):
bridge_name = "xenbr%s" % devid
vif_name = "%s%s.%s" % (vif_type, domid, devid)
ip_link_set(vif_name, "down")
port = get_vswitch_port(vif_name)
clear_vswitch_rules(bridge_name, port)
if action == "filter":
config = get_locking_config(domid, devid)
locking_mode = config["locking_mode"]
if locking_mode == "locked":
create_vswitch_rules(bridge_name, port, config)
if locking_mode in ["locked", "unlocked"]:
ip_link_set(vif_name, "up")
if action == "clear":
ip_link_set(vif_name, "up")
Notice the hardcoded xenbr? After changing to bridge_name = "xapi2" everything works fine. In my case it's always xapi2. I haven't had time for an elegant solution.
After this I've started the VM again and everything was working as it should. After I changed the IP of the VM it was no longer available on the network.
And here are the ovs-ofctl flows:
ovs-ofctl dump-flows xapi2
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=55.637s, table=0, n_packets=0, n_bytes=0, priority=4000,in_port=4 actions=drop
cookie=0x0, duration=55.769s, table=0, n_packets=5, n_bytes=270, priority=6000,ip,in_port=4,dl_src=96:7e:2b:1c:45:81,nw_src=192.168.1.13 actions=NORMAL
cookie=0x0, duration=55.795s, table=0, n_packets=0, n_bytes=0, priority=7000,arp,in_port=4,dl_src=96:7e:2b:1c:45:81,nw_src=0.0.0.0,arp_sha=96:7e:2b:1c:45:81 actions=NORMAL
cookie=0x0, duration=55.782s, table=0, n_packets=3, n_bytes=126, priority=7000,arp,in_port=4,dl_src=96:7e:2b:1c:45:81,nw_src=192.168.1.13,arp_sha=96:7e:2b:1c:45:81 actions=NORMAL
cookie=0x0, duration=55.808s, table=0, n_packets=0, n_bytes=0, priority=8000,udp,in_port=4,dl_src=96:7e:2b:1c:45:81,tp_dst=67 actions=NORMAL
cookie=0x0, duration=3788.414s, table=0, n_packets=309587, n_bytes=91537264, priority=0 actions=NORMAL
cookie=0x0, duration=55.729s, table=0, n_packets=0, n_bytes=0, priority=6000,icmp6,in_port=4,icmp_type=134 actions=drop
cookie=0x0, duration=55.703s, table=0, n_packets=0, n_bytes=0, priority=6000,icmp6,in_port=4,icmp_type=146 actions=drop
cookie=0x0, duration=55.742s, table=0, n_packets=0, n_bytes=0, priority=7000,icmp6,in_port=4,icmp_type=136 actions=drop
cookie=0x0, duration=55.65s, table=0, n_packets=0, n_bytes=0, priority=6000,icmp6,in_port=4,icmp_type=153 actions=drop
cookie=0x0, duration=55.755s, table=0, n_packets=0, n_bytes=0, priority=7000,icmp6,in_port=4,icmp_type=135 actions=drop
cookie=0x0, duration=55.716s, table=0, n_packets=0, n_bytes=0, priority=6000,icmp6,in_port=4,icmp_type=137 actions=drop
cookie=0x0, duration=55.677s, table=0, n_packets=0, n_bytes=0, priority=6000,icmp6,in_port=4,icmp_type=151 actions=drop
cookie=0x0, duration=55.69s, table=0, n_packets=0, n_bytes=0, priority=6000,icmp6,in_port=4,icmp_type=147 actions=drop
cookie=0x0, duration=55.664s, table=0, n_packets=0, n_bytes=0, priority=6000,icmp6,in_port=4,icmp_type=152 actions=drop
I've seen on the internet that more users are facing this issue so maybe this helps. I hope I didn't write anything stupid, I'm quite new to XCP. :)
Tomas
|
