Tag Archives: JNCIS-ENT

Notas estudo JNCIS-ENT parte 17

Nota: Este Post faz parte do guide de Routing.

[email protected]# run show isis interface
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
em0.0 3 0x2 R2.00 R2.02 1000/10
em1.0 3 0x3 R2.03 R2.00 10/10
lo0.0 0 0x1 Passive Passive 0/0

Campos do output do comando show isis interface:
interface-name (detail output only) – Displays the name of the interface;
Index (detail output only) – Displays the interface index assigned by the junOS OS kernel;
State (detail output only) – Displays the internal implementation information;
Circuit ID (detail output only) – Displays the circuit identifier;
Circuit type (detail output only) – Displays the circuit type, which can be 1 —Level 1 only, 2 —Level 2 only, or 3 — Level 1 and Level 2;
LSP interval (detail output only) – Displays the interface’s link-state PDU interval;
Sysid (detail output only) – Displays the system identifier;
Interface (brief output only) – Displays the interface through which the adjacency is made.
Level 1 DR/Level 2 DR (brief output only) – Displays the Level 1 or Level 2 DIS;
L1/L2 Metric: Displays the interface’s metric for Level 1 and Level 2. If no information is present, the metric is 0;
Adjacencies (detail output only) – Displays the number of adjacencies established on the interface;
Priority (detail output only) – Displays the priority value for this interface;
Metric (detail output only) – Displays the metric value for this interface;
Hello(s) (detail output only) – Displays the interface’s hello interval; and
Hold(s) (detail output only) – Displays the interface’s hold time.

[email protected]# run show isis database
IS-IS level 1 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
R1.00-00 0x1d 0xc00e 737 L1
R2.00-00 0x1a 0x1c02 341 L1 L2 Attached
R2.03-00 0x13 0x225d 341 L1 L2
3 LSPs

IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
R1.00-00 0x5 0xa4c4 699 L1 L2
R2.00-00 0x21 0x6045 761 L1 L2
R2.02-00 0x16 0x4b30 341 L1 L2
R2.03-00 0x3 0 0 L1 L2
R3.00-00 0x1b 0x5e41 1013 L1 L2
5 LSPs

Campos do output do comando show isis database:
LSP ID – Displays the link-state PDU identifier;
Sequence – Displays the sequence number of the link-state PDU;
Checksum – Displays the checksum value of the link-state PDU;
Lifetime (secs) – Displays the remaining lifetime of the link-state PDU, in seconds;
IP prefix (detail and extensive output only) – Displays the prefix advertised by the link-state PDU;
IS neighbor (detail output only) – Displays an IS-IS neighbor of the advertising system; and
Metric (detail and extensive output only) – Displays the metric of the prefix or neighbor.

[email protected]# run show isis adjacency
Interface System L State Hold (secs) SNPA
em0.0 R3 2 Up 23 0:ab:44:8:f8:0
em1.0 R1 1 Up 25 0:ab:ae:99:e3:0

Interface – Displays the interface through wh ich the neighbor is reachable.
System (brief output only) – Displays the system identifier, printed as a name if possible.
L – Displays the level, which can be 1 —Level 1 only; 2 —Level 2 only;
or 3 —Level 1 and Level 2. An exclamation point ( ! ) preceding the level number indicates that the adjacency is missing an IP address.
State – Displays the state of the adjacency. It can be Up, Down, New , One-way, Initializing, or Rejected .
Hold (secs) (brief/standard output only) – Displays the remaining hold time of the adjacency. Note that the show isis adjacency command returns brief output by default.
SNPA (brief output only) – Displays the SNPA (MAC address of the next hop).

[email protected]# run show isis adjacency detail
R3
Interface: em0.0, Level: 2, State: Up, Expires in 24 secs
Priority: 64, Up/Down transitions: 1, Last transition: 00:14:29 ago
Circuit type: 3, Speaks: IP, IPv6, MAC address: 0:ab:44:8:f8:0
Topologies: Unicast
Restart capable: Yes, Adjacency advertisement: Advertise
LAN id: R2.02, IP addresses: 10.1.23.3

R1
Interface: em1.0, Level: 1, State: Up, Expires in 26 secs
Priority: 64, Up/Down transitions: 3, Last transition: 03:04:35 ago
Circuit type: 3, Speaks: IP, IPv6, MAC address: 0:ab:ae:99:e3:0
Topologies: Unicast
Restart capable: Yes, Adjacency advertisement: Advertise
LAN id: R2.03, IP addresses: 10.1.12.1

Campos do output do comando show isis adjacency detail:
Expires in (detail output only): Displays the time until the adjacency expires, in seconds;
Priority (detail output only): Displays the priority to become the DIS;
Up/Down transitions (detail output only): Displays the count of adjacency status changes from up to down or from down to up;
Last transition (detail output only): Displays the time of the last up or down transition;
Circuit type (detail output only): Displays the bit mask of levels on this interface, which can be 1 —Level 1 router, 2 —Level 2 router, or 1/2 —both Level 1 and Level 2 routers;
Speaks (detail output only): Displays the protocols supported by the neighbor; and
IP addresses (detail output only): Displays the IP address of the neighbor.

[email protected]# run show isis spf log
IS-IS level 1 SPF log:
Start time Elapsed (secs) Count Reason
Fri Jul 25 19:01:08 0.000200 3 Lost adjacency R3 on em0.0
Fri Jul 25 19:01:16 0.000189 2 Multi area attachment change
Fri Jul 25 19:15:55 0.000791 1 Periodic SPF
Fri Jul 25 19:19:08 0.000194 1 Updated LSP R3.00-00
Fri Jul 25 19:33:52 0.000201 1 Periodic SPF
Fri Jul 25 19:46:27 0.000353 1 Periodic SPF
Fri Jul 25 19:58:41 0.000201 1 Periodic SPF
Fri Jul 25 20:12:13 0.000216 1 Periodic SPF
Fri Jul 25 20:24:59 0.000187 1 Periodic SPF
Fri Jul 25 20:36:44 0.000276 1 Periodic SPF
Fri Jul 25 20:49:43 0.000207 1 Periodic SPF
Fri Jul 25 21:03:50 0.000207 1 Periodic SPF
Fri Jul 25 21:15:21 0.000252 1 Periodic SPF
Fri Jul 25 21:25:16 0.000215 1 Updated LSP R1.00-00
Fri Jul 25 21:25:26 0.000209 1 Updated LSP R1.00-00
Fri Jul 25 21:25:30 0.000123 1 Updated LSP R1.00-00
Fri Jul 25 21:25:41 0.000222 1 Updated LSP R1.00-00
Fri Jul 25 21:31:15 0.000191 3 Multi area attachment change
Fri Jul 25 21:32:21 0.000180 3 Multi area attachment change
Fri Jul 25 21:38:59 0.000193 1 Updated LSP R1.00-00

IS-IS level 2 SPF log:
Start time Elapsed (secs) Count Reason
Fri Jul 25 18:55:55 0.000060 1 Updated LSP R2.00-00
Fri Jul 25 19:01:08 0.000126 7 Lost adjacency R3 on em0.0
Fri Jul 25 19:01:09 0.000174 2 Updated LSP R2.00-00
Fri Jul 25 19:01:16 0.000388 1 Updated LSP R3.00-00
Fri Jul 25 19:13:30 0.000202 1 Periodic SPF
Fri Jul 25 19:26:28 0.000536 1 Periodic SPF
Fri Jul 25 19:38:54 0.000185 1 Periodic SPF
Fri Jul 25 19:52:54 0.000195 1 Periodic SPF
Fri Jul 25 20:07:49 0.000206 1 Periodic SPF
Fri Jul 25 20:19:58 0.000199 1 Periodic SPF
Fri Jul 25 20:34:46 0.000226 1 Periodic SPF
Fri Jul 25 20:46:44 0.000184 1 Periodic SPF
Fri Jul 25 21:00:02 0.000180 1 Periodic SPF
Fri Jul 25 21:14:24 0.000211 1 Periodic SPF
Fri Jul 25 21:25:16 0.000101 6 Topologies changed for adjacency R1 on em1.0
Fri Jul 25 21:25:30 0.000090 2 Purging LSP R1.00-00
Fri Jul 25 21:25:36 0.000063 1 Updated LSP R1.00-00
Fri Jul 25 21:31:15 0.000301 3 Lost adjacency R3 on em0.0
Fri Jul 25 21:32:21 0.000266 5 Topologies changed for adjacency R3 on em0.0
Fri Jul 25 21:39:21 0.000218 3 Lost adjacency R1 on em1.0

