Skip to main content

EVPN

Ethernet VPN är en L2VPN teknik som ska lösa de brister som finns i VPLS. Information om MAC-adresser transporteras via en egen BGP AFI.

EVPN inkluderar Ethernet over MPLS och Ethernet over VXLAN. Den sistnämnda är populär i nutida datacenterimplementationer. Jag skriver om EVPN med VXLAN här.

En variant av EVPN som finns är PBB-EVPN (provider backbone).

EVPN med VXLAN

BGP är kontrollplan och VXLAN är dataplan. RFC 7348, RFC 7432 & RFC 8365. MAC eller MAC och IP enkapsuleras i UDP 4789. Trafik enkapsuleras och de-enkapsuleras av VTEP:ar.

Begrepp

  • BUM - Broadcast, multicast eller unknown unicast.
  • EVI - Ethernet VPN Identifier.
  • ES - Ethernet Segment. 
  • ESI - Ethernet Segment Identifier. Varje ES identifieras via en ESI. 10 bytes stort. 
  • I-SID - Instance Service Identifier. En identifierar som informerar en router hur L2-paketet från kunden ska mappas. 24 bytes stort värde. 
  • VNI - Virtual Network Instance. En logiskt nätverksinstans som hanterar L2 eller L3 tjänster och definierar en L2 broadcastdomän
  • VNID - Virtual Network Identifier. 24 bitar stort segment ID, tillåter upp till 16 miljoner segment. VLAN mappas till VNID
  • VTEP - Virtual tunnel endpoint. Routrar/switchar. Är i verkligheten i en loopbackadress.
  • NVE  - Network Virtualization Edge. Enhet som implementerar L2 och/eller L3 virtualisering

VXLAN

VXLAN är en teknik där Virtual Network Identifiers (VNID) ersätter identifieringsfunktionen för ett segment när paket transporteras. Den rollen har VLAN i klassiska Ethernetnät. En VNID är 24 bitar stort vilket tillåter upp till 16 miljoner segment i en domän vilket är en stor skillnad mot maxantalet 4096 i klassiska Ethernetnät.. VLAN används fortsatt för lokal kommunikation på en switch. VNID mappas mot VLAN i konfigurationen på en switch vilket gör att VLAN ID:t enbart är relevant lokalt på switchen. Se exempekonfiguration där två olika VLAN på två switchar med samma VNID kommer att kunna kommunicera över L2:

feature vn-segment
feature nv overlay
feature vn-segment-vlan-based

! Löv 1
vlan 10
 vn-segment 301010

! Löv 2
vlan 20
 vn-segment 301010

Underlay

I EVPN (och andra VPN-nät såsom MPLS) används Underlay och Overlay.  Underlay används för att skapa routinggrannskap mellan switchar i EVPN-domänen. Overlay är där den faktiska trafiken går. I Overlay går trafiken i olika Tenants, det vill säga i olika VRF:er. Paket som ska transporteras enkapsuleras med en VXLAN header och en extra IP header. Den extra IP headern innehåller source och destinations IP-adresser som finns i underlay:

image.png

IS-IS, OSPF, iBGP eller eBGP används för att skapa routinggrannskap i underlay. Oavsett om man peerar över IPv4 eller IPv6 kan trafik över båda protokoll skyfflas i overlay då de enkapsuleras med IP-adresserna som används i underlay. OSPF är nog det vanligaste protokollet, i exempel nedanför har jag valt att använda IS-IS då det är det mest resurseffektiva protokollet.

Adresserna som används som source och destination mellan switchar i underlay är ett (eller två) loopback interface som kallas för VTEP, virtual tunnel endpoint. Själva switchen är inte en VTEP, det är loopback interfacet som är det, men folk kallar ofta själva switchen för en VTEP. Best practice är att man har ett loopback interface för router ID, ett loopback interface för VTEP och vid behov ett extra loopback interface för Split Loopbacks om det används (se mer information i sektionen om Split Loopbacks). 

Man behöver bara annonsera loopbacks/VTEPs in i underlay-protokollet. Det går lätt att åstakomma med OSPFs Prefix Suppression eller IS-IS advertise passive only. Det går att de faktiska länkarna mellan switchar (mellan löv och spines) är onumrerade (ip unnumbered). Om man använder multicast för hantering av BUM-trafik måste PIM-feature vara aktiverad och konfigurerad.

