Quando * não * criar um SVI para uma VLAN L2?

Ao criar VLANs apenas para L2 em um switch - o roteamento será tratado por um dispositivo dentro dessa VLAN, como um balanceador de carga - não é necessário criar a interface vlan . Por uma questão de hábito, eu sempre crio a interface de qualquer maneira - sem endereço IP -, então eu obtenho todos os bits da interface e estatísticas de pacotes na "interface sh".

Existem negativos para o que eu acho que é uma prática recomendada apenas criar a interface L2?

Quando você cria ou não a interface para uma VLAN L2?

Estou procurando respostas que discutam apenas VLANs L2, não os méritos e casos de uso de SVIs VLAN L3.

A Cisco reporta uma interface L2 como EtherSVI no meu 6500 - sem endereço IP. É correto ou incorreto ainda pensar em uma interface L2 como um SVI, embora todos nós sabemos que o caso de uso usual é ter um endereço IP para roteamento? A questão é apenas se devo ou não ter essa interface L2 em primeiro lugar. Você pode ver que apenas os contadores L2 são incrementados, mas ainda dando algum valor.

s-oc4-n2-agg1#sh int vl281
Vlan281 is up, line protocol is up
  Hardware is EtherSVI, address is 0019.a925.2000 (bia 0019.a925.2000)
  Description: svi.SLB-FE-Web-Servers
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not supported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:02, output 00:00:10, output hang never
  Last clearing of "show interface" counters 1d12h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  L2 Switched: ucast: 1138722618 pkt, 1070173012274 bytes - mcast: 76471 pkt, 8482399 bytes
  L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
  L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
     74604 packets input, 8350307 bytes, 0 no buffer
     Received 74604 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     218 packets output, 17658 bytes, 0 underruns
     0 output errors, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out

Você pode não querer criar um SVI L2 se usar a remoção de VTP. Se a remoção estiver ativada, uma VLAN não utilizada será removida do tronco, resultando em menos tráfego de transmissão / inundação desnecessário. No entanto, a criação de um SVI cria uma interface "ativa" no seu switch. Uma verificação rápida no GNS3 fornece o seguinte:

R1#show vlan-switch

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa1/1, Fa1/2, Fa1/3, Fa1/4
                                                Fa1/5, Fa1/6, Fa1/7, Fa1/8
                                                Fa1/9, Fa1/10, Fa1/11, Fa1/12
                                                Fa1/13, Fa1/14, Fa1/15
3    VLAN0003                         active
4    VLAN0004                         active
[output omitted]

R1#show interfaces trunk

Port      Mode         Encapsulation  Status        Native vlan
Fa1/0     on           802.1q         trunking      1

Port      Vlans allowed on trunk
Fa1/0     1-4094

Port      Vlans allowed and active in management domain
Fa1/0     1,3-4

Port      Vlans in spanning tree forwarding state and not pruned
Fa1/0     1

Agora, se eu for para o R2, conectado ao Fa1 / 0 e digitar R2(config)#int vlan 3, veremos o seguinte:

R2#show run interface vlan 3
Building configuration...

Current configuration : 38 bytes
!
interface Vlan3
 no ip address
end
R2#show run | include vlan 3
R2#

Como você pode ver, não há interfaces na VLAN 3, exceto o SVI. E de volta ao R1:

R1#show interfaces trunk

Port      Mode         Encapsulation  Status        Native vlan
Fa1/0     on           802.1q         trunking      1

Port      Vlans allowed on trunk
Fa1/0     1-4094

Port      Vlans allowed and active in management domain
Fa1/0     1,3-4

Port      Vlans in spanning tree forwarding state and not pruned
Fa1/0     1,3

Como você pode ver, a VLAN 3 surgiu no porta-malas , aumentando os níveis de tráfego nos seus troncos.

Eu não diria que é uma prática recomendada criar um SVI. No entanto, acho que não haverá muito problema se você o criar. Por exemplo, o Catalyst 3750 suporta 1000 SVIs que você provavelmente não terá.

