Tag Archives: Graceful Routing Engine switchover

Notas estudo JNCIS-ENT parte 14

Nota: Este Post faz parte do guide de Routing.

Graceful Routing Engine switchover (GRES)

GRES Inactivo –  o PFE é reiniciado e o novo Master faz discover de todo o hardware e interfaces. O novo master faz restart ao processo rpd

GRES Activo – o PFE não é reiniciado e toda a informação do kernel/interfaces e preservada. O GRES reduz o tempo de convergência, mesmo reiniciando o rpd

Após os REs serem sincronizados são trocados keepalives, se o backup RE não receber o keepalive durante um periodo de tempo (tipicamente 2 segundos) faz o switchover, e o PFE liga-se ao novo RE.

{master}
[email protected]>  show chassis routing-engine
Routing Engine status:
Slot 0:
Current state                  Master
Election priority              Master (default)

Routing Engine status:
Slot 1:
Current state                  Backup
Election priority              Backup (default)

Nonstop active routing (NSR) – Preserva a informação do Kernel/interfaces, o processo rpd e também executado no Backup RE. O GRES deve estar activo para o NSR operar corretamente
Bidirectional Forwarding Detection (BFD)
Virtual Router Redundancy Protocol (VRRP)
Unified In-Service Software Upgrade (ISSU) – suportado apenas em devices com 2 REs. O GRES e NSR devem estar activos

Garantir que cada RE tem um IP diferente de OOB Management.
set groups re1 system host-name R1-re1
set groups re1 system backup-router 172.18.66.1
set groups re1 interface fxp0 unit 0 family inet address 172.18.66.51/24

set groups re1 system host-name R1-re0
set groups re1 system backup-router 172.18.66.1
set groups re1 interface fxp0 unit 0 family inet address 172.18.66.50/24

{master}[edit]
[email protected]#  set apply-groups [re0 re1]

Caso seja usado o GRES deve ser configurado commit synchronize

[email protected]#  set chassis commit
warning: graceful-switchover is enabled, commit synchronize should be used
commit complete

{master}
[email protected]#  set system commit synchronize

{master}
[email protected]#  system commit
re0:
configuration check succeeds
re1:
commit complete
re0:
commit complete

Se o GRES não estive activo, e recomendado implementar o RE failover protection. O default keepalive e de 300 segundos

[edit chassis redundancy]
[email protected]# set ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don’t inherit configuration data from these groups
> failover             Failover to other Routing Engine
keepalive-time       Time before Routing Engine failover (2..10000 seconds)
> routing-engine       Redundancy options for Routing Engines

É possível realizar o switchover manual usando request chassis routing-engine master

[email protected]> request chassis routing-engine master ?
Possible completions:
acquire              Attempt to become master Routing Engine
release              Request that other Routing Engine become master
switch               Toggle mastership between Routing Engines

Configuring Graceful RE Switchover

set chassis redundancy graceful-switchover

{master}[edit chassis]
[email protected]#

{backup}[edit chassis]
[email protected]#

Monitoring Graceful RE Switchover

!Este comando só e valido no Backup RE
{backup}
[email protected]> show system switchover
Graceful switchover: On
Configuration database: Ready
Kernel database: Ready
Peer state: Steady State

Configuration database – configuration database, ou repository of configuration files, e replicada pelo processo commit synchronize
Kernel and related entries – ksyncd responsável pelo replicação dos estados entre as varias componentes de hardware
PFE state – chassisd efetua a replicaco do estado do PFE

Nonstop Active Routing

Configuring NSR

Usando o NSR as adjacências continuam UP mesmo depois do switchover, ambos os REs executam o processo rpd preservando a informação do kernel e interfaces.
O NSR não usa o helper mode do GR para restaurar a routing information, este requer que ambos os REs usem a mesma versão de software. não é possível ter o GR e NSR activos em simultâneo.

{master}
[email protected]# set routing-options nonstop-routing

!Activar o commit synchronize
[email protected]#  set system commit ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don’t inherit configuration data from these groups
synchronize          Synchronize commit on both Routing Engines by default

 Monitoring NSR