feature bfd
feature isis
feature pim

key chain ISIS-PASSWORD
 key 0
  key-string SYKE

router isis ISIS
 bfd
 net 49.0001.0000.0000.000x.00
 is-type level-2
 log-adjacency-changes
 authentication-type md5 level-2
 authentication key-chain ISIS-PASSWORD level-2
 address-family ipv4 unicast
  advertise passive-only

interface loopback 0
 desc ROUTER-ID
 ip address 198.18.0.x/32
 ip router isis ISIS
 isis passive-interface level-2

interface loopback 1
 description VTEP
 ip address 198.18.2.x/32
 ip router isis ISIS
 isis passive-interface level-2
 ip pim sparse-mode

interface eth1/1
 ip unnumbered loopback 0
 description spine-1 <-> leaf-1
 no shutdown
 ip router isis ISIS
 isis bfd
 isis network point-to-point
 isis circuit-type level-2
 medium p2p
 isis authentication-type md5
 isis authentication key-chain ISIS-PASSWORD
 mtu 9216
 ip pim sparse-mode

! Nedan konfigureras på både löv-switchar och spine-switchar
ip pim rp-address 198.18.2.x group-list 224.0.0.0/4
ip pim rp-address 198.18.2.y group-list 224.0.0.0/4

När underlay routing är etablerad så ska man etablera BGP peering. Detta då kontrollplansinformation om var rötter och hoströtter finns utbyts via BGP i adressfamiljen EVPN (adressfamilj 70). Spines ska vara BGP route-reflektorer, alltså har spines peering-sessioner med samtliga anslutna löv och löv peerar enbart med spines.

! Spinekonfiguration

router bgp 65000
 router-id 198.18.0.0
 log-neighbor-changes
 template peer BGP-TEMPLATE-LEAFS
  remote-as 65000
  update-source loopback 0
  password SYKESYKE
 address-family l2vpn evpn
  send-community extended
  route-reflector-client
 neighbor 198.18.0.1
  inherit peer BGP-TEMPLATE-LEAFS
 neighbor 198.18.0.2
  inherit peer BGP-TEMPLATE-LEAFS

! Lövkonfiguration

router bgp 65000
 router-id 198.18.0.x
 log-neighbor-changes
 template peer BGP-TEMPLATE-SPINES
  remote-as 65000
  update-source loopback 0
  password SYKESYKE
 address-family l2vpn evpn
  send-community both
 neighbor 198.18.0.0
  inherit peer BGP-TEMPLATE-SPINES

Nu har man en fungerande underlay. Det finns säkert optimeringar man kan utföra som jag inte har med här (än).

Overlay

För att få L2-kommunikation att fungera behövs inte all funktion nedanför, men man vill ju routa också så jag tar med samtlig konfiguration.

Har man ännu inte mappat VLAN mot VNI:er så är det hög tid att göra det. Portar mot slututrustning fungerar precis som i klassiskt Ethernetnät, trunkar mot enheter som kan tagga VLAN och otaggat/accessportar mot de som inte kan eller ska tagga själva.

vlan 10
 vn-segment 301010

interface eth 1/9
 desc PC VRF A VN 301010
 no shutdown
 switchport
 switchport mode access
 switchport access vlan 10

När SVI VLAN 10 skapas senare så vill man att det ska kunna routas. Då måste det tilldelas en VRF. Den här VRF:en behöver tilldelas ett VNI (och i slutändan därmed ett VLAN) som används för L3-kommunikation, alltså L3VNI:et. Det här L3VNI:et mappas alltså till ett VLAN som också ska ha ett SVI. SVI:et ska inte ha en IP-adress men ska ha kommandot ip forward. Det kallas ibland för Core Facing VLAN. 

vrf context VRF-A
 vni 202020
 rd auto
 address-family ipv4 unicast
  route-target both auto
  route-target both auto evpn
 address-family ipv6 unicast
  route-target both auto
  route-target both auto evpn

vlan 2500
 vn-segment 202020
 