Campos do output do comando show isis spf log:
Node: Displays the system ID of a node;
Metric : Displays the metric to the node;
Interface: Displays the interface of the next hop;
Via : Displays the system ID of the next hop;
SNPA: Displays the SNPA (MAC address of the next hop);
Start time (log output only): Displays the time that the SPF computation started;
Elapsed time (log output only): Displays the length of time required to complete the SPF computation in seconds;
Count (log output only): Displays the number of times the SPF was triggered; and
Reason (log output only): Displays the reason that the SPF computation was completed.

[email protected]# run show isis statistics
IS-IS statistics for R2:
PDU type Received Processed Drops Sent Rexmit
LSP 75 75 0 186 0
IIH 5404 54 1567 12380 0
CSNP 0 0 0 2784 0
PSNP 7 7 0 0 0
Unknown 0 0 0 0 0
Totals 5486 136 1567 15350 0

Total packets received: 5486 Sent: 15350

SNP queue length: 0 Drops: 0
LSP queue length: 0 Drops: 0
SPF runs: 76
Fragments rebuilt: 112
LSP regenerations: 50
Purges initiated: 7

Campos do output do comando show isis statistics:
PDU type : Displays the PDU type.
Received : Displays the number of PDUs received since IS-IS started or since the statistics were zeroed.
Processed: Displays the number of PDUs received minus the number dropped.
Drops: Displays the number of dropped PDUs.
Sent: Displays the number of PDUs transmitted since IS-IS started or since the statistics were zeroed.
Rexmit : Displays the number of PDUs retransmitted since IS-IS started or since the statistics were zeroed.
Total packets received/sent: Displays the total number of PDUs received and transmitted since IS-IS started or since the statistics were zeroed.
SNP queue length : Displays the number of CSNPs and PSNPs sitting on the sequence number packets (SNP) queue waiting for processing. This value is almost always 0.
LSP queue length : Displays the number of link-state PDUs sitting on the link-state PDU queue waiting for processing. This value is almost always 0.
SPF runs : Displays the number of SPF calculations performed. If this number is incrementing rapidly, it indicates that the network is unstable.
Fragments rebuilt: Displays the number of link-state PDU fragments that the local system has computed.
LSP regenerations: Displays the number of link-state PDUs that were regenerated. A link-state PDU is regenerated when it is nearing the end of its lifetime and it has not changed.
Purges initiated: Displays the number of purges that the system initiated. A purge is initiated if the software decides that a link-state PDU must be removed from the network.

[email protected]# run show isis route
IS-IS routing table Current version: L1: 36 L2: 40
IPv4/IPv6 Routes
—————-
Prefix L Version Metric Type Interface NH Via
10.10.10.1/32 1 36 10 int em1.0 IPV4 R1
10.10.10.3/32 2 40 10 int em0.0 IPV4 R3

Campos do output do comando show isis route:
Current version: Displays the number of the current version of the IS-IS routing table.
L1: Displays the version of the Level 1 SPF that was run.
L2: Displays the version of the Level 2 SPF that was run.
Prefix : Displays the destination of the route.
L : Displays the level, which can be 1 —Level 1 only; 2 —Level 2 only; and 3 —Level 1 and Level 2.
Version: Displays the version (or run) of SPF that generated the route.
Metric : Displays the metric value associated with the route.
Type: Displays the metric type. It can be int (internal) or ext (external).
Interface: Displays the interface to the next hop.
Via : Displays the system ID of the next hop, displayed as a name if possible.

[email protected]# run show isis database extensive
IS-IS level 1 link-state database:

R1.00-00 Sequence: 0x1d, Checksum: 0xc00e, Lifetime: 700 secs
IS neighbor: R2.03 Metric: 10
Two-way fragment: R2.03-00, Two-way first fragment: R2.03-00
IP prefix: 10.1.12.0/24 Metric: 10 Internal Up
IP prefix: 10.10.10.1/32 Metric: 0 Internal Up

Header: LSP ID: R1.00-00, Length: 141 bytes
Allocated length: 284 bytes, Router ID: 10.10.10.1
Remaining lifetime: 700 secs, Level: 1, Interface: 66
Estimated free bytes: 164, Actual free bytes: 143
Aging timer expires in: 700 secs
Protocols: IP, IPv6

Packet: LSP ID: R1.00-00, Length: 141 bytes, Lifetime : 1198 secs
Checksum: 0xc00e, Sequence: 0x1d, Attributes: 0x1 <L1>
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes
Packet type: 18, Packet version: 1, Max area: 0

TLVs:
Area address: 49.0001 (3)
Speaks: IP
Speaks: IPV6
IP router id: 10.10.10.1
IP address: 10.10.10.1
Hostname: R1
IS neighbor: R2.03, Internal, Metric: default 10
IS extended neighbor: R2.03, Metric: default 10
IP address: 10.1.12.1
Local interface index: 64, Remote interface index: 0
IP prefix: 10.1.12.0/24, Internal, Metric: default 10, Up
IP prefix: 10.10.10.1/32, Internal, Metric: default 0, Up
IP extended prefix: 10.1.12.0/24 metric 10 up
IP extended prefix: 10.10.10.1/32 metric 0 up
No queued transmissions

Campos do output do comando show isis database extensive:
LSP ID : Displays the link-state PDU identifier;
Sequence : Displays the sequence number of the link-state PDU;
Checksum : Displays the checksum value of the link-state PDU;
Lifetime (in seconds): Displays the remaining lifetime of the link-state PDU, in seconds;
IP prefix (detail and extensive output only): Displays the prefix advertised by this link-state PDU;
IS neighbor (detail output only): Displays an IS-IS neighbor of the advertising system; and
Metric (detail and extensive output only): Displays the metric of the prefix or neighbor.

IP Configuration is Not necessary

O IS-IS permite formar adjacencias entre neighbors que não estejam configurados com a mesma subnet, isto porque não se baseia no IP.

Troubleshooting No adjacency

Mismatched Areas
MTU minimo 1492
Sem NET configurado

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 14

Notas estudo JNCIS-ENT parte 15

Notas estudo JNCIS-ENT parte 16

Notas estudo JNCIS-ENT parte 16

Nota: Este Post faz parte do guide de Routing.

Appendix B IS-IS

IS-IS Protocol

Protocolo IGP, usa informação link-state e o algoritmo SPF a semelhança do OSPF

ISO

Protocolo desenvolvido pelo International Organization for Standardization (ISO) para o ISO’s Connectionless
Network Protocol (CLNP), descrito no ISO 10589

Dual IS-IS

Extensão do IS-IS para suportar a transição de TCP/IP para OSI. Também conhecido como integrated IS-IS. O Protocolo foi desenhado para suportar CLNP e IP, podendo opera-los em simultâneo.

Single Algorithm

Apenas e usado um algoritmo em ambos os ambientes (IP ou CLNP)

Link-State PDUs

Os pacotes IS-IS standard são alterados para suportar multiplos Network Layer Protocols
Nem todos os junOS devices suportam CLNP ou CLNS routing

A level-1 router cria LSPs level-1
A level-2 router cria LSPs level-2
A level-1-2 router cria LSPs level-1 e LSP level-2

Operation IS-IS

IS-IS consiste num AS com end systems (ESs) e intermediate systems (ISs)

IS-IS Areas

Existem 2 Levels: Level 1 e Level 2
Level 1: Roteia dentro da mesma area
Level 2: Roteia entre areas e interliga com outros ASs

Um router pode assumir a função de L1, L2 ou L1/L2
Um router L1/L2 funciona como um ABR semelhante ao OSPF. Este activa o bit no PDUS Level 1 indicando que e um backbone border router, os routers L1 criam uma default route a apontar para o router L1/L2 mais perto (metrica)

Cada router e identificado com Network Entity Title (NET), o NET e um NSAP onde o n-selector e 0

NSAP and Addressing

NSAP: Network Service Access Point
Total length between 8 and 20 bytes
Area Address: variable length field (up to 13 bytes)
System ID: defines an ES or IS in an area.
NSEL: N-selector. identifies a network service user (transport entity or the IS network entity itself)

NET: the address of the network entity itself

Formato NSAP Address
First 8 bits – escolher um numero (tipicamente 49)
Next 16 bits – area
Next 48 bits – router loopback address
Final 8 bits – zero

