Cisco ASR1001 VxLAN: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
 
(не показано 47 промежуточных версий этого же участника)
Строка 1: Строка 1:
 
[[Категория:Cisco]]
  
[[Категория:Cisco]]
−
[[Категория:ASR100]]
 +
[[Категория:ASR1000]]
  +
[[Категория:ASR1001]]
 
[[Категория:Linux]]
  
[[Категория:Linux]]
 
[[Категория:VxLAN]]
  
[[Категория:VxLAN]]
Строка 9: Строка 10:
   
 
=Терминология=
  
=Терминология=
  +
==Основные термины связанные с <code>VxLAN</code>==
−  
 
* <code>VTEP</code> — Vitual Tunnel End Point, устройство на котором начинается или заканчивается <code>VxLAN</code> тоннель.
 
* <code>VTEP</code> — Vitual Tunnel End Point, устройство на котором начинается или заканчивается <code>VxLAN</code> тоннель.
 
VTEP это не обязательно какое-либо сетевое устройство. Так же может выступать и сервер с поддержкой технологии VxLAN. В примере VTEP это ASR1001 и Linux
  
VTEP это не обязательно какое-либо сетевое устройство. Так же может выступать и сервер с поддержкой технологии VxLAN. В примере VTEP это ASR1001 и Linux
Строка 23: Строка 24:
 
* <code>NVE</code> — network virtual interface
  
* <code>NVE</code> — network virtual interface
 
Это термин использует Cisco что бы обозначать некую виртуальную сущность - контейнер для конфигурационных опций, как IP интерфейс он не существует, на него нельзя назначить IP адрес (что бы это сделать его помещают в бридж и назначают адрес на бридже)
  
Это термин использует Cisco что бы обозначать некую виртуальную сущность - контейнер для конфигурационных опций, как IP интерфейс он не существует, на него нельзя назначить IP адрес (что бы это сделать его помещают в бридж и назначают адрес на бридже)
  +
  +
==<code>Ethernet Virtual Connections </code>==
  +
<BR>
  +
Эти термины и понятия не относятся напрямую к <code>VxLAN</code> однако необходимы<BR>
  +
для понимания как виртуальные <code>VxLAN</code> сети соединяются с физическими <code>VLAN</code>
  +
<BR>
  +
* EVCs (Ethernet Virtual Connections) - технология виртуальных соединений, позволяющая организовать внутри физического коммутатора несколько широковещательных L2 доменов (виртуальных коммутаторов).<BR>
  +
Домен EVC состоит из <code>bridge-domain</code> и подключенными к нему <code>EFP</code>.<BR>
  +
Это обобщенный термин
  +
  +
<BR>
  +
* <code>Bridge domain</code> – это некая L2 логическая широковещательная область внутри устройства.<BR>
  +
Принцип работы такойже как и у коммутатора, а именно передача кадров в соответствии с mac таблицей. <BR>
  +
Для каждого номера bridge-domain будет свой экземпляр mac таблицы.<BR>
  +
Полный аналог Linux Bridge
  +
  +
<BR>
  +
* <code>Ethernet Flow Point</code> (EFP) - это логический интерфейс c набором правил определяющими критерии пересылки пакетов в bridge-domain. <BR>
  +
В конфигурации cisco под EFP понимается <code>service instance</code> с включеными в нее настройками например <BR>
  +
encapsulation, rewrite, bridge-domain и т.п. <BR>
  +
К одному bridge-domain можно подключить сразу несколько EFP на одном физическом интерфейсе.
  +
  +
<BR>
  +
* <code>Encapsulation</code> – этот параметр в настройках Service instance задает критерий выбора пакетов. <BR>
  +
Например настройка <code>encapsulation dot1q 20</code> говорит что будут обработаны только кадры с тегом равным 20 (VLAN 20).
  +
  +
<BR>
   
 
=Unicast VxLAN, минимальная конфигурация=
  
=Unicast VxLAN, минимальная конфигурация=
Строка 55: Строка 83:
 
}}
  
}}
   
  +
==<code>vxlan udp port</code>==
−
==11==
  
  +
Можно переопределить порт (но насколько я понимаю он останется одним для всех тунелей, назначить уникальный порт для каждого тунеля не получится)
−
==22==
  
  +
