Cisco ASR1001 VxLAN
VxLAN на ASR1001
Эта статья появилась по-тому что я не нашел достаточно подробной информации на русском, и решил собратть все в одном месте, с пояснениями=
Терминология
VTEP— Vitual Tunnel End Point, устройство на котором начинается или заканчиваетсяVxLANтоннель.
VTEP это не обязательно какое-либо сетевое устройство. Так же может выступать и сервер с поддержкой технологии VxLAN. В примере VTEP это ASR1001 и Linux
VNI— Virtual Network Index — идентификатор сети в рамкахVxLAN.
Можно провести аналогию с VLAN. Однако есть некоторые отличия. Далее пример описания про Spine-Leaf коммутаторы: При использовании фабрики, VLAN становятся уникальными только в рамках одного Leaf коммутатора и не передаются по сети. Но с каждым VLAN может быть проассоциирован номер VNI, который уже передается по сети.
Пояснение немного путаное, но VNI это идентификатор который передается по сети, (как и VLAN ID), а вот какой трафик попадет в VNI, завсит от настройки - это может быть как трафик из какого-то VLAN, так и трафик например самого маршрутизатор
NVE— network virtual interface
Это термин использует Cisco что бы обозначать некую виртуальную сущность - контейнер для конфигурационных опций, как IP интерфейс он не существует, на него нельзя назначить IP адрес (что бы это сделать его помещают в бридж и назначают адрес на бридже)
Unicast VxLAN, минимальная конфигурация
Настройка состоит из нескольких этапов
Loopback
Для отправки пакетов в которые инкапсулируется трафик, требуется указать IP адрес отправителя, а для жтого требуется указать интерфейс
В целом можно использовать любой интерфейс, но предпочтительно использовать loopback (так как этот интерфейс всегда up не зависимо от состояния физики )
Отдельно отмечу, что маршрут к адресу назначенному на этом интерфейсе уже должен существовать.
interface Loopback1 ip address 100.65.255.254 255.255.255.255 end
Повторюсь, маршрут к адресу 100.65.255.254 уже должен быть
Дело в том, что физические интерфейсы (Gi/0/0/1 например) зависят от состояния линка. В случае пропадания линка интерфейс переходит в состояние down
Соответвенно, все что использует адрес интерфейса как адрес для отправки пакетов, тоже перестанет работать.
С другой стороны, отключение одного из интерфейсов не означает потерю связности (при использовании динамической маршрутизации траффик "развернется" через другой доступный маршрут)
Соответвенно, что бы не сломать VxLAN тунель лучше использовать адреса доступность которых не зависит от одного-единственного физического интерфейса
Конечно при статической маршрутизации или одном маршруте чуда не произойдет, но даже если есть всего один маршрут лучше использовать Loopback - меньше потом переделывать
vxlan udp port
Можно переопределить порт (но насколько я понимаю он останется одним для всех тунелей, назначить уникальный порт для каждого тунеля не получится)
ASR1001-lab(config)#vxlan udp port ? <1024-65535> Port number
- В лабе я оставляю порт по-умолчанию (4789), так как нет причин его менять
interface nve1
Пример настройки
interface nve1 no ip address member vni 8000 ingress-replication 192.168.22.221 ! source-interface Loopback1 end
interface nve1- имя интерфейса. В простейшем примере он только одинno ip address- назначить адрес на интерфейс этого типа нельзя, это неизменяемое значение по-умолчаниюmember vni 8000- номер VNI (может быть более чем один)ingress-replication 192.168.22.221Настройка адреса VTEP (удаленный конец тунеля, в простейшем случае это единственный адрес, другие варианты настройки тут пока не рассматриваются)!source-interface Loopback1- интерфейс, адрес коттрого используется как адрес отправителя VxLANend
В целом возможна и например вот такая конфигурация, но это сейчас не требуется:
interface nve1 no ip address member vni 8000 ingress-replication 192.168.22.221 ! member vni 8001 ingress-replication 192.168.22.221 ! source-interface Loopback1 end
Еще пишут такое про NVE:
Cisco Nexus 9K, supports 1 NVE interface only. the NVE interface represents a VTEP(switch). If you statically configuring the NVE peers then it's recommended to configure upto 16 vtep only. Also, this is with IR (ingress replication). I recommend enabling Mcast in the underlay and make sure that the peers are discovered automatically.
Приверка состояния интерфейса
show nve interface nve 1 Interface: nve1, State: Admin Up, Oper Up Encapsulation: Vxlan source-interface: Loopback1 (primary:100.65.255.254 vrf:0)
(Один VNI лишний - не настроен)
show nve vni Interface VNI Multicast-group VNI state nve1 8001 N/A BD Down/Re nve1 8000 N/A Up
Добавление интерфейсов VxLAN в бриджи
Для Cisco есть два понятия бриджей (для ASR1000)
bridge-domain- это описание того, какие интерфейсы соединить в бридж. В этом примере в бридже будет присутвовать только один интерфейс, и вся возня с бриджами нужна только для того что бы поднять IP адрес на интерфейсаBDIэто интерфейс на который назначается "логика" - IP адреса, ACL и тп, и он не является обязательным, напрмиер если роутер выступает как транзитное L2 устройство, то такой интерфейс будет не нужен
bridge-domain 255 member vni 8000
bridge-domain 255- создать бридж с номером 255, номер тут ничего не означает и назначать номера бриджей можно как угодноmember vni 8000- добавть в бридж интерфейс VNI с номером 8000, который был описан вNVE1
interface BDI255
"Последний штрих" в настройке на стороне ASR это настройка IP адреса на BDI интерфейсе:
interface BDI255 ip address 10.10.10.1 255.255.255.252 end
interface BDI255- тут номер инерфеса (255) должен совпадать с номером bridge-domain
Ответая сторона (линукс)
Тут тоже полностью статическая конфигурация
/sbin/ip link add vxlan8000 type vxlan local 192.168.22.221 remote 100.65.255.254 dstport 4789 vni 8000
vxlan8000 type vxlanИмя интерфейса может быть произвольным, тип VxLANlocal 192.168.22.221 remote 100.65.255.254 dstport 4789Локальная сторона и удаленная (адрес Lo 1 на ASR) и порт (бегло поискав, похоже что порты должны быьт одинаковые с обоих сторон туннеля при использовании ASR)vni 8000номер VNI совпадает с настроенным на ASR
Далее добавить адрес (10.10.10.1 настроен на ASR)
/sbin/ip address add 10.10.10.2/30 dev vxlan8000
/sbin/ip link set up dev vxlan8000
Проверка пингом:
ASR1001-lab#ping 10.10.10.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Если смотреть на трафик то видно инкапсуляцию:
tcpdump -n -i any host 100.65.255.254 tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 19:19:42.390590 eth0 In IP 100.65.255.254.46049 > 192.168.22.221.4789: VXLAN, flags [I] (0x08), vni 8000 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 8, seq 0, length 80 19:19:42.390763 eth0 Out IP 192.168.22.221.39010 > 100.65.255.254.4789: VXLAN, flags [I] (0x08), vni 8000 IP 10.10.10.2 > 10.10.10.1: ICMP echo reply, id 8, seq 0, length 80
Краткие выводы о первой простейшей конфигурации
В целом оно работает, для частных случаев вполне подходит, хотя незаминимым это решение не назвать, но все же это лучше чем ipip или gre
Замечание про Service Instance
В режиме конфигурации интерфейса мы создаём Service Instance — это привязка интерфейса к сервисам. Каким именно — настроим позднее. Н омер Service Instance произвольный — он локальнозначимый для интерфейса (как и у классического сабинтерфейса).
- encapsulation _default_** означает, что мы хватаем все кадры без разбора
(а могли бы выбирать по метке VLAN или по факту наличия двух меток — QinQ, например), то есть весь физический интерфейс привязываем к VFI.
- Хочу знать больше про Service Instance…**
Резонный вопрос от сторонников бритвы Оккамы — зачем какие-то service instance — недостаточно ли просто bridge-domain прописать? Мысль верная, но service-instance — это «новый» подход к концепции обработки тегированного трафика и называется он
EVC — Ethernet Virtual Circuit.
Тут мы на минуту переключимся на Ethernet-коммутаторы, чтобы понять истоки появления этой идеи.
Традиционно метка VLAN использовалась как для разделения трафика в транках, так и для принятия решения о его коммутации в пределах устройства. То есть если с двух разных интерфейсов пришли два кадра с тегом 802.1q 10, то они оба попадали в один VLAN 10 на коммутаторе, соответственно оказывались в одном широковещательном домене. При этом физически нельзя было принять на устройстве больше 4094 VLAN (если не считать QinQ).
Концепция EVC разделяет эти функции — тег 802.1q по-прежнему служит для разделения трафика в транках, однако решение о коммутации теперь на стороне Service instance.
То есть Service-instance — это удобный способ разделить один физический интерфейс на несколько логических и в зависимости от метки VLAN и других параметров помещать пришедшие кадры в тот или иной сервис.
Например VLAN 10 может быть назначен разным клиентам на разных портах одного коммутатора и далее прокинут через PW на другой конец сети, однако при этом нет необходимости настраивать VLAN 10 глобально на устройстве и тем самым помещать все порты с VLAN 10 в один широковещательный домен.
То есть два кадра с тегом 10, придя на разные порты одного коммутатора сразу передадутся по xconnect и нигде не пересекутся. Таким образом понятие VLAN становится локально значимым для порта.
При этом Service Instance может проверять не только верхний тег VLAN, но и внутренний или оба в случае QinQ или значение приоритета CoS.
Можно задать также диапазон VLAN, помещаемых в данный сервис, настроить снятие, добавление или изменение тегов.
Варианты коммутации: передать в xconnect или в bridge-domain.
В случае маршрутизатора классический саб-интерфейс (типа GE1/1**.1234**) заменяется на Service instance с более широкими возможностями по выбору инкапсуляции.
Учитывая, что до сих пор не всё понятно с этим EVC, отсылаю вас к более пространным объяснениям: [на Cisco][44] и [на русском][45].
Ссылки