Exemplo 1:
NSAP:49.0001.1921.6800.1001.00
Router:192.168.1.1(loopback)in Area 1

Exemplo 2:
NSAP:49.0001.1921.6801.0010
192.168.10.10  -> 192.168.010.010  -> system ID 1921.6801.0010
Router:192.168.10.10(loopback)in Area 1

IS-IS PDUs

IS-IS uses the following PDUs to exchange protocol information:

IS-IS Hello (IIH) PDUs – IS-IS broadcasts these PDUs to discover the identity of neighboring IS-IS systems and to
determine whether the neighbors are Level 1 or Level 2 ISs.
Link-state PDUs – These PDUs contain information about the state of adjacencies to neighboring IS-IS systems. Link-state PDUs are flooded periodically throughout an area.
Complete sequence number PDUs (CSNPs) – CSNPs contain a complete description of all link-state PDUs in the IS-IS database. IS-IS periodically sends CSNPs on all links, and the receiving systems use the information in the CSNP to update and synchronize their link-state PDU databases. The designated router multicasts CSNPs on broadcast links in place of sending explicit acknowledgments for each link-state PDU.
Partial sequence number PDUs (PSNPs) – A receiver multicasts these PDUs when it detects that it is missing a link-state PDU or when its link-state PDU database is out of date. The receiver sends a PSNP to the system that transmitted the CSNP, effectively requesting that the missing link-state PDU be transmitted. That router, in turn, forwards the missing link-state PDU to the requesting router.
TLVs – IS-IS PDUs use TLV encoding as the basic structure for all routing information. TLV encoding requires that the
length of any field be defined explicitly when the field is used in a PDU.

IIH PDU Types

LAN hello PDUs – Pode ser divido entre Level 1 and Level 2 hello PDUs, o formato é idêntico. Num broadcast medium os hellos Level 1 e Level 2 usam
o multicast 01-80-C2-00-00-14 ou 01-80-C2-00-00-15, respectivamente.

point-to-point hello PDUs

Hello Transmission

DIS router – envia hellos a cada 3 segundos
non-DIS router – envia hellos a cada 9 segundos
PDU Fields

Circuit type – Defines the router as Level 1, Level 2, or a Level 1 and Level 2 router
Source ID – Identifies the system ID of the router that originated the hello PDU
Holding time – Specifies the period a neighbor should wait to receive the next hello PDU before declaring the originating router dead
PDU length – Specifies the length of the entire PDU in octets
Priority – Provides a value between 0 and 127 used for DIS election
LAN ID – Identifies the system ID or the DIS plus one more octet (the pseudo-node ID) to differentiate this LAN ID from another LAN ID that might have the same designated router

PSNPs

Um receiver multicast PSNPs quando detecta a falta de um link-state PDU ou link-state database está desatualizada

CSNPs

Contem uma descrição completa de todos os link-state PDUs na database. O IS-IS envia CSNPs periodicamente por todos os links.
O designated router multicast CNSPs em links broadcast em vez de enviar ACK explicitamente por cada link-state PDU

IS-IS Information Objects

OS PDUs usam TLV encoding como estrutura básica de toda a routing information. IS-IS ignora TLVs desconhecidos

Consultar TLV do IS-IS no URL http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml

IS-IS Adjacency Rules

Router Level 1 nunca forma adjacência com router Level 2 ou vice-versa
Para adjacências Level 1 a AREA deve ser igual
Para adjacências Level 2 a AREA deve ser diferente

DIS Election

O processo de eleição e garantido atribuindo a priority (entre 0 a 127) a cada interface em Level 1 ou Level 2.
Priority by default e 64 para ambos os Levels, se a priority for 0 o router fica fora do processo de seleção. As interfaces NonBroadcast tem por default priority 0
Router com a maior priority torna-se Designated Router, em caso de empate o router com o subnetwork point of attachment (SNPA) (que e o MAC-address) mais alto ganha a eleição.

Pseudo-Node

Mesmo conceito do OSPF

DIS Characteristics

não existe o conceito de Backup DR, se o IS-IS DIS falhar e eleito um novo. E feito preempt caso exista um router com uma best priority ou SNPA (MAC address) + alto

IS-IS Metrics

O IS-IS usa 1023 como default metric máxima, este valor é definido pelo network administrator.
Qualquer single link pode ter o valor máximo 63,a métrica é o suma dos custos dos links.

Level 1
Internal route preference: 15
External route preference: 160
Wide metrics are enabled, Narrow metrics are enabled
Level 2
Internal route preference: 18
External route preference: 165
Wide metrics are enabled, Narrow metrics are enabled

IS-IS define 3 metrics ou costs opcionais:

delay cost
cost metric
error cost

IS-IS mantém o mapeamento desta 4 métricas para o QoS option no CLNP packet header. O IS-IS usa estes mapeamentos para calcular rotas

Wide Metrics

O IS-IS também usa Wide metrics. E possível definir uma métrica ate 2^24. As Wide Metrics permite um network diameter ate 256 hops.
Este diameter resulta num maximum total path de 2^32.
By default o junOS envia as wide metrics e standard (Narrow) metrics, a wide metric e 63 caso seja usado em simultâneo a standard metric.
Para beneficiar das wide metric pode ser desativado as standard usando wide-metrics-only per level.

set protocols isis level 1 wide-metrics-only

Configuring IS-IS

set protocols isis interface ge-0/0/0.0 level 1 disable
set protocols isis interface at-0/1/1.100 level 2 disable

By default todas as interfaces especificadas no IS-IS são consideradas como Level 1 e Level 2

set interface ge-0/1/0.0 family iso
set interface ge-0/1/0.0 family inet address 10.0.24.1/24

set interface lo0.0 family inet address 192.168.2.1/32
set interface lo0.0 family iso address 49.0001.0192.0168.0201.00

Para usar o IS-IS, deve ser configurado o network entity title (NET) em uma das interfaces (preferencialmente o loopback), e configurar o iso family em todas as interfaces que desejamos executar IS-IS.

O junOS suporta ter múltiplas ISO NETs na interface loopback do router.

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 14

Notas estudo JNCIS-ENT parte 15

Notas estudo JNCIS-ENT parte 15

Nota: Este Post faz parte do guide de Routing.

VRRP Defined

RFC 2338

Terms and Concepts

VRRP Router
Master Router
Backup Routers
Virtual Router

VRRP Communications

VRRP version 2
Usa Multicast 224.0.0.18
Default advertisement 1 segundo
E possível usar subsecond usando o comando fast-interval (o valor pode variar entre 100-999 milisegundos)
O MAC-ADDRESS do VIP tem o formato 00-00-5E-00-01-VRID
O Master state e elegido através da priority mais alta (entre 1 -255), by default e 100
Caso o router tenha o próprio VIP configurado como IP da interface deve ser configurado a priority 255 e ativado automaticamente o preempt.
Em ambientes onde o router não tem o próprio VIP como IP é possível desativar o preempt

VRRP States

Initialize
Master
Backup
Transition – Estado apenas transitório entre Backup e Master. Neste estado não existe forwarding

VRRP Configuration

set interfaces ge-0/0/4.0 family inet addres 172.25.100.2/24 vrrp-group 10 virtual-address 172.25.100.1 priority 200

outras opções:

track
accept-data – Permite que o master responda a ICMP com destino ao VIP. Caso o master tenha o proprio VIP responde by default a ICMP
authenticatioon-type – 3 types:none,simple,MD5
authenticatioon-key
no-preempt

É possível usar o inherit da config quando existem múltiplos grupos VRRP na mesma interface física usando assim algumas das mesmas características.
Com a opcao vrrp-inheret-from as características usadas são:advertise-interval, authentication-key, authentication-type, fast-interval, no-preempt, preempt, track interface, e track route

Unified ISSU

Apenas suportado em chassis com 2 REs e com os serviços GRES e NSR activos. Ambos os REs devem executar a mesma versão de software

Para iniciar o processo deve ser executado o comando request system software-in-service-upgrade no master RE

Para verificar o estados dos FPCs após o ultimo Unified ISSU:

[email protected]>  show chassis in-service-upgrade
Item           Status                  Reason
FPC 0          Online
FPC 1          Online
FPC 2          Online
PIC 0        Online
PIC 1        Online
FPC 3          Offline                 Offlined by CLI command
FPC 4          Online
PIC 1        Online
FPC 5          Online
PIC 0        Online
FPC 6          Online
PIC 3        Online
FPC 7          Online

