ну проще всего каждой вмке по тенанту...

+ policy json

https://www.youtube.com/watch?v=N34RxgzxIQI&feature=youtu.be+

добрый день всем

может кто получал сертификат COA? осталась литература, заметки, план действий. Буду очень признателен если поделитесь

Коллеги, подскажите. У меня под опенстеком calico. Как мне грамотно загнать запрещающее правило в iptables?

Коллеги, подскажите. У меня под опенстеком calico. Как мне грамотно загнать запрещающее правило в iptables?

@adiantum ты помочь обещал)

@adiantum ты помочь обещал)

когда? кому? =)

когда? кому? =)

Мне. С вопросом: как нарисовать deny правило в access group. )

Мне. С вопросом: как нарисовать deny правило в access group. )

security group?

security group?

Да

Да

Давай в личку подробности =)

Так то в security groups только разрешающие правила

Давай в личку подробности =)

Всем интересно будет :))

Давай в личку подробности =)

Ну так. Calico 2.6 OpenStack pike надо сделать deny правило в 10.0.0.0/8

Так то в security groups только разрешающие правила

почему так изящно придумано?

почему так изящно придумано?

потому что по умолчанию все запрещено

Ну так. Calico 2.6 OpenStack pike надо сделать deny правило в 10.0.0.0/8

подергай Серегу про Calico

Да, а мне надо разрешить всё, кроме определённой сети

подергай Серегу про Calico

я в своих поисках добрался до такого https://docs.projectcalico.org/v2.6/reference/calicoctl/resources/policy

в openstack без Calico запрещающие правила есть в fwaas

в openstack без Calico запрещающие правила есть в fwaas

Ну ещё fwaas тащить)

Ну ещё fwaas тащить)

вот и поспрашивай Серегу =)

В итоге получилось сделать средствами калико

$cat deny_ext_to_int.yml apiVersion: v1 kind: policy metadata: name: deny-ext-to-int spec: egress: - action: deny source: nets: - 256.256.256.0/24 destination: nets: - 10.0.0.0/8 $calicoctl create -f deny_ext_to_int.yml

привет всем) Есть openstack ocata, приватные сети с плавающими адресами у виртуалок Проблема касается скорее всего только для компьют нод с lxd, с kvm такой проблемы не встречал Суть в том, что после создания инстанса он получает по dhcp адрес, в arp таблице на инстансе и в неймспейсе qdhcp правильные маки (в том числе адрес роутера), но на виртуальном роутере в arp таблице мак адрес инстанса не верный, из за этого ломается связность. Пинг роутера с инстанса не помогает, запуск dhclient тоже, помогает либо удаление записи из таблицы arp на виртуальном роутере или запуск arpping с роутера Откуда берется неправильный мак на виртуальном роутере не понятно - ни в логах, ни каком либо сервере его нету, порт и инстанс сразу создается с правильным маком изменение настройки arp_responder не помогает, l2_population включено получается что ARP работает корректно внутри спейса qdhcp

Всем привет

а никто с такой фигней не сталкивался при миграции вм https://pastebin.com/2e8xpnSt

не пойму, какой ресурс оно не может обнаружить

не пойму, какой ресурс оно не может обнаружить

посмотреть трафик или логи keystone?

посмотреть трафик или логи keystone?

Ага, похоже, чот в кейстоуне.

а при чем тут кейстоун?

а при чем тут кейстоун?

С пятидесятой строчки погляди. Можно и раньше, но много лишнего читать)

ах да, сорян) не вчитывался сильно)

а никто с такой фигней не сталкивался при миграции вм https://pastebin.com/2e8xpnSt

засорси keystonerc и выполни opensstack token issue

засорси keystonerc и выполни opensstack token issue

поборол уже... остались другие проблемы, но думаю допричесыванием конфигов решаться... будь не ладны эти опенстек апдейты :D

как класно когда все само решается без нашего вмешательства)

привет всем) Есть openstack ocata, приватные сети с плавающими адресами у виртуалок Проблема касается скорее всего только для компьют нод с lxd, с kvm такой проблемы не встречал Суть в том, что после создания инстанса он получает по dhcp адрес, в arp таблице на инстансе и в неймспейсе qdhcp правильные маки (в том числе адрес роутера), но на виртуальном роутере в arp таблице мак адрес инстанса не верный, из за этого ломается связность. Пинг роутера с инстанса не помогает, запуск dhclient тоже, помогает либо удаление записи из таблицы arp на виртуальном роутере или запуск arpping с роутера Откуда берется неправильный мак на виртуальном роутере не понятно - ни в логах, ни каком либо сервере его нету, порт и инстанс сразу создается с правильным маком изменение настройки arp_responder не помогает, l2_population включено получается что ARP работает корректно внутри спейса qdhcp