interface vlan 2500
 no shutdown
 mtu 9216
 vrf member VRF-A
 ip forward

VNI:et är unikt per tenant. Därför behövs alltså ett VNI, ett VLAN och ett SVI per tenant för att kunna routa trafik inom tenanten.
RD och RT skapas med fördel automagiskt. Det finns mig veterligen ingen bra anledning att sköta den hanteringen manuellt i EVPN.

Ett NVE (Network Virtualization Edge) interface måste skapas. Hänvisning ska ske till VTEP-interface (loopback) för enkapsulering och de-enkapsulering av trafik. Vilket kontrollplansprotokoll som skall användas konfigureras här. I NVE interfacet måste samtliga VNI:er som används populeras. De som används som L3VNIer måste specifiseras. Man konfigurerar här vilken multicastgrupp som ska användas för hantering av BUM-trafik, om man använder multicast för hantering av BUM.

Det går att konfigurera ARP suppression globalt eller per-VNI, användning av ARP-suppression är rekommenderat. Observera att det kräver TCAM-carving. 

Samtliga VNI:er måste läggas till under EVPN-konfigurationsläge.

interface nve1  
 no shutdown
 source-interface loopback1
 host-reachability protocol bgp
 global suppress-arp 
 member vni 202020 associate-vrf
 member vni 301010
  mcast-group 239.0.0.1
  suppress-arp disable

ERROR: Please configure TCAM region for Ingress ARP-Ether ACL before configuring ARP supression.
hardware access-list tcam region arp-ether size double-wide 

! tcam-size —TCAM size. The size has to be a multiple of 256. If the size is more than 256, it has to be a multiple of 512. 
! Configuring the hardware access-list tcam region arp-ether size double-wide command is not required for Cisco Nexus 9200, 9300-EX, and  9300-FX/FX2/FX3 and 9300-GX platform switches.


evpn
 vni 301010 l2
   rd auto
   route-target both auto

Nu är det dags att till sist skapa SVI:et som enheter kommer ha som next-hop/default gateway. De ska vara mappade till det lokala VLAN-ID:t, ej VNID (vilket inte är möjligt ändå). Men innan det behöver man specifisera en MAC-adress för Distributed Anycast Gateway (DAG). Detta då SVI:erna kommer att finnas på flera, i många fall samtliga, löv behöver de dela MAC-adress.

fabric forwarding anycast-gateway-mac abba.cafe.1337

interface vlan 10
 no shutdown
 mtu 1500
 vrf member VRF-A
 ip address 10.10.10.1/24
 fabric forwarding mode anycast-gateway
 no ip redirects

Typ 2 rötterna propageras redan i nätet. Men vi vill även ha typ 5 då vi har ett SVI. Detta kan man enkelt lösa genom att redistribuera connected i adressfamiljen för respektive VRF i BGP:

 route-map REDISTRIBUTE_CONNECTED permit 10
 
router bgp 65000
 vrf VRF-A
  address-family ipv4 unicast
   redistribute direct route-map REDISTRIBUTE_CONNECTED
   maximum-paths ibgp 2
  address-family ipv6 unicast
   redistribute direct route-map REDISTRIBUTE_CONNECTED
   maximum-paths ibgp 2

Nu bör L3-forwarding och L2-forwarding inom en EVPN-domän att fungera.

För att få kommunikation med omvärlden, eller en annan routingdomän, behöver en av löven axla rollen som border-löv. I större när har man dedikerade löv för detta men det går bra att kombinera med ett löv som har hostar anslutna till sig. Ett länknät behövs per VRF. Önskvärt är att BGP används, men det går att använda ett annat protokoll och sedan redistribuera rötter åt båda hållen. Ej rekommenderat. Peeringen sker över subinterface som är tilldelade respektive VRF. Rekommenderat är att inte annonsera ut hoströtter den här vägen utan att använda sig av filtrering så att inga /31or (och /128or) annonseras.

ip prefix-list OUTSIDE_IN permit 0.0.0.0/0
ip prefix-list INSIDE_OUT permit 0.0.0.0/0 ge 8 le 31
 
route-map OUTSIDE_IN permit 10
 match ip address prefix-list OUTSIDE_IN

route-map INSIDE_OUT permit 10
 match ip address prefix-list INSIDE_OUT

