Вопросы Теги

Как я могу заставить Linux соблюдать новую сетевую маску без "жесткого" перезапуска сетевой подсистемы?

Sharepoint действительно использует SQL, но будет указан в другом месте. Единственная проблема, которую я вижу, состоит в том, что Вы получите удар производительности.

3
задан 13 April 2017 в 15:14
5 ответов

Первые вещи сначала, не использовать ifconfig и route. Эти команды обычно рассматриваются как устаревшие сегодня; они были записаны слишком долго назад, когда Linux имел совсем другой сетевой стек и был исправлен с тех пор. Самая идея интерфейсных псевдонимов (например, ethX:YY), чтобы иметь несколько адресов, является устаревшей сегодня, они все еще существуют главным образом для угождения самого ifconfig. Сегодня, ip команда должна удовлетворить все Ваши потребности.

Теперь, поймите свою исходную ситуацию: Ваш интерфейс eth0 первоначально имел два активных объема:/24 и/27. 172.16.45.3 был основной адрес для объема/24, в то время как 172.16.45.21 был основной адрес для объема/27 (потому что он перечислен сначала). При выдаче ifconfig команды для изменения префикса первого адреса, это удалило его и повторно вставило его как вторичный адрес в объеме/27. Таким образом, теперь у Вас должно быть что-то вроде этого:

inet 172.16.45.21/27 brd 172.16.45.31 primary   eth0:11
inet 172.16.45.22/27 brd 172.16.45.31 secondary eth0:12
inet 172.16.45.3/27  brd 172.16.45.31 secondary eth0

Не имеет значения, что eth0 должен быть основным, или что похоже, что это должно быть основным (другая причина не использовать ifconfig). Это было вставлено последнее в объеме/27, таким образом, это - вторичный адрес. Это также означает, что исходящие пакеты будут обращены 172.16.45.21, и что при обеспечении eth0:11 вниз с помощью ifconfig все адреса будут удалены вместе. Это - то, как это работает.

Единственный способ зафиксировать это состоит в том, чтобы удалить все адреса из интерфейса и повторно вставить их в правильном порядке. Затем первый добавленный адрес (в объеме/27) будет основным адресом в том объеме, и дальнейшие адреса все будут вторичными устройствами.

Обращение было уже повреждено с начала, не был очень, Вы могли сделать в этой ситуации. Ваше лучшее решение состоит в том, чтобы просто перезапустить сетевую службу.

Одно возможное обходное решение должно изменить адрес маршрутизации от источника. Это будет иметь почти тот же эффект изменения основного адреса. В Вашем случае:

ip route change 172.16.45.0/27 dev eth0 src 172.16.45.3

В этом случае пакетам, идущим в 172.16.45.0/27, установят исходный адрес на 172.16.45.3. Вам будет нужна другая команда, если Вы также захотите изменить источник пакетов, проходящих через шлюз.

3
ответ дан 3 December 2019 в 05:09
  • 1
    I' m принимающий это, потому что это, кажется, становится самым близким к основе проблемы, даже при том, что я can' t больше тестируют его. Спасибо за Ваш ответ деталей. –  jj33 8 January 2010 в 17:48

Я имел подобную проблему (два сервера с eth0 и eth1 в том же сегменте Ethernet) и не мог выяснить, как вызвать источник в моем случае. Однако можно попробовать этот вид подхода для принуждения исходного IP в случае:

ip route add dev eth0 src 172.16.45.3 172.16.45.4 metric 2

Это о метрике снова, но включая источник в уравнении. На моей домашней конфигурации это позволило мне выбирать другой IP для соединения с моим сервером по сравнению с тем, что ядро выберет по умолчанию.

2
ответ дан 3 December 2019 в 05:09

Вы не сказали, какое распределение Вы использование. Необходимо изменить конфигурационные файлы и использовать некоторый initscript для перезагрузки параметров сети. (При пропуске этого шага настройки будут потеряны после перезагрузки.)

Вторая вещь - это в наше время ip инструмент предпочтен по ifconfig на Linux. С ip это можно добавить и удалить IP-адреса на лету.

1
ответ дан 3 December 2019 в 05:09
  • 1
    CentOS 5.1, хотя я don' t ожидают, что ядро этой проблемы будет конкретным распределением. Я действительно изменял файлы конфигурации, таким образом, что они будут корректны при начальной загрузке. Я полностью ожидаю это, если я выполнил ' сеть услуг restart' моя проблема была бы решена, но это прервет produciton трафик, который был всем смыслом моего вопроса. ifconfig может, конечно, добавить и удалить IP-адреса на лету, но я посмотрю на IP, чтобы видеть, предлагает ли он некоторое управление этой ситуацией, что ifconfig не делает. Спасибо за ответ. –  jj33 23 December 2009 в 21:07

Вы попытались установить метрики с ifconfig?

metric n Установите маршрутную метрику интерфейса к n, значение по умолчанию 0. Маршрутная метрика используется протоколом маршрутизации. Более высокие метрики имеют эффект создания менее благоприятного маршрута; метрики считаются, поскольку дополнение скачкообразно двигается к сети назначения или хосту.

Ссылка

В основном Вы хотите предпочесть использовать один NIC по другому. Попытайтесь установить ссылки A и B, чтобы иметь метрику 1.

1
ответ дан 3 December 2019 в 05:09
  • 1
    метрика в и себя wouldn' t фиксируют это я don' t думают, потому что весь дюйм/с использует ту же запись маршрутизации в таблице. It' s не о выборе места назначения, it' s о выборе исходного IP и всего исходного дюйм/с находятся (теперь) в той же подсети. Спасибо за ответ! –  jj33 23 December 2009 в 23:29
  • 2
    А-ч. Я получил его назад. –  Joseph Kern 24 December 2009 в 03:03

Не уверенный, если я понимаю, но возможно можно сделать что-то как

маршрут добавляет - сетевой 172.16.45.0/27 dev eth0

Это вынуждает все соединения с той подсетью пройти eth0, который имеет IP-адрес, который Вы упомянули.

1
ответ дан 3 December 2019 в 05:09
  • 1
    У меня уже есть маршрут для той сети, через то устройство, в моей таблице маршрутизации как показано в маршруте-n вывод выше. " Device" в таблице маршрутизации, кажется, физическое устройство, не логическое устройство, таким образом, они все установлены на физическое устройство eth0 независимо от того, каково логическое устройство выбранного исходящего IP. Спасибо за ответ! –  jj33 23 December 2009 в 23:31

Теги

Похожие вопросы