<PRE>
  +
ASR1001-lab(config)#vxlan udp port ?
  +
<1024-65535> Port number
  +
</PRE>
  +
  +
* В лабе я оставляю порт по-умолчанию (4789), так как нет причин его менять
  +
  +
==<code>interface nve1</code>==
  +
Пример настройки
  +
<PRE>
  +
interface nve1
  +
no ip address
  +
member vni 8000
  +
ingress-replication 192.168.22.221
  +
!
  +
source-interface Loopback1
  +
end
  +
</PRE>
  +
  +
* <code>interface nve1</code> - имя интерфейса. В простейшем примере он только один
  +
* <code> no ip address</code> - назначить адрес на интерфейс этого типа нельзя, это неизменяемое значение по-умолчанию
  +
* <code> member vni 8000</code> - номер VNI (может быть более чем один)
  +
* <code> ingress-replication 192.168.22.221</code> Настройка адреса VTEP (удаленный конец тунеля, в простейшем случае это единственный адрес, другие варианты настройки тут пока не рассматриваются)
  +
* <code> !</code>
  +
* <code> source-interface Loopback1</code> - интерфейс, адрес коттрого используется как адрес отправителя VxLAN
  +
* <code>end</code>
  +
  +
  +
В целом возможна и например вот такая конфигурация, но это сейчас не требуется:
  +
<PRE>
  +
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
  +
</PRE>
  +
  +
Еще пишут такое про NVE:
  +
<PRE>
  +
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.
  +
</PRE>
  +
  +
==Приверка состояния интерфейса==
  +
  +
<PRE>
  +
show nve interface nve 1
  +
  +
Interface: nve1, State: Admin Up, Oper Up Encapsulation: Vxlan
  +
source-interface: Loopback1 (primary:100.65.255.254 vrf:0)
  +
</PRE>
  +
(Один VNI лишний - не настроен)
  +
<PRE>
  +
show nve vni
  +
Interface VNI Multicast-group VNI state
  +
nve1 8001 N/A BD Down/Re
  +
nve1 8000 N/A Up
  +
</PRE>
  +
  +
==Добавление интерфейсов VxLAN в бриджи==
  +
  +
Для Cisco есть два понятия бриджей (для ASR1000)
  +
  +
* <code>bridge-domain</code> - это описание того, какие интерфейсы соединить в бридж. В этом примере в бридже будет присутвовать только один интерфейс, и вся возня с бриджами нужна только для того что бы поднять IP адрес на интерфейса
  +
* <code>BDI</code> это интерфейс на который назначается "логика" - IP адреса, ACL и тп, и он не является обязательным, напрмиер если роутер выступает как транзитное L2 устройство, то такой интерфейс будет не нужен
  +
  +
  +
<PRE>
  +
bridge-domain 255
  +
member vni 8000
  +
</PRE>
  +
* <code>bridge-domain 255</code> - создать бридж с номером 255, номер тут ничего не означает и назначать номера бриджей можно как угодно
  +
* <code>member vni 8000</code> - добавть в бридж интерфейс VNI с номером 8000, который был описан в <code>NVE1</code>
  +
  +
==<code>interface BDI255</code>==
  +
"Последний штрих" в настройке на стороне ASR это настройка IP адреса на BDI интерфейсе:
  +
<PRE>
  +
interface BDI255
  +
ip address 10.10.10.1 255.255.255.252
  +
end
  +
</PRE>
  +
* <code>interface BDI255</code> - тут номер инерфеса (255) должен совпадать с номером bridge-domain
  +
  +
  +
  +
==Ответая сторона (линукс)==
  +
Тут тоже полностью статическая конфигурация
  +
<PRE>
  +
/sbin/ip link add vxlan8000 type vxlan local 192.168.22.221 remote 100.65.255.254 dstport 4789 vni 8000
  +
</PRE>
  +
  +
* <code>vxlan8000 type vxlan </code> Имя интерфейса может быть произвольным, тип VxLAN
  +
* <code>local 192.168.22.221 remote 100.65.255.254 dstport 4789 </code> Локальная сторона и удаленная (адрес Lo 1 на ASR) и порт (бегло поискав, похоже что порты должны быьт одинаковые с обоих сторон туннеля при использовании ASR)
  +
