Жизнь дополнительных IP в CentOS 7

26 Dec 2014 | Автор: anchous |

Прикупил тут новый VPS на базе CentOS 7 как раз под вмварью и пытаюсь на ней поднять дополнительные интерфейсы, но оно как то работает совсем через попу. По началу я грешил было на vmware-tools, но в процессе ковыряния пришел к тому что это админы хостинга что то накосячили с настройкой CentOS7.  Правда спойлер говорит о том, что это тоже оказалась не работа криворуких админов, а очень странная работа сервисов в новой CentOS.

Картина очень интересная – два интерфейса один с диким именем:
# ifconfig
eno16777984: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

при этом в папке сетевых скриптов несколько файликов:
# ls -l /etc/sysconfig/network-scripts/
ifcfg-eno16777984
ifcfg-eth0

если снести скрипт ifcfg-eth0, то IP адрес не поднимается, хотя такого интерфейса в системе нет.

Смотрим какой адаптер у нас поднимается при загрузке:
# yum -y install pciutils-3.2.1-4.el7.x86_64
# lspci | grep -i net
03:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
# cd /etc/sysconfig/network-scripts
# grep HWADDR ifcfg* | grep -v ^\#
ifcfg-eno16777984:HWADDR=00:50:56:AA:50:B3

Пытался добавить скрипты алиасов для интерфейса в виде ifcfg-eno16777984:NN, что всегда работало, но почему то они не стартуют. Хотя если поднимать руками из консоли через ifconfig, то IP поднимается и корректно пашет. При попытке ручного подъема тоже кроет по матери:

# ifup ifcfg-eno16777984:0
Error: no device found for connection ‘System eno16777984:0′.

В CentOS 7 есть специальный гуй отвечающий за настройку сетки, именуемый NetworkManager и вызываемый из командной строки:
# nmtui
в этом гуе как раз и настраиваем сетку, причем надо заметить, что никакие алиасы не добавляются, а дополнительные айпишки навешиваются дополнительно к существующему, в режиме редактирования интерфейса.

Если открыть скрипт старта сетки ifcfg-eno16777984, то обнаружим, что доп.IP прописываются именно в него, в виде записей
IPADDR1=1.1.1.1
PREFIX1=24
IPADDR2=1.2.3.4
PREFIX2=24
причем поковыряв файло  ifcfg-eno16777984, обнаружил что почему то параметр ONBOOT стоял в значении no, поэтому интерфейс поднимался, а IP не подтягивался и далее не отрабатывали и скрипты.

После того как выставил
ONBOOT=yes
стал присваиваться IP, но записи в основном скрипте так и не заработали по непонятной причине.

Вычитал что это может быть багом NetworkManager, т. снес его:
# service NetworkManager off
# chkconfig NetworkManager off
# systemctl disable NetworkManager
# yum remove NetworkManager
но все равно не помогло.

Если честно, к этому моменту я уже изрядно заколебался, и в какой то момент у меня даже заработал такой вот вид алиаса,  ifcfg-eno16777984_1
### ifcfg-eno16777984_1 ###
TYPE=Alias
BOOTPROTO=none
IPADDR1=1.1.1.1
PREFIX1=26
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
NAME=”ifcfg-eno16777984_1″
DEVICE=ifcfg-eno16777984:0
ONBOOT=yes
#########

но на очередной перезагрузке отвалился, т.ч поломав голову я просто переставил систему и оказалось, что у меня в в разделе сетевых интерфейсов остался единственный файл  ifcfg-eno16777984

С ним я тоже повозился изрядно, пока не понял, что для запуска интерфейса важна маска, т.к. IP принадлежащие к разным подсетям с-класса (вида 1.2.2.Х и 1.2.3.X) при ручном запуске с 24 маской нормально себе жили и пинговались, но на автомате не хотели подниматься, пока я не указал для них 16 маску и дефолтный шлюз, т.е конфиг у меня приобрел следующий вид:
TYPE=Ethernet
DEVICE=eno16777984
ONBOOT=yes
HWADDR=00:50:56:AA:50:B3
IPADDR=1.2.2.111
GATEWAY=1.2.2.1
PREFIX=26
BOOTPROTO=none
IPADDR0=1.2.3.100
PREFIX0=16
GATEWAY0=1.2.2.1
IPADDR1=1.2.3.101
PREFIX1=16
GATEWAY1=1.2.2.1
IPADDR2=1.2.4.100
PREFIX2=16
GATEWAY2=1.2.2.1

где строка PREFIX собственно и означает битную маску подсети.

Но самое непонятное во всем этом, заключалось в том, что интерфейсы пинговались, отвечали на запросы, к ним можно было подключиться, но ifconfig выдавал только основной IP, в таком виде:

# ifconfig
eno16777984: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 1.2.2.111  netmask 255.255.255.192  broadcast 1.2.2.127
inet6 fe90::260:56fe:ffba:50b3  prefixlen 64  scopeid 0×20<link>
ether 00:50:56:aa:50:b3  txqueuelen 1000  (Ethernet)
RX packets 1379  bytes 111695 (109.0 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 354  bytes 41885 (40.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

при этом IP числятся активными:
# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno16777984: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:50:56:aa:50:b3 brd ff:ff:ff:ff:ff:ff
inet 1.2.2.111/26 brd 1.2.2.127 scope global eno16777984
valid_lft forever preferred_lft forever
inet 1.2.3.100/16 brd 1.2.255.255 scope global eno16777984
valid_lft forever preferred_lft forever
inet 1.2.3.101/16 brd 1.2.255.255 scope global secondary eno16777984
valid_lft forever preferred_lft forever
inet 1.2.4.100/16 brd 1.2.255.255 scope global secondary eno16777984
valid_lft forever preferred_lft forever
inet6 fe90::260:56fe:ffba:50b3/64 scope link
valid_lft forever preferred_lft forever

Откровенно говоря, на этой торжественной ноте я сдался, т.к IP вроде как работали, хотя и сильно по своему. Не скажу что мне это нравится и вероятнее всего переставлю систему в 6.6.

VN:F [1.9.21_1169]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.21_1169]
Rating: 0 (from 0 votes)

Теги: ,

Ваш отзыв