{master}
[email protected]> show task replication
Stateful Replication: Enabled
RE mode: Master
Protocol        Synchronization Status
OSPF            Complete
BGP                Complete

{master}
[email protected]>  request routing-engine login other-routing-engine

— junOS 10.1R1.8 built 2010-02-12 18:31:54 UTC
{backup}
[email protected]>  show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.1.1.2         fe-0/0/1.0             Full      192.168.100.2    128     0
10.1.2.2         fe-0/0/2.0             Full      192.168.100.3    128     0
{backup}
[email protected]>  show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                10         10          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped…
192.168.100.2         64700         55         54       0       0       24:29 5/5/5/0
0/0/0/0
192.168.100.3         64700         54         52       0       0       23:53 5/5/5/0
0/0/0/0

{backup}
[email protected]>  show route protocol ospf
inet.0: 21 destinations, 34 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
192.168.100.2/32   *[OSPF/10] 00:39:47, metric 1
> to 10.1.1.2 via fe-0/0/1.0
192.168.100.3/32   *[OSPF/10] 00:39:47, metric 1
> to 10.1.2.2 via fe-0/0/2.0
224.0.0.5/32       *[OSPF/10] 00:44:22, metric 1
MultiRecv

Bidirectional Forwarding Detection

Mecanismo para detectar falhas de links em menos de 1 segundo, chamado de subsecond.

Protocolos suportados:OSPF, IS-IS, RIP, BGP, RSVP, PIM, Static routes

Após o BFD ser negociado a sessão entre os 2 neighbors são trocados keepalives monitorizando assim o link. Após falha no BFD o protocolo de routing e notificado. Os timers do protocolo de routing são substituídos pelos do BFD.

não e recomendado que os timers sejam inferiores a 300msec, ainda com este valor e possível detectar falhas em 900msec (3*timer)

Configuring BFD

set protocols ospf area 0 interface ge-0/0/1.0 bfd-liveness-detection minimum-interval 300
set protocols bgp group my-ebgp-group bfd-liveness-detection minimum-interval 300
set protocols bgp group my-ebgp-group neighbor 172.18.1.1 peer-as 65510

Podem ser definidos diferentes intervalos para o send/receive, e possivel usar o comando minimum-interval para ambos

BFD usa periodic packet management (PPM) no PFE. PPM faz off load de algum processamento do RE para o PFE, by default o PPM está activo nas plataformas onde é suportado.

O BFD não traz benefícios em SONET, ATM, pois estes media types ja tem mecanismos semelhantes. Em Ethernet é possível usar o Ethernet OAM, ao contrario do BFD este opera em Layer 2.

By default, as sessões BFD são adaptive pelo que timers podem ser alterados. Se for definido um minimum interval e se o neighbor usar um valor superior, então a sessão BFD usa o valor superior.

[edit protocols]
[email protected]# set ospf area 0 interface ge-0/0/1.0 bfd-liveness-detection ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don’t inherit configuration data from these groups
> authentication       Authentication options
> detection-time       Detection-time options
full-neighbors-only  Setup BFD sessions only to Full neighbors
minimum-interval     Minimum transmit and receive interval (milliseconds)
minimum-receive-interval  Minimum receive interval (1..255000 milliseconds)
multiplier           Detection time multiplier (1..255)
no-adaptation        Disable adaptation
> transmit-interval    Transmit-interval options
version              BFD protocol version number

[edit protocols]
[email protected]# set bgp bfd-liveness-detection ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don’t inherit configuration data from these groups
> authentication       Authentication options
> detection-time       Detection-time options
holddown-interval    Time to hold the session-UP notification to the client
minimum-interval     Minimum transmit and receive interval (milliseconds)
minimum-receive-interval  Minimum receive interval (1..255000 milliseconds)
multiplier           Detection time multiplier (1..255)
no-adaptation        Disable adaptation
> transmit-interval    Transmit-interval options
version              BFD protocol version number

O BFD pode ser definido ao nivel do protocol, group, ou neighbor, a prioridade das definições e pela ordem apresentada.

Monitoring BFD

show bfd session

Para desativar o adaptive mode usar o comando no-adaptation