* <code>vni 8000</code> номер VNI совпадает с настроенным на ASR
  +
  +
Далее добавить адрес (10.10.10.1 настроен на ASR)
  +
<PRE>
  +
/sbin/ip address add 10.10.10.2/30 dev vxlan8000
  +
</PRE>
  +
<PRE>
  +
/sbin/ip link set up dev vxlan8000
  +
</PRE>
  +
  +
Проверка пингом:
  +
<PRE>
  +
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
  +
</PRE>
  +
  +
Если смотреть на трафик то видно инкапсуляцию:
  +
<PRE>
  +
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
  +
</PRE>
  +
  +
==Краткие выводы о первой простейшей конфигурации==
  +
В целом оно работает, для частных случаев вполне подходит, хотя незаминимым это решение не назвать, но все же это лучше чем <code>ipip</code> или <code>gre</code>
  +
  +
  +
=Замечание про Service Instance=
  +
==Зачем это нужно и какое отношение имеет к <code>VxLAN</code>==
  +
<BR>
  +
Отношение к <code>VxLAN</code> это имеет весьма отдаленное, но так как интерфейсы <code>VxLAN</code> нужно в большенстве случаев<BR>
  +
каки-то образом соедининять с L2-интерфейсами (<code>VxLAN</code> это все таки больше всего про <code>L2VPN</code>), без понимания<BR>
  +
<code>Service Instance</code> не обойтсь<BR>
  +
<BR>
  +
  +
==Что такое <code> service instance</code>==
  +
Порще всего думать <code> service instance</code> как об новом специальном способе для создания обычных саб-интерфейсов. <BR>
  +
<BR>
  +
Попробую пояснить это на примере.
  +
<BR>
  +
Есть 2 конфигурации которые по сути могут делать практически одно и то же:
  +
<BR>
  +
<PRE>
  +
interface gigabitethernet0/1
  +
service instance 5 Ethernet
  +
encapsulation dot1q 20
  +
bridge-domain 20
  +
</PRE>
  +
  +
<PRE>
  +
interface gigabitethernet0/1.20
  +
encapsulation dot1q 20
  +
</PRE>
  +
По сути, оба интерфейса "привязаны" к VLAN20 но на ASR1000 нет bridge-group (вместо них - bridge-domain), те синтаксис добаволения в бриджи другой
  +
<BR>
  +
Кроме того
  +
  +
  +
* Номер Service Instance произвольный — он локальнозначимый для интерфейса (как и у классического сабинтерфейса).
  +
  +
**encapsulation _default_** означает, что мы хватаем все кадры без разбора
  +
(а могли бы выбирать по метке VLAN или по факту наличия двух меток — QinQ, например), то есть весь физический интерфейс привязываем к VFI.
  +
  +
  +
===Хочу знать больше про Service Instance===
  +
