Tag Archives: High Availability

Exame JNCIS-SP JN0-360

Ontem realizei o exame JN0-360 da Juniper, este exame é também abrangido pelo “Fast track Program” e como tal 50% desconto se passar no assessment. Terei que aprofundar os conhecimentos em alguns dos tópicos tais como:IS-IS, Layer 2 VPNs

Pré-Requisitos

É necessário ter o JNCIA-Junos

Material de Estudo

Como material de estudo usei os documentos disponibilizados pela Juniper, para realizar o download será necessário realizar o registo no Learning Portal, este passo é importante pois o Pre-assessment que irá garantir o voucher será realizado apartir deste.

Para testar tecnologias como routing o Juniper Olive é perfeito, basicamente  é um junOS virtualizado/emulado. As relacionadas com Switching/High Availability/ Layer 2/3 VPNs entre outras usei os Virtual Labs (acho que só os partners têm acesso), o único senão é que a release dos EX/MX é a 11.x e a recomendada para estudo é a 14.1.

Deixo aqui as minhas notas para download, não estão tão resumidas como gostaria….

Em suma os passos foram:

Importante:É necessário estar autenticado no Learning Portal para aceder aos conteúdos

Após autenticar, abrir Fast Track Portal, são exibidas 2 colunas, abaixo encontra-se representada a coluna da direita. Escolher os recursos de estudo “Review study resources”

junos-ftrack_jncis-sp

Nota: Caso contenha um cadeado significa que ainda não se encontra autenticado

1. Praticar através dos 3 guides disponibilizados no Fast Track Portal

junos-ftrack_jncis-sp_guides

2. Day One Guides

3. Rever alguns dos Learning Bytes

4.Praticar os 2 testes de conhecimento
4.1  Practise Test
4.2  Pre-assessment Oficial (para obter o voucher)

Nota: Neste caso como realizei com sucesso aparece o resultado, mas deverá aparecer um link

Após passar o Pre-assessment Oficial, o voucher será enviado para o email registado no Learning Portal.

De seguida, agendar o Exame final em www.pearsonvue.com e usar o voucher :)

Objectivos Exame inclui:

  • Protocol-Independent Routing
  • Open Shortest Path First (OSPF)
  • Intermediate System to Intermediate System (IS-IS)
  • Border Gateway Protocol (BGP)
  • Layer 2 Bridging and VLANs
  • Spanning-Tree Protocols
  • Multiprotocol Label Switching (MPLS) and MPLS VPNs
  • IPv6
  • Tunnels
  • High Availability
**Clique para expandir/colapsar os objectivos em detalhe**

Exame

A prova tem a duração de 90 minutos com 70 questões. O minimo para passar é de 64%

Resultado

Como é hábito o resultado é provisório, mas recebi há minutos atrás o resultado final e Passei!

Para não haver dúvidas segundo o CertManager, é oficial. Agora é hora de descansar por uns dias!

juniper_certmanager_30122014

Este é o logo oficial

jncis-ent

Referências:

Juniper Fast Track

Juniper Learning Portal

Juniper JNCIS-SP

Junos documentation

Junos documentation for EX Series switches

Junos documentation for MX Series

Juniper Certificações Junho 2013

Exame JNCIA-Junos JN0-102

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 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