(Era pra ser um post curto)
O que faz o comando vlan internal allocation policy ascending (que já vem configurado nos switches Cisco)?
Para responder isso precisamos falar de alguns outros itens antes.
Primeiro é importante lembrar que o padrão 802.1Q suporta até 4096 VLANs, e a quantidade de VLANs que podem estar ativas em um switch depende do modelo.
Segundo, em switches Cisco podemos criar VLANs de 1 à 1001 (standard) ou de 1006 à 4094 (extended). Os IDs de 1002 até 1005 são reservados, bem como as VLANs 0, 4095 e 4096, e não podem ser editadas ou deletadas.
Terceiro, sabemos que switches multilayers (MLS – Multi Layer Switch), suportam roteamento. E para isso podemos usar uma SVI – Switched Virtual Interface, ou uma Routed Port (porta física onde desabilitamos o modo switch com o comando no switchport e associamos IP).
Quando usamos uma SVI fazemos a associação dela com a respectiva VLAN explicitamente, ao colocar o mesmo ID na VLAN e na SVI.
Já quando usamos uma Routed Port não fazemos nenhuma amarração, e aparentemente a porta não pertence a nenhuma VLAN. No entanto, internamente o switch aloca uma VLAN para cada porta física roteada. Isso porque o switch, apesar de fazer o papel de roteador, continua sendo um switch, e os trâmites internos são realizados com base em VLANs.
Assim, para cada porta física L3 criada em um switch, é criada automaticamente uma VLAN (chamada internal usage VLAN) onde os protocolos L2 como Spanning-Tree são desabilitados. Estas VLANs não são divulgadas para outros switches e ficam “escondidas”.
O que o comando vlan internal allocation policy ascending faz (finalmente…) é justamente instruir o switch à escolher IDs para estas vlans internas a partir do 1006 (primeiro ID do range estendido), e acima, conforme necessidade.
Observe que no primeiro momento não havia nenhuma VLAN alocada. Depois de criar uma interface roteada a VLAN 1006 foi reservada.
Claro que se tentarmos criar uma VLAN 1006, não será possível (veja os logs apresentados).
Interessante notar que esta associação da vlan “interna” com a porta física é dinâmica, e caso coloquemos a porta em shutdown a associação é desfeita. Da mesma forma quando reiniciamos o equipamento a vlan utilizada pode mudar.
Depois de dar um shutdown na interface 2 e 3, e voltar a interface 3, a VLAN mudou.
Com tudo isso posto, fica claro que precisamos ter atenção quando usamos o range estendido. A boa prática diz que devemos começar usando o ID 4094 e descer, evitando (ou postergando) assim problemas com a alocação interna (e claro usar o comando show vlan internal usage para ver quais vlans já estão em uso no switch).
Alguns modelos suportam o comando vlan internal allocation policy descending, que faz o switch escolher os IDs a partir do 4094 e descer. Neste caso devemos fazer o contrário, e escolher os IDs a partir de 1006 e subir.
Se você precisar usar um ID que já está alocado internamente, basta dar shutdown na interface associada, criar a VLAN e voltar a porta (no shutdown). Ela usará o próximo ID livre de acordo com a política (ascending ou descending).
VTPv3
Quem usa VTPv3, capaz de gerenciar VLANs do range estendido, precisa ficar atento com as VLANs usadas internamente.
Quando você cria uma VLAN no VTP Server ele faz a checagem localmente, mas não verifica se o ID já está em uso nos demais switches do domínio VTP.
Assim, pode acontecer de você criar uma VLAN mas ela não ser criada em algum outro switch do domínio (e neste caso não vai ter log no VTP Server).
Mais informações neste link.
Até a próxima.
