# Вопросы и действия
Вопросы организационные:
- [ ] 1. Договор (обсуждение 15.04);
- [ ] 2. Фиксирование, планирование работ (Jira и подобные) - нужен доступ, аккаунт (после договора?);
- [ ] 3. Общение в рабочем порядке (почта/slack - аккаунт после договора?);
- [ ] 4. Документирование работ (аккаунт после договора?);
- [ ] 5. Доступ в лабу/к железу для проверки конфигураций, работоспособности (VPN? После договора?);
- [ ] 6. Нужен генератор трафика и доступ к нему для тестирования сети, отказов и т.п.. Если есть возможность взять spirent/ixia на время - было бы не плохо. Если нет, то нужно выделить 1 сервер БМС для trex/warp17 (ПО).

Вопросы по ПО:
- [ ] 1. На MX/EX успешно показал себя 18.4R3 релиз, сейчас доступен 18.4R3-S1, нужно тестировать;
- [ ] 2. Для QFX в случае использования EVPN-VXLAN route type 5 only необходим софт 19.2+ (проверял на qfx5110). В случае классического для Juniper EVPN ESI-LAG и без route type 5 - подойдет 18.4+ релиз (нужен 18.4 для честного active/active, как для L2, так и для L3 префиксов);
- [ ] 3. Какой релиз рекомендовался для CEM?;
- [ ] 4. Нужен ли шаблонизатор/генератор yml файлов для CEM?

Вопросы по физической топологии:
- [ ] 1. Линки между сетеобразующими устройствами будут AOC, как общались ранее?
- [ ] 2. Как будут подключаться BMS к фабрике, кроме data линков?
* OOB для IDRAC/ILO?
* Нужен ли PXE? Если да, то будет ли отдельный интерфейс задействован для PXE? Если не будет отдельного интерфейса, то этот сценарий невозможен без переконфигурирования коммутаторов в single-homing из-за ESI-LAG (нету force-up).
- [ ] 3. Призываю обязательно соблюдать cabling! Он должен быть 1 к 1 на всей сети в рамках POD/DC, чтобы избежать дополнительных проблем при отказах линков/устройств (я имею в виду проблемы с балансировкой).

Вопросы по адинистрированию:
- [ ] 1. VPN для RA в инфраструктуру из своего опыта рекомендую не использовать FO (если ASA/FG), очень хорошо себя показала standalone конструкция с балансировкой между VPN GW средсвами клиента и/или DNS. Но вам виднее.

Вопросы по логической топологии:
- [ ] 1. Ознакомился с документацией к CEM в части overlay - возможно использовать в фабрике к сожалению только ebgp underlay и ibgp overlay;
- [ ] 2. Вам нужно определится с сервисной моделью. Я предлагаю использовать для разделения проектов и групп пользователей роутинг модель (VRF per service), это позволит нативно сегментировать доступы между разными группами пользователей, сервисов, без дополнительной нагрузки на память для ACL и упростит понимание сети (визабилити). Но нужно понимать, что ресурс RI тоже не бесконечен;
- [ ] 3. ASN per leaf, same ASN on SPINE, same (public) ASN on DC EDGE (MX);
- [ ] 4. После определения сервисной модели предлагаю выделить адресные пулы под проекты (с запасом), разбивая их с учетом будущей **возможной** миграции с CRB модели на ERB. То есть:
* Пул для ДЦ
* Пул для POD
* Пул для RACK
* Пул для сервера (в случае виртуализации)
* ASN и пул для DCI/anycast
* Пул для OOB
* Пул для loopback
* Пул для p2p

- [ ] 5. Naming;
- [ ] 6. DHCP?;
- [ ] 7. BFD для underlay eBGP? (уменьшает стабильность сети, но увеличивает скорость реагирования на проблемы с control plane);
- [ ] 8. Мониторинг/контроль качества физических линков (OAM LFM/BER)? Вносит усложнение сети, не всегда нужен, но позволяет видеть ошибки на p2p интерфейсах (не говоря уже про efm);
- [ ] 9. Скейлинг - для QFX10k8 40 стоек (80 100g линков) не проблема, но что дальше будет в будущем, уже думали?
- [ ] 10. Для резервирования серверов по Л2 в overlay сетях **потребуется** менять привычные настройки для kernel, promisc (security), sysctl, software (keepalived/pacemaker);
- [ ] 11. Сервисная модель EVPN (vlan-aware/vlan-bundle?);