[email protected]> show bgp neighbor 172.18.1.1
Peer: 172.18.1.1+179 AS 65510  Local: 172.18.1.2+49363 AS 64700
Type: External    State: Established    Flags: <Sync>
Last State: OpenConfirm   Last Event: RecvKeepAlive
Last Error: None
Export: [ adv-aggregates ]
Options: <Preference AdvertiseInactive GracefulRestart PeerAS Refresh>
Options: <BfdEnabled>
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.10.10.10      Local ID: 192.168.1.1      Active Holdtime: 90
Keepalive Interval: 30         Peer index: 0
BFD: enabled, up
[Trimmed]

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

Notas estudo JNCIS-ENT parte 5

Notas estudo JNCIS-ENT parte 6

Notas estudo JNCIS-ENT parte 7

Notas estudo JNCIS-ENT parte 8

Notas estudo JNCIS-ENT parte 9

Notas estudo JNCIS-ENT parte 10

Notas estudo JNCIS-ENT parte 11

Notas estudo JNCIS-ENT parte 12

Notas estudo JNCIS-ENT parte 13

Notas estudo JNCIS-ENT parte 13

Nota: Este Post faz parte do guide de Routing.

Chapter 5 IP Tunneling

O junOS não suporta IPX ou AppleTalk.

O GRE permite encapsular trafego non-IP, IPX, AppleTalk e IP.

GRE adiciona 24 bytes ao header e usa o protocol type 47
IP-IP adiciona 20 bytes ao header

Os tuneis IP-IP só suporta IP traffic, RFC2003

Os tunneling services podem ser realizados por software ou hardware.
A nomenclatura do tipo de interface irá depender onde se encontra inserida a tunneling services interface card

Tipos de interfaces:
GRE – interface gr-x/y/z
IP-IP – interface ip-x/y/z

O GRE suporta o mecanismo de Keepalive para monitorizar o estado do tunnel.

set protocols oam gre-tunnel interface gr-1/0/10.1 keepalive-time 10 hold-time 30

Os Keepalives sao suportados nos M e MX Series

Quando 2 devices iniciam um sessão TCP determinam o maximum segment size (MSS) permitido no path end-to-end. Tipicamente o valor do MTU é de 1500,mas quando é usado GRE ou IP-IP existe um overhead adicional.
Usando GRE (Max MTU 1476), se o host enviar um pacote superior a 1476, o pacote é fragmentado tipicamente por um dos pontos do tunel.

Se um dos hosts activar o don’t fragment (DF) bit, o route faz drop ao pacotes tipicamente enviando um ICMP informando o sender para usar pacotes mais pequenos.
Para evitar este problema, pode ser alterar o MTU do tunnel, no junOS também é possível activar a config clear-dont-fragment que remove o bit set permitindo assim a fragmentação.

Defining the Tunnel Interface

set interfaces gr-0/0/0.0 family inet
set interfaces gr-0/0/0.0 tunnel source 192.168.1.1
set interfaces gr-0/0/0.0 tunnel destination 192.168.2.1

Outras opções:

copy-tos-to-outer-ip-header – by default o GRE não copia o ToS para outer IP header
allow-fragmentation – by default o GRE faz drop se o MTU for superior a do egress interface
reassemble-packets –  activar o reassemble de pacotes, apenas em interfaces GRE
key – permite identificar individualmente um flow dentro do tunel
clear-dont-fragment-bit – É removido o DF bit mesmo que os pacotes não excedam o MTU

Opcoes para activar/desativar o PMTUD
[edit system internet-options]
[email protected]# set ?
Possible completions:

gre-path-mtu-discovery  Enable path MTU discovery for GRE tunnels
ipip-path-mtu-discovery  Enable path MTU discovery for IP-IP tunnels
no-gre-path-mtu-discovery  Don’t enable path MTU discovery for GRE tunnels
no-ipip-path-mtu-discovery  Don’t enable path MTU discovery for IP-IP tunnels

