Свързване на немаркиран достъпен порт с правилния EVPN VNI

Немаркирана рамка от хост се класифицира от достъпния порт и след това се пренася от VTEP като VNI. Проверете отделно входящия, изходящия трафик и модела на услугата.

Обикновен Ethernet хост изпраща немаркирани рамки и EVPN фабриката все пак трябва да ги пренесе в правилната услуга за наемател. Достъпният порт класифицира рамката в локален сегмент, VTEP съпоставя този сегмент на VNI, а отдалеченото прикачване представя рамката така, както го очаква нейният хост. VLAN и VNI обозначават различни части от този път и не е нужно да споделят номер. Изпълнете runbook-а по-долу по ред, защото грешка на която и да е стъпка дава същия симптом: хост, който изпраща и не получава нищо.

Проследете една рамка през фабриката

За проста услуга, базирана на VLAN, примерен път изглежда така:

Host A: untagged frame
  to access port: local VLAN 110
  to VTEP A: L2VNI 50110
  to VTEP B: corresponding local service
  to access port: untagged frame to Host B

Номерата на VLAN и VNI са примери, не правило. Локалният VLAN е класификация на входа, която съществува на един комутатор; L2VNI е идентификаторът на overlay услугата, който и двата VTEP разбират. Спецификацията за overlay RFC 8365 държи идентификатора на услугата отделно от начина, по който е прикачен даден хост, и назовава три форми: базирана на VLAN, групирана и съобразена с VLAN.

Конфигурирайте класификацията на входа

Хостът има адрес и не достига до нищо, докато самият порт се вижда. Решете в какъв режим на прикачване действително е портът — достъпен порт, който пренася немаркирани рамки, или trunk с native VLAN — и задайте точно този изрично. Немаркирана рамка все пак напуска порта в рамките на именуван локален сегмент и този сегмент е решение, а не страничен ефект на платформата. Отворете текущата конфигурация на порта и прочетете класификацията, която той действително има, вместо да се доверявате на настройка по подразбиране на производителя, която никога не сте задавали.

На типичен комутатор последователността е смяна на режима и присвояване на достъпен VLAN, последвани от проверка, че портът наистина е активен и в това състояние. Ако портът е trunk, native VLAN се грижи за немаркираните рамки и това е друга конфигурация с други режими на отказ. Запишете както режима, така и VLAN, преди да продължите.

show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan brief

Конфигурирайте VTEP и съпоставянето на VNI

VTEP добавя VXLAN инкапсулацията и VNI. Хостът не генерира този заглавен блок и не е нужно да знае, че услугата съществува.

Съпоставете локалния VLAN с L2VNI чрез поддържаната от платформата форма на командата и поддържайте това съпоставяне еднакво в двата края на услугата. L2VNI на наемател и L3VNI, използван за маршрутизация между подмрежи, са различни обекти и смесването на номерата им чупи маршрутизацията, без да засяга пътя L2; и помнете, че работещ underlay маршрут към отдалечения VTEP принадлежи на още един слой от настройката.

Ако съпоставянето е грешно, рамката все пак влиза във фабриката и просто каца в грешната услуга. Затова проверката е проверка на услугата, а не проверка на връзката.

Конфигурирайте представянето на изхода

В отдалечения край получената услуга трябва да се превърне обратно в това, което хостът очаква: чист Ethernet на достъпен порт, конкретен таг на trunk, който контролирате, и обработка на вътрешния таг, съответстваща на избрания модел на услугата. Проверете списъка с разрешени VLAN на trunk-а, преди да обвините overlay-а, защото таг, който изходящият trunk не разрешава, се изхвърля, след като overlay-ът вече е свършил своята работа. Потвърдете, че отдалеченият хост очаква представянето, което получава, а не това, което е предполагала вашата диаграма.

Дали вътрешен таг оцелява е свойство на избрания от вас модел на услугата, затова нито една статия не може да обещае в общия случай премахване или запазване. Дизайн, който предполага едно поведение, и платформа, която реализира другото, ще преминат тест на връзката и ще се провалят в приложението.

Четете заедно локалното изучаване на MAC, маршрута на EVPN услугата и съпоставянето на отдалеченото прикачване и задвижвайте откриването на съседи, от което приложението се нуждае, вместо само ping. MAC адрес, научен в различен bridge домейн, може да е напълно валиден там и въпреки това да сочи към грешната услуга.

Проверете с една двойка хостове

Вдигнете една двойка хостове и докажете целия път, преди да добавите втора двойка. След това прочетете състоянието на двата VTEP и потвърдете, че същият идентификатор на услугата се появява в двата края.

show mac address-table vlan 110
show bgp l2vpn evpn
show nve peers

За всеки край запишете четири стойности: представяне на порта, локален сегмент, L2VNI и обратното представяне на изхода. Този запис позволява на следващия инженер да види защо хостът има проста немаркирана връзка, докато фабриката пренася услуга за наемател. Ако промяна се провали, върнете порта към предишния VLAN и тествайте същата двойка отново, така че откатът да е известно състояние, а не предположение.

Подобни статии