Приведу тут в виде цитаты еще один вариант пояснения:
  +
{{quote|
  +
Резонный вопрос от сторонников бритвы Оккамы — зачем какие-то service instance — недостаточно ли просто bridge-domain прописать? <BR>
  +
Мысль верная, но service-instance — это «новый» подход к концепции обработки тегированного трафика и называется он
  +
<BR>
  +
<code>EVC — Ethernet Virtual Circuit.</code>
  +
<BR>
  +
Тут мы на минуту переключимся на Ethernet-коммутаторы, чтобы понять истоки появления этой идеи.
  +
<BR>
  +
Традиционно метка VLAN использовалась как для разделения трафика в транках,<BR>
  +
так и для принятия решения о его коммутации в пределах устройства. <BR>
  +
То есть если с двух разных интерфейсов пришли два кадра с тегом 802.1q 10, то они оба попадали в один VLAN 10 на <BR>
  +
коммутаторе, соответственно оказывались в одном широковещательном домене. При этом физически нельзя было принять <BR>
  +
на устройстве больше 4094 VLAN (если не считать QinQ). <BR>
  +
<BR>
  +
<BR>
  +
Концепция EVC разделяет эти функции — тег 802.1q по-прежнему служит для разделения трафика в транках, <BR>
  +
однако решение о коммутации теперь на стороне Service instance.<BR>
  +
<BR>
  +
То есть Service-instance — это удобный способ разделить один физический интерфейс на несколько логических <BR>
  +
и в зависимости от метки VLAN и других параметров помещать пришедшие кадры в тот или иной сервис.<BR>
  +
<BR>
  +
Например VLAN 10 может быть назначен разным клиентам на разных портах одного коммутатора и далее прокинут <BR>
  +
через PW на другой конец сети, однако при этом нет необходимости настраивать VLAN 10 глобально на устройстве <BR>
  +
и тем самым помещать все порты с VLAN 10 в один широковещательный домен.<BR>
  +
<BR>
  +
То есть два кадра с тегом 10, придя на разные порты одного коммутатора сразу передадутся по <BR>
  +
xconnect и нигде не пересекутся. Таким образом понятие VLAN становится локально значимым для порта.<BR>
  +
<BR>
  +
При этом Service Instance может проверять не только верхний тег VLAN, но и внутренний или оба в <BR>
  +
случае QinQ или значение приоритета CoS. <BR>
  +
<BR>
  +
Можно задать также диапазон VLAN, помещаемых в данный сервис, настроить снятие, добавление или изменение тегов.<BR>
  +
<BR>
  +
Варианты коммутации: передать в xconnect или в bridge-domain.
  +
<BR>
  +
В случае маршрутизатора классический саб-интерфейс (типа GE1/1**.1234**) заменяется на Service instance <BR>
  +
с более широкими возможностями по выбору инкапсуляции. <BR>
  +
  +
}}
  +
  +
==типы инкапсуляции service-instance==
  +
Для порлноты картины приведу некоторые примеры по настройук инкапсуляции
  +
<BR>
  +
другими словами - условий по которым выбрать трафик который попадет в <code>service-instance</code>
  +
Например VLAN50
  +
<PRE>
  +
interface gigabitethernet0/1
  +
switchport mode trunk
  +
switchport trunk allowed vlan none
  +
service instance 1 Ethernet
  +
encapsulation dot1q 50
  +
</PRE>
  +
  +
Q-in-Q<BR>
  +
Внешний влан 50 (S-Vlan = 50) Внутрений влан 60 (С-Vlan = 60)
  +
<PRE>
  +
interface gigabitethernet0/1
  +
switchport mode trunk
  +
switchport trunk allowed vlan none
  +
service instance 1 Ethernet
  +
encapsulation dot1q 50 second-dot1q 60
  +
</PRE>
  +
  +
Тут важно отметить что траффик не модифицируется - это только условие, если этот трафик отправить в бридж то туда он попадет с тегами, одним или двумя, для модификации нужно указать отдельное правило
  +
  +
==Просмотр информации по <code>service-instance</code>==
  +
Пример для:
  +
<PRE>
  +
interface Port-channel1
  +
description dell-Po2-ports-24-25-25-27
  +
mtu 9216
  +
no ip address
  +
no negotiation auto
  +
load-balancing flow
  +
service instance 1 ethernet
  +
encapsulation dot1q 999 second-dot1q 257
  +
!
  +
</PRE>
  +
<PRE>
  +
show ethernet service instance id 1 interface po 1 detail
  +
Service Instance ID: 1
  +
Service Instance Type: Static
  +
Associated Interface: Port-channel1
  +
Associated EVC:
  +
Port-channel load-balance interface: None
  +
L2protocol drop
  +
CE-Vlans:
  +
Encapsulation: dot1q 999 vlan protocol type 0x8100 second-dot1q 257 vlan protocol type 0x8100
  +
Interface Dot1q Tunnel Ethertype: 0x8100
  +
State: Up
  +
EFP Statistics:
  +
Pkts In Bytes In Pkts Out Bytes Out
  +
10 3600 0 0
  +
EFP Microblocks:
  +
****************
  +
Microblock type: Bridge-domain
  +
Bridge-domain: 255
  +
  +
Microblock type: L2Mcast
  +
L2 Multicast GID: 1
  +
  +
Microblock type: dhcp_snoop
  +
L2 Multicast GID: 1
  +
</PRE>
  +
  +
==Добавдение в <code>bridge-domain</code>==
  +
<PRE>
  +