O PMTUD é uma técnica para determinar o MTU no path entre 2 endpoints para que não exista fragmentação.
O PMTUD activa o DF bit no outgoing packets. Se um device intermédio no path tiver um MTU menor, faz drop ao pacote e envia um ICMP Fragmentation Needed (type 3, Code 4) contendo o MTU. Assim permite ao host reduzir o MTU. O Tunnel endpoint repete o processo de discovery até o MTU ser o pequeno o suficiente para não existir fragmentação em transito.

Required Routes

set routing-options static route 192.168.1.1/32 next-hop 172.18.2.1
set routing-options static route 172.20.110.0/24 next-hop gr-0/0/0.0

[email protected]> show route 192.168.1.1
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
192.168.1.1/32     *[Static/5] 5d 21:02:26
> to 172.18.2.1 via ge-0/0/3.0
[email protected]> show route 172.20.110.0/24
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
172.20.110.0/24    *[Static/5] 10:43:01
> via gr-0/0/0.0

Chapter 6 High Availability

Supported High Availability Features

Graceful restart (GR) – O data plane (forwarding) não e interrompido. Permite ao router passar os estados intermédios de convergência sem o conhecimento do resto da rede.
Graceful Routing Engine switchover (GRES) – Preserva a informacao do Kernel/interfaces mas não o Control Plane
Nonstop active routing (NSR) – Preserva a informação do Kernel/interfaces, o processo rpd e tambem executado no Backup RE. O GRES deve estar activo para o NSR operar corretamente
Bidirectional Forwarding Detection (BFD)
Virtual Router Redundancy Protocol (VRRP)
Unified In-Service Software Upgrade (ISSU) – suportado apenas em devices com 2 REs. O GRES e NSR devem estar activos

Graceful restart (GR)

No caso de o processo rpd ser reiniciado, o beneficio de usar GR e que este evento e comunicado aos neighbors adjacentes da condição.
Assim o router continua a fazer forwarding de tráfego durante o período de restart.Os neighbors deste router são conhecidos como helper routers, pois escondem o evento de restart dos restantes neighbors (diretamente ligados).
Por outras palavras o evento não é visível na restante rede, não sendo o router que o originou removido da topologia de rede.

O GR ocorre apenas se as seguintes condições estão reunidas:

Topologia de rede estável
O neighbor ou peer cooperam
Se o restarting router não estiver já a cooperar com outro restart em progresso
O grace period não expira
Protocolos Suportados pelo GR: OSPF, IS-IS, BGP, RIP, RSVP, LDP, MSDP, PIM

O router deve ter o GR activo para suportar os ambos os modos:restarting router mode e helper router mode
By default os devices operam como helper router mode e não como restaring router mode.

Configuring GR

!Desativar o graceful restarting globalmente
set routing-options graceful-restart disable

!Ativar o restarting mode
set protocols bgp graceful-restart
set protocols bgp my-group type-internal local-address 192.168.1.1
set protocols bgp my-group type-internal neighbor 192.168.1.2
set protocols bgp my-group type-internal neighbor 192.168.2.2 graceful-restart disable

O GR helper mode pode ser desativado per-protocol, per-group, ou per-neighbor

[edit protocols]
[email protected]# set ospf graceful-restart ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don’t inherit configuration data from these groups
disable              Disable OSPF graceful restart capability
helper-disable       Disable graceful restart helper capability
no-strict-lsa-checking  Do not abort graceful helper mode upon LSA changes
notify-duration      Time to send all max-aged grace LSAs (1..3600 seconds)
restart-duration     Time for all neighbors to become full (1..3600 seconds)

[edit protocols]
[email protected]# set bgp graceful-restart ?
Possible completions:
<[Enter]>            Execute this command
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don’t inherit configuration data from these groups
disable              Disable graceful restart
restart-time         Restart time used when negotiating with a peer (1..600)
stale-routes-time    Maximum time for which stale routes are kept (1..600)
|                    Pipe through a command

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

Notas estudo JNCIS-ENT parte 5

Notas estudo JNCIS-ENT parte 6

Notas estudo JNCIS-ENT parte 7

Notas estudo JNCIS-ENT parte 8

Notas estudo JNCIS-ENT parte 9

Notas estudo JNCIS-ENT parte 10

Notas estudo JNCIS-ENT parte 11