а по нашей проблеме - никто не сталкивался или есть идеи какие либо? =) пока выяснили что мак на виртуальном роутере берется со старых, уже удаленных поортов. Но таблица arp с неправильной не обновляется ни при пингах, ни при транзитном трафике(

Есть предположение почему маки не учатся автоматом: проблема может возникать из-за того что libvirt по-умолчанию после создания порта сам шлет RARP пакет в сеть чтобы мак нового порта везде разошелся, а lxc так не делает. Сам опенстек ориентируется на это (что libvirt пошлет RARP) и не посылает такие пакеты. Проблема с тем что мак не учится даже тогда когда вы из инстанса начинаете шлюз пинговать - очень старнная проблема. Вы этот трафик вообще видите на стороне где роутер (по идеи если вы пингуете с инстанса роутер на стороне роутера вы сначала увидите ARP бродкаст потом пинги)? Роутеры на отдельной ноде или DVR?

Если у вас роутеры на отдельном сервере попробуйте на сервере где роутер запустить tcpdump на том физическом интерфейсе где проходит VXLAN/GRE трафик до роутера. Видно ли там инкапсулированный трафик от инстанса? То есть проверить долетает ли трафик в сторону роутера до OVS/LinuxBridge (кстати что у вас там?)

Есть предположение почему маки не учатся автоматом: проблема может возникать из-за того что libvirt по-умолчанию после создания порта сам шлет RARP пакет в сеть чтобы мак нового порта везде разошелся, а lxc так не делает. Сам опенстек ориентируется на это (что libvirt пошлет RARP) и не посылает такие пакеты. Проблема с тем что мак не учится даже тогда когда вы из инстанса начинаете шлюз пинговать - очень старнная проблема. Вы этот трафик вообще видите на стороне где роутер (по идеи если вы пингуете с инстанса роутер на стороне роутера вы сначала увидите ARP бродкаст потом пинги)? Роутеры на отдельной ноде или DVR?

трафик на стороне виртуального роутера от хоста вижу, но ответ роутера идет на неправильный мак)

Есть предположение почему маки не учатся автоматом: проблема может возникать из-за того что libvirt по-умолчанию после создания порта сам шлет RARP пакет в сеть чтобы мак нового порта везде разошелся, а lxc так не делает. Сам опенстек ориентируется на это (что libvirt пошлет RARP) и не посылает такие пакеты. Проблема с тем что мак не учится даже тогда когда вы из инстанса начинаете шлюз пинговать - очень старнная проблема. Вы этот трафик вообще видите на стороне где роутер (по идеи если вы пингуете с инстанса роутер на стороне роутера вы сначала увидите ARP бродкаст потом пинги)? Роутеры на отдельной ноде или DVR?

роутеры на отдельной ноде

Если у вас роутеры на отдельном сервере попробуйте на сервере где роутер запустить tcpdump на том физическом интерфейсе где проходит VXLAN/GRE трафик до роутера. Видно ли там инкапсулированный трафик от инстанса? То есть проверить долетает ли трафик в сторону роутера до OVS/LinuxBridge (кстати что у вас там?)

ovs

хм получается вы даже видите трафик если сделать что-то такое? ip netns exec qrouter-<uuid> tcdpump -i qr-<uuid> -n

Инсталляция большая, в ограничение по макам не уперлись?

при пингах роутера с хоста не видно arp на виртуальном роутере

да вот пример

в общем мак приходит правильный на роутер root@iva-node3:/home/ishergin# ip netns exec qrouter-6aae530b-a1f6-419f-a725-9c5b03d8afbd tcpdump -s0 -i qr-f1e0adb0-49 -ne ether host fa:16:3e:ff:85:56 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on qr-f1e0adb0-49, link-type EN10MB (Ethernet), capture size 262144 bytes ^C12:54:29.046978 fa:16:3e:ff:85:56 > fa:16:3e:b4:d0:f2, ethertype IPv4 (0x0800), length 98: 192.168.17.17 > 188.186.237.65: ICMP echo request, id 3784, seq 1, length 64 но таблица ARP не обновляется и ответ от 188.186.237.65 уходит на другой мак root@iva-node3:/home/ishergin# ip netns exec qrouter-6aae530b-a1f6-419f-a725-9c5b03d8afbd tcpdump -s0 -i qr-f1e0adb0-49 -ne ether host fa:16:3e:07:d5:4d tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on qr-f1e0adb0-49, link-type EN10MB (Ethernet), capture size 262144 bytes ^C12:54:05.144193 fa:16:3e:b4:d0:f2 > fa:16:3e:07:d5:4d, ethertype IPv4 (0x0800), length 98: 188.186.237.65 > 192.168.17.17: ICMP echo reply, id 3756, seq 265, lengt

И ещё есть статья классная https://networkop.co.uk/blog/2016/05/06/neutron-l2pop/

