Cisco EVPN
Ethernet VPN (RFC 8365) är en modernare variant än VPLS för att tillhandahålla Ethernet multipoint services över IP (VXLAN) eller MPLS (RFC 7432) utan att behöva en central controller. EVPN är en adressfamilj i BGP som används för peer discovery och för att distribuera lokala MAC-adresser och MAC/IP bindings till andra tunnel endpoints. Man använder både L2 och L3 forwarding information och det fungerar ihop med externa IP-prefix. Next-hop i EVPN-uppdateringarna är antingen egress Label Switch Router eller VXLAN Tunnel Endpoint. EVPN skalar bra och har bl.a. features för att hålla koll på hostar som flyttar mellan datacenter (sekvensnummer-community i annonseringarna) och kan då konvergera snabbt. Ett EVPN-nätverk kan göra både bridging och routing och har inbyggd support för multi-tenancy (VPN). DHCP Snooping supporteras inte på VXLAN VLAN.
EVPN är ett öppet protokoll så det finns interoperability med andra network vendors, se t.ex. Arista, Cumulus och Quagga EVPN.
Route types
- Ethernet Auto-Discovery Route
- MAC/IP Advertisement Route
- Inclusive Multicast Ethernet Tag Route
- Ethernet Segment Route
- IP Prefix Route
Type 5 Routes format
Encapsulation: | MPLS | VXLAN |
RT-5 Route: | IP Prefix | IP Prefix |
RD: | L3 RD | L3 RD |
IP Length: | prefix length | prefix length |
IP Address: | IP | IP |
Label: | BGP MPLS Label | L3VNI |
Ext Communities: | RT for IP-VRF | RT for IP-VRF, Tunnel Type VxLAN, Router MAC |
Contents
Underlay
Underlay routing kan göras med IGP, iBGP eller eBGP. Alla VTEP:s måste kunna nå varandra med jumbo frames. Alla hårdvaruplattformar har inte stöd för Head-end Replication (aka Ingress Replication) för att lösa tenant BUM så t.ex. med Nexus 5k måste man även köra PIM Bidir i underlay. Notera att IGP-annonsering av NVE loopback address efter boot default kommer att suppressas under 300 sekunder för att overlay ska hinna konvergera. Detta går att ställa in under interface nve 1.
Simpelt NX-OS exempel
feature ospf interface loopback0 description VTEP ip address 1.1.1.1/32 ip router ospf 1 area 0 interface Ethernet1/1 description Uplink no switchport medium p2p mtu 9216 ip address 10.0.2.2/30 no shutdown ip router ospf 1 area 0
Det går även köra upplänkarna IP unnumbered.
Overlay
EVPN-peering för DC VXLAN-overlay kan göras både med iBGP och eBGP, det är designen som avgör.
Konfig för leafs oavsett iBGP eller eBGP overlay.
feature bgp feature vn-segment-vlan-based feature nv overlay nv overlay evpn interface nve1 no shutdown host-reachability protocol bgp source-interface loopback0
IBGP
Den simplaste EVPN fabricen är IBGP overlay med IGP underlay.
router bgp 65000 address-family l2vpn evpn neighbor 2.2.2.2 remote-as 65000 update-source loopback0 address-family l2vpn evpn send-community send-community extended
Route Reflector
Precis som med övriga adressfamiljer kan man med hjälp av route reflector öka skalbarhet och förenkla konfigurationen. Spine-switchar kan t.ex. stå för denna roll i en IBGP EVPN setup.
router bgp 65000 address-family l2vpn evpn neighbor 1.1.1.0/24 remote-as 65000 update-source loopback0 address-family l2vpn evpn send-community extended route-reflector-client
EBGP
Om man bygger sin fabric med EBGP EVPN så måste next-hop-unchanged konfas på spines peeringar mot leaf. Om man kör med autoderiverade RTs måste man skriva om dem innan de når leaf samt att spine switches inte har någon VRF-konfig så man måste slå på retain route-target.
route-map NH-Unchanged permit 10 set ip next-hop unchanged router bgp 65000 address-family l2vpn evpn retain route-target all neighbor 1.1.1.0/24 remote-as 65001 address-family l2vpn evpn route-map NH-Unchanged out rewrite-evpn-rt-asn
All leaf same ASN
Spine
router bgp 65000 neighbor 1.1.1.1 remote-as 65001 address-family l2vpn evpn disable-peer-as-check
Leaf
router bgp 65001 neighbor 2.2.2.2 remote-as 65000 address-family l2vpn evpn allowas-in
Verify Overlay
show nve int nve1 show nve peers detail show bgp l2vpn evpn summary show nve internal platform interface nve 1 detail
Bridging
På varje leaf switch mappas local VLAN till ett VNI (VLAN-based mode).
vlan 100 vn-segment 10100 vlan 101 vn-segment 10101
HER mha EVPN route typ 3
interface nve1 member vni 10100 ingress-replication protocol bgp member vni 10101 ingress-replication protocol bgp
RD och RT för bridging. RT-import/export görs automatiskt utifrån ASN och VNI.
evpn vni 10100 l2 rd auto route-target import auto route-target export auto exit vni 10101 l2 rd auto route-target import auto route-target export auto exit
Verify
show nve vni show nve peers data-plane detail show l2route evpn mac-ip all show forwarding nve l3 peers show mac address-table show system internal l2fwder mac #Nexus 9000v
vPC
Om man kör vPC får man sätta upp sina VTEP-interface (loopback) med dubbla IP-adresser där secondary IP address används för all VXLAN-trafik. Secondary ska vara samma på både vPC-peers och det är så dom presenterar sig själva som en enda VTEP till remote NVE peers. CFS dubbelkollar att man har gjort rätt. Sista oktetten i loopbacks primära IP-adress används för att generera RMAC när man kör vPC. Varje vPC-peer har separata BGP-sessioner till spine. I övrigt måste de ha identisk konfiguration när det gäller VLAN, VNI och NVE (show vpc consistency-parameters vni).
interface loopback0 ip address 100.0.0.11/32 ip address 100.0.0.100/32 secondary
vPC Domain best practice när man kör EVPN.
vpc domain 1 peer-switch peer-keepalive destination 10.0.0.2 source 10.0.0.1 peer-gateway ipv6 nd synchronize ip arp synchronize
advertise-pip
Default annonseras alla Layer-3 routes med secondary IP address (VIP) på VTEP. Prefix routes och leaf switch generated routes synkas ej mellan vPC leaf switches. Om t.ex. vPC-switch och dennes peer har asymmetric external Layer-3 connections och vissa routes endast är nåbara via den ena eller om man ska agera DHCP Relay åt tenants så kan traffic blackholing uppstå med default beteendet. Man kan därför konfa att route type 5 routes ska annonseras med primary IP address så det blir next-hop för fabricen.
router bgp 65000 address-family l2vpn evpn advertise-pip
Backup routing
Om den ena vPC-peeren tappar sina upplänkar till spine och man inte har någon backup routing så uppstår traffic blackholing. Detta kan man motverka genom att bygga en backup-väg över peer-linken till den andra peeren.
vlan 99 interface vlan99 ip address 10.99.99.1/30 ip router ospf 1 area 0.0.0.0 ip pim sparse-mode
Nexus 5600
vpc nve peer-link-vlan 99
BD-oriented mode
I VLAN-based mode är VNI-to-VLAN mapping switch wide men om man lägger in bridge domains emellan så kan man uppnå att VNI-to-VLAN mapping endast är port wide. Dvs man kan använda samma 802.1Q tag på flera portar men de är mappade till olika VNI:er. Konfen ser lite annorlunda ut men både bridging och routing funkar.
Nexus 7k
feature vni feature-set fabric feature fabric forwarding vni 10000 system bridge-domain 100 bridge-domain 100 member vni 10000 encapsulation profile vni Tenant1-101 dot1q 101 vni 10000 interface e2/1 no switchport service instance 1 vni no shutdown encapsulation profile Tenant1-101 default interface Bdi 100 vrf member Tenant1 ip address 10.0.0.1/24
Routing
NX-OS gör endast symmetric vxlan routing, dvs EVPN-routes har både L2VNI och L3VNI. Man anger NVE overlay VLAN:s. Dessa ska ej användas som vanliga VLAN.
system vlan nve-overlay id 3001-3200
RT-import och export görs automatiskt utifrån ASN och VNI.
vrf context Tenant1 vni 30001 rd auto address-family ipv4 unicast route-target both auto route-target both auto evpn
Varje tenant VRF behöver ett VRF overlay VLAN och ett SVI för VXLAN routing.
interface nve1 member vni 30001 associate-vrf vlan 3001 vn-segment 30001 interface Vlan3001 no shutdown mtu 9216 vrf member Tenant1 ip forward ipv6 forward
Verify
show nve vrf show nve internal bgp rnh database vni 30001
Exempel, tenant routing table
routing-context vrf Tenant1 show ip route 10.1.0.10/32, ubest/mbest: 1/0 *via 100.64.0.11%default, [200/0], 00:02:44, bgp-65000, internal, tag 65000 (evpn) segid: 30001 tunnelid: 0xa000003 encap: VXLAN
Troubleshooting
show troubleshoot l3 ipv4 10.0.0.10 src-ip 10.0.0.20 vrf Tenant1
Anycast GW
Om man slår på anycast gateway feature för ett VNI så måste det enableas på alla VTEP:s där VNI finns.
fabric forwarding anycast-gateway-mac 0000.1111.2222 interface Vlan100 vrf member Tenant1 ip address 10.0.0.1/24 fabric forwarding mode anycast-gateway no shut
ARP Suppression
Man kan låta en lokal ARP-proxy hantera requests för att suppressa ARP flooding över VXLAN så mycket som möjligt. Notera att ARP Suppression inte jobbar med något IPv6-relaterat.
interface nve1 member vni 10100 suppress-arp member vni 10101 suppress-arp
show ip arp suppression-cache detail
OBS på vissa plattformar måste man karva TCAM för att kunna konfigurera arp-suppression. Här är ett exempel för Nexus 9000v.
show run all | inc "hardware access-list tcam region" hardware access-list tcam region span 0 hardware access-list tcam region racl 512 copy run start reload hardware access-list tcam region arp-ether 256 double-wide copy run start reload
External Connectivity
Prefix-based routing (Type-5 Routes) används primärt för destinations utanför DC. IP-VRF till IP-VRF görs enligt interface-less model dvs routsen har en RMAC attached.
router bgp 65000 address-family l2vpn evpn maximum-paths ibgp 4 vrf Tenant1 address-family ipv4 unicast advertise l2vpn evpn redistribute direct route-map ALLOW-ALL
Verify
show bgp ip unicast vrf Tenant1
Exempel på släppa ut en tenant (10.0.0.0/24) ifrån evpn-vxlan-fabricen. Vanlig OSPF pratas mellan border leaf och external device. På border leaf:
router ospf 100 vrf Tenant1 redistribute bgp 65000 route-map ALLOW-ANY router bgp 65000 vrf Tenant1 address-family ipv4 unicast advertise l2vpn evpn redistribute ospf 100 route-map ALLOW-ANY aggregate-address 10.0.0.0/24
DHCP Relay
VXLAN EVPN har stöd för DHCP relay-funktionalitet. I en multi-tenant-lösning används tre suboptions av Option 82.
- Sub-option 151 - Virtual Subnet Selection
- Sub-option 11 - Server ID Override
- Sub-option 5 - Link Selection
feature dhcp service dhcp ip dhcp relay ip dhcp relay information option ip dhcp relay information option vpn ipv6 dhcp relay
Om DHCP-server är nåbar i default-VRFen.
interface Vlan1001 description Tenant facing SVI ip dhcp relay address 100.0.1.10 use-vrf default
Om DHCP-server finns i tenant-VRF måste man skapa ett unikt tenant-loopback per VTEP eftersom det måste vara en unik IP-adress som source för de relayade DHCP-paketen för att servern ska kunna svara till rätt relay agent.
interface loopback11 vrf member Tenant1 ip address 11.11.11.11/32 interface Vlan1001 description Tenant facing SVI ip dhcp relay address 100.0.1.10 ip dhcp relay source-interface loopback11
Multicast
EVPN kan lösa IPv4 routed multicast för tenants (TRM). Man kör MVPN ovanpå vxlan-fabricen för att förhindra onödig multicast-forwardering, samma som i MPLS-nät fast utan PIM. Man använder ngMVPN, det behövs ingen RP och designated router är distribuerad (Anchor DR). Inga PIM- eller IGMP-paket skickas alltså över fabricen utan BGP gör jobbet. PIM ASM och PIM SSM funkar i overlay men inte PIM BiDir. Man har en multicastgrupp i underlay per vrf (coret måste vara multicast-baserat). L2 only mode finns också när man t.ex. inte har någon VRF. Med TRM så är inte advertise-pip och advertise virtual-rmac supporterat.
feature ngmvpn ip igmp snooping vxlan advertise evpn multicast ip multicast overlay-spt-only
Tenant
interface loopback 300 vrf member Tenant-TRM ip address 1.1.1.1/32 ip pim sparse-mode vrf context Tenant-TRM vni 30000 ip pim rp-address 1.1.1.1 group-list 224.0.0.0/4 ip pim ssm range 232.0.0.0/8 address-family ipv4 unicast route-target both auto route-target both auto mvpn route-target both auto evpn
IP 1.1.1.1 ska finnas på alla VTEPs samt att "ip pim sparse-mode" ska läggas på tenants L3SVI:er.
Verify
show fabric multicast vrf all show fabric multicast globals
VXLAN EVPN Multi-Site
Man kan bygga en multisite lösning genom att upprätta eBGP-sessioner mellan så kallade border gateways och låta dem skriva om next-hop i EVPN-uppdateringarna, dvs reoriginera EVPN-routes. VTEPs ser endast neighbors och border gateways i sin egen fabric. Alla externa routes har border gateway som next-hop och BGW gör data plane decapsulation och re-encapsulation. Det går alltså att sträcka L2 mellan siter men man får åtminstone protection och enforcement points i form av BGWs och storm-control. BGW-rollen går även att kombinera med vanlig VRF-Lite, t.ex. om det kommer in back-to-back VRF kopplingar för tenants.
Varje sites border gateways sätts upp som anycast (virtual IP), för lastdelning och redundans, och BGWs pratar VIP till VIP med varandra mellan siterna. Utöver VIP har varje BGW en PIP (man använder primary VTEP IP), den används för L2 BUM. Mellan siter är det endast ingress replication för BUM-transport men inom siterna kan det vara PIM ASM eller ingress replication. Det behöver heller inte matcha mellan siterna. BGWs blir BUM-DF per L2VNI, på så sätt distribueras trafiken. Election process görs och DF synkas med hjälp av Route Type 4 (Ethernet segment route) mellan BGWs inom siten. BGW har flera inbyggda split horizon regler för att kunna flooda till alla samtidigt som loopar undviks. Det finns även pseudo-BGW, dvs leaf utan spine. Då har man ingen internal site vtep neighbor. Det är t.ex. användbart vid migreringar in i en EVPN/VXLAN fabric.
evpn multisite border-gateway <id> interface loopback 100 description Anycast BGW IP interface nve 1 source-interface loopback 0 host-reachability protocol bgp multisite border-gateway interface loopback 100 member vni 200 #Every L2VNI that needs stretch multisite ingress-replication interface ethernet1/1 description DCI evpn multisite dci-tracking interface ethernet1/2 description Spine evpn multisite fabric-tracking router bgp 65000 address-family l2vpn evpn neighbor 10.0.0.2 remote-as 65001 peer-type fabric-external address-family l2vpn evpn rewrite-evpn-rt-asn
Tracking är mandatory annars reorigineras inga EVPN routes, det görs endast om det finns DCI/fabric links som är uppe. Man konfar heller inte next-hop-self, detta händer av sig själv eftersom EVPN fungerar så default.
show nve multisite show nve ethernet-segment show nve multisite dci-links show nve multisite fabric-links
För "show nve ethernet-segment" notera att L3VNI alltid står som aktiv på alla BGWs eftersom designated-forwarder election inte görs för dem.
Storm-control
evpn storm-control broadcast level 10
Overlay Stitching
Man kan binda ihop overlays med hjälp av EVPN, t.ex. VXLAN <-> MPLS VPN.
IOS-XE
vrf definition Tenant1 rd 125:101 address-family ipv4 route-target export 65000:30001 route-target import 65000:30001 route-target export 65000:30001 stitching route-target import 65000:30001 stitching exit-address-family bridge-domain 3001 member vni 30001 interface BDI3001 vrf forwarding Tenant1 ip address 169.254.0.1 255.255.255.0 encapsulation dot1Q 3001 no shut interface nve1 no ip address no shutdown source-interface Loopback0 host-reachability protocol bgp member vni 30001 vrf Tenant1 router bgp 65000 bgp log-neighbor-changes no bgp default ipv4-unicast no bgp default route-target filter neighbor 10.0.0.11 remote-as 65000 neighbor 10.0.0.11 update-source Loopback0 neighbor 10.0.0.250 remote-as 65000 neighbor 10.0.0.250 update-source Loopback0 address-family vpnv4 import l2vpn evpn re-originate neighbor 10.0.0.250 activate neighbor 10.0.0.250 send-community extended exit-address-family address-family l2vpn evpn import vpnv4 unicast re-originate neighbor 10.0.0.11 activate neighbor 10.0.0.11 send-community both exit-address-family
Detta autoskapas på ASR.
interface Tunnel0 ip unnumbered Loopback0 no ip redirects ip mtu 9216 tunnel source 10.0.0.25 tunnel mode udp multipoint tunnel src-port 4789
NXOS
vrf context Tenant1 vni 30001 rd auto address-family ipv4 unicast route-target both auto route-target both auto evpn router bgp 65000 neighbor 10.2.2.2 remote-as 65000 address-family vpnv4 unicast import l2vpn evpn reoriginate neighbor 10.10.10.201 remote-as 65000 address-family l2vpn evpn import vpn unicast reoriginate
L3 EVPN over Segment Routing
feature bgp install feature-set mpls feature-set mpls feature mpls segment-routing feature mpls evpn