The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Чехарда с сетевыми интерфейсами... Барабашки, в общем"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"Чехарда с сетевыми интерфейсами... Барабашки, в общем" 
Сообщение от jekahawk emailИскать по авторуВ закладки(ok) on 04-Ноя-05, 15:09  (MSK)
Роутер. На базе INTEL 2xXEON. 1 гиг памяти. Материнка от INTEL 7501BR2
В нем две встроенных сетевых интерфейса.
В наличии было два свободных PCI-слота.
Теперь туда добавили еще два сетевых интерфейса.
eth0 - на провайдера №1
eth1 - локальная подсеть 172.16.1.0/24 (IP 172.16.1.1)
eth2 - на провайдера №2
eth3 - локальная подсеть 172.16.2.0/24 (IP 172.16.2.1)
Настроил роутинг.
Настроил IPTABLES.
Поднят PPTPD и PPP - настроено и работает.

На данный момент дефолтный шлюз через второго прова - через eth2

eth0 Link encap:Ethernet HWaddr 00:07:E9:3F:9D:22
inet addr:x.x.x.x Bcast:x.x.x.x Mask:255.255.255.252
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:623753 errors:0 dropped:0 overruns:0 frame:0
TX packets:1173785 errors:103 dropped:0 overruns:0 carrier:103
collisions:0 txqueuelen:1000
RX bytes:362907890 (346.0 Mb) TX bytes:125107415 (119.3 Mb)
Interrupt:11 Base address:0x1400 Memory:fe7e0000-fe7e0038

eth1 Link encap:Ethernet HWaddr 00:D0:B7:BD:97:9D
inet addr:172.16.1.1 Bcast:172.16.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7422364 errors:0 dropped:0 overruns:0 frame:0
TX packets:41592628 errors:0 dropped:0 overruns:3 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2858904929 (2726.4 Mb) TX bytes:928121158 (885.1 Mb)
Interrupt:11 Base address:0x1480 Memory:fe8f0000-fe8f0038

eth2 Link encap:Ethernet HWaddr 00:D0:B7:60:71:8A
inet addr:x.x.x.x Bcast:x.x.x.x Mask:255.255.255.252
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:93921 errors:0 dropped:0 overruns:0 frame:0
TX packets:161245 errors:0 dropped:0 overruns:1 carrier:0
collisions:0 txqueuelen:1000
RX bytes:61859658 (58.9 Mb) TX bytes:20001401 (19.0 Mb)
Interrupt:10 Base address:0x14c0 Memory:fe8e0000-fe8e0038

eth3 Link encap:Ethernet HWaddr 00:07:E9:3F:9D:23
inet addr:172.16.2.1 Bcast:172.16.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:41671168 errors:0 dropped:0 overruns:0 frame:0
TX packets:5935398 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:955617497 (911.3 Mb) TX bytes:3001342329 (2862.3 Mb)
Base address:0x1440 Memory:fe760000-fe780000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:142419 errors:0 dropped:0 overruns:0 frame:0
TX packets:142419 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:15342706 (14.6 Mb) TX bytes:15342706 (14.6 Mb)

Таблица роутинга:
x.x.x.x/30 dev eth2 scope link
x.x.x.x/30 dev eth0 scope link
172.16.1.0/24 dev eth1 scope link
172.16.2.0/24 dev eth3 scope link
169.254.0.0/16 dev eth3 scope link
127.0.0.0/8 dev lo scope link
default via x.x.x.x dev eth2

============================================
Всё чудно себе работает.

Но периодически возникает СТРАННАЯ проблема.
Иногда пропадает связь у пользователей. VPN отваливается. Инета нет. При этом 172.16.1.1 и 172.16.2.1 пингуются. А странность заключается в том, что в этот момент, если сделать на клиентском компе ARP -A, MAC-адреса eth1 и eth3 МЕНЯЮТСЯ МЕСТАМИ... Конечно, на роутере всё в порядке - всё на месте (как кажется...). Т.е. ifconfig показывает всё правильно.

Резюме: периодически на клиентских компах пропадает доступ к шлюзам подсетей. При этом эти шлюзы пингуются, но их mac-адреса меняются местами (это видно, если на клиентских компах сделать arp -a). Через небольшой промежуток времени всё восстанавливается, и все MAC-адреса соответствуют действительности. Повторюсь - в такие моменты на самом роутере ifconfig показывает всё правильно и все адреса на месте...

Вся эта свистопляска возникла после добавления сетевой карты.

Как такое может быть??? Может это просто банальная нехватка мощности у блока питания на роутере???

З.Ы. Мой роутер уникум или всё же я не первый, кто сталкивается с подобным?... Сейчас прочел, чего сам тут написал - точно полтергейст :(

  Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]

1. "Чехарда с сетевыми интерфейсами... Барабашки, в общем" 
Сообщение от jonatan Искать по авторуВ закладки(??) on 05-Ноя-05, 12:57  (MSK)
Если eth1 и eth3 находятся в одном физическом сегменте, то читайте о проблеме ARP Flux:
http://linux-ip.net/html/ether-arp.html#ether-arp-flux
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Чехарда с сетевыми интерфейсами... Барабашки, в общем" 
Сообщение от JekaH emailИскать по авторуВ закладки on 05-Ноя-05, 15:26  (MSK)
>Если eth1 и eth3 находятся в одном физическом сегменте, то читайте о
>проблеме ARP Flux:
>http://linux-ip.net/html/ether-arp.html#ether-arp-flux

Я забыл сказать, наверное, весьма важную вещь - eth1 и eth3 включены в один и тот же коммутатор без организации каких-либо vlan на последнем...

Возможно, что причины происходящего именно в этом?


  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "Чехарда с сетевыми интерфейсами... Барабашки, в общем" 
Сообщение от jonatan Искать по авторуВ закладки(??) on 06-Ноя-05, 10:12  (MSK)
>Я забыл сказать, наверное, весьма важную вещь - eth1 и eth3 включены
>в один и тот же коммутатор без организации каких-либо vlan на
>последнем...
>
>Возможно, что причины происходящего именно в этом?
Я для кого все это пишу? Или Вы не понимаете, что такое "в одном физическом сегменте"?
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "Чехарда с сетевыми интерфейсами... Барабашки, в общем" 
Сообщение от jekahawk emailИскать по авторуВ закладки(??) on 06-Ноя-05, 21:23  (MSK)
Прошу прощения за непоследовательность... :)

Действительно - Вы правильно диагностировали болезнь.

Только вот из описанного по ссылке решения пока не применил.

Патчить ядро не хочу. А меры по фильтрации арпа почему-то помогли только частично - реже стали происходить проблемы. Т.е. я прописал arp_filtering=1 для всех интерфейсов и для default, но окончательно это не решило проблему.

Наверное всё же придется физически разделять подсети, а это 4 магистрали с суммарным количеством абонентов более 300...

Может быть есть еще какое-то решение?


  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "Чехарда с сетевыми интерфейсами... Барабашки, в общем" 
Сообщение от jonatan Искать по авторуВ закладки(ok) on 07-Ноя-05, 09:03  (MSK)
Ничего патчить не надо. Для ядер 2.4+ достаточно использовать arp_filter:
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth3/arp_filter
На клиентах очистить arp-кэш. Если бы еще и ip-адреса находились в одной логической подсети, то необходимо было бы использовать iproute2 для создания дополнительной таблицы маршрутизации.
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх


Архив | Удалить

Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ]
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру