O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como implementar e verificar Virtual Extensible LAN (VXLAN) Ethernet VPN (EVPN) em Cisco Catalyst 9000 Series Switches somente com Border Gateway Protocol (BGP).
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software e hardware:
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Projetar uma rede de campus de próxima geração envolve a adoção de tecnologias e arquiteturas modernas para atender às demandas em evolução de usuários, aplicativos e dispositivos. A solução VXLAN com BGP EVPN pode fornecer uma arquitetura baseada em estrutura para simplicidade, escalabilidade e facilidade de gerenciamento. Este documento descreve a solução BGP EVPN para usuários que preferem usar o BGP para roteamento IPv4 e EVPN por qualquer motivo.
O VXLAN com BGP EVPN utiliza uma arquitetura spine-leaf em vez do modelo de rede tradicional de 3 camadas. Com uma arquitetura spine-leaf, a spine atua como um canal de alta velocidade entre switches de acesso. O modelo spine permite um modelo de expansão em que a largura de banda entre as folhas pode ser aumentada com a adição de colunas adicionais ou a capacidade do endpoint pode ser aumentada com a adição de mais folhas.
Para usuários que preferem usar o BGP para informações de roteamento IPv4 e EVPN, inclua estas considerações:
Essa topologia mostra um design de estrutura única C9K EVPN comum.
Para o design somente de BGP, a primeira questão a ser considerada é se usar BGP Interno (IBGP) ou BGP Externo (EBGP). O caso do uso do IBGP, que é comum no EVPN VxLAN do DC tradicional. Em comparação com o uso do IBGP como subjacência, ao usar o EBGP, o Spine não precisa mais ser configurado como um refletor de rota, mas funciona como um Servidor de Roteador tradicional para trocar rotas. Portanto, o pré-requisito para este documento é o caso de usar o EBGP.
Opção 1.Two-AS: a lombada usa um AS, e a folha e a folha de borda usam outro AS.
Two-AS
Opção 2. Multi-AS: Spine, Leaf e Border Leaf usam um AS cada.
Comparando os dois projetos, um problema comum é a escalabilidade, porque para a opção 2, cada vez que uma coluna ou folha é adicionada, um novo número AS precisa ser adicionado, o que traz alterações de configuração mais complexas no futuro, que não é É conducente à expansão e manutenção. Portanto, este documento usa a opção 1. para discussão.
Em comparação com o uso do IBGP como subjacência, ao usar o EBGP, o Spine não precisa mais ser configurado como um refletor de rota, mas funciona como um servidor de roteador tradicional para trocar rotas.
Esses são pontos-chave que precisam ser considerados no plano subjacente.
A detecção de loop de AS é feita através da varredura do caminho completo de AS (conforme especificado no atributo AS_PATH) e da verificação de que o número de sistema autônomo do sistema local não aparece no caminho de AS.
De acordo com o diagrama acima, o BGP AS Loop é formado - o mesmo número AS no as-path neste cenário:
Para resolver esse problema, o allow-as-in é configurado na família de endereços IPv4 do BGP, com as instruções descritas aqui:
Observação: quando a estrutura única é usada com o DGW, é improvável que o roteamento seja necessário de um spine para outro. No entanto, considerando as alterações de topologia, como a super-espinha, é recomendável desabilitar a verificação de AS em dispositivos Spine também.
O BGP escolhe uma rota com base em seus critérios, e é improvável que apareça 2 rotas ECMP na tabela BGP por padrão. Para obter ECMP para otimização de largura de banda, 'maximum-paths X' devem ser configurados na família de endereços IPv4 do BGP em todos os dispositivos em execução no BGP. Enquanto isso, sugerimos manter a mesma largura de banda de link entre spine e leaf como prática recomendada.
Observação: os caminhos máximos dependem do design da topologia. Com dois switches spine, você pode configurar 'maximum-paths 2'.
Esses pontos-chave precisam ser considerados no plano de sobreposição.
A detecção de loop de AS é feita através da varredura do caminho completo de AS (conforme especificado no atributo AS_PATH) e da verificação de que o número de sistema autônomo do sistema local não aparece no caminho de AS.
De acordo com a imagem, o BGP AS Loop é formado - o mesmo número AS no as-path neste cenário:
Para resolver esse problema, o allow-as-in deve ser configurado na família de endereços IPv4 do BGP, com as instruções descritas:
Observação: quando a estrutura única é usada com o DGW, é improvável que o roteamento seja necessário de um spine para outro. No entanto, considerando as alterações de topologia, como a super-espinha, é recomendável desabilitar a verificação de AS em dispositivos Spine também.
O BGP altera o atributo do próximo salto das informações de acessibilidade da camada de rede (NLRI - Network Layer Reachability Information) anunciadas do vizinho EBGP por padrão. Leaf/VXLAN Tunnel End Point (VTEP) usa seu endereço de origem NVE como o atributo do próximo salto das rotas EVPN, e esse endereço é usado para determinar o destino do túnel VXLAN (interface virtual de rede/peer NVE). Se os nós Spine mudarem o próximo salto, o túnel VXLAN não poderá ser estabelecido corretamente.
Para resolver esse problema, essas instruções são aplicadas.
As rotas EVPN dos dispositivos Leaf são anunciadas com a comunidade Route Target (RT). Os roteadores sem a configuração RT correspondente descartam as rotas com a comunidade RT por padrão. Enquanto todos os dispositivos spine não têm Roteamento e encaminhamento virtual (VRF) configurado. Isso significa que os dispositivos spine descartam todas as rotas EVPN anunciadas dos dispositivos Leaf por padrão.
Para resolver esse problema, em todos os nós Spine, o filtro de destino de rota padrão precisa ser desabilitado.
Veja a seguir os detalhes da interface para este ambiente de laboratório.
Nome de dispositivo |
Versão de software |
Interface# |
IP Address |
Coluna-1 |
IOS-XE 17.12.1 |
Hu 1/0/9 |
172.16.12.1/30 |
Hu 1/0/10 |
172.16.11.1/30 |
||
Lo 0 |
10.1.255.1/32 |
||
Coluna-2 |
IOS-XE 17.12.1 |
Hu 1/0/9 |
172.16.21.1/30 |
Hu 1/0/10 |
172.16.22.1/30 |
||
Lo 0 |
10.1.255.2/32 |
||
Folha-1 |
IOS-XE 17.12.1 |
Hu 1/0/1 |
172.16.21.2/30 |
Hu 1/0/2 |
172.16.11.2/30 |
||
Linha 1 |
10.2.254.1/32 |
||
Folha-2 |
IOS-XE 17.12.1 |
Hu 1/0/1 |
172.16.12.2/30 |
Hu 1/0/2 |
172.16.22.2/30 |
||
Linha 1 |
10.2.254.2/32 |
Observação: a atribuição de endereço IP neste laboratório é apenas para fins de teste. A máscara de sub-rede (ou seja, /30, /31) para conexões Point-to-Point pode ser considerada com base nos seus requisitos reais de projeto.
Neste exemplo, as interfaces físicas são usadas para estabelecer conexões BGP.
Configuração em Spine:
router bgp 65001
bgp log-neighbor-changes
bgp listen range 172.16.0.0/16 peer-group Leaf-Peers
no bgp default ipv4-unicast
neighbor Leaf-Peers peer-group
neighbor Leaf-Peers remote-as 65002
!
address-family ipv4
redistribute connected
neighbor Leaf-Peers activate
neighbor Leaf-Peers allowas-in 1
maximum-paths 2
exit-address-family
Configuração na Folha-1:
router bgp 65002
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.16.11.1 remote-as 65001
neighbor 172.16.21.1 remote-as 65001
!
address-family ipv4
redistribute connected
neighbor 172.16.11.1 activate
neighbor 172.16.21.1 activate
exit-address-family
Configuração na Folha-2:
router bgp 65002
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.16.12.1 remote-as 65001
neighbor 172.16.22.1 remote-as 65001
!
address-family ipv4
redistribute connected
neighbor 172.16.12.1 activate
neighbor 172.16.22.1 activate
exit-address-family
Configuração em Spine:
router bgp 65001
address-family ipv4
neighbor Leaf-Peers allowas-in 1
Configuração na Folha-1:
router bgp 65002
address-family ipv4
neighbor 172.16.11.1 allowas-in 1
neighbor 172.16.21.1 allowas-in 1
Configuração na Folha-2:
router bgp 65002
address-family ipv4
neighbor 172.16.12.1 allowas-in 1
neighbor 172.16.22.1 allowas-in 1
Configuração em Spine:
router bgp 65001
address-family ipv4
maximum-paths 2
Configuração na Folha:
router bgp 65002
address-family ipv4
maximum-paths 2
Para permitir que a Replicação Multicast (MR) manipule o tráfego de Transmissão, Unicast Desconhecido e Multicast Local de Link (BUM), o roteamento multicast é necessário em todos os dispositivos Spine e Leaf. Todas as interfaces de conexão Spine e Leaf e loopbacks relacionados devem ter o PIM habilitado.
Exemplo de multicast de subjacência em Spine 1:
ip multicast-routing
ip pim rp-address 10.1.255.1 //configure Spine loopback as RP
interface Loopback0
ip pim sparse-mode
interface HundredGigE1/0/9
ip pim sparse-mode
interface HundredGigE1/0/10
ip pim sparse-mode
Configuração em Spine:
router bgp 65001
neighbor Leaf-Peers ebgp-multihop 255
address-family l2vpn evpn
neighbor Leaf-Peers activate
neighbor Leaf-Peers send-community both
Configuração na Folha-1:
router bgp 65002
neighbor 172.16.11.1 ebgp-multihop 255
neighbor 172.16.21.1 ebgp-multihop 255
address-family l2vpn evpn
neighbor 172.16.11.1 activate
neighbor 172.16.11.1 send-community both
neighbor 172.16.21.1 activate
neighbor 172.16.21.1 send-community both
Configuração na Folha-2:
router bgp 65002
neighbor 172.16.12.1 ebgp-multihop 255
neighbor 172.16.22.1 ebgp-multihop 255
address-family l2vpn evpn
neighbor 172.16.12.1 activate
neighbor 172.16.12.1 send-community both
neighbor 172.16.22.1 activate
neighbor 172.16.22.1 send-community both
Configuração na Folha-1:
router bgp 65002
address-family l2vpn evpn
neighbor 172.16.11.1 allowas-in 1
neighbor 172.16.21.1 allowas-in 1
Configuração na Folha-2:
router bgp 65002
address-family l2vpn evpn
neighbor 172.16.12.1 allowas-in 1
neighbor 172.16.22.1 allowas-in 1
Observação: quando a estrutura única é usada com o DGW, é improvável que o roteamento seja necessário de um spine para outro. No entanto, considerando as alterações de topologia, como a super-espinha, é recomendável desabilitar a verificação de AS em dispositivos Spine também.
Configuração em Spine:
route-map BGP-NHU permit 10
set ip next-hop unchanged
!
router bgp 65001
address-family l2vpn evpn
neighbor Leaf-Peers route-map BGP-NHU out
Configuração em Spine:
router bgp 65001
no bgp default route-target filter
vrf definition S1-EVPN
rd 1:1
!
address-family ipv4
route-target export 1:1
route-target import 1:1
route-target export 1:1 stitching
route-target import 1:1 stitching
exit-address-family
router bgp 65002
address-family ipv4 vrf S1-EVPN
advertise l2vpn evpn
redistribute connected
maximum-paths 2
exit-address-family
Habilitar EVPN L2VPN e replicação multicast no Leaf:
l2vpn evpn
replication-type static
Criar instâncias de EVPN (EVI) no Leaf:
l2vpn evpn instance 10 vlan-based
encapsulation vxlan
l2vpn evpn instance 20 vlan-based
encapsulation vxlan
Crie VLANs e VNI para tráfego de usuário no Leaf:
vlan configuration 10
member evpn-instance 10 vni 10010
vlan configuration 20
member evpn-instance 20 vni 10020
Crie a interface NVE e costure VNI em grupos mcast na Folha.
interface nve1
no ip address
source-interface Loopback1
host-reachability protocol bgp
member vni 10010 mcast-group 225.0.0.10
member vni 10020 mcast-group 225.0.0.20
Crie uma VLAN para L3VNI na Folha. O EVI não é necessário para L3VNI.
vlan configuration 3000
member vni 33000
Configurar SVI para L2VNI em Folha.
interface Vlan10
mac-address 0010.0010.0010
vrf forwarding S1-EVPN
ip address 192.168.10.254 255.255.255.0
Configure o SVI para L3VNI no Leaf. "no autostate" é configurado para ativar o SVI quando nenhuma interface ativa for atribuída a essa VLAN.
interface Vlan3000
vrf forwarding S1-EVPN
ip unnumbered Loopback1
no autostate
Em Leaf, costure L3VNI ao VRF na configuração NVE.
interface nve1
member vni 33000 vrf S1-EVPN
Verifique se as sessões de BGP estão estabelecidas
C9600X-SPINE-1#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 10.1.255.1, local AS number 65001 BGP table version is 23, main routing table version 23 12 network entries using 2976 bytes of memory 22 path entries using 2992 bytes of memory 2 multipath network entries and 4 multipath paths 4/3 BGP path/bestpath attribute entries using 1184 bytes of memory 3 BGP AS-PATH entries using 104 bytes of memory 8 BGP extended community entries using 400 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7656 total bytes of memory BGP activity 7259/7235 prefixes, 13926/13892 paths, scan interval 60 secs 12 networks peaked at 07:06:41 Dec 5 2023 UTC (2w1d ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd *172.16.11.2 4 65002 138 130 23 0 0 01:38:17 9 *172.16.12.2 4 65002 138 130 23 0 0 01:38:11 9 * Dynamically created based on a listen range command Dynamically created neighbors: 2, Subnet ranges: 1 BGP peergroup Leaf-Peers listen range group members: 172.16.0.0/16 For address family: L2VPN E-VPN BGP router identifier 10.1.255.1, local AS number 65001 BGP table version is 27, main routing table version 27 10 network entries using 3840 bytes of memory 12 path entries using 2784 bytes of memory 8/6 BGP path/bestpath attribute entries using 2368 bytes of memory 3 BGP AS-PATH entries using 104 bytes of memory 8 BGP extended community entries using 400 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 9496 total bytes of memory BGP activity 7259/7235 prefixes, 13926/13892 paths, scan interval 60 secs 12 networks peaked at 07:38:03 Dec 6 2023 UTC (2w0d ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd *172.16.11.2 4 65002 138 130 27 0 0 01:38:17 6 *172.16.12.2 4 65002 138 130 27 0 0 01:38:11 6 * Dynamically created based on a listen range command Dynamically created neighbors: 2, Subnet ranges: 1 BGP peergroup Leaf-Peers listen range group members: 172.16.0.0/16 Total dynamically created neighbors: 2/(100 max), Subnet ranges: 1
C9500X-LEAF-1#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 10.2.255.1, local AS number 65002 BGP table version is 19, main routing table version 19 12 network entries using 2976 bytes of memory 22 path entries using 2992 bytes of memory 2 multipath network entries and 4 multipath paths 4/3 BGP path/bestpath attribute entries using 1184 bytes of memory 3 BGP AS-PATH entries using 104 bytes of memory 8 BGP extended community entries using 384 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7640 total bytes of memory BGP activity 577/545 prefixes, 4021/3975 paths, scan interval 60 secs 12 networks peaked at 07:10:16 Dec 5 2023 UTC (1d18h ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 172.16.11.1 4 65001 2427 3100 19 0 0 20:39:49 9 172.16.21.1 4 65001 2430 3094 19 0 0 20:39:49 9 For address family: L2VPN E-VPN BGP router identifier 10.2.255.1, local AS number 65002 BGP table version is 5371, main routing table version 5371 16 network entries using 6144 bytes of memory 20 path entries using 4640 bytes of memory 9/9 BGP path/bestpath attribute entries using 2664 bytes of memory 3 BGP AS-PATH entries using 104 bytes of memory 8 BGP extended community entries using 384 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 13936 total bytes of memory BGP activity 577/545 prefixes, 4021/3975 paths, scan interval 60 secs 16 networks peaked at 07:36:38 Dec 6 2023 UTC (18:16:58.620 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 172.16.11.1 4 65001 2427 3100 5371 0 0 20:39:49 4 172.16.21.1 4 65001 2430 3094 5371 0 0 20:39:49 4
Initiate traffic between hosts, verify IP Multicast and PIM configuration, and mroute table.
Please note that on IOS-XE platform, (*, G) entry should always present, and (S, G) entry presents only when BUM traffic present.
C9600X-SPINE-1#show ip mroute IP Multicast Routing Table <snip> Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join t - LISP transit group Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 225.0.0.20), 16:51:00/stopped, RP 10.1.255.1, flags: SJCx Incoming interface: HundredGigE1/0/2, RPF nbr 172.16.11.1 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 16:51:00/00:02:58, flags: (*, 225.0.0.10), 16:51:14/stopped, RP 10.1.255.1, flags: SJCFx Incoming interface: HundredGigE1/0/2, RPF nbr 172.16.11.1 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 16:51:14/00:02:45, flags: (10.2.254.1, 225.0.0.10), 00:00:01/00:02:57, flags: FTx Incoming interface: Loopback1, RPF nbr 0.0.0.0, Registering Outgoing interface list: HundredGigE1/0/2, Forward/Sparse, 00:00:01/00:03:27, flags: (*, 224.0.1.40), 1d18h/00:02:42, RP 10.1.255.1, flags: SJCL Incoming interface: HundredGigE1/0/2, RPF nbr 172.16.11.1 Outgoing interface list: Loopback0, Forward/Sparse, 1d18h/00:02:42, flags
Verificar EVPN L2
C9500X-LEAF-1#show l2vpn evpn evi 10 detail EVPN instance: 10 (VLAN Based) RD: 10.2.254.1:10 (auto) Import-RTs: 65002:10 Export-RTs: 65002:10 <snip> C9500X-LEAF-1#show nve peers 'M' - MAC entry download flag 'A' - Adjacency download flag '4' - IPv4 flag '6' - IPv6 flag Interface VNI Type Peer-IP RMAC/Num_RTs eVNI state flags UP time nve1 33000 L3CP 10.2.254.2 242a.0412.0102 33000 UP A/M/4 18:11:35 nve1 10010 L2CP 10.2.254.2 2 10010 UP N/A 00:36:00 nve1 10020 L2CP 10.2.254.2 2 10020 UP N/A 00:01:17 C9500X-LEAF-1#show bgp l2vpn evpn BGP table version is 5475, local router ID is 10.2.254.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, L long-lived-stale, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 10.2.254.1:10 *> [2][10.2.254.1:10][0][48][683B78FC8C9F][0][*]/20 10.2.254.2 0 65001 65002 ? *> [2][10.2.254.1:10][0][48][683B78FC8C9F][32][192.168.10.45]/24 10.2.254.2 0 65001 65002 ? <snip> C9500X-LEAF-1#show bgp l2vpn evpn detail [2][10.2.254.1:10][0][48][683B78FC8C9F][32][192.168.10.45]/24 BGP routing table entry for [2][10.2.254.1:10][0][48][683B78FC8C9F][32][192.168.10.45]/24, version 5371 Paths: (1 available, best #1, table evi_10) Not advertised to any peer Refresh Epoch 12 65001 65002, imported path from [2][10.2.254.2:10][0][48][683B78FC8C9F][32][192.168.10.45]/24 (global) 10.2.254.2 (via default) from 172.16.21.1 (10.1.255.2) Origin incomplete, localpref 100, valid, external, best EVPN ESI: 00000000000000000000, Label1 10010, Label2 33000 Extended Community: RT:1:1 RT:65002:10 ENCAP:8 Router MAC:242A.0412.0102 rx pathid: 0, tx pathid: 0x0 Updated on Dec 7 2023 01:52:33 UTC C9500X-LEAF-1#show device-tracking database <snip> Network Layer Address Link Layer Address Interface vlan prlvl age state Time left ARP 192.168.20.25 3c13.cc01.a7df Hu1/0/7 20 0005 3mn REACHABLE 103 s ARP 192.168.10.25 3c13.cc01.a7df Hu1/0/7 10 0005 20mn STALE try 0 943 s C9500X-LEAF-1#show l2vpn evpn mac ip IP Address EVI VLAN MAC Address Next Hop(s) --------------------------------------- ----- ----- -------------- ----------- 192.168.10.25 10 10 3c13.cc01.a7df Hu1/0/7:10 192.168.10.45 10 10 683b.78fc.8c9f 10.2.254.2
Verificar EVPN L3
C9500X-LEAF-1#show nve peers 'M' - MAC entry download flag 'A' - Adjacency download flag '4' - IPv4 flag '6' - IPv6 flag Interface VNI Type Peer-IP RMAC/Num_RTs eVNI state flags UP time nve1 33000 L3CP 10.2.254.2 242a.0412.0102 33000 UP A/M/4 18:50:51 nve1 10010 L2CP 10.2.254.2 2 10010 UP N/A 01:15:16 nve1 10020 L2CP 10.2.254.2 2 10020 UP N/A 00:31:39 9500X-LEAF-1#sh bgp l2vpn evpn BGP table version is 5523, local router ID is 10.2.255.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, L long-lived-stale, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path <snip> Route Distinguisher: 1:1 (default for vrf S1-EVPN) *> [5][1:1][0][24][192.168.10.0]/17 0.0.0.0 0 32768 ? *> [5][1:1][0][24][192.168.20.0]/17 0.0.0.0 0 32768 ? C9500X-LEAF-1#sh ip ro vrf S1-EVPN Routing Table: S1-EVPN <snip> 192.168.10.0/24 is variably subnetted, 4 subnets, 2 masks C 192.168.10.0/24 is directly connected, Vlan10 S 192.168.10.25/32 is directly connected, Vlan10 B 192.168.10.45/32 [20/0] via 10.2.254.2, 00:00:56, Vlan3000 L 192.168.10.254/32 is directly connected, Vlan10 192.168.20.0/24 is variably subnetted, 4 subnets, 2 masks C 192.168.20.0/24 is directly connected, Vlan20 S 192.168.20.25/32 is directly connected, Vlan20 B 192.168.20.45/32 [20/0] via 10.2.254.2, 00:49:54, Vlan3000 L 192.168.20.254/32 is directly connected, Vlan20
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
12-Feb-2024 |
Versão inicial |