!Cancelar o processo de upgrade (unified ISSU)
[email protected]>  request system abort software-in-service-upgrade

 
Appendix A IPv6

Alguns dos benefícios do IPv6
More efficient routing
Quality of service (QoS)
Elimination of the NAT requirement
Network Layer security with end-to-end IPsec
Ease of management using stateless address autoconfiguration
Improved header format to reduce header overhead

O header IPv6 tem 40 bytes (fixos) e inclui os seguintes campos:

Version: 4-bit field containing the number 6, indicating IPv6
Traffic class: 8-bit field that determines the traffic priority
Flow label: 20-bit field used for QoS management
Payload length: 16-bit field indicates the size of the payload in octets
Next header: 8-bit field indicating the next encapsulated protocol
Hop limit : 8-bit field replaces the time-to-live (TTL) field in IPv4
Source address : 128 bits
Destination address: 128 bits

IPv6 Defines Six Extension Headers

As extensões possíveis no header:

Hop-by-hop options: Signifies that the options need to be examined by each node along the path of a packet
Routing: Provides a list of intermediate nodes that should be visited on the path to the packet’s destination
Fragment: Signals when a packet has been fragmented by the source
Destination options: Options examined only by the destination node , and capable of appearing twice in a packet
Authentication header: Used with IPsec to verify  authenticity of a packet
Encrypted security payload: Used with IPsec and carries encrypted data for secure communication

IPv6 Address Types

3 Tipos de endereços IPv6:
• Unicast
• Multicast
• Anycast

Prefix Notation

O RFC4291 define as ultimas regras sobre prefix notation

::/128 : unspecified;
::1/128: This prefix notation should be used for the loopback;
FF00::/8 : Multicast
FE80::/10: Local-Link

Special Addresses
Link-Local Unicast Addresses – Prefix (10bits) + SubnetID (54bits) + Interface ID (64bits)
Site-Local Unicast Addresses – Enderecos Privatos a semelhanca do RFC1918 em IPv4. Prefix (10bits) + SubnetID (54bits) + Interface ID (64bits)
Global Unicast Addresses – Enderecos roteados na Internet. FP (3bits) + GlobalRouting Prefix (45bits) + SID (16bits) + Interface ID (64bits)

Stateless Autoconfiguration

Permitir atribuir IP automaticamente sem a necessidade de DHCP.

Stateless autoconfiguration consiste em varios elementos:

• Extended unique identifier (EUI)
• Router advertisement message
• Router solicitation message
• Prefix list

Neighbor Discovery (ND)

É o processo de tracking dos neighbors no mesmo local link.
O ND é opcional nos devices IPv6.
Após o host enviar um Router Solicitation (RS) o router confirma enviando um Router Advertisement (RA) com a prefix list. O host o endereçamento no prefix-list para efectuar a autoconfiguracao

Stateful Autoconfiguration

O DHCPv6 e conhecido como stateful, definido no RFC3315

set interfaces ge1/1/0.110 family inet6 address fec0:0:0:2003::1/64

[email protected]# run show interfaces terse ge-1/1/0
Interface               Admin Link Proto    Local                 Remote
ge-1/1/0                up    up
ge-1/1/0.110            up    up   inet     172.16.110.1/24
inet6    fe80::8271:1f00:6ec1:a278/64
fec0:0:0:2003::1/64

[email protected]# run show route table inet6.0

inet6.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both

fe80::/64          *[Direct/0] 00:02:24
> via ge-1/1/0.110
fe80::8271:1f00:6ec1:a278/128
*[Local/0] 00:02:24
Local via ge-1/1/0.110
fec0:0:0:2003::/64 *[Direct/0] 00:02:24
> via ge-1/1/0.110
fec0:0:0:2003::1/128
*[Local/0] 00:02:24
Local via ge-1/1/0.110

[email protected]# run show ipv6 neighbors
IPv6 Address                 Linklayer Address  State       Exp Rtr Secure Interface
fec0:0:0:2003::2             80:71:1f:c1:c3:78  reachable   34  yes no      ge-1/1/0.110

IPv6 Multicast Address

No IPv6 o ICMPv6 é usado no multicast group management  para optimizar o tráfego multicast. Este processo é referido como Multicast Listener Discovery (MLD)

Os enderecos multicast segundo o RFC 4291:

• Solicited-node multicast addresses are for Neighbor Solicitation (NS) messages;
• All-nodes multicast addresses are for Router Advertisement (RA) messages; and
• All-routers multicast addresses are for Router Solicitation (RS) messages.

IPv6 Anycast Address

Definido no RFC 2526
Permite que o mesmo IP esteja distribuído, mas apenas um Host irá receber o tráfego

set routing-options rib inet6.0 static route 0::/0 next-hop FEc0:0:0:2003::2 preference 250

OSPFv3 Configuration Example

O processo de selecao do RID no OSPFv3 e identico ao da v2, o RID continua a ser IPv4

Monitoring OSPFv3 Operations

show ospf3 neighbor
show ospf3 interface
show ospf3 database
show ospf3 route

IS-IS Configuration

set interfaces ge1/1/0.110 family iso
set interfaces ge1/1/0.110 family inet6 address fec0:0:0:2003::1/64

set interfaces lo0 unit 0 family iso address 49.0002.1111.1111.1111.00
set interfaces lo0 unit 0 family inet6 address fec0:0:0:1001::1/128

Monitoring IS-IS Operations

[email protected]# run show isis interface
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
ge-1/1/0.110          3   0x1 mxA-1.00          mxA-1.00               10/10
lo0.0                 0   0x1 Passive           Passive                 0/0

[edit]
[email protected]# run show isis adjacency

BGP Configuration

!eBGP Peering
set protocols bgp group ext-65501 type external
set protocols bgp group ext-65501 peer-AS 65501
set protocols bgp group ext-65501 neighbor fec0:0:0:2003::2

Monitoring BGP Operations

show bgp summary

Tunneling IPv6 Traffic

Por vezes e necessário encapsular trafego IPv6 em IPv4.

Alguns dos mecanismos de transicao
•IPv4-compatible addressing
•Configured tunnels
•6to4
•6over4

!Site A
set interface gr-0/0/0.0 tunnel source 172.16.110.1 destination 172.16.110.2
set interface gr-0/0/0.0 family inet6 address fec0:0:0:1000::1/126
set routing-options rib inet6.0 static route fec0:0:0:2000::/64 next-hop gr-0/0/0.0
set routing-options rib inet6.0 static route fec0:0:0:1001::/64 next-hop gr-0/0/0.0

!Site B
set interface gr-0/0/0.0 tunnel source 172.16.110.2 destination 172.16.110.1
set interface gr-0/0/0.0 family inet6 address fec0:0:0:1000::2/126
set routing-options rib inet6.0 static route fec0:0:0:2000::/64 next-hop gr-0/0/0.0
set routing-options rib inet6.0 static route fec0:0:0:1001::/64 next-hop gr-0/0/0.0

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 14

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 12

Nota: Este Post faz parte do guide de Routing.

Configuring BGP

set routing-options router-id 192.168.100.1
set routing-options autonomous-system 65503

!iBGP Peering
set protocols bgp group int-65503 type internal
set protocols bgp group int-65503 local-address 192.168.100.1
set protocols bgp group int-65503 neighbor 192.168.100.2

!eBGP Peering
set protocols bgp group ext-65501 type external
set protocols bgp group ext-65501 peer-AS 65501
set protocols bgp group ext-65501 neighbor 172.30.1.2

set policy-options policy-statement next-hop-self-policy term alter-next-hop then next-hop self

Nota: não usar action accept em conjunto com next-hop, porque efetivamente faz match de todas as rotas

!Usar o Next-hop self address
set protocols bgp group int-65503 export next-hop-self-policy

Advertising the Aggregate Route

set routing-options aggregate route 172.24.0.0/22

set policy-options policy-statement adv-aggregate term match-aggregate from protocol aggregate
set policy-options policy-statement adv-aggregate term match-aggregate from route-filter 172.24.0.0/22 exact
set policy-options policy-statement adv-aggregate term match-aggregate then accept

!Advertise the aggregate
set protocols bgp group ext-65501 export adv-aggregate

