URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 94876
[ Назад ]
Исходное сообщение
"Не работает маршрутизация в линуксе"
Отправлено Docent , 28-Июл-13 19:12 
Всем привет.
Уже раза два-три сталкивался с проблемой маршрутизации на линуксовом сервере.
Вдруг ни с того ни с сего, линукс пытается ко всем IP-адресам найти MAC-адреса через ARP-запросы не смотря на то, в какой подсети находится этот адрес.
Я просмотрел отчеты разных команд, отвечающих за сеть - все как должно быть, но сеть не работает.
Вот сейчас опять таже проблема образовалась.
# ifconfig
eth0      Link encap:Ethernet  HWaddr 22:5e:6d:e0:ec:69
          inet addr:10.1.10.27  Bcast:10.1.10.31  Mask:255.255.255.240
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:184336163 errors:0 dropped:0 overruns:0 frame:0
          TX packets:194773342 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:16476583446 (16.4 GB)  TX bytes:16857644986 (16.8 GB)

eth0:1    Link encap:Ethernet  HWaddr 22:5e:6d:e0:ec:69
          inet addr:192.168.254.52  Bcast:192.168.254.63  Mask:255.255.255.240
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

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:18461800 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18461800 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1173944616 (1.1 GB)  TX bytes:1173944616 (1.1 GB)

# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 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
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 22:5e:6d:e0:ec:69 brd ff:ff:ff:ff:ff:ff
    inet 10.1.10.27/28 brd 10.1.10.31 scope global eth0
    inet 192.168.254.52/28 brd 192.168.254.63 scope global eth0:1

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.10.17    0.0.0.0         UG    0      0        0 eth0
10.1.10.16    0.0.0.0         255.255.255.240 U     0      0        0 eth0
192.168.254.48  0.0.0.0         255.255.255.240 U     0      0        0 eth0

# ip route show table all
default via 10.1.10.17 dev eth0
10.1.10.16/28 dev eth0  proto kernel  scope link  src 10.1.10.27
192.168.254.48/28 dev eth0  proto kernel  scope link  src 192.168.254.52
broadcast 10.1.10.16 dev eth0  table local  proto kernel  scope link  src 10.1.10.27
local 10.1.10.27 dev eth0  table local  proto kernel  scope host  src 10.1.10.27
broadcast 10.1.10.31 dev eth0  table local  proto kernel  scope link  src 10.1.10.27
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1
broadcast 192.168.254.48 dev eth0  table local  proto kernel  scope link  src 192.168.254.52
local 192.168.254.52 dev eth0  table local  proto kernel  scope host  src 192.168.254.52
broadcast 192.168.254.63 dev eth0  table local  proto kernel  scope link  src 192.168.254.52
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101

# traceroute -nI 10.4.10.10
traceroute to 10.4.10.10 (10.4.10.10), 30 hops max, 60 byte packets
1  10.1.10.27  2998.733 ms !H  2998.706 ms !H  2998.711 ms !H

# ping 10.4.10.10
PING 10.4.10.10 (10.4.10.10) 56(84) bytes of data.
From 10.1.10.27 icmp_seq=1 Destination Host Unreachable
From 10.1.10.27 icmp_seq=2 Destination Host Unreachable
From 10.1.10.27 icmp_seq=3 Destination Host Unreachable
From 10.1.10.27 icmp_seq=4 Destination Host Unreachable
From 10.1.10.27 icmp_seq=5 Destination Host Unreachable

В это же самое время в другой сессии на этом сервере:
# tcpdump -ni eth0 -vvs2000 host 10.4.10.10
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 2000 bytes
21:07:03.740745 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.4.10.10 tell 10.1.10.27, length 28
21:07:04.737552 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.4.10.10 tell 10.1.10.27, length 28
21:07:05.737609 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.4.10.10 tell 10.1.10.27, length 28
21:07:06.739356 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.4.10.10 tell 10.1.10.27, length 28
21:07:07.737532 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.4.10.10 tell 10.1.10.27, length 28

Содержание
Сообщения в этом обсуждении
"Не работает маршрутизация в линуксе"
Отправлено Etch , 29-Июл-13 06:53 
Вдруг ни с того ни с сего? Может с железом чего? Передёнуть интерфейс (ifdown/ifup) или перезагрузка не помогает?
"Не работает маршрутизация в линуксе"
Отправлено Docent , 29-Июл-13 20:28 
> Вдруг ни с того ни с сего? Может с железом чего? Передёнуть
> интерфейс (ifdown/ifup) или перезагрузка не помогает?

