Назад | Перейти на главную страницу

Проблема IP Forwarding - отбрасывание пакетов Rx во встроенной сети Linux

У меня есть компьютер и две встроенные системы на базе Linux, которые я пытаюсь объединить с помощью IP-пересылки. Они охватывают две отдельные локальные сети. Обе сети подключены. Я могу пинговать 10.10.10.6 с ПК и пинговать 10.10.30.1 с цели 1. Проблема возникает, когда я запускаю приложение на цели 1, которое генерирует здоровый (<3 Мбит / с) объем UDP-трафика, направленного на ПК. Производительность системы не может идти в ногу со временем, и я вижу, что количество отброшенных пакетов RX непрерывно увеличивается на интерфейсе 10.10.10.4 цели 0.

У обеих целей достаточно циклов ЦП. Возникает вопрос, почему цель 0 отбрасывает так много пакетов?

Могу ли я что-нибудь сделать с конфигурацией, чтобы получить сквозное соединение? Увеличить размер буфера?

+-----------+   +--------------------------------------+   +-------------------+ 
|  PC       |-->|              target 0                |-->|  target 1         |
|10.10.30.1 |   | eth1 =10.10.30.2   eth0 =10.10.10.4  |   | eth0 = 10.10.10.6 |
+-----------+   +--------------------------------------+   +-------------------+

цель 0 имеет два интерфейса Ethernet и ip_forwarding = 1

А у меня настройка маршрута следующая: на ПК:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
       10.10.10.6  255.255.255.255       10.10.30.2      10.10.30.1       1
       10.10.30.0    255.255.255.0       10.10.30.1      10.10.30.1       20

и по цели 0:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.30.0      *               255.255.255.0   U     0      0        0 eth1
10.10.10.0      *               255.255.255.0   U     0      0        0 eth0
default         10.10.10.6      0.0.0.0         UG    0      0        0 eth0
default         10.10.30.1      0.0.0.0         UG    0      0        0 eth1

и по цели 1:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.30.1      10.10.10.4      255.255.255.255 UGH   0      0        0 eth0
10.10.10.0      *               255.255.255.0   U     0      0        0 eth0
default         10.10.10.4      0.0.0.0         UG    0      0        0 eth0

Изменить: цель 0

# ip link list | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

цель 1

# ip link list | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000

Подтверждено, что оба соединения установлены на 100 Мбит / с в полнодуплексном режиме.

Другая мысль:

Похоже, что вход в цель 0 затоплен, может ли переключение между двумя целями, буферизовать пакеты, а затем залить цель 0 большим пакетом данных?

Обновить:

При замене коммутатора 10/100/1000 на старый полудуплексный концентратор 10M система работает нормально, пакеты не отбрасываются.

В плохом состоянии дамп регистра ethtool указывал, что счетчик RX_DROP постоянно увеличивается. Это указывает на то, что процессор / Linux не может достаточно быстро удалить данные из микросхемы Ethernet. С концентратором 10M это больше не проблема.

Мне кажется, что Linux неправильно настроен для поддержания более высокой (но не такой высокой) скорости передачи данных. Хотелось бы понять, почему ОС / процессор не успевают?

Вы проверили, что все ссылки работают в дуплексном режиме?

dmesg | grep -i duplex

Должен дать вам эту информацию о Linux. Если это не помогло, попробуйте:

mii-tool <interface>

(Обратите внимание, что последний должен запускаться как root.)

Каков размер отправляемых вами UDP-пакетов? 3 Мбит / с может означать 2 000 пакетов в секунду или 50 000 пакетов в секунду, в зависимости от размера ваших дейтаграмм.

3 МБ / с не должны беспокоить большинство современного оборудования, поэтому я заинтересован в дуплексе всех ссылок. Полудуплексное соединение приведет к конфликтам, а также к увеличению буферизации.

Что касается вашего вопроса о том, что коммутатор может буферизовать кадры, это возможно, но обычно не настраивается. Можете ли вы предоставить информацию о марке / модели коммутаторов?

Какой размер MTU установлен на target0 и target1?

Поскольку это L3, который пересылает пакет, размер которого превышает MTU на Target0, его необходимо фрагментировать перед передачей на интерфейс Et1 Target0, возможно, это является причиной проблем (однако у нас нет доказательств, что это приведет к отбрасыванию пакетов RX).

Можете ли вы сделать список IP-ссылок | grep mtu 'для обеих целей?

Включили ли вы какую-либо фильтрацию IPtables или что-нибудь, связанное с IP-политикой / QoS?