Прошу помощи однофорумчан :Есть сервер с CentOS 6.0 на нем настроена и работает виртуализация KVM, виртуалки тоже CentOS 6.0
Поставили сервер на colocation в ДЦ, провайдер на выбранном нами тарифном плане,
как уже позже выяснилось, на порту делает ограничение - 1 mac адрес , хотя дает несколько белых IP адреса.структура подключения сети у нас следующая :
ISP-eth --> eth0 --> br0 --> KVM_VM_eth0подсеть - 203.0.113.0/23 - белые IP адреса (адресация изменена для примера)
203.0.113.2 (br0) - шлюз провайдера
203.0.113.175 (br0) - шлюз - он же гипервизор
203.0.113.218 (KVM_VM_eth0) - виртуалкатак вот работает сеть только на 203.0.113.175 (br0),
когда запускаю на гипервизоре виртуальную машину, присвоив ей IP:203.0.113.218/23, GW:203.0.113.2 то трафик
не входит в мир и виртуальная машина также из вне не доступна! При выключенном
файрволе суть проблемы та же! Гипервизор - естественно из виртуалки пингуется.связался с провайдером он сказал, что есть ограничение на порту 1 mac (от провайдера приходит один кабель) и предложил два варианта:
1. настроить свой основной сервер роутером для белых IP, чтобы виртуальные машины ходили через него.
2. сменить тарифный план, где нет таких ограничений, который стоит в два раза дороже.Конечно же делаю первый вариант :
На гипервизоре выключаю файрвол (или добавляю -A FORWARD -d 203.0.113.0/23 -j ACCEPT , -A FORWARD -s 203.0.113.0/23 -j ACCEPT)
смотрю чтобы был разрешен роутинг пакетов:
[root@gateway ~]# sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0в виртуальной машине, делаю следующие настройки IP:203.0.113.218/23, GW:203.0.113.175
после делаю пинг с виртуалки:203.0.113.175
[root@virt-machine ~]#ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 203.0.113.175: icmp_seq=1 Redirect Host(New nexthop: 203.0.113.2)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=39.7 ms
From 203.0.113.175: icmp_seq=2 Redirect Host(New nexthop: 203.0.113.2)
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=39.2 msвидно, что несколько пакетов проходит и потом все залипает и сеть не работает.
тут же:
[root@virt-machine ~]# ping 203.0.113.175
PING 203.0.113.175 (203.0.113.175) 56(84) bytes of data.
64 bytes from 203.0.113.175: icmp_seq=1 ttl=64 time=0.202 ms
64 bytes from 203.0.113.175: icmp_seq=2 ttl=64 time=0.170 ms
64 bytes from 203.0.113.175: icmp_seq=3 ttl=64 time=0.206 ms
64 bytes from 203.0.113.175: icmp_seq=4 ttl=64 time=0.166 ms
--- 203.0.113.175 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3926ms
rtt min/avg/max/mdev = 0.166/0.186/0.206/0.018 msЕсли подождать некоторое время, то снова можно пропустить пару пакетов и
сеть снова залипнет. Через некоторое время опять.делаю пинг из вне на виртуальную машину:
$ ping 203.0.113.218
PING 203.0.113.218 (203.0.113.218): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
пробовал отключать gso,tso,lro внутри виртуалки# ethtool -K eth0 gso off
# ethtool -K eth0 tso off
# ethtool -K eth0 lro offПопробовал сделать на шлюзе-гипервизоре NAT , и прописал соответствующие настройки в вируалке - все работает как часы !!! А с белыми IP адресами не пашет.
Также раньше настраивал виртуализацию на трех разных серверах в другом ДЦ - там нет ограничения на порту только для 1 mac'a
плюс стоит свой свич и все отлично работает.На этом все не заканчивается ! :
Пошел дальше - попросил провайдера снять на несколько часов органичнее 1 mac на порту - админам респект и уважуха,
потому как пошли на встречу и выполнили просьбу.Тестирую :
Тест 1. настраиваю сеть в виртуалке - IP:203.0.113.218/23, GW:203.0.113.2(шлюз провайдера) - трафик ходит все работает :
[root@virt-machine ~]# ip route ls
62.149.12.0/23 dev eth0 proto kernel scope link src 203.0.113.218
169.254.0.0/16 dev eth0 scope link metric 1002
default via 203.0.113.2 dev eth0[root@virt-machine ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=38.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=39.3 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=39.0 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=39.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=39.1 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=57 time=38.9 ms--- 8.8.8.8 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6672ms
rtt min/avg/max/mdev = 38.882/39.059/39.335/0.276 msroot@dvk ~]# traceroute yandex.ru
traceroute to yandex.ru (77.88.21.11), 30 hops max, 60 byte packets
1 gw2.isp.net (203.0.113.2) 0.514 ms 0.488 ms 0.510 ms
2 hobbit.isp.net (203.19.2.99) 0.841 ms 0.814 ms 0.814 ms
3 yandex-10G-gw.ix.net.ua (195.35.65.88) 0.547 ms 0.524 ms 0.507 ms
4 panas-vlan601.yandex.net (87.250.233.69) 7.953 ms 7.949 ms 7.913 ms
5 213.180.213.118 (213.180.213.118) 20.035 ms 20.009 ms 20.009 ms
6 l3-s900-dante.yandex.net (213.180.213.70) 20.328 ms 20.332 ms 20.411 ms
7 s600-s900.yandex.net (213.180.213.54) 23.734 ms 20.694 ms 20.659 ms
8 yandex.ru (77.88.21.11) 20.867 ms 20.586 ms 20.557 ms
Тест 2. настраиваю сеть в виртуалке - IP:203.0.113.218/23, GW:203.0.113.175(мой шлюз) - трафик также ходит все работает ,
но в глаза бросаются сразу следующие моменты - первые пакеты идут через мой шлюз, а потом каким-то образом виртуалка
переключает маршрут и пытается использовать по умолчанию шлюз провайдера, хотя в ip route строго задан мой шлюз пот умолчанию. Примеры ниже:[root@virt-machine ~]# ip route ls
62.149.12.0/23 dev eth0 proto kernel scope link src 203.0.113.218
169.254.0.0/16 dev eth0 scope link metric 1002
default via 203.0.113.175 dev eth0[root@virt-machine ~]# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * 209.85.249.22 (209.85.249.22) 39.068 ms 39.071 ms
6 72.14.239.60 (72.14.239.60) 39.525 ms 41.753 ms 41.711 ms
7 209.85.254.114 (209.85.254.114) 41.518 ms 209.85.254.118 (209.85.254.118) 38.617 ms 38.578 ms
8 google-public-dns-a.google.com (8.8.8.8) 38.764 ms 38.908 ms 38.865 msеще раз - будет уже по другому :
[root@virt-machine ~]# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 gw2.isp.net (203.0.113.2) 0.909 ms 0.872 ms 0.897 ms
2 * * *
3 google-gw.itsinternet.net (213.133.164.166) 1.075 ms 1.108 ms 1.645 ms
4 209.85.249.22 (209.85.249.22) 38.533 ms 38.507 ms 209.85.241.54 (209.85.241.54) 65.360 ms
5 72.14.239.60 (72.14.239.60) 39.010 ms 38.989 ms 38.949 ms
6 209.85.254.118 (209.85.254.118) 38.690 ms 209.85.254.112 (209.85.254.112) 39.108 ms 209.85.254.114 (209.85.254.114) 39.078 ms
7 216.239.46.183 (216.239.46.183) 39.314 ms * *
8 google-public-dns-a.google.com (8.8.8.8) 38.972 ms 38.812 ms 38.770 msдальше все работает то есть, как то переключаются маршруты и сразу используется шлюз провайдера,
когда не было разрешено больше 1 mac адреса, то не работало, потому как маршруты переключатся и по умолчанию используется шлюз провайдера ,
а он не доступен потому, как действует ограничение на 1 mac и трафик со вторым mac'ом просто зарезается на порту свича.проверяю еще раз :
рестартую сеть
[root@virt-machine ~]# service network restart
Shutting down interface eth0: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: lo: Disabled Privacy Extensions
[ OK ]
Bringing up interface eth0: [ OK ][root@virt-machine ~]# ip route
62.149.12.0/23 dev eth0 proto kernel scope link src 203.0.113.218
169.254.0.0/16 dev eth0 scope link metric 1002
default via 203.0.113.175 dev eth0[root@virt-machine ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 203.0.113.175: icmp_seq=1 Redirect Host(New nexthop: 203.0.113.2)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=39.0 ms
From 203.0.113.175: icmp_seq=2 Redirect Host(New nexthop: 203.0.113.2)
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=39.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=39.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=38.8 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=57 time=39.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=57 time=38.8 ms--- 8.8.8.8 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8871ms
rtt min/avg/max/mdev = 38.811/39.023/39.629/0.280 ms[root@virt-machine ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=38.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=39.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=39.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=38.9 ms--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4221ms
rtt min/avg/max/mdev = 38.864/39.066/39.477/0.328 ms
[root@virt-machine ~]# traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 gw2.isp.net (203.0.113.2) 0.526 ms 0.478 ms 0.492 ms
2 * * *
3 google-gw.itsinternet.net (213.133.164.166) 1.000 ms 1.039 ms 1.112 ms
4 209.85.241.54 (209.85.241.54) 1.376 ms 209.85.249.22 (209.85.249.22) 38.755 ms 38.734 ms
5 72.14.239.60 (72.14.239.60) 38.694 ms 72.14.239.14 (72.14.239.14) 25.191 ms 72.14.239.60 (72.14.239.60) 38.650 ms
6 209.85.254.112 (209.85.254.112) 38.474 ms 209.85.254.118 (209.85.254.118) 38.688 ms 209.85.250.231 (209.85.250.231) 30.608 ms
7 * * *
8 72.14.236.68 (72.14.236.68) 53.332 ms google-public-dns-a.google.com (8.8.8.8) 40.639 ms 39.771 msпройдет время, маршрут удалится - и можно повторить ситуацию еще раз
[root@virt-machine ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 203.0.113.175: icmp_seq=1 Redirect Host(New nexthop: 203.0.113.2)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=39.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=39.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=39.6 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=38.7 ms--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4755ms
rtt min/avg/max/mdev = 38.718/39.139/39.635/0.395 ms
[root@virt-machine ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=39.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=38.9 ms--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2760ms
rtt min/avg/max/mdev = 38.922/39.031/39.199/0.120 ms
ИТОГ:Что это за такое магическое переопределение шлюза по умолчанию? И как с этим боротся, что бы всегда использовался мой шлюз.
Подскажите пожалуйста кто-то , а то фантазия уже закончилась.Наперед огромное спасибо.
sysctl -w net.ipv4.conf.all.accept_redirects=0
?
как решить эту проблему?
> как решить эту проблему?Какую? Комманду выше нужно выполнить и посмотреть что будет. По идее все должно быть хорошо.
Ниасилил, многабукав.
На Xen я делаю через proxy_arp.
net.ipv4.conf.eth0.proxy_arp = 1VM:
net.ipv4.conf.vif1/0.proxy_arp = 1
ifconfig eth0 - стандартно (HOSTIP)
ifconfig vif1.0 - при поднятии в скриптах выставляется адрес eth0 (HOSTIP) с маской /32
Линуксовые виртуалки (дебиан) конфигурятся потом так:
auto eth0
iface eth0 inet static
address IP
pointopoint HOSTIP
gateway HOSTIP
netmask 255.255.255.255
post-up ethtool -K eth0 tx off
Виндовые виртуалки тоже работают. Маску там я ставил /24 потому что такая маска на основном физ интерфейсе HOSTIP. Помоему можно ставить любую меньшую маску =) Дальше всё работает из-за включенного proxy-arp.а, да. При поднятии виртуалки я также прописываю в хост-системе маршрут к ней:
ip route add ${addr} dev ${vif} src ${hostip}
------------------
Существует также второй вариант, без использования proxy_arp.Это арп-публикация:
Делается так:/usr/sbin/arp -i eth0 -d $IP pub
После этого комп начинает получать трафик для этого айпи, а дальше его требуется замаршрутизировать в нужный интерфейс виртуалки командойip route add ${addr} dev ${vif} src ${hostip}
Этот вариант может не очень корректно сработать с Win, которая никак не поймет что Ethernet бывает point-to-point.
В обеих случаях снаружи все адреса видятся привязанными к мак-адресу физ сервера.
Изменение переменной net.ipv4.conf.all.accept_redirects=0 ничего не решило.А вот за подсказку с proxy_arp огромное спасибо! Не знал раньше о таком.
Теперь все работает, как часы и кому интересно, как именно обошел проблему - по порядку:читаем, что это за технология - http://xgu.ru/wiki/Proxy_ARP
также четвертая ссылка в гугле ведет на отличную статью http://habrahabr.ru/blogs/linux/70512/
но я не хотел сильно глобально переделывать структуру сети и использовать tap интерфейсы, потому сделал приблизительно, как
написано здесь http://www.opennet.me/tips/info/923.shtmlПришлось немного перестроить структуру сети.
Сейчас она выглядит вот так :ISP-eth --> eth0 --> eth1 --> br1 --> KVM_VM_eth0
203.0.113.175/23 (eth0), GW:203.0.113.2
203.0.113.175/23 (br1)интерфейс br1 используем для наших KVM виртуалок
в /etc/rc.local добавляем переопределении маршрутов :
ip route del 203.0.113.0/23 dev eth0
ip route add 203.0.113.2 dev eth0и не забываем включить proxy_arp в /etc/sysctl.conf:
net.ipv4.conf.eth0.proxy_arp = 1
net.ipv4.conf.br1.proxy_arp = 1! Уточнение : Ethernet link есть только на интерфейсе eth0, но это нам не мешает использовать eth1 для
наших целей, который мы просто поднимаем и создаем поверх него br1.теперь все работает, как и задумывалось - все виртуалки ходят через собственный шлюз,
а в traceroute из vm есть честный промежуточный хоп - наш шлюз :[root@virt-machine ~]# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 server1.isp.com (203.0.113.175) 0.198 ms 0.141 ms 0.125 ms
2 gw2.isp.net (203.0.113.2) 0.493 ms 0.524 ms 0.514 ms
3 * * *
4 google-gw.itsinternet.net (213.133.164.166) 0.830 ms 0.956 ms 0.929 ms
5 209.85.249.22 (209.85.249.22) 53.853 ms 53.812 ms 53.684 ms
6 72.14.239.60 (72.14.239.60) 38.750 ms 38.867 ms 38.848 ms
7 209.85.254.118 (209.85.254.118) 38.543 ms 209.85.254.112 (209.85.254.112) 38.820 ms 38.735 ms
8 google-public-dns-a.google.com (8.8.8.8) 39.097 ms 38.863 ms 39.113 ms
!Дополнение!Появилось время описываю - есть еще некоторые моменты, который нужно проделать
после всего выше сказанного, все это нужно для более стабильной работы такой структуры сети:в дополнение нужно удалить созданные маршруты по умолчанию на br1 и создать новые -
добавляем в /etc/rc.local еще следующие :ip route del 203.0.113.0/23 dev br1
ip route add 203.0.113.218 dev br1
ip route add 203.0.113.219 dev br1в итоге у вас должно быть так:
[root@gateway ~]# ip route ls
203.0.113.219 dev br1 scope link
203.0.113.218 dev br1 scope link
203.0.113.2 dev eth0 scope link
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev br1 scope link metric 1006
default via 203.0.113.2 dev eth0а также в iptables форвардинг лучше разрешить только на те IP, которые есть у вас дополнительно кроме шлюзового IP - к примеру, у нас 203.0.113.218, 203.0.113.219, значит соответственно:
удаляем ->
-A FORWARD -d 203.0.113.0/23 -j ACCEPT
-A FORWARD -s 203.0.113.0/23 -j ACCEPTдобавляем ->
-A FORWARD -d 203.0.113.218/32 -j ACCEPT
-A FORWARD -s 203.0.113.218/32 -j ACCEPT
-A FORWARD -d 203.0.113.219/32 -j ACCEPT
-A FORWARD -s 203.0.113.219/32 -j ACCEPTПри таких настройках, все работает просто отлично - проверено уже несколькими неделями.
Спасибо еще раз PavelR за подсказку - смотреть в сторону proxy_arp.
> Есть сервер с CentOS 6.0 на нем настроена и работает виртуализация KVM,
> виртуалки тоже CentOS 6.0[...]
> Что это за такое магическое переопределение шлюза по умолчанию? И как с
> этим боротся, что бы всегда использовался мой шлюз.
> Подскажите пожалуйста кто-то , а то фантазия уже закончилась.И я тоже "многа букаф и ниасилил". :-S
Не знаю, поможет ли, но напомнило -- вот здесь http://zaitcev.livejournal.com/211321.html человек решает проблемы с какими-то неработающими статическими роутами, используя zebra routed на хосте и в KVM-ах. На Fedora.
+++Отдельное спасибо http://planet.kernel.org/