bridge-domain 255
  +
member vni 8000
  +
member Port-channel1 service-instance 1
  +
</PRE>
  +
  +
  +
"Старый" синтаксис (пример ниже) не работает
  +
<PRE>
  +
interface gigabitethernet0/1
  +
switchport mode trunk
  +
switchport trunk allowed vlan none
  +
service instance 1 Ethernet
  +
encapsulation dot1q 50 second-dot1q 60
  +
rewrite ingress tag pop 2 symmetric
  +
bridge-domain 400
  +
</PRE>
  +
<PRE>
  +
ASR1001-lab(config-if-srv)#bridge-domain 255
  +
% New configuration model is being used.
  +
Please use member command under bridge-domain.
  +
</PRE>
  +
  +
==Модификация трафика==
  +
Если не придпринимать дополнительных действий, то конфигурация вида
  +
<PRE>
  +
interface Port-channel1
  +
description dell-Po2-ports-24-25-25-27
  +
mtu 9216
  +
no ip address
  +
no negotiation auto
  +
load-balancing flow
  +
service instance 1 ethernet
  +
encapsulation dot1q 999 second-dot1q 257
  +
!
  +
end
  +
</PRE>
  +
приведет к тому что в бридж-ждомен попадет трафик с 2 тегами
  +
<PRE>
  +
20:21:58.626285 0c:80:63:21:c3:45 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 360: vlan 999, p 0, ethertype 802.1Q (0x8100), vlan 257, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 0c:80:63:21:c3:45, length 310
  +
</PRE>
  +
{{Note|"Как ты отдампал трафик?":
  +
Для того что бы это увидеть я пробросил через VxLAN трафик на линукс. Но об этом подробнее ниеже
  +
}}
  +
  +
Для того что бы получить трафик без тегов используется команда
  +
<PRE>
  +
rewrite ingress tag pop 2 symmetric
  +
</PRE>
  +
Назначение более-менее очевидно
  +
* <code>rewrite ingress </code> применять к входящиму трафику
  +
* <code>tag </code> обрабаьывать тэги
  +
* <code>pop 2 </code> не знаю как на русском это называется - отбросить? выбросить? 2 тега (2 потому что у нас в примере трафик с двойным теггированием)
  +
* <code>symmetric </code> - симетрично создать правило для обратного траффика
  +
После чего на бридже будет трафик уже без тегов
  +
<BR>
  +
Возможности модийикации значительно более широкие, но я пока не тестировал эту фичу (Судя по всему можно менять теги на другие, 2 тега на один или наоборот)
   
 
=Ссылки=
  
=Ссылки=
Строка 72: Строка 434:
   
 
* BVI/BDI интерфейсы https://www.cisco.com/c/en/us/support/docs/lan-switching/integrated-routing-bridging-irb/200650-Understanding-Bridge-Virtual-Interface.html
  
* BVI/BDI интерфейсы https://www.cisco.com/c/en/us/support/docs/lan-switching/integrated-routing-bridging-irb/200650-Understanding-Bridge-Virtual-Interface.html
  +
  +
Ethernet Virtual Connections (EVCs).
  +
* (рус)http://steinkafer.blogspot.com/2017/12/cisco-evc.html
  +
* (рус) https://admin-gu.ru/device/cisco/cisco-evcs-nastrojka-bridge-domain-service-instance-i-rewrite
  +
  +
  +
EVPN
  +
* https://bitworks.software/2018-10-24-vxlan-bgp-evpn.html
  +
https://bitworks.software/2018-10-24-vxlan-bgp-evpn.html
  +
https://www.cisco.com/c/en/us/support/docs/lan-switching/integrated-routing-bridging-irb/200650-Understanding-Bridge-Virtual-Interface.html
  +
  +
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-16/ce-xe-16-book/evpn-vxlan-l3.html
  +
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-16/ce-xe-16-book/evpn-vxlan-l3.html
  +
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-16/ce-xe-16-book/evpn-vxlan-l3.html
  +
  +
https://protocoholic.com/2019/09/19/cisco-mpls-vpn-configuration-example-and-explanation/
  +
https://protocoholic.com/2018/05/06/asr1000-vxlan-unicast-mode-configuration-and-verification/

