Nota: Este Post faz parte do guide de Switching.
Software Upgrade
É possível fazer upgrades individualmente ou a todos os membros
!Fazer upgrade a um membro
{master:0}
user@Switch-1>request system software add member <member-id>
!Fazer upgrade a todos os membros
{master:0}
user@Switch-1>request system software add
Software Compatibility Check
Os novos membros fazem upgrade ao firmware para a mesma versão do master
Os upgrade podem ser feitos manualmente ou usando a feature que o faz automaticamente
Software Upgrades Using NSSU
Requisitos para suportar NSSU:
- Membros conectados em topologia ring
- Master e Backup devem ser adjacentes
- Line cards devem estar preprovisionadas na Line card role
- Os membros do virtual chassis tem no-split-configured configurado
- Todos os membros devem ter a mesma versao de firmware
- NSR e GRES deve estar activo
- Opcionalmente, pode ser activado o NSB(Non-stop bridging) bem como fazer backup ao firmware usando request system snapshot
Upgrade Process using NSSU
1.Download dos software packages e copia-los para /var/tmp
2.Login no master switch usando a consola ou VME interface
3.Iniciar o processo NSSU :
{master:0}
user@Switch> request system software nonstop-upgrade /var/tmp/package-name.tgz
Iniciar o processo NSSU numa plataforma mixed de Virtual Chassis
{master:0}
user@Switch> request system software nonstop-upgrade set [/var/tmp/package1-name.tgz /var/tmp/package2-name.tgz]
Topology Discovery
Os membros do Virtual Chassis usam Virtual Chassis Control Protocol (VCCP) para criar uma topologia loop-free
São trocadas mensagens link state advertisement (LSA) entre todos os PFEs, todos os membros build PFE topology maps.
Cada membro executa o algoritmo shortest-path first (SPF) para cada PFE criar uma PFE map table entre todos os PFEs.
Cada PFE cria source ID egrees filter tables usadas para prevenir looping de pacotes broadcast/multicast
Estas topology maps determinam o best path individualmente entre PFEs
O algoritmo SPF e baseado em hop count e bandwidth, em caso de falha e efectuada novo calculo de SPF
Inter-Chassis Packet Flow
Para minimizar a interrupção de tráfego durante o RE failover activar o Graceful Routing Engine switchover
{master:0}
user@Switch-1#set chassis redundancy graceful-switchover
Existem outras opcoes:
auto-sw-update – efectuar automaticamente upgrade ao firmware dos membros para a versao do master, by default feature disable
fast-failover – automaticamente faz reroute do trafego em caso de perda de um switch ou link. Cada VCP e automaticamente configurado com uma backup port dos mesmo tipo (dedicated VCP,SFP uplink VCP) ou XFP uplink VCP). A porta backup funciona como standby. Feature efectiva apenas na topologia ring usando portas identicas. By default feature activa, mas deve ser ativada para os uplinks convertidos para VCPs caso necessario
id – ID do Virtual Chassis, tem precedencia sob o assignado automaticamente
mac-persistence-timer – Se o switch master for removido/desconectado do Virtual Chassis, esta feature determina por quanto tempo e que o backup (new master) vai usar o antigo mac-address do old master switch
no-split-detection – desativar a feature de split e merge que by default esta enable. A feature de split and merge permite reagir ao “split brain” do virtual chassis
preprovisioned – permite determinar/controlar qual o role e ID de um member no virtual chassis. O preprovision faz link entre o serial number de cada member e o Role/ID.
Usando esta opção e necessário selecionar 2 members elegíveis para o processo de mastership, e devem ser designados como routing-engines, os restantes como Line Cards
O GRES não preserva o data-plane activo
Dynamic Configuration Process
Configurar no master a high prioriry (255), configurar o backup com high prioriry (255), e ligar os restantes switches sequencialmente
edit virtual-chassis member <member-id> mastership-priority <priority>
Preprovisioned Configuration
set virtual-chassis preprovisioned member 2 role routing-engine serial-number BM0208105170
set virtual-chassis preprovisioned member 3 role line-card serial-number BM0208105171
show virtual-chassis vc-port
Converter UPlinks em VCPs
{master:0}
user@Switch-1> request virtual-chassis vc-port set pic-slot 1 port 0 local
fpc0:
————————————————————————–
{master:0}
user@Switch-1> show interfaces terse vcp-255/1/0
Interface Admin Link Proto Local Remote
vcp-255/1/0 up down
vcp-255/1/0.32768 up down
{master:0}
user@Switch-1> show interfaces terse xe-0/1/0
error: device xe-0/1/0 not found
!Remover o VCP link colocando a interface no seu formato original (xe-0/1/0):
{master:0}
user@Switch-1> request virtual-chassis vc-port delete pic-slot 1 port 0 local
fpc0:
{master:0}
user@Switch-1> show interfaces terse vcp-255/1/0
error: device vcp-255/1/0 not found
{master:0}
user@Switch-1> show interfaces terse xe-0/1/0
Interface Admin Link Proto Local Remote
xe-0/1/0 up down
Chapter 7 High Availability Features
High Availability Features:
Link Aggregation Groups (LAG) – conhecido como 802.3ad
Redundant Trunk Groups (RTG) – pode ser usado como método alternativo ao Spanning-tree
Graceful Routing Engine switchover(GRES) – Permite mudar entre o master e o backup com uma interrupcao minima sincronizando as tabelas do kernel/PFE. Requer RE redundantes ou Virtual Chassis
Nonstop Active Routing switchover(NSR) – alta disponibilidade com RE redundantes ou Virtual Chassis, não requer o restart dos routing protocols sincronizando o processo rpd e routing information
Nonstop Bridging(NSB) – alta disponibilidade com RE redundantes ou Virtual Chassis, não requer o restart dos Layer 2 protocols sincronizando o processo RE e switching information
Link Aggregation Groups (LAG)
Mesmo Duplex/Speed
Ate 8 links por LAG
As portas podem pertencer a membros diferentes usando Virtual Chassis
Processing and Forwarding Considerations
O trafego RE e sempre enviado atraves do lowest member link
O hashing usa Layer 2, Layer 3 e Layer 4 no trafego IP
O Non-IP usa o source/destination MAC
Implementing LAG
set chassis aggregated-devices ethernet device-count 1
Nota: O device-count indica o numero de interfaces, p.exemplo: usando o valor 2 sao criados o ae0 e ae1
{master:0}[edit]
user@Switch-1# show chassis
aggregated-devices {
ethernet {
device-count 2;
}
}
{master:0}[edit]
user@Switch-1# run show interfaces terse | match ae
ae0 up down
ae1 up down
set interface ae0 unit 0 family ethernet-switching
set interface ae0 aggregated-ether-options lacp active
set interface ge-0/0/12 ether-options 802.3ad ae0
set interface ge-0/0/13 ether-options 802.3ad ae0
By default o LACP envia mensagens a cada 1 segundo, e possível modificar usando:
{master:0}[edit interfaces ae0 aggregated-ether-options lacp]
user@Switch-1# set periodic ?
Possible completions:
fast Transmit packets every second
slow Transmit packets every 30 seconds
Usando rates diferentes, o transmissor usa o rate do receptor
Redundant Trunk Groups (RTG)
Alternativa ao STP nos switches de acesso em acessos redundantes (uplinks), em access ou trunk mode
1 switch tem 2 uplinks ao Core, em que 1 dos links esta sempre activo o o outro em backup. Em caso de falha do active o backup fica activo. A convergência e inferior a 1 segundo
O Switch faz drop ao trafego no backup link , mas o tráfego controlo Layer 2 continua a ser permitido (LACP ou LLDP)
O RTG e tipicamente configurado apenas nos switches de accesso
O RTG e STP são mutuamente exclusivos numa porta
Os BPDUs do STP são descartados nos links RTG
O STP e configurado nos switches de agregação
Nota: Maximo 16 RTG por switch
Configuring RTG
set ethernet-switching-options redundant-trunk-group group rtg-1 interface ae0.0 primary
set ethernet-switching-options redundant-trunk-group group rtg-1 interface ge-0/0/10.0
se o primary for omitido, a highest interface e escolhida como activa. Não existe preempt em qualquer cenário
show redundant-trunk-group
Referências:
Notas estudo JNCIS-ENT parte 1
Notas estudo JNCIS-ENT parte 2
Notas estudo JNCIS-ENT parte 3
Notas estudo JNCIS-ENT parte 4
4 thoughts on “Notas estudo JNCIS-ENT parte 5”