Сегодня выяснилось, что таких сервера два. Один - Убунта 12.10 на виртуалке под Проксмоксом, другой - Убунта 12.04 на железном компе.
Написал специальный скрипт, который последовательно запускает трейс до каждого адреса в удаленной сети и фиксирует сколько хопов проходит. Получилось, что из 254 адресов только 5 заткнулись на первом же хопе.
Логики непрохождения адресов вообще никакой, например: трейс до адресов 10.2.80.71, 72, 74, 75, 76, 78 проходит, а до 73 и 77 - нет, на первом же хопе выдается !Н и таймаут 3000мс.
Все непрошедшие адреса видно в arp как (incomplete).
Это было на железном сервере. Я его перезапустил - он заработал нормально.
Виртуальный пока не перезапускаю, жду каких-нибудь идей :-)

"Не работает маршрутизация в линуксе"
Отправлено Etch , 30-Июл-13 08:43 
> Сегодня выяснилось, что таких сервера два. Один - Убунта 12.10 на виртуалке
> под Проксмоксом, другой - Убунта 12.04 на железном компе.

А их что-нибудь объединяет в топологии сети по отношению к беспроблемным машинам?

"Не работает маршрутизация в линуксе"
Отправлено Docent , 31-Июл-13 08:03 
>> Сегодня выяснилось, что таких сервера два. Один - Убунта 12.10 на виртуалке
>> под Проксмоксом, другой - Убунта 12.04 на железном компе.
> А их что-нибудь объединяет в топологии сети по отношению к беспроблемным машинам?

Нет

"Не работает маршрутизация в линуксе"
Отправлено Etch , 30-Июл-13 11:21 
> Виртуальный пока не перезапускаю, жду каких-нибудь идей :-)

Покажите вывод команды:
ip r g проблемный_ИП

И попробуйте вылечить (временно) командой:
ip r flush cache

"Не работает маршрутизация в линуксе"
Отправлено Docent , 31-Июл-13 08:10 
>> Виртуальный пока не перезапускаю, жду каких-нибудь идей :-)
> Покажите вывод команды:
> ip r g проблемный_ИП
> И попробуйте вылечить (временно) командой:
> ip r flush cache

10.1.16.10 - проблемный
10.1.16.11 - не проблемный

# traceroute -nI 10.1.16.10
traceroute to 10.1.16.10 (10.1.16.10), 30 hops max, 60 byte packets
1  10.1.10.27  3000.202 ms !H  3000.087 ms !H  3000.091 ms !H
# ip r g 10.1.16.10
10.1.16.10 dev eth0  src 10.1.10.27
    cache <redirected>  ipid 0x3b47 rtt 69ms rttvar 88ms cwnd 10
# ip r g 10.1.16.11
10.1.16.11 via 10.1.10.17 dev eth0  src 10.1.10.27
    cache

# ip r flush cache
# ip r g 10.1.16.10
10.1.16.10 via 10.1.10.17 dev eth0  src 10.1.10.27
    cache
# traceroute -nI 10.1.16.10
traceroute to 10.1.16.10 (10.1.16.10), 30 hops max, 60 byte packets
1  10.1.10.17  0.447 ms  0.438 ms  0.438 ms
2  10.1.16.10  0.438 ms  0.447 ms  0.451 ms

ВАУ!
Помогло
Теперь бы еще узнать причину :-)

"Не работает маршрутизация в линуксе"
Отправлено Etch , 31-Июл-13 13:50 
> ВАУ!
> Помогло
> Теперь бы еще узнать причину :-)

В кэше засел неправильный маршрут. Как он туда попал? - возможно на этой машине игрались с маршрутами. Или (чуть ниже ruata высказал идею) кто-то другой прислал ICMP redirect - т.е. либо на роутере игрались с маршрутами, либо кто-то намеренно вредит.

Я бы на вашем месте сделал следующее:
1) поставил в сеть снифер для отслеживания пакетов ICMP redirect
2) покопал на предмет возможности задания ядру времени кэширования сетевых маршрутов и посмотрел это значение на проблемных машинах (по дефолту это время не должно быть большим).