interface eth 1/1
 no shutdown
 description OUTSIDE
 mtu 9216

interface eth1/1.1500
 no shut
 encapsulation dot1q 1500
 description VLAN 1500, eBGP VRF-A till utsida
 mtu 9216
 vrf member VRF-A
 ip address 10.200.201.11/29

router bgp 65000
 vrf VRF-A
  neighbor 10.200.201.9
   remote-as 665
   password outside
   update-source ethernet 1/1.1500
   address-family ipv4 unicast
    route-map OUTSIDE_IN in
    route-map INSIDE_OUT out

BGP rötter / EVPN Route-Types

Ett antal typer av BGP rötter används i EVPN AFI. 

Route typ
 Beskrivning
0. Reserverad
1. Ethernet active discovery (AD) route
 Används för att signalera tillbakadragande av MAC-adresser, aliasing och split-horizon etiketter.
2. MAC/IP advertisement route
 Innehåller MAC-adresser med EVPN ESI:er och MPLS etiketter. Måste innehålla en MAC-adress men kan innehålla IP-adress.
3. Inclusive multicast route
 Innehåller attributer för att representera ingress replication.
4. Ethernet Segment (ES) route
5. IP Prefix Route
 En route för ett helt nät. 
6. Selective Multicast Ethernet Tag Route
7. IGMP Join Synch Route
8. IGMP Leave Synch Route
9. Per-Region I-PMSI A-D route
10. S-PMSI A-D route
11. Leaf A-D route
12-255. Unassigned

Typ 2

En typ 2 innehåller information tillhörande en host. En route typ 2 måste innehålla:

  • MAC Address (/48)
  • MPLS Label1 (L2VNI)
  • Route Target for MAC-VRF 

Den kan innehålla:

  • IP Address (/32 eller /128)
  • MPLS Label2 (L3VNI)
  • Route Target för IP-VRF
  • Router MAC

 NVE lär sig IP-attribut genom ARP eller ND. Typ 2 importeras i en viss VRF/MAC-VRF. 

Ex. om VNI är 551337 används för L2-segmentet kan route-target för L2/MACVRF se ut enligt 65500:551337. Om L3VNI 31337 används kan route-target för IP-VRF/L3 att se ut enligt 65500:31337. 

Typ 5

En route typ 5 måste innehålla:

  • IP Prefix
  • MPLS Label (L3VNI)
  • Route Target för IP VRF
  • Router MAC

Den kan även innehålla Gateway-IP. NVE lär sig IP-attribut genom redistribuering eller routing-protokol.

Symmetric/asymmetric IRB

När ett paket transporteras mellan två VXLAN/EVPN routrar så märks paketet med ett VNID (Virtual Network Identifier). Beroende på vilken leverantör (och kanske konfiguration?) så används antingen symmetrisk eller asymmetrisk IRB. 

Med asymmetrisk IRB så används taggas det routade paketet med VNID:t som används för det lokala segmentet på routern som paketet routas till. För att det ska fungera måste VNID:t finnas definierat på både den lokalswitchen och fjärrswitchen. I stora nät där det kan finnas enormt många VNI:er så skalar det här dåligt.

Med symmetrisk IRB så används samma, utpekade, VNI för att tagga paketen. I nve-interface konfigurationen pekas VNI ut. Kallas för transit L3 VNI. En transit L3 VNI används per tenant (VRF). 

BGP NLRI innehåller route-target, ex. 65001:50000, där den andra delen (50000) är vilket VNI som ska användas för enkapsulering av paketet. 

Cisco NXOS använder sig av symmetrisk IRB. Om ett paket routas mellan olika nät, ex. från 192.168.1.20/24 till 172.16.10.20/24, kommer L3VNI att användas för att tagga VXLAN-paketen, alltså transit L3 VNIn som är konfigurerad för tenaten. Om ett paket brygas inom samma nät, från 192.168.1.10/24 till 192.168.1.20/24, kommer L2VNI:n att användas för att tagga paketen. L2VNI:n har i konfigurationen kopplats ihop med ett lokalt VLAN.

Ingress replication

