LINUX.ORG.RU
Форум — Admin  

Почему не пингуются veth адреса с другой стороны от парных veth в бридже?

 , , ,


0

1

Сделал скрипт для настройки бриджа для тестов и экспериментов:

DHCP Server <-> server---server_br <-> bridge

dhclient client1 <-> client1---client1_br <-> bridge

dhclient client2 <-> client2---client2_br <-> bridge

dhclient client3 <-> client3---client3_br <-> bridge

server, server_br, clientN, clientN_br - это имена интерфейсов veth (виртуальных «патчей»).


+ ifconfig -a
bond0: flags=5122<BROADCAST,MASTER,MULTICAST>  mtu 1500
        ether 46:5d:f3:67:fd:0b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether ca:4e:93:0d:08:a2  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 108 (108.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

client1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether a2:28:6b:ef:fc:90  txqueuelen 1000  (Ethernet)
        RX packets 1  bytes 54 (54.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

client2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether f6:f7:dc:4d:38:36  txqueuelen 1000  (Ethernet)
        RX packets 1  bytes 54 (54.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

client3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 76:5a:e7:30:2e:51  txqueuelen 1000  (Ethernet)
        RX packets 1  bytes 54 (54.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

client1_br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether ca:4e:93:0d:08:a2  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 54 (54.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

client2_br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether ca:5b:c7:5f:6b:8e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 54 (54.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

client3_br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether ea:3d:63:4a:9a:20  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 54 (54.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.15  netmask 255.255.255.0  broadcast 10.0.2.255
        ether 00:17:a5:36:cf:ae  txqueuelen 1000  (Ethernet)
        RX packets 2616305  bytes 221079995 (210.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2484697  bytes 3410215862 (3.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 4407  bytes 1266168 (1.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4407  bytes 1266168 (1.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

server: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.1  netmask 255.255.255.0  broadcast 192.168.10.255
        ether 3a:64:d7:9b:80:77  txqueuelen 1000  (Ethernet)
        RX packets 1  bytes 54 (54.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

server_br: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether d2:ed:a1:21:f0:24  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 54 (54.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


root@chimaera:/etc/dhcp# dhclient -v client3
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/client3/76:5a:e7:30:2e:51
Sending on   LPF/client3/76:5a:e7:30:2e:51
Sending on   Socket/fallback
DHCPDISCOVER on client3 to 255.255.255.255 port 67 interval 5
DHCPOFFER of 192.168.10.13 from 192.168.10.1
DHCPREQUEST for 192.168.10.13 on client3 to 255.255.255.255 port 67
DHCPACK of 192.168.10.13 from 192.168.10.1
bound to 192.168.10.13 -- renewal in 271 seconds.


root@chimaera:/etc/dhcp# dhclient -v client2
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/client2/f6:f7:dc:4d:38:36
Sending on   LPF/client2/f6:f7:dc:4d:38:36
Sending on   Socket/fallback
DHCPDISCOVER on client2 to 255.255.255.255 port 67 interval 8
DHCPOFFER of 192.168.10.12 from 192.168.10.1
DHCPREQUEST for 192.168.10.12 on client2 to 255.255.255.255 port 67
DHCPACK of 192.168.10.12 from 192.168.10.1
bound to 192.168.10.12 -- renewal in 270 seconds.


root@chimaera:/etc/dhcp# dhclient -v client1
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/client1/a2:28:6b:ef:fc:90
Sending on   LPF/client1/a2:28:6b:ef:fc:90
Sending on   Socket/fallback
DHCPDISCOVER on client1 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on client1 to 255.255.255.255 port 67 interval 8
DHCPOFFER of 192.168.10.14 from 192.168.10.1
DHCPREQUEST for 192.168.10.14 on client1 to 255.255.255.255 port 67
DHCPACK of 192.168.10.14 from 192.168.10.1
bound to 192.168.10.14 -- renewal in 234 seconds.

Т.е. получается, что dhclient работает. Он ведь шлет запрос именно с указанного интерфейса?

Но пинги почему-то не идут ни между client, ни server.

root@chimaera:/etc/dhcp# ping -w 3 -4 -I client1 192.168.10.1
PING 192.168.10.1 (192.168.10.1) from 192.168.10.14 client1: 56(84) bytes of data.

--- 192.168.10.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2034ms

root@chimaera:/etc/dhcp# ping -w 3 -4 -I client1 192.168.10.13
PING 192.168.10.13 (192.168.10.13) from 192.168.10.14 client1: 56(84) bytes of data.

--- 192.168.10.13 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2056ms
☆

Последнее исправление: sanyo1234 (всего исправлений: 2)
← Не обновляется Gitlab CE c 14.4.5 на 14.5 и выше в докере
gitlab clean up artifact files →

У тебя они все вместе что ли запущены на одном хосте?

Покажи «ip ro» и «brctl show»

vel ★★★★★
()
Ответ на: комментарий от vel

У тебя они все вместе что ли запущены на одном хосте?

Да, просто для экспериментов с DHCP.

root@chimaera:/etc/dhcp# brctl show
bridge name     bridge id               STP enabled     interfaces
bridge          8000.ca4e930d08a2       no              client1_br
                                                        client2_br
                                                        client3_br
                                                        server_br


root@chimaera:/etc/dhcp# ip ro
default via 10.0.2.2 dev eth0 
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 
192.168.10.0/24 dev server proto kernel scope link src 192.168.10.1 
192.168.10.0/24 dev client3 proto kernel scope link src 192.168.10.13 
192.168.10.0/24 dev client1 proto kernel scope link src 192.168.10.14 
192.168.10.0/24 dev client2 proto kernel scope link src 192.168.10.12

root@chimaera:/etc/dhcp# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 server
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 client3
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 client1
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 client2


root@chimaera:/etc/dhcp# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.10.12                    (incomplete)                              server
192.168.10.14            ether   a2:28:6b:ef:fc:90   C                     server
192.168.10.13                    (incomplete)                              client1_br
10.0.2.2                 ether   52:55:0a:00:02:02   C                     eth0
sanyo1234 ☆
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

скрипт - нет.

Чтобы эта конструкция нормально работала проще всего вынести клиентов в отдельные netns (ip netns ...) Достаточно перенести в них вторые интерфейсы veth и там же запускать dhclient.

192.168.10.0/24 dev server proto kernel scope link src 192.168.10.1 
192.168.10.0/24 dev client3 proto kernel scope link src 192.168.10.13 
192.168.10.0/24 dev client1 proto kernel scope link src 192.168.10.14 
192.168.10.0/24 dev client2 proto kernel scope link src 192.168.10.12

Вот это основная проблема - доступ в одну сеть через разные интерфейсы.

Первая проблема - это arp. Нужно растраивать sysctl (arp_accept,arp_announce,all.arp_filter,arp_ignore).

Вторая проблема - роутинг. Как минимум нужно отключать rp_filter.

Непонятно чего ты хочешь делать с этим.

vel ★★★★★
()
Ответ на: комментарий от vel

Непонятно чего ты хочешь делать с этим.

Виртуальные интерфейсы в виртуальном свитче для экспериментов с клиент-серверными приложениями типа DHCP сервера и клиентов, которым нужны разные MAC адреса на отдельных интерфейсах.

Как еще можно насоздавать виртуальных интерфейсов с разными MAC другим способом? Насоздавать tap интерфейсов без их подключения в какой-либо свитч? Разве они будут видеть друг друга изначально хотя бы на уровне L2?

Правильно ли я пониманию суть TAP vs VETH ? как описано далее:

tun/tap - можно рассматривать как сетевой патчик, одна сторона которого подсоединена к интегрированному с ним приложению (например, OpenVPN, QEMU, etc.), а вторая с коннектором, который можно подключать к виртуальному свитчу либо использовать как интерфейс для любых TCP/IP приложений.

veth - можно рассматривать как патч, обе стороны которого с коннекторами.

Коннекторы патчей можно подсоединять к свитчам (bridge или ovswitch), после чего коннектор теряет возможность назначения персонального IP адреса для работы с TCP/IP приложениями в качестве интерфейса.

С другой стороны коннекторам патчей, неподключенным к свитчам, можно назначать IP адрес для соединения с любым приложением, заранее неинтегрированным с TUN/TAP, но интегрированным с протоколом TCP/IP.

В виде диаграммы возможных подключений выглядит примерно так:

Любое TCP/IP приложение или свитч <-> Interface1 (tun1/tap1) <-> TUN/TAP <-> Интегрированное с TUN/TAP приложение (например OpenVPN); 

Любое TCP/IP приложение или свитч <-> Interface1 (veth1) <-> veth1-veth2 <-> Interface2 (veth2) <-> Любое TCP/IP приложение или свитч; 

где InterfaceN - настраивается командой ifconfig/ip (для TCP/IP приложения) или командой brctl addif (для подключения к свитчу).
sanyo1234 ☆
() автор топика
Ответ на: комментарий от vel

Вот это основная проблема - доступ в одну сеть через разные интерфейсы.

Допустим, я переделаю, как ты предлагаешь с разделением по namespaces, и ping и другие протоколы тоже заработают.

Но почему уже сейчас конфиг работает с DHCP клиентами и сервером?

sanyo1234 ☆
() автор топика
Ответ на: комментарий от sanyo1234

В твоем случае dhcp не использует маршрутизацию. Прием и передача пакетов происходит через сокет привязанный к сетевому интерфейсу.

Про пинги. Запусти tcpdump на интерфейсах server,client{123} и запусти пинг (как ты это запускал). Посмотри кто куда отвечает и с какого интерфейса.

Если ты будешь указывать вместо имени интерфейса его адрес (-I), то все будет работать. «ping -I <interface_name>» это особое заклинение.

В линуксячем стеке, ситуация когда несколько сетевых интерфейсов с разными ip-адресами находятся в одной сети настраивается достаточно сложно.

vel ★★★★★
()
Ответ на: комментарий от vel

В линуксячем стеке, ситуация когда несколько сетевых интерфейсов с разными ip-адресами находятся в одной сети настраивается достаточно сложно.

Действительно:

https://askubuntu.com/questions/1330889/why-cant-two-interfaces-belong-to-the...

https://access.redhat.com/solutions/30564

Root Cause

    When there are 2 interfaces on the same subnet there is no assurance as to which interface will be used to transmit traffic and the machine will accept traffic for either IP on either interface.
    This is because in Linux the IP address belongs to the host and is not associated with the interface.
    If you ping with -I DEV, attempting to use a given interface, there is no guarantee the reply packet (if there even is one) will come back to the same interface, so pings done with -I DEV may not work.

Нужно поизучать этот вопрос поподробнее.

sanyo1234 ☆
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от vel

Большое спасибо, за указание на причину проблемы по моему изначальному вопросу.

Хотел попутно спросить, правильно ли я понимаю про IP адресацию:


x.x.x.x - IP адрес, состоящий из номера сети и номера узла,
характеризует не отдельный компьютер или маршрутизатор, а одно сетевое соединение
255.255.255.0 - пример маски ПОДсети /24 - части более крупной сети, классовая адресация больше неактуальна
x.x.x.0 = IP адрес &(побитно) маска - адрес сети (в примере /24)
x.x.x.0 - некоторая сеть - всегда является подсетью (подмножеством) сети 0.0.0.0/0
Множество всех адресов соответствует нулевой маске подсети и обозначается /0, а конкретный адрес IPv4 — маске подсети с длиной префикса в 32 бита, обозначаемой /32.
x.x.x.255 = адрес ||(побитно) !маска  - широковещательный адрес всех хостов в сети (в примере /24).
Если пропинговать 192.168.0.255 из какой-нибудь другой сети, например из 10.0.0.0/24 то ICMP-пакеты скорее всего отбросятся на ближайшем маршрутизаторе, т.к. по умолчанию маршрутизация directed broadcast адресов запрещена (для защиты от smurf-атак)
Количество хостов в подсети определяется как 2^(32-N)-2, где N — длина маски.
Максимальной длиной маски для подсети с несколькими хостами является N=30 (.0 + 2 хоста .255)
/32 — это подсеть, состоящая из одного хоста
Сеть можно разбивать на подсети
K=2X-Y, где K — количество подсетей с длиной маски Y, умещающихся в подсеть с длиной маски X
10/8, 172.16/12 и 192.168/16 (да, можно и так записывать префиксы, полностью откидывая хостовую часть) определены как диапазоны для частного использования, запрещенные к маршрутизации в интернете
0.0.0.0 - эта локальная сеть
224.0.0.0/4 для мультикаста 
255.255.255.255, ff:ff:ff:ff:ff:ff - широковещательный адрес всех хостов в локальной сети

Правильная маршрутизация больших сетей: OSPF+BGP
Устранение точки единственного отказа достигается только тогда, когда каждый компонент, который может поломаться, будет продублирован. 

Клиенты кладут болт на все DHCP опции, которые не запрашивали. Но некоторые клиенты, например NetworkManager из состава CentOS 6.5 готов обработать любую опцию которую ему прислал сервер.
sanyo1234 ☆
() автор топика
Ответ на: комментарий от vel

Чтобы эта конструкция нормально работала проще всего вынести клиентов в отдельные netns (ip netns ...) Достаточно перенести в них вторые интерфейсы veth и там же запускать dhclient.

Перенес все интерфейсы clientN в namespaces clientN_ns.

bridge, server и clientN_br оставил в дефолтном namespace (без изменений).

Все прекрасно заработало, пинги идут, как и было задумано изначально. :)

Получается, почти как контейнеры, только очень легкие (разделение только для сети, как я и хотел) одной командой ip netns exec xxx cmd без лишней мороки с docker или тем более с виртуалками.

Большое спасибо за помощь!

sanyo1234 ☆
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Не обновляется Gitlab CE c 14.4.5 на 14.5 и выше в докере
Admin
gitlab clean up artifact files →