Текущая версия на 09:42, 22 июля 2024

VxLAN на ASR1001

Эта статья появилась по-тому что я не нашел достаточно подробной информации на русском, и решил собратть все в одном месте, с пояснениями=

Терминология

Основные термины связанные с VxLAN

  • 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 адрес (что бы это сделать его помещают в бридж и назначают адрес на бридже)

Ethernet Virtual Connections


Эти термины и понятия не относятся напрямую к VxLAN однако необходимы
для понимания как виртуальные VxLAN сети соединяются с физическими VLAN

  • EVCs (Ethernet Virtual Connections) - технология виртуальных соединений, позволяющая организовать внутри физического коммутатора несколько широковещательных L2 доменов (виртуальных коммутаторов).

Домен EVC состоит из bridge-domain и подключенными к нему EFP.
Это обобщенный термин


  • Bridge domain – это некая L2 логическая широковещательная область внутри устройства.

Принцип работы такойже как и у коммутатора, а именно передача кадров в соответствии с mac таблицей.
Для каждого номера bridge-domain будет свой экземпляр mac таблицы.
Полный аналог Linux Bridge


  • Ethernet Flow Point (EFP) - это логический интерфейс c набором правил определяющими критерии пересылки пакетов в bridge-domain.

В конфигурации cisco под EFP понимается service instance с включеными в нее настройками например
encapsulation, rewrite, bridge-domain и т.п.
К одному bridge-domain можно подключить сразу несколько EFP на одном физическом интерфейсе.


  • Encapsulation – этот параметр в настройках Service instance задает критерий выбора пакетов.

Например настройка encapsulation dot1q 20 говорит что будут обработаны только кадры с тегом равным 20 (VLAN 20).


Unicast VxLAN, минимальная конфигурация

Настройка состоит из нескольких этапов

Loopback

Для отправки пакетов в которые инкапсулируется трафик, требуется указать IP адрес отправителя, а для жтого требуется указать интерфейс
В целом можно использовать любой интерфейс, но предпочтительно использовать loopback (так как этот интерфейс всегда up не зависимо от состояния физики )
Отдельно отмечу, что маршрут к адресу назначенному на этом интерфейсе уже должен существовать. 

interface Loopback1
 ip address 100.65.255.254 255.255.255.255
end

Повторюсь, маршрут к адресу 100.65.255.254 уже должен быть

Note: "Почему бы не использовать физические интерфейсы?":

