Доброго времени суток!Прошу прощения за глупый вопрос.
Камнем преткновения является шлюз, имеющий два интерфейса: eth1 - внешний (DHCP) (для PPPoE-соединения,
предоставляемого провайдером), eth0 - внутренний (192.168.0.0/24).
Адреса, полученнные от DHCP-сервера провайдера через интерфейс eth1, к сожалению, принадлежат подсети 192.168.0.0/16,
но тут ничего нельзя сделать.
Примерно через 30 минут после PPPoE-соединения в логах появляются записи вида:Sep 7 03:29:45 xxxxx dhclient: DHCPREQUEST on eth1 to 192.168.0.111 port 67
Sep 7 03:30:05 xxxxx dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Sep 7 03:30:05 xxxxx dhclient: DHCPACK from 192.168.0.111
Sep 7 03:30:05 xxxxx dhclient: bound to 192.168.0.2 -- renewal in 1503 seconds.
Sep 7 03:55:08 xxxxx dhclient: DHCPREQUEST on eth1 to 192.168.0.111 port 67
Sep 7 03:55:48 xxxxx last message repeated 4 times
Sep 7 03:56:59 xxxxx last message repeated 5 times
Sep 7 03:58:16 xxxxx last message repeated 5 times
Sep 7 03:59:35 xxxxx last message repeated 5 times
Sep 7 04:00:42 xxxxx last message repeated 5 times
Sep 7 04:01:45 xxxxx last message repeated 5 times
Sep 7 04:02:46 xxxxx last message repeated 5 times
Sep 7 04:03:52 xxxxx last message repeated 4 times
Sep 7 04:04:53 xxxxx last message repeated 4 times
Sep 7 04:06:05 xxxxx last message repeated 4 times
Sep 7 04:07:13 xxxxx last message repeated 6 times
Sep 7 04:08:14 xxxxx last message repeated 4 times
Sep 7 04:09:33 xxxxx last message repeated 6 times
Sep 7 04:10:42 xxxxx last message repeated 5 times
Sep 7 04:11:46 xxxxx last message repeated 5 times
Sep 7 04:12:52 xxxxx last message repeated 6 times
Sep 7 04:14:07 xxxxx last message repeated 6 times
Sep 7 04:15:18 xxxxx last message repeated 5 times
Sep 7 04:16:27 xxxxx last message repeated 5 times
Sep 7 04:17:29 xxxxx last message repeated 5 times
Sep 7 04:18:30 xxxxx last message repeated 4 times
Sep 7 04:19:34 xxxxx last message repeated 5 times
Sep 7 04:20:35 xxxxx last message repeated 4 times
Sep 7 04:21:42 xxxxx last message repeated 5 times
Sep 7 04:22:35 xxxxx last message repeated 4 times
Sep 7 04:22:50 xxxxx dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Sep 7 04:22:50 xxxxx dhclient: DHCPACK from 192.168.0.111
Sep 7 04:22:50 xxxxx dhclient: bound to 192.168.0.2 -- renewal in 1775 seconds.
Sep 7 04:52:25 xxxxx dhclient: DHCPREQUEST on eth1 to 192.168.0.111 port 67Примерно через час пропадает соединение с интернетом, сопровождая это событие записью: kernel: eth1: link down,
однако, интерфейсы eth1 и ppp0 остаются поднятыми.Заранее спасибо.
P.S. ОС - CentOS 5.2; адрес, получаемый через ppp0 - статический, "белый"
>Камнем преткновения является шлюз, имеющий два интерфейса: eth1 - внешний (DHCP) (для
>PPPoE-соединения,
>предоставляемого провайдером), eth0 - внутренний (192.168.0.0/24).
>
>Адреса, полученнные от DHCP-сервера провайдера через интерфейс eth1, к сожалению, принадлежат подсети
>192.168.0.0/16, но тут ничего нельзя сделать.Вроде как неправильно что такие адреса имеются на обоих интерфейсах - попробуй смени на eth0 сетку к примеру на 172.16.0.0/12
Всем огромное спасибо за ответы! Проблема временно решена прописыванием статического адреса из подсети 192.168.1.0/24 на eth1.>Вроде как неправильно что такие адреса имеются на обоих интерфейсах - попробуй
>смени на eth0 сетку к примеру на 172.16.0.0/12Мне самому очень неприятно решать проблемы, возникающие из-за недальновидности провайдера. Сменить адрес внутренней сетки проблематично из-за ее топологии (несколько беспроводных роутеров + пар свичей), попросту не хочется трогать то, что работает.
> eth0 - статический?
Да
> Но можно свою подсеть переадресовать?
Можно, но только в крайнем случае (из-за означенных выше причин).
> А как выглядит таблица маршрутов при поднятом РРРоЕ?
К сожалению, не успел ее зафиксировать на момент возникновения проблемы.
> DHCP провайдера висит на 192.168.0.111 или это выданный для eth1 адрес? Сами мы насквозь статические :)
Фактичести оказалось, что DCHP-серверами провайдера являются ADSL модемы (192.168.0.111 - один из этих модемов), расположенные, вопреки ожиданиям, совершенно не у него, а в "где-то в соседнем здании". ;) Т.е. большинство проблем было вызвано именно плохой осведомленностью топлогии целевой сети.
> Предположим, при поднятом РРРоЕ, DHCPREQUEST on eth1 заводится через ррр0 или eth0, а не eth1. Не знаю, есть в CentOS фришный tcpdump или аналог
Было замечено, что при даже при принудительном повышении приоретета маршрута для подсети 192.168.0.0/24 через eth1 проблема имела место быть. Хотя насчет ppp0 не проверял.
> Потому, что _link_ down, а не interface, adapter или что там... Он, чуть погодя после падения интернета, небось и к DHCP цепляется нормально?
Нет, к сожалению не цепляется. Поэтому пришлось лично навестить сам шлюз ;)
>А можно для общего развития посмотреть на dhclient.conf?
Конечно, можно. Но ничего хитрого там нет: он создавался только с целью запретщения перезаписи resolv.conf (есть, конечно, и другие способы: например, можно указать PEERDNS=no в /etc/sysconfig/network-scripts/ifcfg-eth1, но я питаю нелюбовь к RedHat'овскому /etc/sysconfig :)
Сам файл:
interface "eth1"
{
request subnet-mask, broadcast-address, time-offset, domain-name, host-name, routers;
supersede domain-name-servers 127.0.0.1;
}
Доброго дня>
>Прошу прощения за глупый вопрос.
>Прошу прощения за, возможно, глупый ответ :)
> ...eth1 - внешний (DHCP) (для PPPoE-соединения, предоставляемого провайдером), eth0 - внутренний (192.168.0.0/24).
>eth0 - статический?
>Адреса, полученнные от DHCP-сервера провайдера через интерфейс eth1, к сожалению, принадлежат подсети
>192.168.0.0/16,
>но тут ничего нельзя сделать.Но можно свою подсеть переадресовать?
>Примерно через 30 минут после PPPoE-соединения ...А как выглядит таблица маршрутов при поднятом РРРоЕ?
> ... в логах появляются записи вида:
>
>Sep 7 03:29:45 xxxxx dhclient: DHCPREQUEST on eth1 to 192.168.0.111 port
>67DHCP провайдера висит на 192.168.0.111 или это выданный для eth1 адрес? Сами мы насквозь статические :)
>Sep 7 03:30:05 xxxxx dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port
>67
>Sep 7 03:30:05 xxxxx dhclient: DHCPACK from 192.168.0.111
>Sep 7 03:30:05 xxxxx dhclient: bound to 192.168.0.2 -- renewal in
>1503 seconds.
>Sep 7 03:55:08 xxxxx dhclient: DHCPREQUEST on eth1 to 192.168.0.111 port
>67Предположим, при поднятом РРРоЕ, DHCPREQUEST on eth1 заводится через ррр0 или eth0, а не eth1. Не знаю, есть в CentOS фришный tcpdump или аналог...
>Примерно через час пропадает соединение с интернетом, сопровождая это событие записью: kernel:
>eth1: link down,
>однако, интерфейсы eth1 и ppp0 остаются поднятыми.Потому, что _link_ down, а не interface, adapter или что там... Он, чуть погодя после падения интернета, небось и к DHCP цепляется нормально?
А можно для общего развития посмотреть на dhclient.conf?
>[оверквотинг удален]
>аналог...
>
>>Примерно через час пропадает соединение с интернетом, сопровождая это событие записью: kernel:
>>eth1: link down,
>>однако, интерфейсы eth1 и ppp0 остаются поднятыми.
>
>Потому, что _link_ down, а не interface, adapter или что там... Он,
>чуть погодя после падения интернета, небось и к DHCP цепляется нормально?
>
>А можно для общего развития посмотреть на dhclient.conf?вопрос конешно тупой - но вы уверены что в вашей локалке никто не имеет 192.168.0.111 ?
просто все проблемы с маршрутизацией при не правильной настройке сети либое есть либо нет, и периодично они не могут возникать. А вот из за конфликта адресации, и не прямой адресации (кода конфликт просиходит в одной сети), а на уровне arp таблиц в полне может. Допустем есть машина которая имеет 192.168.0.111, но он мало общаеться с сервером, так вот в момет "обещия" у сервера конфликт на 1 ip 2 разных мака. получаем траблы. Как вариант такая же проблема может быть и состороны сетки вашего прова, тогда из интерфейс теряет ваш сервак.
З.Ы. для локалки и внешнего интерфейса теоритически можно использовать 2 адреса из одного диапазона адресов с маской 24,16 и т.д. - надо только отстроить правельно подсети на интерфейсах (чтобы подсети на интерфейсах не пересекались), тогда никаких конфликтов не будет.
З.Ы.2 после падения eth1 ppp0 есчо "живой"/поднят скорее всего потому что не отработали таймоуты и наверника стоит флаг кипэлайф.
З.Ы.3 собщение eth1 link down - означает физический разрыв связи, он может происзодить как и из-за глюков физики на интерфейсе, как из за того что при конфликтных ситуациях некоторое оборудование гасит линг на интерфейсе на котором конфликт. При такой проблеме я бы попробовал поменять физически интерфейс у себя, при чем на какой нить тупой реалтек (который не умеет сам себе гасить линк, при живой линии, не потушив сам интерфейс), и посмотрел - если и дальше продолжался бы link down (а скорее всего так и будет) то выносилбы мозг прову.
Удачи