O import e export de policies podem ser aplicadas nas sessões BGP no neighbor, group ou ao nível do protocolo. O router aplica apenas a policy import/export mais especifica, as policies configuradas serão inerentes nos níveis mais baixos, caso não exista policy nos níveis mais baixos. No entanto se existir policy nos níveis mais baixos será aplicada a respectiva policy.

set protocols bgp import add-community
set protocols bgp export alt-next-hop

set protocols bgp groups ISPs type external
set protocols bgp groups ISPs import alt-local-pref
set protocols bgp groups ISPs export adv-aggregate
set protocols bgp groups ISPs neighbor 172.25.1.1 peer-as 65100

set protocols bgp groups ISPs neighbor 172.25.2.1 export adv-custom
set protocols bgp groups ISPs neighbor 172.25.2.1 peer-as 65200

set protocols bgp groups Internal-Peers type internal
set protocols bgp groups Internal-Peers neighbor 192.168.100.10
set protocols bgp groups Internal-Peers neighbor 192.168.100.20

Import Policy Versus Export Policy

Routes from BGP Peers->RIB-In->Import Policy->RIB-Local (Route table)->Export policy->RIB-Out->Routes to BGP Peers

Só é possível exportar active routes. Por exemplo, se o router receber uma rota via BGP e OSPF sera escolhida a do OSPF devido a sua preference causando assim a inactive BGP route. É possível alterar este comportamento usando o advertise-inactive

Displaying BGP Summary Information

[email protected]# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped…
172.16.110.2          65502         13         12       0       0        4:29 0/0/0/0              0/0/0/0

Output fields do comando show bgp summary:

Groups : Displays the number of BGP groups;
Peers: Displays the number of BGP peers;
Down peers: Displays the number of unestablished BGP peers;
Peer: Displays the address of each BGP peer; each peer has one line of output;
AS: Displays the peer’s AS number;
InPkt: Displays the number of packets received from the peer;
OutPkt : Displays the number of packets sent to the peer;
OutQ: Displays the count of the number of BGP packets queued to be transmitted to a particular neighbor; it
usually is 0 because the queue is emptied quickly;
Last Up/Down: Displays the last time since the neighbor transitioned to or form the established state; and
State: Displays either the BGP state or, if the neighbor is connected, the number of paths received from the
neighbor, the number of these paths that have been accepted as active and are being used for forwarding, and the
number of routes being damped.

[email protected]# run show bgp neighbor
Peer: 172.16.110.2+57229 AS 65502 Local: 172.16.110.1+179 AS 65501
Type: External    State: Established    Flags: <Sync>
Last State: OpenConfirm   Last Event: RecvKeepAlive
Last Error: None
Export: [ policy-out ]
Options: <Preference PeerAS Refresh>
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 100.1.1.2       Local ID: 100.1.1.1         Active Holdtime: 90
Keepalive Interval: 30         Peer index: 0
BFD: disabled, down
Local Interface: ge-1/1/0.110
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 65502)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes:              0
Received prefixes:            0
Accepted prefixes:            0
Suppressed due to damping:    0
Advertised prefixes:          3
Last traffic (seconds): Received 2    Sent 21   Checked 20
Input messages:  Total 50     Updates 2       Refreshes 0     Octets 1038
Output messages: Total 52     Updates 3       Refreshes 0     Octets 1169
Output Queue[0]: 0

Output fields do comando show bgp neighbor:

Peer: Displays the address of each BGP peer; each peer has one line of output.
Type: Displays the type of peer ( Internal  or  External ).
State: Displays the BGP state for this neighbor.
Flags: Displays the internal peer-specific flags for this neighbor.
Last State: Displays the BGP state of this neighbor prior to the current state.
Last Event: Displays the last BGP state transition event.
Last Error: Displays the last notification message sent to the neighbor.
Options: Displays the configuration options in effect for this neighbor.
Holdtime : Displays the configured hold time for this neighbor.
Preference: Displays the configuration preference for routes learned from the neighbor.
Peer ID: Displays the neighbor’s router ID.
Local ID : Displays the local system’s router ID.
Active Holdtime: Displays the hold-time value that was negotiated during the BGP open.
Table inet.0 Bit : Displays the Internal bit used for the peer group.
Send state: Displays whether all peers in the group have received all their updates ( in sync or  out of
sync).
Active Prefixes: Displays the number of prefixes accepted as active from this neighbor.
Last traffic (seconds): Displays how recently a BGP message was sent or received between the local
system and this neighbor.
Output Queue: Displays the number of BGP update messages pending for transmission to the neighbor.
Deleted routes: Displays the prefixes queued for withdrawal through pending update messages.
Queued AS Path: Displays an AS path queued for transmission in an update message.

[email protected]# run show bgp group
Group Type: External                               Local AS: 65501
Name: ext             Index: 0                   Flags: <Export Eval>
Export: [ policy-out ]
Holdtime: 0
Total peers: 1        Established: 1
172.16.110.2+53009
inet.0: 0/0/0/0

Groups: 1  Peers: 1    External: 1    Internal: 0    Down peers: 0   Flaps: 1
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
0          0          0          0          0          0

Output fields do comando show bgp group :

Group Type: Displays the type of BGP group. It can be either  Internal  or  External .
• AS: Displays the number of the remote AS. For IBGP, this  number should be the same as the local AS number.
• Local AS : Displays the number of the local AS.
• Export : Displays the export policies configured for the BGP group with the export statement.
• Total peers : Displays the total number of peers in the group.
• Established : Displays the number of peers within the group that are in the established state.
• ip addresses: Displays the list of peers that are members of the group; the address is followed by the peer’s
port number.
• Options: Displays configured BGP options; these options can be one or more of the following:
– Local address : Displays the address configured with the  local-address  statement.
– NLRI: Displays the configured MBGP state for the BGP group; it can be either multicast or unicast, or both if
you have configured  nlri any .
– Hold time: Displays the hold time configured with the  hold-time statement; the default hold time is
90 seconds.
– Preference: Displays the preference value configured with the  preference statement; the default
preference value is 170.

Displaying Received BGP Routes

!O IP a usar deve ser o local do router usao para fazer peering
[email protected]# run show route advertising-protocol bgp ?
Possible completions:
<neighbor>           IP address of neighbor (local for RIP and RIPng)
!O IP e o do neighbor
[email protected]# run show route receive-protocol bgp ?
Possible completions:
<peer>               IP address of neighbo

!Rotas advertidas depois de aplicar o export policy
[email protected]# run show route advertising-protocol bgp 172.16.110.1

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Prefix                  Nexthop              MED     Lclpref    AS path
* 9.9.9.9/32              Self                 100                200 [65501] I
* 10.210.14.128/27        Self                 100                200 [65501] I
* 172.16.110.0/24         Self                 100                200 [65501] I

!Rotas recebidas antes de aplicar o import policy
[email protected]# run show route receive-protocol bgp 172.16.110.1

inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
Prefix                  Nexthop              MED     Lclpref    AS path
* 9.9.9.9/32              172.16.110.1         100                200 65501 I
10.210.14.128/27        172.16.110.1         100                200 65501 I
172.16.110.0/24         172.16.110.1         100                200 65501 I
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 11

Nota: Este Post faz parte do guide de Routing.

Monitoring Commands

show ospf route
show ospf database
show ospf statistics
show ospf log

[email protected]> show ospf interface extensive
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/3.0          DR      0.0.0.1         192.168.1.2     192.168.1.1        1
Type: LAN, Address: 172.26.1.2, Mask: 255.255.255.252, MTU: 1500, Cost: 1
DR addr: 172.26.1.2, BDR addr: 172.26.1.1, Priority: 128, Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Topology default (ID 0) -> Cost: 0
ge-0/0/1.0          BDR     0.0.0.0         192.168.1.3     192.168.1.2        1
Type: LAN, Address: 172.26.2.1, Mask: 255.255.255.252, MTU: 1500, Cost: 1
DR addr: 172.26.2.2, BDR addr: 172.26.2.1, Priority: 128, Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Topology default (ID 0) -> Cost: 0