Дело в том, что физические интерфейсы (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 - интерфейс, адрес коттрого используется как адрес отправителя VxLAN
  • end


В целом возможна и например вот такая конфигурация, но это сейчас не требуется: 

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 Имя интерфейса может быть произвольным, тип VxLAN
  • local 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

Зачем это нужно и какое отношение имеет к VxLAN


Отношение к VxLAN это имеет весьма отдаленное, но так как интерфейсы VxLAN нужно в большенстве случаев
каки-то образом соедининять с L2-интерфейсами (VxLAN это все таки больше всего про L2VPN), без понимания
Service Instance не обойтсь

Что такое service instance

Порще всего думать service instance как об новом специальном способе для создания обычных саб-интерфейсов.

Попробую пояснить это на примере.
Есть 2 конфигурации которые по сути могут делать практически одно и то же: 

interface gigabitethernet0/1
 service instance 5 Ethernet 
  encapsulation dot1q 20
  bridge-domain 20

interface gigabitethernet0/1.20
  encapsulation dot1q 20

По сути, оба интерфейса "привязаны" к VLAN20 но на ASR1000 нет bridge-group (вместо них - bridge-domain), те синтаксис добаволения в бриджи другой
Кроме того


  • Номер 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
с более широкими возможностями по выбору инкапсуляции.


типы инкапсуляции service-instance

Для порлноты картины приведу некоторые примеры по настройук инкапсуляции
другими словами - условий по которым выбрать трафик который попадет в service-instance Например VLAN50 

interface gigabitethernet0/1
 switchport mode trunk
 switchport trunk allowed vlan none
 service instance 1 Ethernet
  encapsulation dot1q 50

Q-in-Q
Внешний влан 50 (S-Vlan = 50) Внутрений влан 60 (С-Vlan = 60) 

interface gigabitethernet0/1
 switchport mode trunk
 switchport trunk allowed vlan none
 service instance 1 Ethernet
  encapsulation dot1q 50 second-dot1q 60

Тут важно отметить что траффик не модифицируется - это только условие, если этот трафик отправить в бридж то туда он попадет с тегами, одним или двумя, для модификации нужно указать отдельное правило

Просмотр информации по service-instance

Пример для: 

interface Port-channel1
 description dell-Po2-ports-24-25-25-27
 mtu 9216
 no ip address
 no negotiation auto
 load-balancing flow
 service instance 1 ethernet
  encapsulation dot1q 999 second-dot1q 257
 !

show ethernet service instance id 1 interface po 1 detail
Service Instance ID: 1
Service Instance Type: Static
Associated Interface: Port-channel1
Associated EVC:
Port-channel load-balance interface: None
L2protocol drop
CE-Vlans:
Encapsulation: dot1q 999 vlan protocol type 0x8100 second-dot1q 257 vlan protocol type 0x8100
Interface Dot1q Tunnel Ethertype: 0x8100
State: Up
EFP Statistics:
   Pkts In   Bytes In   Pkts Out  Bytes Out
        10       3600          0          0
EFP Microblocks:
****************
Microblock type: Bridge-domain
Bridge-domain: 255

Microblock type: L2Mcast
L2 Multicast GID: 1

Microblock type: dhcp_snoop
L2 Multicast GID: 1

Добавдение в bridge-domain

bridge-domain 255
 member vni 8000
 member Port-channel1 service-instance 1


"Старый" синтаксис (пример ниже) не работает 

interface gigabitethernet0/1
 switchport mode trunk
 switchport trunk allowed vlan none
 service instance 1 Ethernet
  encapsulation dot1q 50 second-dot1q 60
  rewrite ingress tag pop 2 symmetric
  bridge-domain 400

ASR1001-lab(config-if-srv)#bridge-domain 255
% New configuration model is being used.
Please use member command under bridge-domain.

Модификация трафика

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

interface Port-channel1
 description dell-Po2-ports-24-25-25-27
 mtu 9216
 no ip address
 no negotiation auto
 load-balancing flow
 service instance 1 ethernet
  encapsulation dot1q 999 second-dot1q 257
 !
end

приведет к тому что в бридж-ждомен попадет трафик с 2 тегами 

20:21:58.626285 0c:80:63:21:c3:45 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 360: vlan 999, p 0, ethertype 802.1Q (0x8100), vlan 257, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 0c:80:63:21:c3:45, length 310
Note: "Как ты отдампал трафик?":

Для того что бы это увидеть я пробросил через VxLAN трафик на линукс. Но об этом подробнее ниеже

Для того что бы получить трафик без тегов используется команда 

  rewrite ingress tag pop 2 symmetric

Назначение более-менее очевидно

  • rewrite ingress применять к входящиму трафику
  • tag обрабаьывать тэги
  • pop 2 не знаю как на русском это называется - отбросить? выбросить? 2 тега (2 потому что у нас в примере трафик с двойным теггированием)
  • symmetric - симетрично создать правило для обратного траффика

После чего на бридже будет трафик уже без тегов
Возможности модийикации значительно более широкие, но я пока не тестировал эту фичу (Судя по всему можно менять теги на другие, 2 тега на один или наоборот)

Ссылки


Ethernet Virtual Connections (EVCs).


EVPN

https://bitworks.software/2018-10-24-vxlan-bgp-evpn.html https://www.cisco.com/c/en/us/support/docs/lan-switching/integrated-routing-bridging-irb/200650-Understanding-Bridge-Virtual-Interface.html

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-16/ce-xe-16-book/evpn-vxlan-l3.html https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-16/ce-xe-16-book/evpn-vxlan-l3.html https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-16/ce-xe-16-book/evpn-vxlan-l3.html

https://protocoholic.com/2019/09/19/cisco-mpls-vpn-configuration-example-and-explanation/ https://protocoholic.com/2018/05/06/asr1000-vxlan-unicast-mode-configuration-and-verification/

Источник — https://noname.com.ua/mediawiki/index.php?title=Cisco_ASR1001_VxLAN&oldid=13729