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}
user@R1-re0> 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]
user@R1-re0# set apply-groups [re0 re1]

Caso seja usado o GRES deve ser configurado commit synchronize

user@R1-re0# set chassis commit
warning: graceful-switchover is enabled, commit synchronize should be used
commit complete

{master}
user@R1-re0# set system commit synchronize

{master}
user@R1-re0# 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]
user@R1# 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

user@R1> 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]
user@R1-re0#

{backup}[edit chassis]
user@R1-re1#

Monitoring Graceful RE Switchover

!Este comando só e valido no Backup RE
{backup}
user@R1-re1> 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}
user@R1-re0# set routing-options nonstop-routing

!Activar o commit synchronize
user@R1-re0# 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}
user@R1-re0> show task replication
Stateful Replication: Enabled
RE mode: Master
Protocol       Synchronization Status
OSPF           Complete
BGP               Complete

{master}
user@R1-re0> request routing-engine login other-routing-engine
€
— junOS 10.1R1.8 built 2010-02-12 18:31:54 UTC
{backup}
user@R1-re1> 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}
user@R1-re1> 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}
user@R1-re1> 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]
user@R1# 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]
user@R1# 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

user@R1> 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