Notas estudo JNCIS-ENT parte 12

Notas estudo JNCIS-ENT parte 6

Nota: Este Post faz parte do guide de Switching.

Graceful Routing Engine Switchover Operations
1. Após o RE serem sincronizados, estes trocam keepalives
2. Se o backup não receber o keepalive do master (em 2 segundos), faz a transição (mastership)
3. O PFE liga-se ao novo master RE
4. o novo master RE e o PFE sincronizam, e o novo master RE enviam os updates necessário para o PFE

Efectuar um switchover do RE:

{master:0}
[email protected]> request chassis routing-engine master switch
Toggle mastership between routing engines ? [yes,no] (no)  yes
{master:0}
[email protected]>
Switch-1 (ttyu0)
login: lab
Logging to master
Password:
— JUNOS 12.2R1.8 built 2012-08-25 01:27:13 UTC
{master:1}
[email protected]>

Outra opcoes:

{master:0}
[email protected]>  request chassis routing-engine master ?
Possible completions:
acquire              Attempt to become master Routing Engine
release              Request that other Routing Engine become master
switch               Toggle mastership between Routing Engines

Configuring Graceful Routing Engine Switchover

set chassis redundancy graceful-switchover

! Só é possível executar este comando no backup RE
show system switchover

O master RE replica o state do RE e PFE:

configuration database – a configuration database é replicada através do comando commit synchronize
chassisd – replica o state do PFE
ksyncd – replica o state do kernel

Nonstop Active Routing

Usa o GRES
Preserva o routing information e as sessões dos protocolos

Caso o NSR não suporte o protocolo de routing, este opera normalmente

Configuring NSR

set chassis redundancy graceful-switchover
set routing-options nonstop-routing
set system commit synchronize

Monitoring NSR

[email protected]# run show task replication
Stateful Replication: Enabled
RE mode: Master
Protocol        Synchronization Status
OSPF            Complete

Nonstop Bridging

Usa o GRES
Preserva a Layer 2 information e as sessões dos protocolos

Configuring NSB

set chassis redundancy graceful-switchover
set ethernet-switching-options nonstop-bridging
set system commit synchronize

Output do backup RE com NSB:
{backup:1}
[email protected]> show spanning-tree bridge
STP bridge parameters
Snipped…
If NSB is not enabled the Ethernet subsystem will not be running as illustrated in the following output:
{backup:1}
[email protected]> show spanning-tree bridge
error: the ethernet-switching subsystem is not running

Ethernet Ring Protection Switching (ERPS)

Definido no ITU-T G.8032
Converge em 50 ms, loop-free
A topologia deve ser em ring, e deve conter no mínimo 3 switches
Devido ao fast failover o ERPS pode substituir o STP
Por questões de performance não e recomendado ter + de 16 nodos na topologia

Ring Protection Link

Apenas um link age como RPL no ring
O nodo RPL-owner controla o RPL
Em condições normais o RPL-owner coloca o RPL em blocked prevenindo loops
Quando um link falha o RPL passa a forwarding, quando o antigo link volta novamente a ficar operacional a RPL passa a blocked

Usando VLANs STP deve ser desativado, pelo que interfere com a comunicação do RPL port

RPL-Owner Node

Único nodo que envia Ring Automatic Protection Switching (R-APS) messages a notificar os restantes nodos do state do RPL

APS Protocol

Requer um canal dedicado (uma VLAN) para enviar as R-APS entre nodos, de qualquer forma todas as vlans no trunk são afectadas pelo algoritmo APS

Idle State

Quando não existe falhas, todos os nodos estao em idle state.
RPL envia R-APS messages a cada 5 segundos

Signal Failure
Ocorre quando e detectada uma falha num link unblocked do ring

sw1–sw4
|  **  |
sw2–sw3

Entre SW2 e SW3:
Espera pelo expirar do hold interval (default 0), o JunOS não suporta hold time
Muda estado idle para protection
Block as portas falhadas e flush da MAC table
Envia 3 R-APS messages nos primeiros 10 ms seguindo de 1 a cada 5 segundos, ate a condição de signal failed desaparecer

