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
1 thought on “Notas estudo JNCIS-ENT parte 14”