O campos de output do comando show ospf interface são:
• Intf: Displays the name of the interface running OSPF.
• State: Displays the state of the interface. It can be BDR ,  Down,  DR,  DRother,  Loop,  PtToPt , or  Waiting.
• Area: Displays the number of the area in which the interface is located.
• DR ID: Displays the address of the area’s designated router.
• BDR ID : Displays the BDR for a particular subnet.
• Nbrs: Displays the number of neighbors on this interface.
• Type (detail and extensive output only): Displays the type of interface. It can be  LAN ,  NBMA,  P2MP,  P2P , or
Virtual.
• address (detail and extensive output only): Displays the IP address of the neighbor.
• mask (detail and extensive output only): Displays the mask of the interface.
• MTU  (detail and extensive output only): Displays the interface’s maximum transmission unit (MTU).
• cost (detail and extensive output only): Displays the interface’s cost (metric).
• DR addr (detail and extensive output only): Displays the address of the designated router.
• BDR addr : Displays the address of the BDR.
• adj count (detail and extensive output only): Displays the number of adjacent neighbors.
• Flood list (extensive output only): Displays the list of LSAs pending flood on this interface.
• Ack list  (extensive output only): Displays the list of pending acknowledgments on this interface.
• Descriptor list (extensive output only): Displays the list of packet descriptors.
• Dead (detail and extensive output only): Displays the configured value for the dead timer.
• Hello (detail and extensive output only): Displays the configured value for the hello timer.
• ReXmit  (detail and extensive output only): Displays the configured value for the retransmit timer.
• OSPF area type (detail and extensive output only): Displays the type of OSPF area, which can be Stub,  Not
Stub, or  NSSA.

O campos de output do comando show ospf route são:
• Prefix : Displays the destination of the route.
• Route/Path Type: Displays how the route was learned:
– ABR : Route to area border router;
– ASBR: Route to AS border router;
– Ext : External router;
– Inter: Interarea route;
– Intra: Intra-area route; or
– Network: Network router.
• Metric : Displays the route’s metric value.
• Next hop i/f: Displays the interface through which the route’s next hop is reachable.
• Next hop addr : Displays the address of the next hop.
• area (detail output only): Displays the area ID of the route.
• options (detail output only): Displays the option bits from the LSA.
• origin  (detail output only): Displays the router from which the route was learned.

O campos de output do comando show ospf database extensive são:
• bits: Displays the flags describing the router that generated the LSP.
• link count: Displays the number of links in the advertisement.
• Each link contains the following output fields:
– id: Displays the ID of a router or subnet on the link.
– data: For stub networks, displays the subnet mask; otherwise, it displays the IP address of the router that
generated the LSP.
– type: Displays the type of link; it can be  PointToPoint,  Transit,  Stub, or  Virtual.
– TOS count: Displays the number of type-of-service (ToS) entries in the advertisement.
– TOS 0 metric: Displays the metric for ToS 0.
• Each ToS entry contains the following output fields:
– TOS : Displays the ToS value.
– metric : Displays the metric for the ToS.
– Aging timer  (extensive output only): Displays how long until the LSA expires (displayed as hrs:min:sec).
– Installed (extensive output only): Displays how long ago the route was installed.
– expires (extensive output only): Displays how long until the route expires (displayed in hrs:min:sec).
– Ours (extensive output only): Indicates that this advertisement is local.

!Visualizar as ocorrências dos cálculos do SPF
show ospf log

OSPF Tracing

set protocols ospf traceoptions file trace-ospf
set protocols ospf traceoptions flag error detail
set protocols ospf traceoptions flag event detail
set protocols ospf area 0 interface ge-0/0/0.0
set protocols ospf area 0 interface lo0.0

Viewing OSPF Error Counters

show ospf statistics
clear ospf statistics

Chapter 4 Border Gateway Protocol

Why BGP?
BGP é um path-vector protocol usado para interdomain routing.

RFC 4271 – BGP version 4 (BGP4)

BGP Peering Sessions

Neighbor States:
TCP Connectivity
Idle
Connect
Active

BGP Connectivity:
OpenSent
OpenConfirm
Established

BGP Message Types
Open
Update
Keepalive
Notification
Refresh – soft clearing do BGP

BGP Update Messages

Descrevem um single path para múltiplos prefixos. BGP peer assume essa informação enquanto não receber nenhum update subsequente advertindo um novo path para o prefixo ou lista-lo como unreachable.

BGP Message Types

BGP Attributes
Type Well-know mandatory
AS Path
Origin
Next-hop

Type Well-know discretionary:
Local Preference
Atomic Aggregator

Type Optional transitive:
Community
Agregator

Type Optional nontransitive:
MED
Cluster List
Originator ID

BGP Attributes

Type Well-know mandatory – A implementação do BGP deve obrigatoriamente suportar
Type Well-know discretionary – A implementação do BGP deve obrigatoriamente suportar
Type Optional transitive – a sua implementação não é obrigatória, mas caso suportado devem ser passados sem serem modificados aos outros Peers BGP
Type Optional nontransitive – a sua implementação não é obrigatória. Se um atributo optional nontransitive não for reconhecido, e ignorado e não enviado aos outros peers

Os Common BGP Attributes:Next-hop,Local Preference,AS-Path,Origin,MED,Community

Next-Hop Attribute

Se o next-hop para um determinado prefixo não for reachable, e colocado na tabela de routing como hidden

show route hidden

Local-Preference Attribute

Atributo visível apenas entre iBGP peers, permite direcionar tráfego de outbound para um determinado peer

Caso seja configurado o local-preference na config e via routing policy, o sistema usa o valor da routing policy

AS-Path Attribute

Verifica o AS-Path e caso o router identifique o seu próprio AS number neste update, é feito Drop devido ao mecanismo de Loop.

É advertido aos restantes peers o best path (menor AS Path para um prefixo)

Origin Attribute

O router que adverte o prefixo e responsável por inserir o atributo Origin

IGP – BGP assigna valor 0 a rota IGP. Exemplos: OSPF, IS-IS, static, e aggregate.
EGP – BGP assigna valor 1 a rota. Rotas EGP do protocolo EGP original, predecessor do BGP
Incomplete – BGP assigna valor 3 a rotas unknown. Estas rotas são conhecidas como não tendo origem no IGP ou EGP

By default o junOS assigna o valor I de IGP, este pode ser alterado usando um routing policy

MED Attribute

Usado para influenciar tráfego inbound (para o meu AS), o BGP assume o MED com valor 0 caso não seja usado o atributo.

Usar o comando metric-out no BGP protocol, group ou neighbor, é possível também usar na routing policy usando metric

Community Attribute

Permite identificar um conjunto de atributos de um grupo de prefixos

set policy-options policy-statement ibgp-export from neighbor 172.25.125.2
set policy-options policy-statement ibgp-export then community set custom-routes

set policy-options community custom-routes members 64700:133

[email protected]# set policy-options policy-statement ibgp-export then community ?
Possible completions:
<community_name>     Name to identify a BGP community
+                    Add BGP communities to the route
–                    Remove BGP communities from the route
=                    Set the BGP communities in the route
add                  Add BGP communities to the route
delete               Remove BGP communities from the route
set                  Set the BGP communities in the route

Summary of BGP Active Route Selection

1. Maior Local Preference
2. AS-Path mais curto
3. Menor Origin Value (I [IGP] < E [EGP] < ? [Incomplete])
4. Menor MED
5. Preferencia de rotas eBGP sob iBGP
6. Prefere best exit do AS (Escolhe o menor cost IGP para o next-hop do BGP)
7. Para rotas eBGP recebidas, prefere a corrente rota, de outra forma prefere a com o menor RID
8. Cluster Length mais curto
9.Prefere as rotas do peer com o menor Peer ID

Descrição de algumas das regras:

6. Escolhe o menor cost IGP para o next-hop do BGP. Para iBGP peer, instala os next-hop com base nas seguintes 3 regras:
a. BGP examina as tabelas inet.0 e inet.3 para encontrar o next-hop. É escolhido o next-hop com menor preference, frequentemente o BGP usa a versão do next-hop inet.3, via MPLS LSP.

b. A preference deve empatar na inet.0 e inet.3, e usado o next-hop na instance inet.3

c. Quando existe um empate na preference e a instance esta na mesma routing table, e examinado o numero de equal-cost paths por cada instance. E instalado o next-hop da instance com mais paths
Este empate é capaz ocorrer quando traffic-engineering bgp-igp é usado no MPLS.

7. BGP usa a rota advertida pelo peer com menor RID. Quando comparando rotas external de 2 External ASs distinctos, se as rotas forem iguais ate a comparação do RID, e preferida a corrente rota.
Esta preferência previne issues relacionados com oscilação de rotas relacionados com o MED
O comando external-router-id sobrepoem-se a este comportamento e prefere a rota external com o menor RID, independentemente de que rota esta atualmente activa.