Todos os switchs excepto o SW2 e SW3:
Mudam de estado idle para protection
Flush da MAC table e param de enviar R-APS messages

RPL Owner (SW1):
Desbloqueia RPL
Listen por R-APS messages do SW2 e SW3
Para de enviar R-APS messages

Restoration of a Failed Link

SW2 e SW3:
bloqueiam novamente o link que falhou não enviam R-APS requests
Começam a enviar novos R-APS e com o link bloqueado até receber uma R-APS do SW1, não existindo Flush da MAC table

SW1:(Após não receber request R-APS messages)
Espera pelo expire do restore time (default 5 minutos)
Bloqueia o RPL e transmite R-APS message
Os outros switches unblock das portas e Flush MAC table
Todos os switches mudam do estado protection para idle

ERPS Configuration

Os timers podem ser configurados globalmente ou por ring:
guard-interval (disabled by default) – Previne o o nodo de receber outdated R-APS messages restore-interval – tempo de espera do nodo para processar ERP PDUs

sw1-(east)——–sw4
(west)  ******** |
|
(east)  ******** |
sw2-(west)—–sw3

[email protected]#
!West
set interfaces ge-0/0/4 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/4 unit 0 family ethernet-switching vlan members all
!East
set interfaces ge-0/0/12 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/12 unit 0 family ethernet-switching vlan members all

set vlans control vlan-id 100
set vlans data vlan-id 101

set protocols protection-group ethernet-ring my-erps ring-protection-link-owner east-interface control-channel ge-0/0/12.0

!Definir RPL Interface
set protocols protection-group ethernet-ring my-erps ring-protection-link-owner east-interface ring-protection-link-end

set protocols protection-group ethernet-ring my-erps ring-protection-link-owner west-interface control-channel ge-0/0/4.0

set protocols protection-group ethernet-ring my-erps control-vlan control data-channel vlan data

[email protected]#
!East
set interfaces ge-0/0/4 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/4 unit 0 family ethernet-switching vlan members all
!West
set interfaces ge-0/0/12 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/12 unit 0 family ethernet-switching vlan members all

set vlans control vlan-id 100
set vlans data vlan-id 101

set protocols protection-group ethernet-ring my-erps west-interface control-channel ge-0/0/12.0

set protocols protection-group ethernet-ring my-erps east-interface control-channel ge-0/0/4.0

set protocols protection-group ethernet-ring my-erps control-vlan control data-channel vlan data

show protection-group ethernet-ring aps detail
show protection-group ethernet-ring interface detail
show protection-group ethernet-ring node-state detail

Multiple Spanning Tree Protocol (MSTP)  

Possível ter ate 64 instâncias (MSTIs)
CST permite interligar múltiplas MSTs regions

MSTP Configuration

set protocols mstp configuration-name <configuration-name>
set protocols mstp revision-level <revision-level>
set protocols mstp bridge-priority <priority>
set protocols mstp msti <msti-id> bridge-priority <bridge-priority> vlan (vlan-id | vlan-name)

By default revision-level 0

show spanning-tree mstp configuration
show spanning-tree interface
show spanning-tree bridge

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

Notas estudo JNCIS-ENT parte 5

Notas estudo JNCIS-ENT parte 5

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}
[email protected]>request system software add member <member-id>

!Fazer upgrade a todos os membros
{master:0}
[email protected]>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}
[email protected]> request system software nonstop-upgrade /var/tmp/package-name.tgz

Iniciar o processo NSSU numa plataforma mixed de Virtual Chassis
{master:0}
[email protected]>  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}
[email protected]#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}
[email protected]> request virtual-chassis vc-port set pic-slot 1 port 0 local
fpc0:
————————————————————————–
{master:0}
[email protected]> 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}
[email protected]> 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}
[email protected]> request virtual-chassis vc-port delete pic-slot 1 port 0 local
fpc0:
{master:0}
[email protected]> show interfaces terse vcp-255/1/0
error: device vcp-255/1/0 not found
{master:0}
[email protected]> 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]
[email protected]# show chassis
aggregated-devices {
ethernet {
device-count 2;
}
}

{master:0}[edit]
[email protected]# 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]
[email protected]# 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