"Не работает маршрутизация в линуксе"
Отправлено Etch , 31-Июл-13 13:56 
Кстати, у вас же там явно написано:
cache <redirected>
- прежде всего сосредоточьтесь на ICMP redirect
"Не работает маршрутизация в линуксе"
Отправлено Pahanivo , 29-Июл-13 08:41 
что при этом кажет
arp -a ?
"Не работает маршрутизация в линуксе"
Отправлено Docent , 29-Июл-13 20:29 
> что при этом кажет
> arp -a ?

# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
10.4.0.1                         (incomplete)                              eth0
10.1.24.1                        (incomplete)                              eth0
10.1.14.11                       (incomplete)                              eth0
10.1.10.10               ether   00:26:55:86:77:2f   C                     eth0
10.2.10.67                       (incomplete)                              eth0
10.1.10.19               ether   0a:89:b7:6c:4c:24   C                     eth0
10.1.16.17                       (incomplete)                              eth0
10.2.10.62                       (incomplete)                              eth0
10.1.10.28                       (incomplete)                              eth0
10.3.0.1                         (incomplete)                              eth0
192.168.254.49           ether   2a:88:2b:ea:95:88   C                     eth0
10.1.10.37               ether   02:1c:88:94:84:2b   C                     eth0
192.168.254.2                    (incomplete)                              eth0
10.1.10.18               ether   fe:33:e9:2a:9e:cc   C                     eth0
10.2.10.61                       (incomplete)                              eth0
149.255.7.88                     (incomplete)                              eth0
10.1.10.13               ether   e6:16:a4:84:d6:2d   C                     eth0
10.2.0.1                         (incomplete)                              eth0
10.1.10.22               ether   aa:21:23:b4:0b:bd   C                     eth0
10.1.16.20                       (incomplete)                              eth0
10.1.10.17               ether   2a:88:2b:ea:95:88   C                     eth0
10.1.10.12               ether   00:30:48:90:41:d8   C                     eth0
10.1.16.10                       (incomplete)                              eth0
10.1.16.19                       (incomplete)                              eth0
10.1.14.222                      (incomplete)                              eth0
10.1.16.14                       (incomplete)                              eth0
10.1.10.2                ether   2a:88:2b:ea:95:88   C                     eth0
192.168.254.18                   (incomplete)                              eth0
10.2.10.63                       (incomplete)                              eth0

Как видно, тут даже интернетовский адрес вкрался: 149.255.7.88.

"Не работает маршрутизация в линуксе"
Отправлено izyk , 30-Июл-13 00:57 
Классная, у вас топология сети:

192.168.254.49           ether   2a:88:2b:ea:95:88   C                     eth0
10.1.10.17               ether   2a:88:2b:ea:95:88   C                     eth0
10.1.10.2                ether   2a:88:2b:ea:95:88   C                     eth0

Думаю, вы с MAC адресами, нахитрили.

"Не работает маршрутизация в линуксе"
Отправлено Docent , 30-Июл-13 06:46 
>[оверквотинг удален]
>     eth0
> 10.1.10.17            
>    ether   2a:88:2b:ea:95:88   C  
>            
>         eth0
> 10.1.10.2            
>     ether   2a:88:2b:ea:95:88   C
>            
>          eth0
> Думаю, вы с MAC адресами, нахитрили.

А что именно с МАС адресами не то?
Если то, что они одинаковые, так это естественно, если учесть, что все эти адреса находятся на одном компьютере.
Сетка 10.1.0 не цельная, а разбита на несколько подсетей /29,/29,/28,/27 и т.д.

"Не работает маршрутизация в линуксе"
Отправлено izyk , 30-Июл-13 14:23 

> А что именно с МАС адресами не то?
> Если то, что они одинаковые, так это естественно, если учесть, что все
> эти адреса находятся на одном компьютере.
> Сетка 10.1.0 не цельная, а разбита на несколько подсетей /29,/29,/28,/27 и т.д.

На каком компьютере и как они попали в arp таблицу на одном компьютере через один и тот-же интерфейс?
В arp таблице - MAC адреса соседних компов(не важно виртуальных или реальных).
Совет: нарисуйте свою сеть.