IBGP Next-Hop Propagation

By default o Next-hop de uma rota eBGP não e alterada, quando e injectada no iBGP.
Usar o comando next-hop self na routing policy

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 10

Nota: Este Post faz parte do guide de Routing.

OSPF Routers

Area border router (ABR) – conectado a 2 areas, em que uma delas é a area 0
Autonomous system boundary router (ASBR)
Backbone router – contido apenas na area 0
Internal router – contido apenas numa area

OSPF Area Types

Intra-Area routes
External routes
Inter-Area routes

A config de Stub Area injecta uma default route, e remove as external routes.
A Totally Stubby Area recebem apenas a default route. O ABR não envia LSA type 3/4/5
Apenas o Not-so-stubby-area (NNSA) permite injectar rotas externas dentro de uma area, de qualquer forma external routes não são enviados para a area NSSA (ABR não envia LSA type 4/5)

LSA Types

Type 1 – Router
Type 2 – Network
Type 3 – Summary
Type 4 – ASBR Summary
Type 5 – External
Type 7 – NSSA External
Type 6 – Multicast OSPF LSA
Type 8 – External attributes LSA
Type 9 – Opaque LSA (link scope)
Type 10 – Opaque LSA (area scope—used for traffic engineering)
Type 11 – Opaque LSA (AS scope)
Para restringir os LSA type 3 no NSSA usar o comando no-summaries

junOS OS OSPF Support

Suporta:
OSPVv2/v3
Autenticacao (MD5) e IPsec
Summarization
External prefix limits – Limitar o numero de prefixos external usando prefix-export-limit.By default sem limite
Graceful restart (GR) – By default disabled. O router informa os neighbors antes de reiniciar. Os neighbors continuam a enviar tráfego para o router pensando que este continua na topologia.E definido um período em que os neighbors consideram o router parte de topologia.
Bidirectional Forwarding Detection (BFD) – Os timers sao adaptive. Por exemplo, o timer pode adaptar-se a um valor + alto se a adjacência falhar, ou um neighbor negociar um valor + alto que o configurado

Basic Configuration

!IPv4
set protocols ospf area interface

!IPv6
set protocols ospf3 area interface

Determining the Router ID

!Config explicitamente o RID
set routing-options router-id 192.168.100.1

O junOS define o router-id através de um loopback com mask diferente de 127/8 em primeiro lugar, senão existitir nenhum loopback
O junOS usa o próximo IP disponível, tipicamente a dedicated management interface.

Configuring OSPF

!Manipular custo do OSPF na interface
set protocols ospf area 0.0.0.1 interface ge-1/0/0.0 metric 100
set protocols ospf area 0.0.0.1 interface lo0.0

O custo de uma interface no OSPF e definido pela formula:
cost = reference-bandwidth / bandwidth

!By default reference bandwidth e de 100mbps
[email protected]# set protocols ospf reference-bandwidth ?
Possible completions:
Bandwidth for calculating metric defaults

Defining and Applying the Redistribution Policy

set policy-options policy-statement 2ospf term match-direct-route from protocol direct
set policy-options policy-statement 2ospf term match-direct-route from route-filter 172.18.1.0/24 exact
set policy-options policy-statement 2ospf term match-direct-route then accept

set protocols ospf export 2ospf

[email protected]> show ospf neighbor extensive
Address          Interface              State     ID               Pri  Dead
172.26.1.1       ge-0/0/3.0             Full      192.168.1.1      128    33
Area 0.0.0.1, opt 0x42, DR 172.26.1.2, BDR 172.26.1.1
Up 22:01:45, adjacent 22:01:37
Topology default (ID 0) -> Bidirectional
172.26.2.2       ge-0/0/1.0             Full      192.168.1.3      128    32
Area 0.0.0.0, opt 0x42, DR 172.26.2.2, BDR 172.26.2.1
Up 1d 03:41:28, adjacent 1d 03:41:28
Topology default (ID 0) -> Bidirectional
172.26.3.2       ge-0/0/2.0             Full      192.168.1.3      128    34
Area 0.0.0.0, opt 0x42, DR 172.26.3.2, BDR 172.26.3.1
Up 1d 03:43:14, adjacent 1d 03:43:14
Topology default (ID 0) -> Bidirectional

O campos de output são :
• Address: Displays the address of the neighbor.
• Intf: Displays the interface through which the neighbor is reachable.
• State: Displays the state of the neighbor, which can be  Attempt,  Down,  Exchange ,  ExStart,  Full,  Init,
Loading, or  2Way.
• ID: Displays the RID of the neighbor.
• Pri : Displays the priority of the neighb or to become the designated router.
• Dead: Displays the number of seconds until the neighbor becomes unreachable.
• area (detail and extensive output only): Displays the area in which the neighbor is located.
• opt  (detail and extensive output only): Displays the option bits from the neighbor.
• DR (detail and extensive output only): Displays the address of the designated router.
• BDR  (detail and extensive output only): Displays the address of the BDR.
• Up (detail and extensive output only): Displays the length of time since the neighbor came up.
• adjacent  (detail and extensive output only): Displays the le ngth of time since the adjacency with the neighbor was established.

!Remover as adjacências
clear ospf neighbor

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 9

Nota: Este Post faz parte do guide de Routing.

Chapter 3 Open Shortest Path First

OSPF Packet Types

Type 1 – Hello
Type 2 – Database Description
Type 3 – Link-State Request
Type 4 – Link-State Update
Type 5 – Link-State Acknowledgment

Hello Packet

Enviado para 224.0.0.5 a cada 10 segundos
Pacote com os seguintes headers:
Network mask*
Hello interval*
Dead interval*
Options*
Router Priority
Designated router
Backup designated router
Neighbor

*Os fields devem fazem match para formar adjacência sob um broadcast medium. O Network Mask não requer match em links point-to-point

Database Description Packet

Usados apenas durante a adjacência, serve para indicar o responsavel pelo processo database synchronization e transferir os LSA headers entre devices.

O Router com RID superior e indicado como Master no processo database synchronization, o Master define e mantém a sequence numbers na transferência.

Database Description fields:
OSPF header
Sequence number
LSA header

Link-State Request

Se a database não tiver nenhum refresh requisita informação ao neighbor

Link-State Request fields:
OSPF header
Link-state type
Link-state ID
Advertising router

Link-State Update

Contem diversos LSAs, é transmitido através do 224.0.0.5 ou 224.0.0.6 dependendo do link type. São transmitidos com base em Request na formação inicial da adjacência

Link-State Update fields:
OSPF header
Number of advertisements
Link-state advertisements

Link-State Acknowledgment

Estes pacotes são recebidos em resposta aos LSA Update enviados.

Forming Adjacency

Adjacency states:
Down
Init
2Way – Existe comunicacao bidirecional
ExStart – determina qual o router Master/Slave
Exchange – trocam os LSA headers das suas databases, caso o router não conheça um LSA header faz LSA requests a solicitar a restante informação
Loading – Indica que o route continua a receber informação do peer
Full – As databases estão síncronas, estado convergente

[email protected]# set protocols ospf area 0.0.0.0 interface ge-1/1/0.110

[email protected]# run show ospf interface
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-1/1/0.110        DR      0.0.0.0         10.210.14.132   0.0.0.0            0

[email protected]# set protocols ospf area 0.0.0.0 interface ge-1/1/0.110 interface-type p2p

[email protected]# run show ospf interface
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-1/1/0.110        PtToPt  0.0.0.0         0.0.0.0         0.0.0.0            0

Electing a Dedignated Router

Elegido DR com Best Priority (valores [1- 255]), by default 128. O Tie-breaker é o RID + alto
O processo para eleger o BDR é idêntico, este assume funções caso detecte que o DR fique indisponível
Priority = 0 não é considerado no processo de seleção e o estado é DRother

Não existe preempt, se um router com melhor priority ficar activo e já existir um DR, o DR não é substituído

OSPF Neighbor Relationship

O state away existe entre routers DROther (non-DR/BDR)

OSPF Areas

O tráfego interarea transita pelo backbone (area 0), este comportamento pode ser alterado usando multi-area adjacency na mesma logical interface eliminando assim a necessidade do tráfego interarea transitar pelo backbone. Multi-area adjacency documentada no RFC 5185

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 8

Nota: Este Post faz parte do guide de Routing.

Chapter 2 Load Balancing and Filter-Based Forwarding

