Exemplo de configuração de rede virtual fácil

Opções de download

  • PDF     (317.7 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (140.9 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (133.6 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:4 de agosto de 2014
ID do documento:117974

Linguagem imparcial

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.

Sobre esta tradução

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.

Introduction

Este documento descreve o recurso Easy Virtual Network (EVN), projetado para fornecer um mecanismo de virtualização fácil e simples de configurar em redes de campus. Ele aproveita as tecnologias atuais, como Virtual Routing and Forwarding-Lite (VRF-Lite) e o encapsulamento dot1q, e não introduz nenhum novo protocolo.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nas seguintes versões de hardware e software:

  • Switches Cisco Catalyst 6000 (Cat6k) Series que executam a versão de software 15.0(1)SY1

  • Roteadores de serviços agregados Cisco 1000 Series (ASR1000) que executam a versão de software 3.2s

  • Roteadores de serviços integrados Cisco 3925 e 3945 Series que executam o Cisco IOS® versões 15.3(2)T e posteriores

  • Switches Cisco Catalyst 4500 (Cat4500) e 4900 (Cat4900) Series que executam o software versão 15.1(1)SG

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informações de Apoio

Aqui está uma visão geral do recurso EVN:

  • O recurso EVN usa VRF-Lite para criar vários (até 32) contextos de roteamento.

  • A conectividade dentro do Virtual Routing and Forwarding (VRF) entre dispositivos de Camada 3 é garantida através de troncos de Rede Virtual (VNET).

  • Os troncos VNET são troncos dot1q regulares.

  • Cada VRF que deve ser transportado através dos troncos VNET deve ser configurado com uma marca VNET.

  • Cada marca VNET é igual a uma marca dot1q.

  • As subinterfaces dot1q são criadas e ocultadas automaticamente.

  • A configuração da interface principal é herdada por todas as subinterfaces (ocultas).

  • Instâncias separadas de protocolos de roteamento devem ser usadas em cada VRF sobre troncos VNET para anunciar a acessibilidade do prefixo.

  • O vazamento de rota dinâmica entre VRFs (ao contrário das rotas estáticas) é permitido sem o uso do Border Gateway Protocol (BGP).

  • O recurso é suportado para IPv4 e IPv6.

Configurar

Use as informações descritas nesta seção para configurar o recurso EVN.

Note: Use a Command Lookup Tool ( somente clientes registrados) para obter mais informações sobre os comandos usados nesta seção.

Diagrama de Rede

Essa configuração de rede é usada para ilustrar a configuração do EVN e os comandos show:

Aqui estão algumas notas importantes sobre esta configuração:

  • Dois VRFs são definidos (CUST-A e CUST-B) que são executados a partir do núcleo da rede através de troncos VNET.

  • O OSPF (Open Shortest Path First) é usado nos VRFs para anunciar a acessibilidade.

  • O VRF COM hospeda um servidor comum (100.1.1.100) que deve ser alcançável do VRF CUST-A e CUST-B.

  • A imagem usada é i86bi_linux-adventerprise9-ms.153-1.S.

Tip: A configuração do Cisco IOS no Linux (IOL) usada está disponível aqui.

Configurar EVN

Conclua estes passos para configurar o recurso EVN:

  1. Configure a definição de VRF:
    vrf definition [name]
    vnet tag [2-4094]
    !
    address-family ipv4|ipv6
    exit-address-family
    !
    Aqui estão algumas observações importantes sobre esta configuração:

    • A Cisco recomenda que você use tags no intervalo de 2 a 1.000. Não use as VLANs 1.001 a 1.005 reservadas. As VLANs estendidas de 1.006 a 4.094 podem ser usadas, se necessário.

    • A marca VNET não deve ser usada por uma VLAN atual.

    • As marcas VNET devem ser as mesmas em todos os dispositivos para qualquer VRF especificado.

    • O endereço-família ipv4|ipv6 deve ser configurado para ativar o VRF no AF relacionado.

    • Não há necessidade de definir uma Direção de Rota (RD) porque o EVN não usa BGP.

    Com essa configuração, os VRFs devem ser definidos em todos os roteadores de núcleo 4x. Por exemplo, no CORE-1:
    vrf definition CUST-A
       vnet tag 100
       !
       address-family ipv4
       exit-address-family
      vrf definition CUST-B
       vnet tag 200
       !
       address-family ipv4
       exit-address-family
    Use a mesma marca VNET em todos os roteadores para esses VRFs. No CORE-4, VRF COM não requer uma marca VNET. O objetivo é manter esse VRF local no CORE-4 e configurar o vazamento e a redistribuição para fornecer acesso ao servidor comum do CUST-A e do CUST-B.

    Insira este comando para verificar vários contadores VNET:
    CORE-1#show vnet counters
      Maximum number of VNETs supported: 32
      Current number of VNETs configured: 2
      Current number of VNET trunk interfaces: 2
      Current number of VNET subinterfaces: 4
      Current number of VNET forwarding interfaces: 6
      CORE-1#
  2. Configure o tronco VNET:
    interface GigabitEthernetx/x
      vnet trunk
      ip address x.x.x.x y.y.y.y
      ...
    Aqui estão algumas observações importantes sobre esta configuração:

    • O comando vnet trunk cria tantas subinterfaces dot1q como o número de VRFs definidos com uma marca VNET.

    • O comando vnet trunk não pode coexistir com algumas subinterfaces configuradas manualmente na mesma interface física.

    • Essa configuração é permitida em interfaces roteadas (não portas de switch), físicas e de canal de porta.

    • Os endereços IP (e outros comandos) aplicados na interface física são herdados pelas subinterfaces.

    • As subinterfaces de todos os VRFs usam o mesmo endereço IP.

    Com essa configuração, há dois VRFs VNET, de modo que duas subinterfaces são criadas automaticamente na interface configurada como o tronco VNET. Você pode inserir o comando show derivado-config para exibir a configuração oculta que é criada automaticamente:

    Esta é a configuração que é executada atualmente:
    CORE-1#show run | s Ethernet0/0 
    interface Ethernet0/0
     vnet trunk
     ip address 192.168.1.1 255.255.255.252
     !
    CORE-1#
    Esta é a configuração derivada:
    CORE-1#show derived-config | s Ethernet0/0
    interface Ethernet0/0
     vnet trunk
     ip address 192.168.1.1 255.255.255.252
    Interface Ethernet0/0.100
     description Subinterface for VNET CUST-A
     encapsulation dot1Q 100
     vrf forwarding CUST-A
     ip address 192.168.1.1 255.255.255.252
    interface Ethernet0/0.200
     description Subinterface for VNET CUST-B
     encapsulation dot1Q 200
     vrf forwarding CUST-B
     ip address 192.168.1.1 255.255.255.252
    CORE-1#
    Como mostrado, todas as subinterfaces herdam o endereço IP da interface principal.

  3. Atribuir (sub)interfaces de borda aos VRFs. Para atribuir uma interface ou subinterface a um VRF VNET, use o mesmo procedimento usado para atribuir um VRF normalmente:
    interface GigabitEthernet x/x.y
     vrf forwarding [name]
      ip address x.x.x.x y.y.y.y
      ...
    Com essa configuração, a configuração é aplicada no CORE-1 e no CORE-4. Aqui está um exemplo para o CORE-4:
    interface Ethernet2/0
       vrf forwarding CUST-A
       ip address 10.1.2.1 255.255.255.0
      !
      interface Ethernet3/0
       vrf forwarding CUST-B
       ip address 10.2.2.1 255.255.255.0
      !
      interface Ethernet4/0
       vrf forwarding COM
       ip address 100.1.1.1 255.255.255.0
  4. Configurar protocolos de roteamento para cada VRF (isso não é específico para EVN ou VNET):
    router ospf x vrf [name]
      network x.x.x.x y.y.y.y area x
      ...

    Note: Essa configuração deve incluir os endereços de tronco VNET, bem como os endereços da interface de borda.


    Com essa configuração, dois processos OSPF são definidos, um por VRF:
    CORE-1#show run | s router os
      router ospf 1 vrf CUST-A
       network 10.1.1.0 0.0.0.255 area 0
       network 192.168.1.0 0.0.0.255 area 0
      router ospf 2 vrf CUST-B
       network 10.2.1.0 0.0.0.255 area 0
       network 192.168.1.0 0.0.0.255 area 0
      CORE-1#
    Você pode entrar no modo de contexto de roteamento para visualizar as informações relacionadas a um VRF específico sem as especificações de VRF em cada comando: 
    CORE-1#routing-context vrf CUST-A
      CORE-1%CUST-A#
      CORE-1%CUST-A#show ip protocols
      *** IP Routing is NSF aware ***
      Routing Protocol is "ospf 1"
        Outgoing update filter list for all interfaces is not set
        Incoming update filter list for all interfaces is not set
        Router ID 192.168.1.13
        It is an area border router
        Number of areas in this router is 1. 1 normal 0 stub 0 nssa
        Maximum path: 4
        Routing for Networks:
          10.1.1.0 0.0.0.255 area 0
          192.168.1.0 0.0.0.255 area 0
        Routing Information Sources:
          Gateway         Distance      Last Update
          192.168.1.9          110      1d00h
          192.168.1.14         110      1d00h
        Distance: (default is 110)
      CORE-1%CUST-A#
      CORE-1%CUST-A#show ip os neighbor 
    Neighbor ID     Pri   State         Dead Time   Address         Interface
    192.168.1.14      1   FULL/DR       00:00:30    192.168.1.14    Ethernet1/0.100
    192.168.1.5       1   FULL/BDR      00:00:37    192.168.1.2     Ethernet0/0.100
    10.1.1.2          1   FULL/BDR      00:00:33    10.1.1.2        Ethernet2/0
    CORE-1%CUST-A#

    Note: A saída do comando show ip protocols exibe apenas as informações relacionadas ao VRF selecionado.


    Quando você visualiza o Routing Information Base (RIB) para ambos os VRFs, é possível verificar a sub-rede remota através dos dois troncos VNET:
    CORE-1%CUST-A#show ip route 10.1.2.0   
      Routing Table: CUST-A
      Routing entry for 10.1.2.0/24
        Known via "ospf 1", distance 110, metric 30, type intra area
        Last update from 192.168.1.2 on Ethernet0/0.100, 1d00h ago
        Routing Descriptor Blocks:
        * 192.168.1.14, from 192.168.1.9, 1d00h ago, via Ethernet1/0.100
            Route metric is 30, traffic share count is 1
          192.168.1.2, from 192.168.1.9, 1d00h ago, via Ethernet0/0.100
            Route metric is 30, traffic share count is 1
      CORE-1%CUST-A#
      CORE-1%CUST-A#routing-context vrf CUST-B
      CORE-1%CUST-B#
      CORE-1%CUST-B#show ip route 10.2.2.0
      Routing Table: CUST-B
      Routing entry for 10.2.2.0/24
        Known via "ospf 2", distance 110, metric 30, type intra area
        Last update from 192.168.1.2 on Ethernet0/0.200, 1d00h ago
        Routing Descriptor Blocks:
        * 192.168.1.14, from 192.168.1.6, 1d00h ago, via Ethernet1/0.200
            Route metric is 30, traffic share count is 1
          192.168.1.2, from 192.168.1.6, 1d00h ago, via Ethernet0/0.200
            Route metric is 30, traffic share count is 1
      CORE-1%CUST-B#
      CORE-1%CUST-B#exit
      CORE-1#
      CORE-1#
  5. Determine o vazamento da rota entre os VRFs. O vazamento de rota é realizado por meio da replicação de rota. Por exemplo, algumas rotas em um VRF podem ser disponibilizadas para outro VRF: 
    vrf definition VRF-X
      address-family ipv4|ipv6
       route-replicate from vrf VRF-Y unicast|multicast
        [route-origin] [route-map [name]]
    Aqui estão algumas observações importantes sobre esta configuração:

    • O RIB para VRF-X tem acesso às rotas selecionadas, com base nos parâmetros de comando do VRF-Y.

    • As rotas replicadas no VRF-X são marcadas com um flag [+].

    • A opção multicast permite o uso de rotas de outro VRF para RPF (Reverse Path Forwarding).

    • A origem da rota pode ter um destes valores:

      • todos os
      • bgp
      • conectado
      • eigrp
      • isis
      • móvel
      • odr
      • ospf
      • rip
      • estático

    Ao contrário do nome indica, as rotas não são replicadas ou duplicadas; esse é o caso com vazamento normal através de RT comum de BGP, que não consome memória extra.

    Com essa configuração, o vazamento de rota é usado no CORE-4 para fornecer acesso de CUST-A e CUST-B a COM (e vice-versa):
    vrf definition CUST-A
      address-family ipv4
         route-replicate from vrf COM unicast connected
    !
    vrf definition CUST-B
      address-family ipv4
         route-replicate from vrf COM unicast connected
    !
    vrf definition COM
      address-family ipv4
         route-replicate from vrf CUST-A unicast ospf 1 route-map USERS
         route-replicate from vrf CUST-B unicast ospf 2 route-map USERS
    !
    route-map USERS permit 10
      match ip address prefix-list USER-SUBNETS
    !
    ip prefix-list USER-SUBNETS seq 5 permit 10.0.0.0/8 le 32

    CORE-4#show ip route vrf CUST-A
    Routing Table: COM
    Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
           E1 - OSPF external type 1, E2 - OSPF external type 2
           i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
           ia - IS-IS inter area,* - candidate default, U - per-user static route
           o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
           a - application route
           + - replicated route, % - next hop override
    ...
           10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
    O        10.1.1.0/24 [110/30] via 192.168.1.10, 3d19h, Ethernet1/0.100
               [110/30] via 192.168.1.5, 3d19h, Ethernet0/0.100
           100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
    C   +    100.1.1.0/24 is directly connected (COM), Ethernet4/0
        
    CORE-4#show ip route vrf CUST-B
    ...       10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
    O        10.2.1.0/24 [110/30] via 192.168.1.10, 1d00h, Ethernet1/0.200
               [110/30] via 192.168.1.5, 1d00h, Ethernet0/0.200
           100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
    C   +    100.1.1.0/24 is directly connected (COM), Ethernet4/0

    CORE-4#show ip route vrf COM   
    ...
           10.0.0.0/24 is subnetted, 2 subnets
    O   +    10.1.1.0 [110/30] via 192.168.1.10 (CUST-A), 3d19h, Ethernet1/0.100
               [110/30] via 192.168.1.5 (CUST-A), 3d19h, Ethernet0/0.100
    O   +    10.2.1.0 [110/30] via 192.168.1.10 (CUST-B), 1d00h, Ethernet1/0.200
               [110/30] via 192.168.1.5 (CUST-B), 1d00h, Ethernet0/0.200
           100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
    C        100.1.1.0/24 is directly connected, Ethernet4/0
    Nesse ponto, as rotas replicadas não são propagadas no Interior Gateway Protocol (IGP), portanto, somente CE-A-2 e CE-B-2 têm acesso ao serviço COM (100.1.1.100), não CE-A-1 e CE-B-1.

    Você também pode usar o vazamento de rota de ou para uma tabela global:
    vrf definition VRF-X
     address-family ipv4
      route-replicate from vrf >global unicast|multicast [route-origin]
       [route-map [name]]
      exit-address-family
     !
     exit
    !
    global-address-family ipv4 unicast 
     route-replicate from vrf [vrf-name] unicast|multicast [route-origin]
      [route-map [name]]
  6. Defina a propagação de vazamento de rota. As rotas vazadas não são duplicadas no RIB do VRF de destino. Em outras palavras, eles não fazem parte do RIB do VRF de destino. A redistribuição normal entre os processos do roteador não funciona, então você deve definir explicitamente a conexão VRF do RIB à qual a rota pertence:
    router ospf x vrf VRF-X
      redistribute vrf VRF-Y [route-origin] [route-map [name]]
    As rotas vazadas do VRF-Y são redistribuídas no processo OSPF executado no VRF-X. Veja um exemplo no CORE-4:
    router ospf 1 vrf CUST-A
       redistribute vrf COM connected subnets route-map CON-2-OSPF
    !
    route-map CON-2-OSPF permit 10
     match ip address prefix-list COM
    !
    ip prefix-list COM seq 5 permit 100.1.1.0/24
    O mapa de rota não é necessário nesse caso, pois há apenas uma rota conectada no VRF COM. Agora há acessibilidade para o serviço COM (100.1.1.100) do CE-A-1 e do CE-B-1:
    CE-A-1#ping 100.1.1.100
      Type escape sequence to abort.
      Sending 5, 100-byte ICMP Echos to 100.1.1.100, timeout is 2 seconds:
      !!!!!
      Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
      CE-A-1#

    CE-B-1#ping 100.1.1.100
      Type escape sequence to abort.
      Sending 5, 100-byte ICMP Echos to 100.1.1.100, timeout is 2 seconds:
      !!!!!
      Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
      CE-B-1#

Ajustar o tronco VNET

Esta seção fornece informações que você pode usar para ajustar o tronco VNET.

Lista de Troncos

Por padrão, todos os VRFs configurados com uma marca VNET são permitidos em todos os troncos VNET. Uma lista de troncos permite especificar a lista de VRFs autorizados no tronco VNET:

vrf list [list-name]
  member [vrf-name]
!
interface GigabitEthernetx/x
  vnet trunk list [list-name]

Note: Deve haver uma linha por VRF permitido.

Como exemplo, o CORE-1 é ajustado para o VRF CUST-B no tronco VNET entre CORE-1 e CORE-2:

vrf list TEST
 member CUST-A
!
interface ethernet0/0
 vnet trunk list TEST

Como mostrado, o peering OSPF para VRF CUST-B através do tronco cai:

%OSPF-5-ADJCHG: Process 2, Nbr 192.168.1.2 on Ethernet0/0.200 from FULL to DOWN,
 Neighbor Down: Interface down or detached

A subinterface do VRF CUST-B é removida:

CORE-1#show derived-config | b Ethernet0/0 
  interface Ethernet0/0
   vnet trunk list TEST
   ip address 192.168.1.1 255.255.255.252
  !
  interface Ethernet0/0.100
   description Subinterface for VNET CUST-A
   encapsulation dot1Q 100
   vrf forwarding CUST-A
   ip address 192.168.1.1 255.255.255.252
  !

Atributos de tronco por VRF

Por padrão, as subinterfaces dot1q herdam os parâmetros da interface física para que as subinterfaces de todos os VRFs tenham os mesmos atributos (como custo e autenticação). Você pode ajustar os parâmetros de tronco por tag VNET:

interface GigaEthernetx/x
  vnet trunk
  vnet name VRF-X
   ip ospf cost 100
  vnet name VRF-Y
   ip ospf cost 15

Você pode ajustar estes parâmetros:

CORE-1(config-if-vnet)#?
      Interface VNET instance override configuration commands:
        bandwidth     Set bandwidth informational parameter
        default       Set a command to its defaults
        delay         Specify interface throughput delay
        exit-if-vnet  Exit from VNET submode
        ip            Interface VNET submode Internet Protocol config commands
        no            Negate a command or set its defaults
        vnet          Configure protocol-independent VNET interface options
      CORE-1(config-if-vnet)#
      CORE-1(config-if-vnet)#ip ?     
        authentication      authentication subcommands
        bandwidth-percent   Set EIGRP bandwidth limit
        dampening-change    Percent interface metric must change to cause update
        dampening-interval  Time in seconds to check interface metrics
        hello-interval      Configures EIGRP-IPv4 hello interval
        hold-time           Configures EIGRP-IPv4 hold time
        igmp                IGMP interface commands
        mfib                Interface Specific MFIB Control
        multicast           IP multicast interface commands
        next-hop-self       Configures EIGRP-IPv4 next-hop-self
        ospf                OSPF interface commands
        pim                 PIM interface commands
        split-horizon       Perform split horizon
        summary-address     Perform address summarization
        verify              Enable per packet validation
      CORE-1(config-if-vnet)#ip

Neste exemplo, o custo OSPF por VRF para CORE-1 é alterado, de modo que o caminho CORE-2 é usado para CUST-A e o caminho CORE-3 para CUST-B (o custo padrão é 10):

interface Ethernet0/0
  vnet name CUST-A
    ip ospf cost 8
  !
  vnet name CUST-B
    ip ospf cost 12
  !

CORE-1#show ip route vrf CUST-A 10.1.2.0 
      
Routing Table: CUST-A
Routing entry for 10.1.2.0/24
 Known via "ospf 1", distance 110, metric 28, type intra area
 Last update from 192.168.1.2 on Ethernet0/0.100, 00:05:42 ago
 Routing Descriptor Blocks:
 * 192.168.1.2, from 192.168.1.9, 00:05:42 ago, via Ethernet0/0.100
   Route metric is 28, traffic share count is 1
CORE-1#
CORE-1#show ip route vrf CUST-B 10.2.2.0
      
Routing Table: CUST-B
Routing entry for 10.2.2.0/24
 Known via "ospf 2", distance 110, metric 30, type intra area
 Last update from 192.168.1.14 on Ethernet1/0.200, 00:07:03 ago
 Routing Descriptor Blocks:
 * 192.168.1.14, from 192.168.1.6, 1d18h ago, via Ethernet1/0.200
   Route metric is 30, traffic share count is 1
CORE-1#

Marcas de VNET por link

Por padrão, a marca VNET definida na definição de VRF é usada para todos os troncos. No entanto, você pode usar uma marca VNET diferente por tronco.

Este exemplo descreve um cenário em que você está conectado a um dispositivo sem capacidade de EVN e usa VRF-Lite com um tronco manual, e a marca global VNET é usada por outra VLAN:

Com essa configuração, a marca VNET usada no tronco entre CORE-1 e CORE-2 para CUST-A é alterada de 100 para 101:

interface Ethernet0/0
  vnet name CUST-A
   vnet tag 101

Após essa alteração ocorrer no CORE-1, uma nova subinterface será criada:

CORE-1#show derived-config | b Ethernet0/0       
interface Ethernet0/0
 vnet trunk
 ip address 192.168.1.1 255.255.255.252
!
interface Ethernet0/0.101
 description Subinterface for VNET CUST-A
 encapsulation dot1Q 101
 vrf forwarding CUST-A
 ip address 192.168.1.1 255.255.255.252
!
interface Ethernet0/0.200
 description Subinterface for VNET CUST-B
 encapsulation dot1Q 200
 vrf forwarding CUST-B
 ip address 192.168.1.1 255.255.255.252

Se essa alteração ocorrer somente em uma extremidade, a conectividade será perdida no VRF associado e o OSPF será desativado:

%OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.5 on Ethernet0/0.101 from FULL to DOWN,
 Neighbor Down: Dead timer expired

Quando a mesma marca VNET é usada no CORE-2, a conectividade é restaurada e a marca dot1q 101 é usada nesse tronco enquanto 100 ainda é usada no tronco CORE-1 para CORE-3:

%OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.5 on Ethernet0/0.101 from LOADING to
 FULL, Loading Done

Verificar

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshoot

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Informações Relacionadas

Histórico de revisões

Revisão Data de publicação Comentários
1.0
04-Aug-2014
Versão inicial
TAC Authored

Colaborado por engenheiros da Cisco

  • Fabrice Ducomble
    Cisco TAC Engineer.

Este documento lhe foi útil?

FeedbackFeedback

Contate a Cisco

Este documento se refere a estes produtos