Används ingress replication för att transportera BUM-trafik (istället för multicast) så används typ 3 rötter för att dessa. Grannar går att se med show nve vni ingress-replication.

Ingress replication-grannar konfigureras statiskt. Se exempel (NXOS):

interface nve1
  no shutdown
  source-interface loopback1
  member vni 1000
    ingress-replication protocol static
      peer-ip 203.0.113.2
      peer-ip 203.0.113.3
      peer-ip 203.0.113.4

ARP Suppression

ARP Suppression används för att minska ARP-trafiken inom en fabric. Närmaste VTEP till sluthosten blir proxy för samtliga ARP-frågor. Aktiveras per L2VNI. Verifiering med show ip arp suppression-cache { detail }.

Exempelkonfiguration (NXOS):

interface nve1  
 no shutdown
 source-interface loopback1
 host-reachability protocol bgp
 member vni 202020 associate-vrf
 member vni 301010
  mcast-group 239.0.0.1
  suppress-arp

Switchen kommer då att snoopa efter ARP-frames och bygga Typ 2-rötter som populeras till grannar. Om en ARP-fråga kommer till en switch skickas den inte vidare till hosten utan switchen svarar direkt på frågan med sluthostens MAC-address. Alltså fungerar det inte som proxy-arp där switchen skulle svara med sin egen mac-address.

TCAM carving krävs för att ARP Suppression ska fungera.

IGMP Snooping

Användning av IGMP Snooping i EVPN-domänen är önskvärt. Det stöds enbart om BGP används som kontrollprotokoll, ej flood and learn. Aktiveras med ip igmp snooping vxlan.  Det går även att konfigurera ip igmp snooping disable-nve-static-router-port vilket gör att trafik i overlay enbart skickas till intressenter, alltså de som redan har skickat en IGMP Membership Report. Default är att trafiken repliceras.

DHCP Relay

Finns DHCP i nätet måste DHCP Relay konfigurereas. Då DHCP-frågan kan komma från olika löv och svarstrafiken måste hitta rätt måste en bra source för frågorna konfigureras, då DAG används kan inte den adressen användas för att proxa-trafiken. Man kan välja vilken VRF som ska användas för att agera DHCP-relay oavsett vilken VRF som frågorna kommer ifrån. Det kanske inte är önskvärt att exempelvis använda VTEP-adressen som source för denna då man isåfall måste routa ut från underlay.

För att det här ska fungera med ex. Infoblox DHCP-server vill man inte använda Ciscos egna implementation av DHCP option 82, utan industristandard suboption link-selection (sub-option 5) som sätter GiAddr-fältet i DHCP-frågan till loopbackens IP-nummer. 

feature dhcp

service dhcp
ip dhcp relay
ip dhcp relay information option
ip dhcp relay information option vpn
ipv6 dhcp relay

interface loopback 3
 vrf member VRF-A
 ip address 10.10.10.10/32

interface VlanlOOl
  ip dhcp relay address 1.3.3.7 use—vrf VRF-A
  ip dhcp relay source—interface loopback2

vPC i EVPN

Ett vPC par kommer att ha en egen VTEP-IP men även en sekondär VTEP-IP. Den sekondära är den delade VTEP-IPn. Se exempelkonfiguration:

interface loopback0
 description RID
 ip address 198.18.0.1/32

interface loopback1
 description VTEP
 ip address 198.18.1.254/32
 ip address 198.18.1.1/32 secondary

Annonsering av samma typ 2 rötter

Ofta kommer båda vPC-switchar att annonsera samma typ 2 rot i EVPN-adressfamiljen. De två olika rötterna kan särskiljas från varandra då Route Distinguisher blir olika per switch. Detta då RD byggs på router ID, vilket skiljer sig från varandra.

Annonsering av statiska rötter (typ 5)

Om en statisk route enbart annonseras av 1 vPC medlem och trafiken dyker upp på den andra vPC-switchen så kan trafiken per default inte skickas över till sin granne. Detta då peer-länken enbart hanterar L2. För att trafik ska fungera finns två val.

Det första är att skapa ett länknät per vrf mellan vPC switcharna som byter ut rötterna via BGP. Det skalar dåligt. Det andra alternativet är advertise-pip som beskrivs nedan.

