Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento es explicar cómo desplegar un despliegue Multisite del nexo 9000 VXLAN de Cisco usando el modelo compartido de la frontera usando la versión DCNM 11.2.
El DC1 y DC2 son dos ubicaciones del datacenter que son el ejecutarse vxlan;
Los gatewayes de frontera DC1 y DC2 están teniendo conexiones físicas a las fronteras compartidas;
Las fronteras compartidas tienen la conectividad externa (eg.; Internet); las conexiones VRF lite se terminan tan en las fronteras compartidas y una ruta predeterminado es inyectada por las fronteras compartidas a los gatewayes de frontera en cada sitio
Las fronteras compartidas se configuran en el vPC (esto es un requisito cuando la tela se despliega usando DCNM)
Los gatewayes de frontera se configuran en el modo del Anycast
Funcionamiento del nexo 9ks 9.3(2)
DCNM que funciona con la versión 11.2
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
1) Considerando que este documento está basado en dos Datacenters que utiliza la característica multisite vxlan, dos telas fáciles tienen que ser creadas
2) Cree otra tela fácil para la frontera compartida
3) Cree el MSD y mueva el DC1 y DC2
4) Cree la tela externa
5) Cree la arpillera y el recubrimiento Multisite (para el este/el oeste)
6) Cree las conexiones de la extensión VRF en las fronteras compartidas
# las interfaces de recursos físicos (que son las interfaces de la espina dorsal/de la hoja) pueden ser “innumerables” o de punto a punto; Si es innumerable se utiliza, los IP Addresses requeridos son menos (pues la dirección IP es la del loopback innumerable)
# AGM es utilizado por los host en la tela como la dirección MAC del default gateway; Éste será lo mismo en todo el Switches de la hoja que sean los default gatewayes
# el modo de la replicación seleccionado aquí puede ser Multicast o replicación del IR-ingreso; El IR replicará cualquier tráfico entrante del VAGO dentro de un vlan vxlan en una moda del unicast al otro VTEPs que también se llama replicación del centro distribuidor mientras que el modo de multidifusión enviará el tráfico del VAGO con un IP Address de destino externo como el del grupo de multidifusión definido para cada las redes hasta la espina dorsal y las espinas dorsales hará la replicación de multidifusión basada apagado del ACEITE de los IP Address de destino externos al otro VTEPs
# subnet-> del grupo de multidifusión requerido replicar el tráfico del VAGO (como el pedido ARP de un host)
# si el TRM se requiere para ser habilitado, seleccione la casilla de verificación contra lo mismo y proporcione el direccionamiento MDT para el TRM VRF.
# el sitio ID mencionado aquí auto-se puebla en esta versión DCNM que se derive del ASN que se define por debajo la lengueta “general”
# terraplén up/Modify otros campos que son relevantes
# la capa 2 VXLAN VNI Range-> éstos es el VNIDs que será asociado más adelante al vlans (lo mostrará que trague más lejos)
# la capa 3 VXLAN VNI Range-> éstos es la capa 3 VNIDs que también será asociada más adelante para acodar el Vn-segmento 3 VNI Vlan
# esta sección muestra la lista completa de telas, ASN, los modos de la replicación para cada uno de las telas
Haga clic en el DC1 en el diagrama arriba y eso daría la opción para agregar el Switches.
# puesto que esto es un despliegue greenfield, observe que “la opción de los config del coto” está seleccionada como “NO”; cuál borrará todas las configuraciones de los cuadros mientras que hace la importación y también recargará el Switches
# seleccione “detección del comienzo” de modo que DCNM comience a descubrir el Switches basado en los IP Addresses proporcionados en “la columna IP del germen”
# seleccione el Switches relevante y después haga clic en la “importación en la tela”
# una vez que se hace la importación, la topología bajo el constructor de la tela puede parecer abajo;
# el Switches puede ser movido alrededor haciendo clic en un Switch y alineándolo a la ubicación correcta dentro del diagrama
# seleccione “la sección de la disposición de la salvaguardia” después de cambiar el Switches en la orden que la disposición es necesaria
# el click derecho cada uno del Switches y fijó el papel correcto; Aquí, el DC1-BGW1 y el DC1-BGW2 son los gatewayes de frontera
# DC1-SPINE-> será fijado a la espina dorsal del papel, DC1-VTEP-> será papel-hoja fijada
# DCNM ahora enumerará el Switches y también tendrá el avance de las configuraciones que DCNM va a avanzar a todo el Switches.
# una vez que es acertado, el estatus reflejará y también el Switches será mostrado en el verde
# tela selecta DC1 (de la esquina superior derecha caiga abajo), control > VRF
# está después crear el VRF
# la versión 11.2 DCNM auto-está poblando el VRF ID; Si sus diferentes, teclean adentro el que usted necesita y selecciona “cree el VRF”
# aquí, la capa 3 VNID usada es 1001445
# proporcione el ID de la red (que es el VNID correspondiente del Vlans de la capa 2
# proporcione el VRF que el SVI debe ser parte de; Por abandono, DCNM 11.2 puebla el nombre VRF previamente creado; Cambie según las necesidades
# Vlan ID será la capa 2 VLan que se asocia a este VNID determinado
# el IPv4 Gateway-> esto es el Gateway IP Address del Anycast que será configurado en el SVI y será lo mismo para todo el VTEPs dentro de la tela
# una vez que se pueblan los campos, haga clic en “crean la red”.
# cree cualquier otra red que se requiera ser parte de esta tela;
# el estatus estará en el “NA” si esto no se despliega al Switches. Puesto que éste es un multisite e implica los gatewayes de frontera, el despliegue de las redes/VRF será plumón posterior discutido.
# los VRF también se crean como ella estaban para las telas DC1 y DC2
# las redes no se requieren en una frontera compartida pues la frontera compartida no tendrá ningún vlans/VNIDs de la capa 2; Las fronteras compartidas no son una terminación del túnel para ningún del este/al oeste trafican del DC1 a DC2; Solamente los gatewayes de frontera desempeñarían un papel en términos de encapsulación/decapsulation vxlan para del este/al oeste el tráfico DC1<>DC2
Van al constructor de la tela y crean la nueva tela y utilizan la plantilla - > MSD_Fabric_11_1
# la nota que el Multi-sitio cubrió el método de implementación IFC tiene que ser “centralized_To_Route_Server”; Aquí, las fronteras compartidas se consideran como Route Server y así que esta opción se utiliza del descenso abajo
# dentro de la “lista Multisite del Route Server”; Aquí, encuéntrela que hacia fuera los IP Addresses del loopback de Loopback0(which son el loopback de la encaminamiento) en la frontera compartida y llene
# el ASN es el que está en la frontera compartida (refiera el diagrama encima de este documento para más detalles); Con el fin de este documento, ambas las fronteras compartidas se configuran en el mismo ASN; Complete por consiguiente
# una vez que se pueblan todos los campos, haga clic el botón de la “salvaguardia” y una nueva tela será creada con el template-> MSD
# está después mover las telas DC1 y DC2 a este MSD
# después de que el movimiento de la tela, él parezca abajo
# hecho una vez, haga clic en el botón “save&Deploy” que avanzará las configuraciones necesarias por lo que es multisite se trata a los gatewayes de frontera
# cree la tela externa y agregue al router externo a ella como se muestra abajo;
# el nombre la tela y utiliza el template-> el "External_Fabric_11_1";
# proporcione el ASN
# en el extremo, las diversas telas parecerán abajo
# evpn compartido del eBGP l2vpn del funcionamiento de las fronteras con los gatewayes de frontera y las conexiones VRF-LITE hacia el router externo
# antes de formar el evpn del eBGP l2vpn con los loopback, se requiere aseegurarse que los loopback sean accesibles vía un cierto método; En este ejemplo, estamos utilizando el IPv4 AF del eBGP de los BGW a las fronteras compartidas y después hacemos publicidad de los loopback para formar más lejos la vecindad del evpn l2vpn.
# una vez que se selecciona la tela MSD, Switch a la “visión tabular”
# seleccione la “inter-tela” y utilice el “Multisite_UNDERLAY”
# aquí estamos intentando formar una vecindad BGP del IPv4 con el Router del borde compartido; Seleccione tan el Switches y las interfaces por consiguiente.
# nota que si el CDP está detectando al vecino del DC1-BGW1 a SB1, él se requiere solamente para proporcionar los IP Addresses aquí en esta sección y que configurará con eficacia los IP Addresses en las interfaces pertinentes después de realizar la “salvaguardia y los desplegará”
# una vez se selecciona la salvaguardia y despliega, las líneas de la configuración necesaria se propaga para el DC1-BGW1; El mismo paso tendrá que ser realizado después de seleccionar la tela de la “frontera compartida” también.
# del CLI, lo mismo se pueden verificar usando el comando abajo;
DC1-BGW1# show ip bgp sum BGP summary information for VRF default, address family IPv4 Unicast BGP router identifier 10.10.10.1, local AS number 65000 BGP table version is 11, IPv4 Unicast config peers 1, capable peers 1 2 network entries and 2 paths using 480 bytes of memory BGP attribute entries [1/164], BGP AS path entries [0/0] BGP community entries [0/0], BGP clusterlist entries [0/0] Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.4.10.2 4 65001 6 7 11 0 0 00:00:52 0
# la nota que el “save&Deploy” tiene que ser hecha en la tela DC1 también (selecciona el descenso abajo para el DC1 y después realiza lo mismo) para propagar el IP Addressing relevante, las configuraciones BGP al Switches en DC1(which sea los gatewayes de frontera);
# también, la arpillera multisite tiene que ser creada del DC1-BGWs, DC2-BGWs a las fronteras compartidas; Así pues, los mismos pasos que arriba tienen que ser hechos para lo mismo también.
# en el extremo, las fronteras compartidas tendrán vecindad del IPv4 AF del eBGP con todos los BGW en el DC1 y DC2 como abajo;
SHARED-BORDER1# sh ip bgp sum BGP summary information for VRF default, address family IPv4 Unicast BGP router identifier 10.10.100.1, local AS number 65001 BGP table version is 38, IPv4 Unicast config peers 4, capable peers 4 18 network entries and 20 paths using 4560 bytes of memory BGP attribute entries [2/328], BGP AS path entries [2/12] BGP community entries [0/0], BGP clusterlist entries [0/0] Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.4.10.1 4 65000 1715 1708 38 0 0 1d03h 5 10.4.10.6 4 65000 1461 1458 38 0 0 1d00h 5 10.4.10.18 4 65002 1459 1457 38 0 0 1d00h 5 10.4.10.22 4 65002 1459 1457 38 0 0 1d00h 5 SHARED-BORDER2# sh ip bgp sum BGP summary information for VRF default, address family IPv4 Unicast BGP router identifier 10.10.100.2, local AS number 65001 BGP table version is 26, IPv4 Unicast config peers 4, capable peers 4 18 network entries and 20 paths using 4560 bytes of memory BGP attribute entries [2/328], BGP AS path entries [2/12] BGP community entries [0/0], BGP clusterlist entries [0/0] Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.4.10.10 4 65000 1459 1458 26 0 0 1d00h 5 10.4.10.14 4 65000 1461 1458 26 0 0 1d00h 5 10.4.10.26 4 65002 1459 1457 26 0 0 1d00h 5 10.4.10.30 4 65002 1459 1457 26 0 0 1d00h 5
# arriba está el edificio anterior del requisito previó la vecindad del evpn l2vpn de los BGW a las fronteras compartidas (nota ese su no obligatorio para utilizar el BGP; cualquier otro mecanismo para intercambiar los prefijos del loopback haría); En el extremo, el requerimiento base es que todos los loopback (de las fronteras compartidas, los BGW) deben ser accesibles de todos los BGW
# también observe por favor que una vecindad del IPv4 AF del iBGP necesita ser establecida entre las fronteras compartidas; A partir del hoy, DCNM no tienen una opción para construir un iBGP entre las fronteras compartidas usando una plantilla/caen abajo; Para eso, una configuración Freeform tiene que ser hecha que se muestra abajo;
# encuentre los IP Addresses que se configuran en el respaldo SVI de las fronteras compartidas; Como se muestra arriba, freeform se agrega en el Switch Shared-border1 y el vecino iBGP especificado es el del compartido-border2(10.100.100.2)
# la nota que mientras que proporciona a las configuraciones dentro del freeform en DCNM, proporciona el espaciamiento correcto después de cada los comandos (número par de la licencia de los espacios; significando, después de BGP 65001 del router, proporcione dos espacios y después dé el comando vecino del <> y así sucesivamente)
# también aseegurese realizar una redistribución directa para las rutas directas (rutas del loopback) en el BGP o una cierta otra forma para hacer publicidad de los loopback; en el ejemplo anterior, un route-map directo se crea para hacer juego todas las rutas directas y entonces redistribuir directo se hace dentro del IPv4 AF BGP
# una vez que la configuración “se guarda y se despliega” de DCNM, la vecindad del iBGP se forma como se muestra abajo;
SHARED-BORDER1# sh ip bgp sum BGP summary information for VRF default, address family IPv4 Unicast BGP router identifier 10.10.100.1, local AS number 65001 BGP table version is 57, IPv4 Unicast config peers 5, capable peers 5 18 network entries and 38 paths using 6720 bytes of memory BGP attribute entries [4/656], BGP AS path entries [2/12] BGP community entries [0/0], BGP clusterlist entries [0/0] Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.4.10.1 4 65000 1745 1739 57 0 0 1d04h 5 10.4.10.6 4 65000 1491 1489 57 0 0 1d00h 5 10.4.10.18 4 65002 1490 1487 57 0 0 1d00h 5 10.4.10.22 4 65002 1490 1487 57 0 0 1d00h 5 10.100.100.2 4 65001 14 6 57 0 0 00:00:16 18 # iBGP neighborship from shared border1 to shared border2
# con el paso antedicho, la arpillera multisite es de configuración completa.
# el siguiente paso es construir el recubrimiento multisite;
# nota que, las fronteras aquí compartidas es también los Route Server
# seleccione el MSD y después vaya a la “visión tabular” donde las nuevas relaciones pueden ser establecidas; De allí, las nuevas relaciones multisite del recubrimiento tienen que ser establecidas y los IP Addresses relevantes tuvieron que proporcionado el ASN correcto como abajo; Este paso tiene que ser hecho para todos los vecinos del evpn l2vpn (que es de cada BGW a cada frontera compartida)
# arriba está un ejemplo; Realice lo mismo para el resto de los links multisite del recubrimiento y en el extremo, el CLI parecerá abajo;
SHARED-BORDER1# sh bgp l2vpn evpn summary BGP summary information for VRF default, address family L2VPN EVPN BGP router identifier 10.10.100.1, local AS number 65001 BGP table version is 8, L2VPN EVPN config peers 4, capable peers 4 1 network entries and 1 paths using 240 bytes of memory BGP attribute entries [1/164], BGP AS path entries [0/0] BGP community entries [0/0], BGP clusterlist entries [0/0] Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.10.10.1 4 65000 21 19 8 0 0 00:13:52 0 10.10.10.2 4 65000 22 20 8 0 0 00:14:14 0 10.10.20.1 4 65002 21 19 8 0 0 00:13:56 0 10.10.20.2 4 65002 21 19 8 0 0 00:13:39 0 SHARED-BORDER2# sh bgp l2vpn evpn summary BGP summary information for VRF default, address family L2VPN EVPN BGP router identifier 10.10.100.2, local AS number 65001 BGP table version is 8, L2VPN EVPN config peers 4, capable peers 4 1 network entries and 1 paths using 240 bytes of memory BGP attribute entries [1/164], BGP AS path entries [0/0] BGP community entries [0/0], BGP clusterlist entries [0/0] Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.10.10.1 4 65000 22 20 8 0 0 00:14:11 0 10.10.10.2 4 65000 21 19 8 0 0 00:13:42 0 10.10.20.1 4 65002 21 19 8 0 0 00:13:45 0 10.10.20.2 4 65002 22 20 8 0 0 00:14:15 0
# como hemos acabado la arpillera y el recubrimiento multisite, el siguiente paso es desplegar las redes/VRF en todos los dispositivos;
# comenzando con los VRF en Fabrics-> DC1, DC2 y fronteras compartidas.
# una vez que se selecciona la opinión VRF, haga clic en “continúan”; Esto enumerará hacia fuera los dispositivos en la topología
# puesto que el VRF tiene que ser desplegado a los switches múltiples (gatewayes de frontera incluyendo y hoja), seleccione el checkbox en el extremo derecho y después seleccione el Switches que tiene el mismo papel al mismo tiempo; eg.; El DC1-BGW1 y el DC1-BGW2 pueden ser seleccionados al mismo tiempo y después salvar ambo el Switches; Después de esto, seleccione el Switches de la hoja que son aplicable (aquí sería DC1-VTEP)
# según lo considerado arriba, cuando “despliegue” se selecciona la opción, todo el Switches que fueron seleccionados previamente comenzarán el despliegue y finalmente darán vuelta al verde si el desplegar era acertado.
# los mismos pasos tendrán que ser realizados para las redes que despliegan;
# si se crean las Redes múltiples, tenga presente para navegar a las lenguetas subsiguientes para seleccionar las redes antes de desplegar
# el estatus ahora dará vuelta a “DESPLEGADO” del “NA” y el CLI de los switches abajo se puede utilizar para verificar las implementaciones
DC1-VTEP# sh nve vni Codes: CP - Control Plane DP - Data Plane UC - Unconfigured SA - Suppress ARP SU - Suppress Unknown Unicast Xconn - Crossconnect MS-IR - Multisite Ingress Replication Interface VNI Multicast-group State Mode Type [BD/VRF] Flags --------- -------- ----------------- ----- ---- ------------------ ----- nve1 100144 239.1.1.144 Up CP L2 [144] # Network1 which is VLan 144 mapped to VNID 100144 nve1 100145 239.1.1.145 Up CP L2 [145] # Network2 Which is Vlan 145 mapped to VNID 100145 nve1 1001445 239.100.100.100 Up CP L3 [tenant-1] # VRF- tenant1 which is mapped to VNID 1001445
DC1-BGW1# sh nve vni Codes: CP - Control Plane DP - Data Plane UC - Unconfigured SA - Suppress ARP SU - Suppress Unknown Unicast Xconn - Crossconnect MS-IR - Multisite Ingress Replication Interface VNI Multicast-group State Mode Type [BD/VRF] Flags --------- -------- ----------------- ----- ---- ------------------ ----- nve1 100144 239.1.1.144 Up CP L2 [144] MS-IR nve1 100145 239.1.1.145 Up CP L2 [145] MS-IR nve1 1001445 239.100.100.100 Up CP L3 [tenant-1]
# arriba es de BGW también; tan en fin, todo el Switches que habíamos seleccionado anterior en el paso será desplegado con las redes y el VRF
# los mismos pasos tienen que ser realizados para la tela DC2, frontera compartida también. Tenga presente que las fronteras compartidas no necesitan ninguna redes ni acodan 2 VNIDs; solamente se requiere el L3 VRF.
# en esta topología, los puertos Eth1/2 y Eth1/1 del DC1-VTEP y DC2-VTEP respectivamente están conectados con los host; tan moviendo ésos como puertos troncales en DCNM GUI como se muestra abajo
# seleccione la interfaz pertinente y cambie el “vlans permitido” de ningunos a “todos” (o solamente el vlans que están necesitando ser permitidos)
# puesto que el Switches compartido de la frontera es los Route Server, se requiere para realizar algunos cambios en términos de neighborships del evpn BGP l2vpn
# el tráfico del VAGO del inter-sitio se replica usando el unicast; Significa, cualquier tráfico del VAGO en Vlan 144(eg) después de que llegue en los BGW; dependiendo de qué BGW es el forwarder(DF) señalado, el DF realizará una replicación del unicast al sitio remoto; Se alcanza esta replicación después de que el BGW reciba una ruta del tipo 3 del telecontrol BGW; Aquí, los BGW están formando el evpn l2vpn que mira solamente con las fronteras compartidas; y las fronteras compartidas no deben tener cualquier capa 2 VNIDs (si está creada, ésta dará lugar a blackholing del este/al oeste del tráfico). Puesto que la capa 2 VNIDs falta y el route tipo 3 es originado por los BGW por VNID, las fronteras compartidas no honrarán la actualización de BGP que viene adentro de los BGW; Para reparar esto, utilice “conservan la ruta-blanco toda” bajo evpn AF l2vpn
# otra punta es aseegurarse que las fronteras compartidas no cambian el salto siguiente (el BGP por abandono cambia el salto siguiente para los neighborships del eBGP); Aquí, el túnel inter del sitio para el tráfico de unidifusión del sitio 1 a 2 y vice versa debe ser de BGW al BGW (de dc1 a dc2 y vice versa); Para alcanzar esto, un route-map tiene que ser creado y ser solicitado los neighborships de cada evpn l2vpn de la frontera compartida a cada los BGW
# para ambas las puntas antedichas, un freeform tiene que ser utilizada en las fronteras compartidas como abajo
route-map direct route-map unchanged set ip next-hop unchanged router bgp 65001 address-family ipv4 unicast redistribute direct route-map direct address-family l2vpn evpn retain route-target all neighbor 10.100.100.2 remote-as 65001 address-family ipv4 unicast next-hop-self neighbor 10.10.10.1 address-family l2vpn evpn route-map unchanged out neighbor 10.10.10.2 address-family l2vpn evpn route-map unchanged out neighbor 10.10.20.1 address-family l2vpn evpn route-map unchanged out neighbor 10.10.20.2 address-family l2vpn evpn route-map unchanged out
# para del norte/al sur trafique de los host conectados dentro del Switches de la hoja, los BGW utilizan el SRC IP externo de la dirección IP NVE Loopback1; Las fronteras compartidas solamente por abandono formarán el peering NVE con el Loopback IP Address Multisite de los BGW; tan si un paquete vxlan viene a la frontera compartida con una dirección IP externa del SRC del BGW Loopback1, el paquete será caído debido a la Srta. SRCTEP; Para evitar esto, un loopback en el arrendatario-VRF tiene que ser creado en cada Switch BGW y después hacer publicidad al BGP de modo que las fronteras compartidas reciban esta actualización y después formen el peering NVE con la dirección IP BGW Loopback1;
# el peering NVE parecerá inicialmente abajo en las fronteras compartidas
SHARED-BORDER1# sh nve pee Interface Peer-IP State LearnType Uptime Router-Mac --------- -------------------------------------- ----- --------- -------- ----------------- nve1 10.222.222.1 Up CP 01:20:09 0200.0ade.de01 # Multisite Loopback 100 IP address of DC1-BGWs nve1 10.222.222.2 Up CP 01:17:43 0200.0ade.de02 # Multisite Loopback 100 IP address of DC2-BGWs
# como se muestra arriba, el loopback2 se crea de DCNM y se configura en tenant-1 VRF y se da la etiqueta de 12345 pues ésta es la etiqueta que el route-map utiliza para hacer juego el loopback mientras que hace el anuncio
DC1-BGW1# sh run vrf tenant-1 !Command: show running-config vrf tenant-1 !Running configuration last done at: Tue Dec 10 17:21:29 2019 !Time: Tue Dec 10 17:24:53 2019 version 9.3(2) Bios:version 07.66 interface Vlan1445 vrf member tenant-1 interface loopback2 vrf member tenant-1 vrf context tenant-1 vni 1001445 ip pim rp-address 10.49.3.100 group-list 224.0.0.0/4 ip pim ssm range 232.0.0.0/8 rd auto address-family ipv4 unicast route-target both auto route-target both auto mvpn route-target both auto evpn address-family ipv6 unicast route-target both auto route-target both auto evpn router bgp 65000 vrf tenant-1 address-family ipv4 unicast advertise l2vpn evpn redistribute direct route-map fabric-rmap-redist-subnet maximum-paths ibgp 2 address-family ipv6 unicast advertise l2vpn evpn redistribute direct route-map fabric-rmap-redist-subnet maximum-paths ibgp 2 DC1-BGW1# sh route-map fabric-rmap-redist-subnet route-map fabric-rmap-redist-subnet, permit, sequence 10 Match clauses: tag: 12345 Set clauses:
# después de este paso, los peeringes NVE mostrarán para todos los IP Addresses Loopback1 junto con el Loopback IP Address multisite.
SHARED-BORDER1# sh nve pee Interface Peer-IP State LearnType Uptime Router-Mac --------- -------------------------------------- ----- --------- -------- ----------------- nve1 192.168.20.1 Up CP 00:00:01 b08b.cfdc.2fd7 nve1 10.222.222.1 Up CP 01:27:44 0200.0ade.de01 nve1 192.168.10.2 Up CP 00:01:00 e00e.daa2.f7d9 nve1 10.222.222.2 Up CP 01:25:19 0200.0ade.de02 nve1 192.168.10.3 Up CP 00:01:43 6cb2.aeee.0187 nve1 192.168.20.3 Up CP 00:00:28 005d.7307.8767
# en esta etapa, el del este/al oeste trafican se deben remitir correctamente
# habrá situaciones cuando los host fuera de la tela tendrán que hablar con los host dentro de la tela. En este ejemplo, lo mismo es hecha posible por las fronteras compartidas;
# cualquier host que esté viviendo en el DC1 o DC2 podrá hablar con los host externos vía la frontera compartida conmuta.
# para ese propósito, las fronteras compartidas están terminando el VRF Lite; Aquí en este eBGP del ejemplo se está ejecutando de las fronteras compartidas a los routeres externos tal y como se muestra en del diagrama al principio.
# para configurar esto de DCNM, se requiere agregar las conexiones de la extensión del vrf. Debajo de los pasos es ser hecho para alcanzar lo mismo.
# seleccione el alcance del constructor de la tela a la “frontera compartida” y cambie a la visión tabular
# seleccione los links y agregue un link de la “Inter-tela” como se muestra abajo
# un subtipo VRF LITE tiene que ser seleccionado del descenso abajo
# la tela de la fuente es fronteras compartidas y la tela del destino es externa pues éste va a ser un VRF LITE del SB al externo
# seleccione las interfaces pertinentes que van hacia el router externo
# proporcione la dirección IP y la máscara y el IP Address del vecino
# el ASN auto-será poblado.
# una vez que se hace esto, haga clic la salvaguardia
# realice lo mismo para ambas las fronteras compartidas y para todas las conexiones externas de la capa 3 que están en VRFLITE
# vaya a la sección compartida de la frontera VRF
# el VRF estará en el estatus desplegado; Seleccione el checkbox en la derecha para poder seleccionar los switches múltiples
# seleccione las fronteras compartidas y “la ventana de la conexión de la extensión VRF” abrirá
# bajo “extienda”, cambian de “ningunos” a “VRFLITE”
# haga lo mismo para ambas fronteras compartidas
# una vez se hace que, los “detalles de la extensión” poblarán las interfaces VRF LITE que fueron dadas previamente en el paso a) arriba.
# el DOT1Q ID es auto poblado a 2
# otros campos son también auto poblados
# si la vecindad del IPv6 tiene que ser establecida vía VRFLITE, el paso a) se debe hacer para el IPv6
# ahora haga clic la salvaguardia
# finalmente, haga “despliegan” en la esquina superior derecha de la página web.
# A acertada despliega dará lugar a avanzar las configuraciones a las fronteras compartidas que incluya los IP Addresses de la configuración en esos subinterfaces y el establecimiento del IPv4 Neighborships BGP con los routeres externos
# tenga presente que las configuraciones del router externo (IP Addresses de la configuración en los subinterfaces y las declaraciones de la vecindad BGP) son hechas manualmente por el CLI en este caso.
# las verificaciones CLI se pueden hacer por los comandos abajo en ambas las fronteras compartidas;
SHARED-BORDER1# sh ip bgp sum vr tenant-1 BGP summary information for VRF tenant-1, address family IPv4 Unicast BGP router identifier 172.16.22.1, local AS number 65001 BGP table version is 18, IPv4 Unicast config peers 1, capable peers 1 9 network entries and 11 paths using 1320 bytes of memory BGP attribute entries [9/1476], BGP AS path entries [3/18] BGP community entries [0/0], BGP clusterlist entries [0/0] Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 172.16.22.2 4 65100 20 20 18 0 0 00:07:59 1 SHARED-BORDER2# sh ip bgp sum vr tenant-1 BGP summary information for VRF tenant-1, address family IPv4 Unicast BGP router identifier 172.16.222.1, local AS number 65001 BGP table version is 20, IPv4 Unicast config peers 1, capable peers 1 9 network entries and 11 paths using 1320 bytes of memory BGP attribute entries [9/1476], BGP AS path entries [3/18] BGP community entries [0/0], BGP clusterlist entries [0/0] Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 172.16.222.2 4 65100 21 21 20 0 0 00:08:02 1
# con todas las configuraciones antedichas, del norte/al sur el accesibilidad será establecido demasiado como se muestra debajo (los ping del router externo a los host en la tela)
EXT_RTR# ping 172.16.144.1 # 172.16.144.1 is Host in DC1 Fabric PING 172.16.144.1 (172.16.144.1): 56 data bytes 64 bytes from 172.16.144.1: icmp_seq=0 ttl=251 time=0.95 ms 64 bytes from 172.16.144.1: icmp_seq=1 ttl=251 time=0.605 ms 64 bytes from 172.16.144.1: icmp_seq=2 ttl=251 time=0.598 ms 64 bytes from 172.16.144.1: icmp_seq=3 ttl=251 time=0.568 ms 64 bytes from 172.16.144.1: icmp_seq=4 ttl=251 time=0.66 ms ^[[A^[[A --- 172.16.144.1 ping statistics --- 5 packets transmitted, 5 packets received, 0.00% packet loss round-trip min/avg/max = 0.568/0.676/0.95 ms
EXT_RTR# ping 172.16.144.2 # 172.16.144.2 is Host in DC2 Fabric PING 172.16.144.2 (172.16.144.2): 56 data bytes 64 bytes from 172.16.144.2: icmp_seq=0 ttl=251 time=1.043 ms 64 bytes from 172.16.144.2: icmp_seq=1 ttl=251 time=6.125 ms 64 bytes from 172.16.144.2: icmp_seq=2 ttl=251 time=0.716 ms 64 bytes from 172.16.144.2: icmp_seq=3 ttl=251 time=3.45 ms 64 bytes from 172.16.144.2: icmp_seq=4 ttl=251 time=1.785 ms --- 172.16.144.2 ping statistics --- 5 packets transmitted, 5 packets received, 0.00% packet loss round-trip min/avg/max = 0.716/2.623/6.125 ms
# Traceroutes también señala a los dispositivos correctos en la trayectoria del paquete
EXT_RTR# traceroute 172.16.144.1 traceroute to 172.16.144.1 (172.16.144.1), 30 hops max, 40 byte packets 1 SHARED-BORDER1 (172.16.22.1) 0.914 ms 0.805 ms 0.685 ms 2 DC1-BGW2 (172.17.10.2) 1.155 ms DC1-BGW1 (172.17.10.1) 1.06 ms 0.9 ms 3 ANYCAST-VLAN144-IP (172.16.144.254) (AS 65000) 0.874 ms 0.712 ms 0.776 ms 4 DC1-HOST (172.16.144.1) (AS 65000) 0.605 ms 0.578 ms 0.468 ms
EXT_RTR# traceroute 172.16.144.2 traceroute to 172.16.144.2 (172.16.144.2), 30 hops max, 40 byte packets 1 SHARED-BORDER2 (172.16.222.1) 1.137 ms 0.68 ms 0.66 ms 2 DC2-BGW2 (172.17.20.2) 1.196 ms DC2-BGW1 (172.17.20.1) 1.193 ms 0.903 ms 3 ANYCAST-VLAN144-IP (172.16.144.254) (AS 65000) 1.186 ms 0.988 ms 0.966 ms 4 172.16.144.2 (172.16.144.2) (AS 65000) 0.774 ms 0.563 ms 0.583 ms EXT_RTR#