Инсталляция большая, в ограничение по макам не уперлись?

вроде тюнили, порядка 4000 виртуалок, примерно сотня роутеров

при пингах роутера с хоста не видно arp на виртуальном роутере

да жто я уже понял, это часть проблемы почему не переучивается ARP так как он переучивается только из ARP пакетов, то есть у вас на инстансе МАК учится как-то статикой и нет ARPов в начале

вроде тюнили, порядка 4000 виртуалок, примерно сотня роутеров

Насколько тюнили? Сколько сейчас ?

@ihard подскажешь?)

gc.treshold так по-моему

net.ipv4.neigh.default.gc_thresh1 = 4096 net.ipv4.neigh.default.gc_thresh2 = 8192 net.ipv4.neigh.default.gc_thresh3 = 12288 net.ipv4.neigh.default.base_reachable_time = 86400 net.ipv4.neigh.default.gc_stale_time = 86400

net.ipv4.neigh.default.gc_thresh1 = 4096 net.ipv4.neigh.default.gc_thresh2 = 8192 net.ipv4.neigh.default.gc_thresh3 = 12288 net.ipv4.neigh.default.base_reachable_time = 86400 net.ipv4.neigh.default.gc_stale_time = 86400

Вы чего, это мало

4к виртуалок, у вас маки уже чистятся

С первой границы сразу чистка начинается

спасибо! попробуем поднять

Для начала проверьте сколько сейчас уже

Там в проке есть файлик

а вот мак на роутере из старого порта откуда берется интересно? если RARP не было, но для адреса виртуалки прописывается неправильный мак? какой механизм отвечает в openstack за это?

https://networkop.co.uk/blog/2016/05/06/neutron-l2pop/

понял

Посмотрите статью

два варианта: 1) если у вас схема с ARP proxy то на каждом сервере ARP proxy представляется как бе шлюзом для своих же виртуальных сущностей и бродкаст в сеть не кидается 2) если у вас выключен ARP proxy режим то обычный ARP learning (мака нет, надо спросить ARP request и т.д.) насколько понимаю если у вас со стороны инстанса в арп таблице реальный мак роутера, то на compute ноде у вас нет ARP proxy (иначе бы в таблице инстанса вы видели именно мак ARP proxy), а вот со стороны network ноды уже интересней, может у вас он включен там?

два варианта: 1) если у вас схема с ARP proxy то на каждом сервере ARP proxy представляется как бе шлюзом для своих же виртуальных сущностей и бродкаст в сеть не кидается 2) если у вас выключен ARP proxy режим то обычный ARP learning (мака нет, надо спросить ARP request и т.д.) насколько понимаю если у вас со стороны инстанса в арп таблице реальный мак роутера, то на compute ноде у вас нет ARP proxy (иначе бы в таблице инстанса вы видели именно мак ARP proxy), а вот со стороны network ноды уже интересней, может у вас он включен там?

у нас пока на compute ноде arp_responder = False, а сетевых True) сейчас проверим

это и может быть проблемой, везде один конфиг должен быть в этом плане, иначе у вас с одной стороны бродкаст ARP ходит, с другой - нет

было и true - тоже не работало

попробуйте везде просто отключить arp_responder, это переведет сеть на обычный ARP learning, и даже если левый мак адрес на роутере будет появляться в начале, он будет переучиваться когда будет прилетать ARP от инстанса (сейчас же он просто не долетает насколько я понял)

тут наверное есть шарящие в cloudinit - подскажите, как мне правильнее запустить скрипт при первом запуске. Я так понимаю, что есть такая вещь как scripts-per-once, но не очень понял как ей оnдать именно скрипт? достаточно ли будет подложить его в /var/lib/cloud/scripts/per-once? или стартовать из самого конфига?

важная поправка - он должен запуститься единожды

подскажите: Запускаю ВМ из имиджа, он его тянет из ceph-а в папку /var/lib/nova/instances/_base как сделать, что бы он его не тянул, пул с имеджами доступен всем нодам, невижу смысла его вытягивать из этого пула

подскажите: Запускаю ВМ из имиджа, он его тянет из ceph-а в папку /var/lib/nova/instances/_base как сделать, что бы он его не тянул, пул с имеджами доступен всем нодам, невижу смысла его вытягивать из этого пула

А в конфиге glance у тебя стоит show_image_direct_url = True?

И show_multiple_locations = True на всякий случай.

show_image_direct_url = True это ставил show_multiple_locations = True это сейчас прописал, glance перестартанул, всё равно кидает образ, один раз конечно, но всё же

А когда делаешь openstack image show он показывает в поле location что это rbd:// ?

да и локайшин и direct_url ссылка в рбд

https://pastebin.com/4paA0Tm1

поцчему нигде не написано, что при влындивании ha нужно фернет и креденшиалс ключи копировать на все ноды контроллера?