Ett tredje alternativ är att dubbelansluta så ingen orphan port är inblandad, men det är såklart inte alltid möjligt.

Advertise-pip & advertise virtual-rmac

I ett VPC-par så annonseras nätverken med en virtuell VTEP. Det kan orsaka blackholing om länken till destinationen på en av VPC-medlemmarna går ned. Då rötterna annonseras med den virtuella VTEPen kan båda VPC-medlemmarna ta emot trafiken.

För  att undvika blackholingen kan man använda sig av advertise-pip (primary IP). Då annonseras röttern med switcharna egna VTEP-adresser som next-hop och routen tas tillbaka om länken till destinationen går ned. Det konfigureras i BGP adressfamiljen. Nackdelen är nu att NVE peers ökar, det blir totalt 3 peerings till VPC-par (1 för VPC1, 1 för VPC2 och en för virtuella IPn).

Vill man fortsätta annonsera typ 2 rötter (host) med virtuella VTEP-adressen måste advertise virtual-rmac läggas till i konfigurationen för nve interfacet. Best practice är att man konfigurerar båda samtidigt, alltså enligt nedan.

router bgp 1337
 address-family l2vpn evpn
  advertise-pip

interface nve 1
 advertise virtual-rmac

Fabric Peering

Med Fabric Peering så skapar man en virtuell peer-länk över länkarna som går till spines. Skapas över L3. VTEP IP-adressen ska inte användas för peeringen, ta ut en ny loopback i underlay för fabric peering. CFS (Cisco Fabric Services) trafik bör prioriteras i forwardingen. En port-kanal måste skapas för att fabric peering ska fungera men inga interface ska tilldelas port-kanalen. port-type fabric måste läggas till på upplänkarna mot spines.

Peer Keepalive-länken behövs fortfarande. Kan vara out-of-band eller in-band.

Konfiguration:

vpc domain 1
 peer-switch
 peer-keepalive 10.10.10.82 source 10.10.10.81
 virtual peer-link destination 10.44.0.4 source 10.44.0.3 dscp 56
 delay restore 150
 peer-gateway
 auto-recovery reload-delay 360
 ipv6 nd synchronize
 ip arp synchronize

interface port-channel1337
 description vpc-peer-link
 switchport
 switchport mode trunk
 spanning-tree port type network
 vpc peer-link

interface Ethernet1/49
 mtu 9216
 port-type fabric

BUM-traffik i vPC

Med ingress replication kommer BUM-trafiken att skickas till den delade anycast VTEP-adressen. ip arp synchronize och ipv6 nd synchronize bör vara konfigurerat i vPC-domänen för att snabbt sprida informationen.

Används multicast så skickas även trafiken till anycastadressen. Enbart en av vPC medlemmarna är vald som en decapsulation nod. Den eper med lägst cost till RP blir vald till decapsulation nod. Är det samma cost till RP så blir vPC Primary vald.

Vid initiering av BUM-trafik (arp request, neighbor discovery) från vPC-klustret så kommer mottagande medlem att skicka ut multicastfrågan mot RP men även till vPC-granne, även om trafiken först kommer in till secondary vPC medlem. Svarstrafiken kommer att komma till den vPC-medlem som är decapsulation node

vPC Infrastructure VLANs

vPC Infrastructure VLANs används när en vPC switch upplänkar mot spines går ned. Det används som Backup Routing Path och ska finnas i den globala VRFen. Infrastructure VLAN:et ska finnas tillåtet på vPC Peer-link. Ett routinggrannskap måste finnas över vPC Infrastructure VLAN:et.

Konfiguration:

vlan 1337
 name VPC_INFRASTRUCTURE_VLAN

interface Vlan1337
 ip router isis ISIS


system nve infra-vlans 1337

vPC Delay Restore & vPC Orphan Port Delay Restore

vPC Delay Restore är en teknik som gör att vid uppstart kommer ej vPC-portar nedströms upp förrän underlay och overlay har konvergerats. Best practice är att vPC Delay Restore är igång. Är igång per default med 150 sekunder. Vill man ändra värdet gör man det i vpc-domänkonfigurationsläge med delay restore <1-3600>.

