Просмотр кода страницы Calico Kubernetes the hard way v2 How packet goes from pod

Материал из noname.com.ua

← Calico Kubernetes the hard way v2 How packet goes from pod

У вас нет прав на выполнение действия «редактирование этой страницы» по следующей причине:

---

Вы можете просмотреть и скопировать исходный код этой страницы.

[[Категория:K8s]] [[Категория:Networking]] [[Категория:Linux]] [[Категория:Calico]] [[Категория:Kubernetes the hard way v2]] [[Категория:proxy_arp]] [[Категория:proxy_arp_pvlan]] [[Категория:arp]] =Calico: как пакет выходит из POD= Это заметка про Calico, где рассматривается небольшая часть пути пакета - как пакет покидает POD. <BR> Она появилась по-тому что сеть сделана в Calico не совсем классическим способом, и используются механизмы которые редко можно встретить за пределами сетей провайдеров. <BR> =Упрощенная схема= На схеме не показаны интерфейсы которые не описаны в этом документе, только те что касаются пересылки пакетов из POD в хостовую систему <PRE> +----------------------------------------+ | Host: | | +---------------------+ | | | POD | | | | | | | | 10.244.235.132/32 | | | +---eth0--------------+ | | | | | | | | calieede18e00ae | | На этом интерфейсе НЕТ ip адреса | +----------------------------------------+ </PRE> ="Странности" внутри PODa= Внутри <code>POD</code> таблица маршрутизации выглядит достаточно необычно: <PRE> route -n </PRE> <PRE> Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 169.254.1.1 0.0.0.0 UG 0 0 0 eth0 169.254.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 </PRE> При этом на первый взгляд выглядит так как-будто работать такая схема не должна <BR> Адрес 169.254.1.1 это вообще [[Bogon#169.254.0.0.2F16|Link-Local address]] <BR> На интерфейсе установлен адрес с маской /32, в качестве шлюза указан адрес доступный непосредственно через интерфейс <PRE> ifconfig </PRe> <PRE> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450 inet 10.244.235.132 netmask 255.255.255.255 broadcast 0.0.0.0 inet6 fe80::68a6:d0ff:fe94:1d10 prefixlen 64 scopeid 0x20<link> ether 6a:a6:d0:94:1d:10 txqueuelen 0 (Ethernet) RX packets 5 bytes 446 (446.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 17 bytes 1286 (1.2 KB) TX errors 0 dropped 1 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) 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 </PRE> <BR> Сам интерфейс внутри <code>POD</code> представляет из себя обычный для контейнеров <code>veth</code>, второй конец которой находится за пределами сетевого пространства имен <code>POD</code>, <br> для того что бы найти второй конец виртуального линка можно определить <code>peer_ifindex</code> <PRE> ethtool -S eth0 NIC statistics: peer_ifindex: 254 rx_queue_0_xdp_packets: 0 rx_queue_0_xdp_bytes: 0 rx_queue_0_xdp_drops: 0 </PRE> В примере выше <code>peer_ifindex: 254</code> это и есть индекс искомого интерфейса (на хосте, за пределами POD), который можно увидеть командой <code>ip link show</code> <PRE> ip -d link show </PRE> '''254''' это и есть найденный <code>peer_ifindex</code> <PRE> ... 254: calieede18e00ae@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 13 promiscuity 0 minmtu 68 maxmtu 65535 veth addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 RX: bytes packets errors dropped overrun mcast 237561215 1243131 0 0 0 0 TX: bytes packets errors dropped carrier collsns 236237144 1273779 0 0 0 0 </PRE> =Как это работает (отправка пакета из <code>POD</code>)= Для того что бы <code>POD</code>мог отправить пакет, он проделывает следующие шаги: * просматривает таблицу маршрутизации * так как в таблице всего одна запись, шлюз, то все пакеты будут отправляться на шлюз * для того что бы отправить пакет на шлюз необходимо знать МАК-адрес шлюза, соответственно необходима запись в arp-таблице * для ее создания будет создан arp-запрос Но, так как (со стороны хоста, за пределами контейнера) на ответной части интерфейса eth0, интерфейсе <code>calieede18e00ae</code> нет никакого ip адреса, возникает вопрос.<BR> <BR> <BR> '''Откуда берется arp-ответ?''' <BR> <BR> =Linux proxy_arp= Короткий ответ на вопрос - это "<code>proxy arp</code>". <BR> Для того что бы в первом приближении понять что механизм <code>proxy_arp</code> включен, можно проверить <code>sysctl</code>: <PRE> sysctl -a | grep calieede18e00ae | grep -v ipv6 </PRE> Вывод сокращен: <PRE> ... net.ipv4.conf.calieede18e00ae.proxy_arp = 1 net.ipv4.conf.calieede18e00ae.proxy_arp_pvlan = 0 net.ipv4.neigh.calieede18e00ae.proxy_delay = 0 ... </PRE> Из вывода видно (<code>net.ipv4.conf.calieede18e00ae.proxy_arp = 1</code>), что для интерфейса механизм <code>proxy_arp</code> включен (значение ключа установлено в 1) <BR> Далее рассмотрим его работу более подробно. ==Proxy ARP: 2 варианта== В целом в Linux есть 2 реализации proxy_arp, которые работают немного по разному # <code>proxy_arp</code>, который используется Calico # <code>proxy_arp_pvlan</code>, который реализует несколько другую логику ответов на arp-запросы (о нем ниже) ==proxy_arp== Описание в документации достаточно скудное: <PRE> proxy_arp - BOOLEAN Do proxy arp. proxy_arp for the interface will be enabled if at least one of conf/{all,interface}/proxy_arp is set to TRUE, it will be disabled otherwise </PRE> Информации не много. Из других источников, удалось выяснить, что при включении этой опции ядро будет отвечать на arp-запросы только если они требуют переадресации. <BR> Попробую пояснить на примерах. ===Пример=== Допустим есть интерфейс <code>eth0</code> на котором включен <code>proxy_arp</code> и на этом интерфейсе настроен IP адрес <code>192.168.0.1/24</code>. <BR> Согласно маске <code>/24</code>, это означает что все адреса от <code>192.168.0.0</code> до <code>192.168.0.255</code> доступны непосредственно через этот интерфейс. <BR> <BR> Ядро будет отвечать МАК-адресом интерфейса <code>eth0</code> на все ARP-запросы, полученные на интерфейсе <code>eth0</code>,<BR> если IP aдрес в запросе, для которого запрашивается МАК адрес<BR> доступен НЕ через этот интерфейс, другими словами любой адрес в <code>ARP, Request who-has </code> не из диапазона <code>192.168.0.0-192.168.0.255</code> <BR> * <code>ARP, Request who-has 10.20.30.40</code> - будет обработан и отправлен ответ с мак-адресом интерфейса <code>eth0</code>,так как адрес в запросе <code>10.20.30.40</code> не из диапазона <code>192.168.0.0-192.168.0.255</code> (при условии что существует маршрут к <code>10.20.30.40</code>, в том числе даже если это <code>default</code> * <code>ARP, Request who-has 192.168.0.100</code> - будет проигнорирован так как адрес <code>192.168.0.100</code> из <code>192.168.0.0-192.168.0.255</code> Это поведение вполне можно считать логичным - по-умолчанию ядро предполагает, что хост с адресом <code>192.168.0.100</code>, так как он находится в сети доступной через <code>eth0</code>, сам может ответить и "помогать" с таким запросом необходимости нет. <BR> В нашем случае с <code>Calico</code> этот механизм вполне работает, и вот почему * Ядро получает arp-запрос <code>ARP, Request who-has 169.254.1.1</code> на интерфейсе <code>calieede18e00ae</code> * Адрес <code>169.254.1.1</code> с точки зрения ядра доступен через маршрут по-умолчанию (а не через интерфейс <code> calieede18e00ae</code>) * Условия соблюдены, значит ответ на запрос будет отправлен. <BR>Отмечу отдельно, что в такой конфигурации можно было бы обойтись даже без шлюза, указав со стороны POD маршрут по-умолчанию в интерфейс <code>eth0</code><BR> Это несомненно работает, но влечет за собой перерасход памяти, так как вместо одной записи для шлюза в таблицу arp будут попадать записи для каждого IP адреса с которым POD будет устанавливать соединение<BR> ==proxy_arp_pvlan== Второй доступный в Linux механизм это <code>proxy_arp_pvlan</code></BR> Мне при первом прочтении документация показалась совершенно недостаточной <PRE> proxy_arp_pvlan - BOOLEAN Private VLAN proxy arp. Basically allow proxy arp replies back to the same interface (from which the ARP request/solicitation was received). This is done to support (ethernet) switch features, like RFC 3069, where the individual ports are NOT allowed to communicate with each other, but they are allowed to talk to the upstream router. As described in RFC 3069, it is possible to allow these hosts to communicate through the upstream router by proxy_arp'ing. Don't need to be used together with proxy_arp. This technology is known by different names: In RFC 3069 it is called VLAN Aggregation. Cisco and Allied Telesyn call it Private VLAN. Hewlett-Packard call it Source-Port filtering or port-isolation. Ericsson call it MAC-Forced Forwarding (RFC Draft). </PRE> Тут суть проблемы в том, что существуют сети, которые хотя и выглядят внешне как ethernet таковыми являются не в полной мере * Радио (wifi) - представим себе ситуацию, что есть сеть из трех устройств, и максимальное расстояние на которых они могут взаимодействовать это 100м. Сеть состоит из точки доступа (базовой станции) и 2 клиентов <PRE> |((((((((((( )))))) | (((((( ))))))) | | /|\ | +---+-------+ +--------------+ +---+-------+ | Client 1 | | Base Station | | Client 2 | +-----------+ +--------------+ +-----------+ 192.168.0.2/24 192.168.0.1/24 192.168.0.3/24 0M -----------------------100M ----------------200M </PRE> Из грубой схемы видно, что хотя каждый из клиентов сможет передавать данные на базовую станцию и получать от нее ответы, связаться друг с другом напрямую клиенты не могут из-за того что находятся далеко друг от друга. <BR> при этом типичная ситуация что все клиенты находятся в одном диапазоне адресов. Таким образом возникает проблема передачи данных от Client1 к Client 2: * ** Прямая связь невозможна из за расстояния ** База даже при включенном <code>proxy_arp</code> будет "думать" что клиенты должны и без нее знать маки друг-друга * Сети с изоляцией портов. Эта технология позволяет специально запретить всякое прохождение пакетов между портами коммутатора, указанными как клиентские и разрешить прохождение только от порта роутера к клиенту и от клиента к порту роутера. У разных производителей оборудования технология может называться по-разному. <BR> Для решения этих проблем и был добавлен механизм <code>proxy_arp_pvlan</code>, который разрешает ответы proxy_arp даже если они получены с того же интерфейса где ожидаемо находится адрес, который запрашивался</BR> В документации написано ''' Basically allow proxy arp replies back to the same interface (from which the ARP request/solicitation was received).''', что меня сбивает с толку и наводит на мысли о том что есть случаи когда ответ отправляется не с того интерфейса, с которого был запрос. Это НЕ ТАК. Речь идет о том интерфейсе, через который доступен адрес, чей мак запрашивается. <BR> * В случае если к базовой станции из примера выше приходит запрос <code>ARP, Request who-has 192.168.0.3 </code>от клиента 1, базовая станция сделает следующие шаги ** Проверит через какой интерфейс получен запрос (для простоты считаем что это wifi0) ** Проверит через какой интерфейс доступен запрошенный адрес 192.168.0.3, это тоже wifi0 В зависимости от настройки <code>proxy_arp_pvlan</code> будет принято решение * если <code>proxy_arp_pvlan = 1 </code> ответ будет отправлен, так как базовая станция знает что не каждый клиент может получить мак другого клиента * если <code>proxy_arp_pvlan = 0 </code> запрос будет проигнорирован, так как базовая станция думает что клиенты могут сами обменяться информацией о мак-адресах При этом настройка <code>proxy_arp_pvlan</code> никак не влияет на работу <code>proxy_arp</code> - для запросов адресов которые доступны через другие интерфейсы, отличные от того через который поступил запрос, будет обработан или игнорироваться в зависимости от значения <code>proxy_arp</code> =Для Cisco= * <code>ip proxy-arp</code> - аналог <code>proxy_arp</code> * <code>ip local-proxy-arp</code> - аналог <code>proxy_arp_pvlan</code> =Подведение итога= Для закрепления еще раз повторю путь пакета из <code>POD</code> до хост-системы * '''Внутри POD3''' POD хочет отправить пакет * '''Внутри POD3''' POD просматривает свою таблицу маршрутизации и находит что у него единственный маршрут через шлюз * '''Внутри POD3''' Шлюз доступен через интерфейс eth0 * '''Внутри POD3''' формируется и отправляется ARP запрос * '''На ноде''' Arp запрос получен на стороне ноды, и обработан за счет механизма proxy_arp * '''Внутри POD3''' POD получает ответ на свой запрос, добавляет запись в свою arp таблицу * '''Внутри POD3''' POD отправляет пакет, где в МАК-адрес получателя это МАК-адрес интерфейса на стороне ноды, изученный их ARP-ответа * '''На ноде''' Нода получает пакет, и так как ма-адрес получателя это ее МАК то пакет не отбрасывается а обрабатывается далее согласно правилам маршрутизации/файрволла =Ссылки= * https://qiita.com/ukinau/items/cb25588fb0c276a009dc ( на японском, переводил хромом, более-менее понятно)

Возврат к странице Calico Kubernetes the hard way v2 How packet goes from pod.