"Не работает маршрутизация в линуксе"
Отправлено Docent , 31-Июл-13 08:23 
>> А что именно с МАС адресами не то?
>> Если то, что они одинаковые, так это естественно, если учесть, что все
>> эти адреса находятся на одном компьютере.
>> Сетка 10.1.0 не цельная, а разбита на несколько подсетей /29,/29,/28,/27 и т.д.
> На каком компьютере и как они попали в arp таблицу на одном
> компьютере через один и тот-же интерфейс?
> В arp таблице - MAC адреса соседних компов(не важно виртуальных или реальных).

Эти адреса находятся на одном интерфейсе маршрутизатора, поэтому и получается, что несколько адресов имеют один мак-адрес:
eth40     Link encap:Ethernet  HWaddr 2a:88:2b:ea:95:88
eth40:1   Link encap:Ethernet  HWaddr 2a:88:2b:ea:95:88
eth40:2   Link encap:Ethernet  HWaddr 2a:88:2b:ea:95:88
eth40:3   Link encap:Ethernet  HWaddr 2a:88:2b:ea:95:88
eth40:4   Link encap:Ethernet  HWaddr 2a:88:2b:ea:95:88

> Совет: нарисуйте свою сеть.

Это не реально, она слишком сложная. Возможно, что из-за этой сложности и вкралась какая-то ошибка.
Вкратце: это кластер виртуальных машин Проксмокс их двух узлов. Почти все сервера виртуальные, в т.ч. и маршрутизатор. Около 15 VLAN.

"Не работает маршрутизация в линуксе"
Отправлено izyk , 30-Июл-13 01:06 
Да, еще proxy_arp на маршрутизаторах и серверах посмотрите.
"Не работает маршрутизация в линуксе"
Отправлено Docent , 30-Июл-13 07:02 
> Да, еще proxy_arp на маршрутизаторах и серверах посмотрите.

proxy_arp везде отключен

"Не работает маршрутизация в линуксе"
Отправлено Pahanivo , 29-Июл-13 08:42 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
"Не работает маршрутизация в линуксе"
Отправлено Docent , 29-Июл-13 20:32 
> unreachable default dev lo  table unspec  proto kernel  metric
> 4294967295  error -101
> unreachable default dev lo  table unspec  proto kernel  metric
> 4294967295  error -101

Я тоже не понял, что это такое, но на других работающих серверах у меня так же, поэтому я не стал обращать на это внимания.

"Не работает маршрутизация в линуксе"
Отправлено ruata , 29-Июл-13 08:47 
Судя по traceroute дело до шлюза 10.1.10.17 не доходит
Советую проверить куда уходят пакеты на 10.4.10.10 на самом шлюзе
Возможно шлюз присылает ICMP redirect марщрута обратно и 10.1.10.27 пытается отправить сам
"Не работает маршрутизация в линуксе"
Отправлено izyk , 29-Июл-13 10:01 
См. таб. марш. на "10.1.10.17".
"Не работает маршрутизация в линуксе"
Отправлено Docent , 29-Июл-13 20:47 
> Судя по traceroute дело до шлюза 10.1.10.17 не доходит
> Советую проверить куда уходят пакеты на 10.4.10.10 на самом шлюзе
> Возможно шлюз присылает ICMP redirect марщрута обратно и 10.1.10.27 пытается отправить
> сам

С самого шлюза они идут правильно.
Как я писал в первом посте:
> # ping 10.4.10.10
> PING 10.4.10.10 (10.4.10.10) 56(84) bytes of data.
> From 10.1.10.27 icmp_seq=1 Destination Host Unreachable
> From 10.1.10.27 icmp_seq=2 Destination Host Unreachable
>
> В это же самое время в другой сессии на этом сервере:
> # tcpdump -ni eth0 -vvs2000 host 10.4.10.10
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 2000 bytes
> 21:07:03.740745 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.4.10.10 tell 10.1.10.27, length 28
> 21:07:04.737552 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.4.10.10 tell 10.1.10.27, length 28

Т.е. кроме ARP-запросов больше вообще ничего не ходит.
Правда, сейчас поверил - до адреса 10.4.10.10 пакеты через шлюз уже проходят, хотя полно других адресов, до которых все равно не идут: до 10.2.10.52 проходит, а до 10.2.10.62 - шлет ARP-запросы.