vPC Oprthan Port Delay Restore utför samma funktion som ovan fast för Orphan Ports. Default är samma som vPC delay restore time. Kan justeras i vpc-domänkonfigurationsläge med delay restore orphan-port 0-300.

SVI Delay Restore

Är per default 10 sekunder. Modifieras i vpc-domänkonfigurationsläge med delay restore interface-vlan 1-3600.

NVE Hold-Down timer

Under uppstart vill man inte annonsera sina nät och hostar till resten av EVPN-fabric innan länkar och SVI är redo. Därför ska NVE Hold-Down timern komma sist.  Per default är tiden 180 sekunder, vilket är högst om man inte modifierar övriga räknare. Kan ställas in i vpc-domänkonfigurationsläge med source-interface hold-down <1-1500>.

Split Loopbacks (Orphan ports, fabric-ready time)

Används för att minska nedtiden för orphan ports. Finns i NXOS 10.4.1 och senare. Olika loopbacks används för anycast VTEP och PIP. För typ 2 orphan rötter och typ 5 rötter minskas konvergeringstiden. Konfigureras i vpc-domänkonfigurationsläge med fabric-ready time <1-1200>. Default är tre fjärdedelar av source-interface hold-down-timer, alltså 135 sekunder.

Fullständig konfiguration ser ut såhär:

interface loopback1
 description VTEP
 ip address 10.200.200.254/32

interface loopback2
 description Anycast VTEP Split Loopback
 ip address 10.200.200.123/32

interface nve1
 source-interface loopback1 anycast loopback2

VXLAN vPC Consistency Checking

Följande ska matcha mellan vPC-medlemmarna:

  • VLAN-till-VNI mapping
  • Samma SVIer ska finnas på switcharna
  • Samma VNI måste användas för samma transportmetod av BUM-trafik
  • När VNI använder multicast replication av BUM måste båda VTEPar använda smama multicastgrupp för specifiserad VNI

Om vPC VTEP consistency checken misslyckas kommer NVE loopback interface att bli admin shut på sekondära vPC-switchen.

Migrering till EVPN

Förberedelser

Innan migrering från traditionell Ethernet miljö till EVPN/VXLAN vill man byta MAC-adress på SVI:er till den mac-adress som kommer användas av distributed anycast gateway (DAG). Detta så att trafik ska flöda sömlöst när DAG tar över L3-ansvaret. 

Är den gamla miljön Cisco Nexus med HSRP så byter man MAC på standby enheten och sen preemptar så den tar över då ett GARP-meddelande skickas vid preempt. Exempelkonf:

interface Vlan1337
 hsrp 1
  mac-address dead.cafe.beef
  priority 130
  preempt

Byt sedan på f.d. primär efteråt. Har man en IOS/Catalyst-miljö, ex. VSS, så byt mac-adress på SVI:er med kommandot mac-address cafe.cafe.cafe.

Default Gateway Coexistence of HSRP and Anycast Gateway

Man kan använda sig av den här tekniken för att ha SVI:erna aktiva i EVPN-miljön och i klassiska miljön samtidigt. Funktionen innebär mer efffektiv routing och mindre störande migreringar. Tekniken implementeras helt i EVPN-miljön. Ciscos information om detta finns här.

Följande måste konfigureras för att det ska fungera:

  • MAC-adress på DAG och SVI måste matcha (se förberedelser ovan)
  • TCAL carving behövs utföras för Ingress PACL. Verifiera med show hardware access-list tcam region, konfigurera med hardware access-list tcam region ing-ifacl 512, starta om
  • L2-trunk mellan nya miljön och gamla med port-type external konfigurerat på trunken
  • Unik BIA (Burnt In Address) IPv4&IPv6 måste konfigureras på samtliga SVIer på border-löv (används för att skicka proxy ARP/ND)
  • Om border-lövet är i ett vPC par måste peer-gateway och layer3 peer-router vara konfigurerat 

Exempelkonfiguration:


interface port-channel 40
 port-type external

interface vlan 1100
 vrf member vrf50
 ip address 192.168.1.1/24
 ip address 192.168.1.10/24 secondary use-bia
 ipv6 address 2001:DB8:1::1/64
 ipv6 address 2001:DB8:1::10/64 use-bia

Back to top