Equal-cost Multipath Load Sharing (ECMP)

Usando ECMP a entrega dos pacotes pode chegar ao destino out-of-order

Per-Packet Load Balancing

Faz forwarding dos pacotes em round-robin mode, o junOS não suporta o forwarding per-packet

Per-Flow Load Balancing

Permite que os pacotes sigam o mesmo path, não exisitndo pacotes out-of-order.
Todos os protocolos (não apenas TCP) podem beneficiar deste mecanismo.

Default Behavior for the junOS OS

No IGP load-balancing o junOS escolhe um dos available equal-cost paths para os qual o tráfego de destino será enviado, desta forma e possível saber sempre (any time) por onde o tráfego flui.
Quando existem existem multiple equal-cost paths o junOS seleciona um next-hop e instala-o na forwarding table.

By default no BGP o método de load-balancing e ligeiramente diferente, e usado o per-prefix. O per-prefix load-balancing ocorre quando as rotas são recebidas via iBGP com os atributos (next-hop) idênticos
não e garantido uma distribuição perfeita do tráfego devido ao algoritmo (hash) para selecionar o next-hop para um prefixo dado. A distribuição efectiva aumenta com um grande numero de prefixos.

Nota:E possível alterar o comportamento do load-balancing usando policy rules

Configuration Examples

! O junOS apenas faz load-balancing para os prefix abaixo
set policy-options policy-statement load-balance-all from route-filter 172.24.0.0/24 exact
set policy-options policy-statement load-balance-all from route-filter 172.24.1.0/24 exact
set policy-options policy-statement load-balance-all then load-balance per-packet

Esta policy deve ser aplicada como export sob a hierarquia routing-options

Nos Internet Processor II ASIC suportam ate 64 ECMP, os tráfego de destino e encaminhado pela mesmo interface outbound com base em algumas características do flow

Nos Internet Processor I ASIC (plataformas legacy) suportam até 8 ECMP, o balanceamento é feito per-packet. O tráfego é distribuído em round-robin usando diversas outbound interfaces

Applying a Load-Balancing Policy

Aplicar load-balacing afeta apenas a forwarding table.

É possível manipular a forwarding table usando uma policy

set routing-options forwarding-table export <policy-name>

RE{RT—Export—>FT—->} PFE{FT}

Determining Traffic Flows

By default o junOS considera que o trafego ingress com os características abaixo pertencem ao mesmo flow:
Incoming interface Index | Destination Address
Source Address                 | Protocol

!Incluir o layer 4 no calculo do flow, deve ser config o layer3 caso seja usado o layer4
set forwarding-options hash-key family inet layer-3 layer-4

Também é possível optimizar MPLS e VPLS flows usando set family mpls e set family multiservice

By default o IPv6 e automaticamente balanceado usando Layer3/Layer4

Filter-Based Forwarding

Permite tomar decisões com base no prefixo destino
Suportado em IPv4 e IPv6

Configuring Filter-Based Forwarding

1.Criar um match filter sob a hierarquia firewall
2.Criar uma routing instance sob a hierarquia routing-instances
3.Criar um RIB Group sob a hierarquia routing-options Partilha as rotas entre instances assim os directly connected nex-hop podem ser resolved

1)
!Este exemplo permite fazer forwarding do trafego para a instance indicada, deve ser ainda configurado no input da interface onde este trafego e recebido
set firewall family inet filter <filter-name> term <term-name> from match-condition
set firewall family inet filter <filter-name> term <term-name> then routing-instance <instance-name>

2)
!Para usar filter-based o instance-type deve ser sempre forwarding
set routing-instances <instance-name> instance-type forwarding routing-options static route 0.0.0.0/0 next-hop <ip-address>

!Tambem e possivel indicar outra routing instance usando next-table
set routing-instances <instance-name> instance-type forwarding routing-options static route 0.0.0.0/0 next-table inet.0

3)
!Esta config partilha as rotas das interfaces entre as instances referidas. Este requisito consegue resolver directly connected next hops
set routing-options interface-routes rib-group inet <group-name>
set routing-options rib-groups <group-name> import-rib [inet.0 instance-name.inet.0]

Neste passo e criada a routing table (ou RIB group) que adiciona interfaces routes a forwarding routing instances usadas no FBF bem como a instance default inet.0 . Esta config resolve as rotas instaladas nas instances directly connected next hops nessa interface

Exemplo: Usar FBF para balancear tráfego com base no source address

R1}-ge-0/0/2—ISP-A
R1}-ge-0/0/3—ISP-B

set firewall family inet filter my-match-filter term match-subnet-A from source-address 172.25.0.0/24
set firewall family inet filter my-match-filter term match-subnet-A then routing-instance ISP-A

set firewall family inet filter my-match-filter term match-subnet-B from source-address 172.25.1.0/24
set firewall family inet filter my-match-filter term match-subnet-B then routing-instance ISP-B

set interfaces ge-0/0/8 unit 0 family inet filter input my-match-filter
set interfaces ge-0/0/8 unit 0 family inet address 172.25.0.1/24
set interfaces ge-0/0/8 unit 0 family inet address 172.25.1.1/24

set routing-instances ISP-A instance-type forwarding routing-options static route 0.0.0.0/0 next-hop 172.20.0.2
set routing-instances ISP-B instance-type forwarding routing-options static route 0.0.0.0/0 next-hop 172.20.1.2

Exemplo: Configure the RIB Group

set routing-options interface-routes rib-group inet my-rib-group
set routing-options rib-groups my-rib-group import-rib [inet.0 ISP-A.inet.0 ISP-B.inet.0]

Nota:A default route  também e incluída

[email protected]> show route table ISP-B.inet.0
ISP-B.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
0.0.0.0/0          *[Static/5] 03:32:41
> to 172.20.1.2 via ge-0/0/3.0
172.20.0.0/30      *[Direct/0] 03:32:41
> via ge-0/0/2.0
172.20.0.1/32      *[Local/0] 03:19:07
Local via ge-0/0/2.0
172.20.1.0/30      *[Direct/0] 03:32:41
> via ge-0/0/3.0
172.20.1.1/32      *[Local/0] 03:19:09
Local via ge-0/0/3.0
172.25.0.0/24      *[Direct/0] 03:32:41
> via ge-0/0/1.0
172.25.0.1/32      *[Local/0] 03:19:09
Local via ge-0/0/1.0
172.25.1.0/24      *[Direct/0] 03:32:41
> via ge-0/0/1.0
172.25.1.1/32      *[Local/0] 03:19:09
Local via ge-0/0/1.0

Então e se a rede source fosse 172.26.1.0/24???
Seria Droped uma vez que não existe Firewall rule a permitir, caso fosse aplicada a config abaixo o lookup seria com base no destino a default routing table

[edit firewall]
[email protected]# show family inet filter my-match-filter
term match-subnet-A {
from {
source-address {
172.25.0.0/24;
}
}
then {
routing-instance ISP-A;
}
}
term match-subnet-B {
from {
source-address {
172.25.1.0/24;
}
}
then {
routing-instance ISP-B;
}
}
term else-accept {
then {
accept;
}
}

Usando a opção instance-import

A config usando rib-group apesar de ter performance, esta técnica tem algumas limitações:

Lack of intuitiveness – não é muito intuitivo
Complex configuration requirements
Redundancy
Per-protocol configuration

set policy-options policy-statement ISP-A-import from instance master
set policy-options policy-statement ISP-A-import then accept

set routing-instances ISP-A instance-type forwarding routing-options static route 0.0.0.0/0 next-hop 172.20.0.2
set routing-instances ISP-A instance-type forwarding routing-options instance-import ISP-A-import

Multitopology Routing Basics

Nota:não disponível nos EX

Permite configurar class-based forwarding para diferentes tipos de tráfego voice, video, etc. Permite ter uma tabela de routing para cada tipo especifico de tráfego

Configuring Topologies

set routing-options topolgies family inet topology my-video-topology

Cada topology cria uma nova routing table e popula-a com direct routes da topology

Configuring Filter-Based Forwarding for Multitopology Routing

set firewall family inet filter my-match-filter term term-name from forwarding-class expedited-forwarding
set firewall family inet filter my-match-filter term term-name then topology my-video-topology

E configurado um firewall filter no ingress para mapear para uma forwarding class especifica

Podem ser usadas uma das 4 forwarding-class:
expedited-forwarding
assured-forwarding
best-effort
network-control

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