Q. Quantos SVIs podem ser criados nos comutadores Cisco Catalyst 3750 Series? A. Até 1000 SVIs podem ser criados. No entanto, o número máximo de SVIs depende do número de rotas e entradas de multicast. Por exemplo, o switch pode suportar 64 SVIs com 8000 rotas e 250 entradas multicast.

Pela minha experiência, os contadores de SVIs não podem realmente ser confiáveis.

Eu nunca crio um SVI quando não há um requisito especial para ele. Não vejo desvantagem, mas sem adicionar linhas inúteis, você mantém a configuração do dispositivo limpa. Isso pode ajudar durante as sessões de solução de problemas.

Um SVI é útil quando você deve fornecer um serviço de Camada3 às portas de switch Ethernet conectadas .

Os SVIs fornecem uma maneira eficiente de conectar serviços de roteamento IP a uma Vlan Ethernet que já existe em um switch. Ele efetivamente evita que você compre um roteador externo apenas para oferecer HSRP, ou protocolos de roteamento dinâmico.

Quando você não cria o SVI para uma VLAN L2?

Quando você não deseja que os usuários tenham exposição a esses recursos ou não quer complicar a configuração. Isso é apenas uma questão de gosto ... Eu nunca defino um SVI, a menos que precise de serviços de roteamento IP em uma Vlan ... mas prefiro configurações mínimas sempre que possível.

Eu não consideraria isso uma prática recomendada, como se você não deseja que a opção forneça a funcionalidade L3, ela não é necessária ou útil. Agora, eu quero preceder o resto disso dizendo que nunca faço isso a menos que queira a funcionalidade L3, para que eu possa estar errado.

Você menciona os contadores, mas os contadores não devem aumentar, a menos que o tráfego entre "dentro" ou "fora" da interface. Suspeito que, se você abranger um SVI usado conforme mencionado, não verá o tráfego esperado.

Eu também teria preocupações sobre o que o switch faria com certos recursos e não me sentiria confortável em testá-los. Por exemplo, se você também não desativou o proxy-arp no SVI, ele ainda responderá com o endereço MAC do SVI para hosts em outras VLANs? Eu suspeito que sim, e se o fizer, ele encaminhará esse tráfego para outra VLAN?

Adicionar IP acessível para VLAN é potencialmente perigoso do ponto de vista da segurança.

Também é uma ameaça do ponto de vista da estabilidade, pois o tráfego para o IP (incluindo ARP, IPv6 ND e assim por diante) atinge a fila da CPU. Se você possui uma VLAN simples apenas com L2, não há nada além dos protocolos L2 (haha) que podem influenciar a situação do switch e seu plano de controle. Se você adicionar informações de acessibilidade L3, de repente você estará lidando com o que a L3 tem a oferecer, incluindo protocolos de roteamento, blackholing, entradas limitadas de FIB, potencialmente também diferentes modelos de QoS possíveis ao lidar com L2 vs L3.

De qualquer forma, você está adicionando complexidade à rede. Complexidade é ruim.

Como a regra do KISS diz, você NÃO adiciona "SVI automaticamente" à VLAN L2. Se for apenas para operação L2, eu o adicionaria à 'descrição' da interface.

Existem algumas plataformas como a minha "favorita" 6500 que podem ter fortes reações negativas a alguns tipos ou quantidades de tráfego que são perfeitamente boas ao serem completamente trocadas pelo roteador, tornando-se uma história diferente quando você cria um SVI. Normalmente, isso seria tráfego não-IP, mas é muito difícil de prever.

Se a VLAN em questão é 'privada' e não é roteada L3 em nenhum lugar (digamos, um batimento cardíaco de cluster), um SVI no comutador de camada 2 permitirá que o seu NOC faça ping nas interfaces e obtenha tabelas ARP, o que é uma grande ajuda na solução de problemas. Se a VLAN em questão for roteada, não há grande benefício, exceto como medida temporária para provar que uma VLAN é troncalizada para esse comutador (alguns servidores precisam de provas) executando o ping no gateway padrão dessa VLAN a partir do comutador.