Проблемы с сетевым интерфейсом / dhcp Ubuntu с KVM и сетевым мостом
6213
Alex Edwards
У меня есть система Ubuntu под управлением 12.10
Я использую KVM и настроил мост для виртуальных машин, который использует пересылку nat. У меня периодически возникают проблемы с пропаданием соединения, иногда оно сохраняется в течение нескольких дней, а иногда и нескольких минут.
Я отключил мост, чтобы решить проблему, но это все еще происходит, я пытался сделать ручной выпуск и обновление dhcp, который иногда работает, он возвращает мне новый ip, и я снова отсутствует, но я заметил, что мой ip не обновляется, когда я запускаю ifconfigили в настройках подключения kvm.
/ и т.д. / интерфейсы
auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp #auto br0 #iface br0 inet dhcp # bridge_ports eth0 # bridge_stp off # bridge_fd 0 # bridge_maxwait 0
Internet Systems Consortium DHCP Client 4.2.4 Copyright 2004-2012 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/virbr0/f6:94:09:8f:7b:b5 Sending on LPF/virbr0/f6:94:09:8f:7b:b5 Listening on LPF/eth0/38:60:77:aa:aa:aa Sending on LPF/eth0/38:60:77:aa:aa:aa Sending on Socket/fallback DHCPRELEASE on eth0 to 10.0.0.254 port 67
sudo dhcpclient -v
Internet Systems Consortium DHCP Client 4.2.4 Copyright 2004-2012 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/virbr0/f6:94:09:8f:7b:b5 Sending on LPF/virbr0/f6:94:09:8f:7b:b5 Sending on Socket/fallback DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 15
На данный момент я знаю, что единственный выход из этого состояния - это отключить сетевой кабель и перезапустить
ОБНОВИТЬ
Когда соединение обрывается, у меня был некоторый успех, работающий sudo dhclient -vбез потери адреса в первую очередь.
Dhclient -v
Internet Systems Consortium DHCP Client 4.2.4 Copyright 2004-2012 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/virbr0/96:a2:d6:f5:30:fc Sending on LPF/virbr0/96:a2:d6:f5:30:fc Listening on LPF/eth0/38:60:77:aa:aa:aa Sending on LPF/eth0/38:60:77:aa:aa:aa Sending on Socket/fallback DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 DHCPREQUEST of 10.0.0.129 on eth0 to 255.255.255.255 port 67 DHCPOFFER of 10.0.0.129 from 10.0.0.254 DHCPACK of 10.0.0.129 from 10.0.0.254 bound to 10.0.0.129 -- renewal in 5716 seconds.
здесь я вижу, что меня арендуют, 10.0.0.129но ifconfig по-прежнему отображает10.0.0.137
может быть, я должен отключить эту беспроводную карту, поскольку я не использую это
Alex Edwards 11 лет назад
0
Вы можете опубликовать вывод `tail -f / var / log / syslog`? и tcpdump networkmanager в то время как соединение теряется? (лучше всего на http://pastebin.com)
rubo77 11 лет назад
0
@ rubo77 сделает, это может быть какое-то время его хорошо вели себя сегодня!
Alex Edwards 11 лет назад
0
Я искренне удивлен, что никто не упомянул очевидный ответ -
Отбросьте DHCP и используйте статическую IP-адресацию. Вы можете продолжить с NAT ETC, просто не назначайте IP-адреса из пула DHCP, но в той же подсети, и все должно работать надежно и предсказуемо.
Все, что вам нужно сделать, чтобы включить статическую IP-адресацию, это изменить
авто eth0 iface eth0 inet dhcp
в
авто eth0 адрес XXXX iface eth0 inet static маска сети 255.255.255.0 шлюз XXXY
Убедитесь, что шлюз является адресом, назначенным KVM (если вы выполните / sbin / route -n, он покажет вам шлюз по умолчанию - это IP-адрес для использования).
хорошее статическое IP-объяснение для моста
Thufir 6 лет назад
0
0
killermist
Выстрел в темноте:
ethX не должен ничего DHCP.
С машины, основанной на Proxmox, результат ifconfig (с мостом vmbr0 к eth1 (единственный реальный, подключенный NIC, потому что это gbit)), я получаю:
хорошо, я отключил мост, который является br0, когда он включен, у eth0 нет ip, он появляется на br0, но я все еще получаю те же проблемы с пропаданием соединения. virbr0 - это нечто, созданное kvm, я думаю, что это nat для виртуальных хостов, которые получают внешне адресуемые ips, когда они работают, но эта конфигурация не работает ни с одним vm.
Alex Edwards 11 лет назад
0
Ya. Это был выстрел в темноте, и он был слишком длинным, чтобы комментировать вопрос. Я подумал, что это может вызвать некоторые идеи, которые могут привести вас к правильному результату. Я надеюсь, что вы поймете это, или что кто-то другой знает ответ.
killermist 11 лет назад
0
0
rubo77
Another shot in the dark:
you could try to disable IPv6 control in Networkmanager: set it from Method:"Automatic" to Method "Ignore"
that solved this kind of problem to me once.
if that doesen't work, you should examin the output of
tail -f /var/log/syslog
while the connection gets lost and reconnects
another hint can be gained by examining a tcpdump of networkmanager
ipv6 уже должен быть отключен. У меня есть net.ipv6.conf.all.disable_ipv6 = 1, net.ipv6.conf.default.disable_ipv6 = 1, net.ipv6.conf.lo.disable_ipv6 = 1, в моем файле sysctl.conf
Alex Edwards 11 лет назад
0
0
pilona
If you're using a bridge to connect your VMs to the same network as eth0, you should generally not need to do any NATing. You should only need to perform the following five steps:
Configure your hypervisor to use the appropriate bridge interface. KVM is just something provided by the kernel. A hypervisor may use that to implement a virtual machine. If the hypervisor is set to use virbr0 but you configured br0, you will of course have issues. It seems that virbr0 is what your hypervisor set up automagically, so at this point you only need to make sure your VMs use that interface (I would assume that is already done) and that eth0 has been added to it (i.e., sudo brctl addif virbr0 eth0)
Make sure all the relevant links are up (i.e., sudo ip link set dev eth0 up; sudo ip link set dev virbr0 up). Prefer ip from the iproute2 package; ifconfig from the net-tools package is long deprecated, though it should work still for something so basic.
Enable IP forwarding in the kernel (i.e., sysctl net.ipv4.ip_forward=1)
Set your firewall to allow the bridged traffic. If you're not particularly picky or concerned about people sending arbitrary traffic to your VMs, you can just do the following to allow any traffic through:
If bridged traffic is visible to iptables (i.e., net.bridge.bridge-nf-call-iptables = 1):
Flush the iptablesFORWARD chain (iptables -F FORWARD) in table filter.
Set its policy to ACCEPT (iptables -P FORWARD ACCEPT).
Make sure you're not doing filtering in any other tables (which you shouldn't, as it isn't their purpose).
If bridged traffic is visible to arptables (i.e., net.bridge.bridge-nf-call-arptables = 1), you'll need to do something similar to the above for the IN and OUT chains in table filter (the only table in fact).
Again, do something similar for ebtables. No need to check whether a certain sysctl is set, it is always relevant for bridged traffic.
I have omitted the details for the last two since it's quite unlikely that you're system has any configuration there. You may not even have them installed on your system, in which case you can just skip those steps.
Make sure you're not ARP proxying. You probably don't need need it (e.g., for something completely unrelated to this question) and are probably not doing it, so just sudo sysctl net.ipv4.conf.all.proxy_arp=0. If you are bridging, you shouldn't proxy ARP for such a simple example.
To my knowledge, there is no such thing as "NAT forwarding". Did you just mean plain IP forwarding (not the same thing as ethernet bridging either)? Did you mean port forwarding? Just forwarding the bootps (67) and bootpc (68) ports (used by the DHCP server and client respectively) and NATing everything else is a very queer setup and will make debugging things hard.