Appunti JNCIE-SP - Versione Revisionata

Rotte Statiche

Un rotta statica è valida finchè non la rimuovi o finchè ha un next-hop valido. Il next-hop
può essere:

IP direttamente connesso.

Interfaccia

Un IP remoto,dobbiamo aggiungere l’opzione resolve, in questo caso il router esegue un

lookup nella tabella di routing

Reject scarta il pacchetto inviando un messaggio icmp al mittente

Discard scarta il pacchetto in modo silente

Qualified next hop permette di inserire un secondo IP specificando la route preference (Se
minore di 5 viene scelto come rotta principale)

Label switch path (LSP) in una rete dove è configurato MPLS possiamo assegnare un LSP
come next-hop

Il next-hop è solo un attributo configurabile, oltre il next-hop possiamo configurare

active (default) dice al router di eliminare la rotta se il next-hop non è disponibile

passive opposto di active, mantiene la rotta anche se il next-hop non è disponibile

as-path serve ad assegnare un as-path (utile quando distribuiamo la rotta in bgp)

community

install (default) dice di inserire la rotta nella tabella di forwarding

no-install opposto di install

metric cambia la metrica alla rotta (attenzione non cambia il route preference)

no-readvertise non esporta la rotta su altri protocolli

readvertise (default) esporta la rotta su gli altri protocolli

no-retain (default) con questa opzione la rotta viene tolta dalla tabella di forwarding se il
processo di routing è shutdown

retain mantiene le route in tabella di forwarding

preference modifica il route preference (che di default è 5)

next-table supponiamo di avere delle routing instance possiamo definire su quale tabella di
routing cercare la rotta

receive questo comando può essere utilizzato quando importiamo route da una vrf o su una
vrf e quindi vogliamo provare a pingare indirizzi che si raggiungono attraverso interfacce
che non fanno parte della VRF, in questo caso si definisce una statica verso l’ip di
destinazione della ptp con il campo receive.

Quando configuriamo delle statiche possiamo definire all’interno del menù

routing-option static

delle opzioni valide per tutte (a meno di override delle singole route) questo inserendo
tutte le opzioni sotto il campo default

Esempio

root@MX204-Test# show

inactive: route [Link]/0 next-hop [Link];

route [Link]/29 next-hop [Link];

route [Link]/24 {

next-hop [Link];

preference 4;

route [Link]/8 next-hop [Link];

route [Link]/32 next-hop [Link];

route [Link]/32 next-hop [Link];

defaults {

no-readvertise;

preference 8;

In questo esempio abbiamo indicato come route preference 8 per tutte tranne per la
[Link]/24 che avrà una preference di 4

Rotte Aggregate
Le route aggregate servono per sommarizzare delle route, per essere attiva una rotta
aggregata bisogna che nel route ci sia una contribute route cioè una rotta più specifica
rispetto l’aggregata.

Con il comando show route protocol aggregate detail riusciamo a vedere anche le
contribute route che fanno parte dell’aggregata

Esempio

user@Chardonnay>

show route protocol aggregate detail

inet.0: 23 destinations, 25 routes (23 active, 0 holddown, 0 hidden)

[Link]/17 (1 entry, 1 announced)

*Aggregate Preference: 130

Next hop type: Reject

State: <Active Int Ext>

Age: 23

Task: Aggregate

Announcement bits (2): 0-KRT 5-Resolve inet.0

AS path: I (LocalAgg)

Flags: Depth: 0 Active

AS path list:

AS path: I Refcount: 3

Contributing Routes (3):

[Link]/24 proto Static

[Link]/24 proto Static

[Link]/24 proto Static

I next-hop disponibili per le aggregate sono

Reject

discard
Le opzioni disponibili sono:

active (default) dice al router di eliminare la rotta se il next-hop non è disponibile

passive opposto di active, mantiene la rotta anche se il next-hop non è disponibile

as-path serve ad assegnare un as-path (utile quando distribuiamo la rotta in bgp)

brief con questa opzione viene assegnato all’aggregata il più lungo as-path fra gli as-path
delle contribute route

community

full con questa opzione tutti gli as-path delle contribute route vengono inclusi nell’aggregata

metric cambia la metrica alla rotta (attenzione non cambia il route preference)

policy di default tutte le contribute route fanno parte dell’aggregata, ma è possibile

selezionarne alcune attraverso delle policy

preference modifica il route preference (che di default è 130)

Anche in questo caso è possibile definire delle opzioni di default inserendole nel menù
routing-option aggregate default

Come si vede nell’esempio il pacchetto A che è destinato ad una contribute route viene
inoltrato correttamente, mentre il pacchetto B viene scartato perchè non c’è nessuna
contribute e matcha solo con l’aggregata

Generated Route

Una generated route è simile l’aggregata e serve a generare delle route sommarizzate. A
differenza delle aggregate (che hanno come next-hop reject o discard) le generate route
hanno un ip come next-hop.

Anche le generate route devono avere almeno una rotta valida per essere attiva, ma a
differenza delle aggregate il contribute route deve avere come next-hop un ip o deve essere
direttamente connesso, se hanno come next-hop reject o discard non vengono scelte come
contribute route.

Ogni generated route selezione fra le contribute route la principale che è di solito quella che
il prefisso più basso come valore numerico.

Es.

Se per la [Link]/16 ci sono 2 contribute route es. [Link]/30 e [Link]/24 lei

sceglierà come primaria la [Link]/24 perchè 24 è più piccolo di 30.

Per vedere le varie generated route si utilizza il comando

show route protocol generated detail

Martian Route

Sono route non ruotate su internet

Prefix bits of [Link] /8 and more specific routes

Prefix bits of [Link] /8 and more specific routes

Prefix bits of [Link] /16 and more specific routes

Prefix bits of [Link] /16 and more specific routes

Prefix bits of [Link] /24 and more specific routes

Prefix bits of [Link] /24 and more specific routes

Prefix bits of [Link] /4 and more specific routes

Le Martian route non sono permesse in tabella di routing, se vogliamo permetterle

dobbiamo configurarle con il comando

routing-options {

martians {

prefix/prefix-length match-type allow;

dove prefix/prefix-length rappresenta la net e match-type invece può essere

exact

longer

orlonger

prefix-lenght-range

through

upto

per vedere le martian route utilizziamo il comando

show route martians

Puoi definire le rouunting instance all’interno del menù routing-instance, le rouinting-
instance vengono utilizzate per il filter-based forwarding, vpn e system virtualization.
Possono essere del tipo

Forwarding: utilizzata per implementare FBF

L2VP Per implementare L2VPN

No-Forwarding utilizzata per separare grandi rete in piccole entità

Virtual-Router per implementare sistemi di virtualizzazioni non associate a vpn

VRF per implementare l3VPN

VPLS per implementare point to multipoint LAN

Esempio di Routing instance

Se ad esempio vogliamo testare il funzionemento, utilizzando il ping, dobbiamo utilizzare

ping address routing-instance nome-routing-instance, per vedere la tabella di routing
utilizziamo il comando show route table [Link].0 (NB nome routing
instance seguito da .inet.0, ovviamente se vogliamo vedere la inet.0 della routing instance),
per vedere le interfacce utilizziamo il comando show interface terse routing-instance nome-
routing-instance, per vedere tutte le tabelle si utilizza il comando show route instance.

Per importare o esportare route tra le instance, si possono utilizzare i comandi:

instance-import

instance-export

auto-export

Per collegare 2 routing-instance si possono utilizzare interfacce fisiche o virtuali (come ad

esempio le logical-tunnel). Le logical tunnel non possono essere configurati su tutti gli
apparati ma solo quelli che hanno le schede (NB almeno un’interfaccia della scheda deve
essere attiva).

Possono essere di tipo Ethernet, ccc, vpls, vlan-ccc, vlan, vlan-vpls. E si ci può configurare
IPv4, IPv6, isis mpls.

Ogni unit è associata ad un’altra.

le tabelle di routing di un router (RIB) junos sono:

inet.0 contiene IPv4 unicast

inet.1 contiene IPv4 Multicast

inet.2 contiene IPv4 unicast, ma questa tabella viene utilizzata dal protocollo di routing
multicast per evitare i loop, questo processo è detto Reverse Path Forwarding (RPF)

inet.3 contiene gli ip di uscita dei MPLS label switch path (LSP)

inet.4 conserva le informazioni apprese utilizzando il Multicast Source Discovery Protocol

(MSDP)

inet6.0 contiene IPv6 unicast

mpls.0 non è una routing table, ma una switching table. Questa tabella contiene gli MPLS
label

bgp.l3vpn.0 conserve tutte le informazioni di routing delle L3 VPN

bgp.l2vpn.0 conserve tutte le informazioni di routing delle L2 VPN

Certe volte può servire copiare delle route che appartengono ad una RIB (Routing
Information Base, o semplicemente tabelle di routing) su altre RIB (anche crearne nuove).
In questo caso utilizziamo le RIB Groups

routing-option {

rib-groups {

<rib-group name> {

import-rib [ source-routing-table destination-routing-table1 destination-routing-

table2 ......... ]

import-policy policy-name;(opzionale)

export-rib table (opzionale)

Con questo comando scegliamo solo cosa copiare e dove copiare, ma non viene copiata
nessuna informazione. Per copiare le informazioni dobbiamo configurare i vari protocolli di
routing (in base a quale route dobbiamo copiare):

Per il routing statico dobbiamo utilizzare il comando

routing-option {

interface-routes {
 rib-group nome-rib-group

Per OSPF

protocols {

ospf {

rib-group nome-rib-group

BGP

protocols {

bgp {

family inet {

unicast {

rib-group bgp-rg;

quello sopra è un esempio si può configurare anche su family inet multicast, family INET6
ecc.

Solo per il traffico IPv4 ed IPv6 puoi utilizzare dei firewall filter utilizzando forwarding class
e routing instance. Questo si chiama Filter Based Forwarding (FBF).

Puoi definire un filtro partendo dal source (ad esempio se due clienti condividono lo stesso
L2, ma devono uscire da fornitori diversi), quindi applichi un filtro nell’interfaccia di
ingresso. Oppure se vuoi duplicare il traffico di un interfaccia d’uscita (port mirroring).
Tu puoi creare un regola di firewall classificando il pacchetto con il non-terminating action
forwarding-class class-name

Oppure cambiare il percorso con la teminating action routing-instance routing-instance-

name <topology topology-name>

NB: per inserire nella routing-instance master si deve utilizzare il comando routing-instance
default (master non è un comando valido)

Vediamo un esempio di ingress

Vediamo la configurazione di P1

set firewall filter classify-customers term sp1-customers from source-address [Link]/24

set firewall filter classify-customers term sp1-customers from source-address [Link]/24

set firewall filter classify-customers term sp1-customers then log

set firewall filter classify-customers term sp1-customers then routing-instance sp1-route-

table

set firewall filter classify-customers term sp2-customers from source-address [Link]/24

set firewall filter classify-customers term sp2-customers from source-address [Link]/24

set firewall filter classify-customers term sp2-customers then log

set firewall filter classify-customers term sp2-customers then routing-instance sp2-route-

table

set firewall filter classify-customers term default then accept

set interfaces fe-1/2/0 unit 0 family inet filter input classify-customers

set interfaces fe-1/2/0 unit 0 family inet address [Link]/30

set interfaces fe-1/2/1 unit 0 family inet address [Link]/30

set interfaces fe-1/2/2 unit 0 family inet address [Link]/30

set protocols ospf rib-group fbf-group

set protocols ospf area [Link] interface all

set protocols ospf area [Link] interface fxp0.0 disable

set routing-instances sp1-route-table instance-type forwarding

set routing-instances sp1-route-table routing-options static route [Link]/0 next-hop

[Link]
set routing-instances sp2-route-table instance-type forwarding

set routing-instances sp2-route-table routing-options static route [Link]/0 next-hop

[Link]

set routing-options interface-routes rib-group fbf-group

set routing-options rib-groups fbf-group import-rib inet.0

set routing-options rib-groups fbf-group import-rib [Link].0

set routing-options rib-groups fbf-group import-rib [Link].0

In pratica tutto il traffico con source [Link]/24 e [Link]/24 viene inserito nella routing-
instance sp1-route-table, quello con [Link]/24 e [Link]/24 nella sp2-route-table.

Un esempio di egress invece

set interfaces ge-2/1/0 unit 0 family inet filter input filter1

set interfaces ge-2/1/0 unit 0 family inet address [Link]/30

set interfaces ge-2/1/0 unit 0 description to-R1

set interfaces ge-2/1/0 unit 0 family iso

set interfaces ge-2/1/1 vlan-tagging

set interfaces ge-2/1/1 description to-R3

set interfaces ge-2/1/1 unit 0 vlan-id 1001

set interfaces ge-2/1/1 unit 0 family inet address [Link]/30

set interfaces ge-2/1/1 unit 0 family iso

set interfaces ge-2/1/1 unit 1 vlan-id 1002

set interfaces ge-2/1/1 unit 1 family inet address [Link]/30

set interfaces ge-2/1/1 unit 1 family iso

set interfaces lo0 unit 0 family inet address [Link]/32

set interfaces lo0 unit 0 family iso address 49.0001.0010.0000.0404.00

set firewall family inet filter filter1 term t1 from source-address [Link]/32

set firewall family inet filter filter1 term t1 then next-interface ge-2/1/1.0

set firewall family inet filter filter1 term t2 from source-address [Link]/32
set firewall family inet filter filter1 term t2 then next-interface ge-2/1/1.1

set protocols isis interface all level 1 disable

set protocols isis interface fxp0.0 disable

set protocols isis interface lo0.0

In questo esempio abbiamo utilizzato il comando next-interface ma avremmo potuto

utilizzare anche il comando next-ip [Link] routing-instance VR1

Ovviamente creando la routing instance VR1

Nelle rounting-instance possiamo importare delle RIB utilizzando delle policy vedi esempio

NB: per indicare la inet.0 si utilizza master

Quando digitiamo il comando show route, abbiamo alcune informazioni

inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

[Link]/24 *[Direct/0] [Link]

> via fe-0/0/0.0

[Link]/32 *[Local/0] [Link]

Local

[Link]/16 *[Aggregate/130] [Link]

> to [Link] via fe-0/0/2.0

[Link]/24 *[IS-IS/18] [Link], metric 20, tag 2

> to [Link] via fe-0/0/2.0

Route status (segnato rosso) che comprende active route (+), last active route (-), both
current and last active route (*) . Per le route non attive non viene utilizzata alcuna icona

Protocol name (azzurro) viene indicato il protocollo con cui viene appresa la rotta

Protocol preference (giallo) viene indicato il route prefere ce

Next-hop information una route può avere uno o più next-hop assegnati. In caso di next-hop
multipli allora si può applicare il load balancing

con show route hidden vediamo le route hidden

Di default una rotta accetta un solo next-hop ma possiamo dire al router di accettare più
next-hop con il comando

policy-options {

policy-statement please-load-balance-traffic {

then {

load-balance per-packet;

in questo modo creiamo la policy, resta che applicarla all’export della forwarding-table con
il comando

set forwarding-table export please-load-balance-traffic

Con il load-balance per packet i pacchetti vengono inviati in round-robin, ma questo

potreste creare dei problemi perchè i pacchetti potrebbero essere consegnati non in ordine

I nuovi router utilizzano i load per-flow che bilancia le sessioni

Per ogni rotta è possibile installare fino a 64 equal-cost path .

Di default il router definisce un flow guardando source e destination, ma è possibile

aggiungere anche le porte TCP utilizzando questa configurazione:

Si può aggiungere anche family mpls e family multiservice

Per verificare se il traffico viene bilanciato si utilizza il comando

show route forwarding-table

Con show route resolution unresolved vediamo le route hidden per non si riesce a risolvere
il next-hop

Junos route prefence

OSPF

Come funzione un protocollo di routing link state?

Quando un link viene aggiungo un link-state router, il router aggiunge subito le

informazioni del link sul proprio link-state database. Dopo invia degli Hello messagges per
verificare se un altro router è in ascolto nel link. Se un router è in ascolto allora si forma
un’adiacenza, che abilita i due routers a scambiarsi il riepilogo delle informazioni della link-
state database. Ogni router valuta le informazioni ricevute e determina se ha bisogno di
aggiornare il proprio link-state database, in caso positivo allora richiede l’update (che
contiene tutte le informazioni). Questo processo continua finche entrambi i router hanno lo
stesso link-state database.

Ogni router utilizza l’algoritmo di Dijkstra per calcolare ogni path. L’utilizzo dello stesso
link-state database e dello stesso algoritmo permetto una topologia loop-free.

Pacchetti OSPF

Ogni pacchetto OSPF condivide un header di 24 ottetti. Questo serve al router destinatario
di valutare se un pacchetto è valido o no.

Questo header contiene

Version (1 ottetto) indica la versione ospf utilizzata (di default 2)

Type (1 ottetto) indica il tipo di pacchetto ed ha questi possibili valori:

1 Hello Packet

2 Database descriptor

3 Link state request

4 Link state update

5 Link state acknowledgment

Packet length (2 ottetti) indica la lunghezza dell’intero pacchetto OSPF

Router ID (4 ottetti) Il router ID del router che sta inviando il pacchetto

Area ID (4 ottetti) Contiene il 32-bit area ID

Checksum (2 ottetti) contiene il checksum dell’intero pacchetto ad esclusione dei 64-bit del
campo authentication

Authentication type indica il tipo di autenticazione, e può contenere i seguenti valori:

0 Nessuna autenticazione

1 password

2 MD5

Authentication (2 ottetti) contiene la i dati di autenticazione

Hello packet
L’Hello packet viene utilizzato per stabilire e mantenere l’adiacenza, è inviato a tutti tramite
l’indirizzo mulicast [Link] sia per connessione broadcast che point-to-point.

Database Description Packet

Dopo aver scoperto i propri vicini, il router forma l’adiacenza, questa adiacenza richiede che
ogni router invia le informazioni del proprio local database. Per far ciò il router utilizza il
Database Description (DD). In questo pacchetto il router sommarizza il local database
inviando degli LSA (Link-State Advertisement) Header. Il router che riceve questo pacchetto
analizza questa header per capire se deve aggiornare il database

Link-State Request Packet

Durante il processo di sincronizzazione del database, il router potrebbe capire che il proprio
database non è aggiornato. Quindi utilizzato il pacchetto Link-State Request per richiedere
uno o più LSA (NB nello stesso pacchetto possono essere richiesti più LSA)

Link-State Update Packet

Le informazioni del Link-State Database sono popolate attraverso i Link State

Advertisement (LSA). Ogni LSA contiene routing, metric ed informazioni sulla topologia di
una porzione di network OSPF. Questo pacchetto viene floodato su tutto il network finchè
ogni router riceva una copia, o può essere utilizzato in risposta ad un Link-state request.

Link-State Acknowledgment Packet

L’affidabilità del protocollo OSPF prevede che ad ogni Link-State Update packet si risponda
con un Link-State Acknowledgment packet

Adiacenza OSPF

Durante il processo di formazione dell’adiacenza, due router attraversano diversi stati

prima di diventare neighbors.

DOWN Down è lo stato iniziale, può essere in questo stato quando si configura per la prima
volta OSPF e non ha ricevuto ancora nessun hello packet, oppure non ha ricevuto un hello
packet durante il dead interval e metto down l’adiacenza

Init Questo avviene quando un router riceve un hello packet, ma il proprio Router ID non è
contenuto nel pacchetto (guarda header Hello packet). Questo significa che non c’è ancora
comunicazione bidirezionale.

Attempt stato valido solo per il Non-Broadcast Multi-Access (NBMA) Network. Significa che
un hello packet non è stato ricevuto da un neighbor ed il local router invia un unicast hello
packet al neighbor entro l’hello interval.
2-way indica che il local local router riceve un hello packet con all’interno il proprio router-
id. Significa che la comunicazione bidirezionale è attiva quindi i due router sono OSPF
neighbors

EXStart in questo stato si stabilisce chi sarà il router incaricato del processo di
sincronizzazione del database. Il router con il più alto router ID sarà il master

Exchange in questo stato si scambiano i Database description (DD) packet

Loading Se un router ha bisogno di aggiornare la propria tabella allora passa allo stato di
loading ed invia un link-state request packet.

Full i due router hanno completato il processo di sincronizzazione del link-state database

Router LSA

Il primo passo per costruire un network OSPF è quello di annunciare i prefissi connessi.
Queste informazioni sono contenute nei router LSA (type code 1) che mostrano dati sul
local router. Questi includono anche tutti i link connessi al router, le metriche delle
interfacce e la capacità del router OSPF.

Queste LSA type 1 sono scambiati con tutti i router che fanno parte della stessa area, se un
router fa parte di aree diverse avrà un LSA type 1 per ogni area.

Quando colleghiamo due router ognuno di essi genera a LSA type 1 e l’aggiunge al proprio
database. Dopo che i due router diventano adiacenti allora floodano LSA a tutti i vicini.
Questi LSA descrivono tutte le network connesse incluse le interfacce di loopback.

Supponiamo invece che 5 router condividano lo stesso segmento network, ogni router del
segmento vede l’hello packet, perchè inviato all’indirizzo [Link] (ALLSFPRouter), quindi
all'interno del link si formeranno 10 adiacenze.

Questa configurazione però ha un duplice problema, primo ogni router del link invia le
stesse informazioni al resto della rete OSPF, secondo ogni router flooda LSA agli altri router
del link.

Per evitare questi problemi si utilizza il Designed Router (DR) , ogni segmento network
elegge un DR, ogni DR stabilisce l’adiacenza con il resto dei router, i router del segmento
invieranno le informazioni al DR utilizzando l’indirizzo [Link] (AllDRRouter). Il DR
floodare dei LSA TYPE 2 (Network LSA) al resto della rete. Oltre al DR viene eletto anche
Backup Designed Router (BDR). Il BDR resta in ascolto sulla [Link], forma adiacenze con
tutti i router del segmento network e monitora il DR.

L’elezione del DR avviene quando nessun DR è stato eletto, questo si capisce perchè
nell’hello packet non viene indicato nessun DR address. L’elezione del DR si basa su Router
Priority e Router ID. Inizialmente si sceglie il router con Priorità più alta, a parità di priorità
viene scelto quello con ID più alto. Di solito quando si forma un segmento network, ed
ancora non è stato eletto alcun DR, il tempo di attesa (detto WaitTimer) è settato allo stesso
tempo del dead interval per essere certi che tutti i router del segmento ricevano l’hello
packet.

NB: Una volta eletti DR e BDR non sono più cambiati a meno che uno dei due esca dalla rete.
Anche se un router con priorità più alta viene inserito nel segmento, non diventa DR finchè
non cadono DR e BDR, in pratica se cade il DR, il BDR diventa DR ed il nuovo router diventa
BDR per diventare DR deve attendere che il BDR cada.

Di default la priorità è 128. In un DRother le sessioni ospf sono full solo verso DR e BDR,
mentre tra i DRother restano in 2 way

Le aree OSPF sono state definite per limitare il flood LSA, ogni area ha un univoco ID di 32
bit rappressato in ottetti (esempio di area ID [Link]), molti preferiscono utilizzare un
numero intero (es. area 0).

L’area 0 detta anche area backbone è l’area che forma il core del network, collega a tutte le
aree non backbone e redistribuisce le informazioni di router tra queste.

I ruoli e le responsabilità di un router dipendono dalla loro posizione, i router di dividono in

Internal sono router che hanno tutte le interfacce all’interno di una sola area

Backbone router sono router che hanno almeno un’interfaccia in area 0

Area Border Router (ABR) sono router connessi a più area con almeno un’interfaccia
nell’area 0.

Autonomous System Boundary Router (ASBR) inietta route apprese da protocolli esterni
all’interno dell’OSPF

Tra le aree le informazioni di routing vengono scambiate attraverso i network summary

LSA (LSA Type 3) .

Per trasportare route non ospf (esempio delle statiche) si utilizzano gli AS External LSA
(type code 5) . Oltre alle route esterne deve essere anche conosciuto anche l’indirizzo
dell’ASBR.

Nell’esempio in figura Carbenet è L’ASBR è genera LSA type 5 per annunciare le net della
server farm. Ma L’area 10 e l’area 22 non conosco l’indirizzo di Carbenet, quindi Sangria e
Chardonnay utilizzano degli ASBR summary LSA (type 4), per comunicare le net ASBR nella
propria area.

Con le tecniche viste prima abbiamo ridotto il flood degli lsa, ma non ridotto la tabella di
routing dei vari router. Per far ciò possiamo introdurre delle

Stubby areas
Totally stubby ares

Not so Stubby area

I router di una Stub area hanno un link-date database in quanto l’abr non invia gli lsa type 4
e type 5 (route esterne) per queste route viene creata la default

In una totally stubby area i router dell’area contengono solo le route della propria area ed
una default.

Un Not so Stubby area (NSSA) è un’area stubby che permette alcune solo alcune route
external. Per far ciò si utilizzano gli NSSA external LSA (Type 7) . Un esempio di stubby area
è quando dobbiamo collegare un nostro cliente che non utilizza OSPF e dobbiamo
comunque raggiungere le sue net fig 6.19 in questo caso il router Muscat (che ha funzione di
ASBR) crea degli LSA Type 7, che in pratica invia le route esterne a tutti i router all’interno
dell’area, poi Sangria (che ha funzione ABR) sostituite gli LSA Type 7 con degli LSA type 5 e
li invia alle altre aree

Per configurare OSPF in un router bisogna inserire l’interfaccia logica all’interno del menù

protocol ospf area (dove area può essere un numero decimale, che poi viene tradotto in 4
ottetti, o direttamente i 4 ottetti)

Esempio di configurazione multiarea

[edit protocols ospf]

root@R2# show

area [Link] {

interface ge-0/0/0.0;

interface lo0.0 {

passive;

area [Link] {

interface ge-0/0/2.0 {

priority 20;

}
Opzionale di può configurare il numero di route da annunciare con il comando prefix-
export-limit (di default nessun limite), il graceful restart in modo che il local router avverte
il peer prima di riavviare la sessione ed il BFD.

Può capitare di voler instaurare un’adiacenza multiarea, ad esempio si vuole condividere

un link a grande capacità fra 2 ABR

Esempio di configurazione dei due ABR

ABR1

set interfaces so-0/0/0 unit 0 family inet address [Link]/24

set routing-options router-id [Link]

set protocols ospf area [Link] interface so-0/0/0

set protocols ospf area [Link] interface so-0/0/0 secondary

ABR2

set interfaces so-1/0/0 unit 0 family inet address [Link]/24

set routing-options router-id [Link]

set protocols ospf area [Link] interface so-1/0/0

set protocols ospf area [Link] interface so-1/0/0 secondary

Per configurare il router-id (che ha effetto su tutti i protocolli) si utilizza il comando

set routing-option router-id IP

Per configurare un’area come stub utilizziamo i seguenti comandi

set protocol ospf area 0.0.0.X (x diverso da 0) stub default-metric y

Con questo comando indichiamo che l’area x è stub e che ai router viene annunciata la
default con metrica y

ed opzionalmente possiamo utilizzare l’opzione no-summarization per far si che le route

dell’area stub non vengono annunciate sommarizzate.

Il comando stub dice che nell’area non vengono annunciati LSA type 5

Ci sono alcune limitazioni:

Non si può creare un virtual-link tra stub area

una stub area non può contenere un AS boundary router (router di collegamento tra as)
l’area backbone ([Link]) non può essere stub

non si può configurare un’area stub e not-so-stubby area (NSSA)

Nell’esempio precedente l’area 9 deve essere configurata come Not So Stubby Area (NSSA)
in quanto abbiamo delle route esterne (Customer Network).

per configurare un’area nssa si utilizza il comando

set protocol ospf area [Link] nssa

a cui possiamo aggiungere altre opzioni quali

no-summaries che non fa annunciare dall’ABR gli LSA type 3 all’interno dell’area NSSA. Se
combinato con l’opzione default-metric solo le route interne e la default vengono
annunciate nell’area. Solo l’abr ha necessità di questa opzione perchè è l’unico a creare lsa
type 3

default-lsa Serve a configurare L’ABR per generare la default dentro la NSSA, puoi
configurarlo con le opzioni

default-metric Serve a specificare la metrica utilizzata per la default.

metric-type (opzionale) Specifica il tipo di metrica utilizzata per le route esterne. Se Type 1
il costo equivale al costo interno + il costo esterno. Se type 2 il costo assegnato alla rotta
equivale al costo esterno. Di default junos utilizza type 2 e questo costo viene assegnato
all’AS boundary router (router di collegamento tra AS.

type-7 (opzionale) permette gli LSA type 7 all’interno dell’area NSSA.

Come scritto in precedenza l’area backbone deve essere collegata a tutte le altre aree, se
questo non è possibile si utilizza il virtual link

in questo esempio area 0 ed area 3 non sono collegati ma utilizzando il virtual link si
uniscono

set protocols ospf area [Link] virtual-link neighbor-id [Link] transit-area [Link]

in questo comando specifichiamo il neighbor-id (che è il router id), e l’area che si collega
attraverso il link.

Per impostare l’autenticazione tra 2 router si utilizza il seguente comando

set protocols ospf area [Link] interface interfaccia authentication md5 key-id (key-id è
opzionale) key password

dove key-id è un numero da 0 a 255 se non specificato di default viene utilizzato 0.

Un altro comando opzionale (se non impostato di default è 100 Mbps) è il comando
reference-bandwidth che serve al calcolare il costo di un’interfaccia con la formula

cost = ref-bandwidth/bandwidth

si setta con set protocol ospf reference-bandwidth banda

Di default la Lo0 ha metrica zero non viene associata nessuna banda, mentre un’interfaccia
qualsiasi può avere metrica che va da 1 a 65535

Per sommarizzare l’annuncio di alcune route di un’area non backbone si utilizza il comando

set protocols ospf area area area-range network

Per importare o esportare route non OSPF (esempio le statiche) in OSPF possiamo utilizzare
il comando

set protocol ospf import/export nome_policy

Esempio di export delle statiche in OSPF

user@host# show policy-options

policy-statement exportstatic1 {

term exportstatic1 {

from protocol static;

then accept;

user@host# show protocols ospf

export exportstatic1;

Comandi utili per il troubleshooting

show ospf interface

root@R2> show ospf interface

Interface State Area DR ID BDR ID Nbrs

ge-0/0/0.0 DR [Link] [Link] [Link] 1

lo0.0 DRother [Link] [Link] [Link] 0

ge-0/0/2.0 DRother [Link] [Link] [Link] 2

Dove

Interface indica l'interfaccia configurata sul router

State indica lo stato corrente che può essere

BDR il local router è Backup Designated router

DOWN l’interfaccia non è attiva

DR il router è il Designed Router

DRother il router non ne ne backup ne disegned

PtToPt l’interfaccia è ptp

Area indica l’id dell’area

DR ID Indica il router ID del DR. Nel caso di PtP c’è scritto [Link]

BDR ID Indica il router ID del BDR. Nel caso di PtP c’è scritto [Link]

NBR Indica il numero di neighbors trovati

Show ospf neighbor

root@R2> show ospf neighbor

Address Interface State ID Pri Dead

[Link] ge-0/0/0.0 Full [Link] 128 38

[Link] ge-0/0/2.0 Full [Link] 128 33

[Link] ge-0/0/2.0 Full [Link] 30 32

Dove

Address Indirizzo dell’interfaccia del neighbor

Interface L’interfaccia dove ha trovato il neighbor

State lo stato dell’adiacenza OSPF

ID Router ID del neighbor

PRI Priorità del neighbor

Dead il tempo che rimane prima che il neighbor venga dichiarato non raggiungibile. Ogni
volta che si riceve un hello packet allora il tempo viene settato al valore di dead interval
Con il comando clear ospf neighbor [neighboor-address] si cancellano le adiacenze nel caso
in cui specifichiamo il neighboor cancelliamo solo l’adiacenza con il vicino se non
specifichiamo l’indirizzo cancelliamo tutte le adiacenze.

Con il comando show ospf database visualizziamo la link-state dabase, cioè vediamo tutti gli
LSA suddivisi per area.

ser@Shiraz> show ospf database

OSPF link state database, area [Link]

Type ID Adv Rtr Seq Age Opt Cksum Len

Router *[Link] [Link] 0x80000004 2965 0x2 0x3407 60

Router [Link] [Link] 0x80000004 2971 0x2 0xb58a 60

Router [Link] [Link] 0x80000008 2800 0x2 0x2f12 60

Router [Link] [Link] 0x8000000c 1328 0x2 0x6d4 108

Summary [Link] [Link] 0x80000005 728 0x2 0x3525 28

ASBRSum [Link] [Link] 0x80000006 128 0x2 0xf976 28

OSPF external link state database

Type ID Adv Rtr Seq Age Opt Cksum Len

Extern [Link] [Link] 0x80000034 306 0x2 0xe5da 36

Extern [Link] [Link] 0x80000034 5 0x2 0xdae4 36

Extern [Link] [Link] 0x80000033 1206 0x2 0xd1ed 36

Extern [Link] [Link] 0x80000033 907 0x2 0xc6f7 36

I campi sono:

Type che indica il tipo di LSA, e può essere:

Router Type 1 LSA

Network Type 2 LSA

Summary Type 3 LSA

ASBRSum Type 4 LSA

Extern type 5 LSA

NSSA Type 7 LSA

ID Indica L’ID dell’LSA è univoco e definisce LSA. Se c’è un * significa che è ganerato dal
router

ADV RTR il router ID che genera LSA

SEQ è il sequence number che determina LSA più recente

AGE indica l’età dell’LSA, comincia da zero e cresce fino a 3600. Quando arriva a 3600 deve
essere aggiornato

OPT viene indicato il valore del campo option field del pacchetto Hello

Cksum è il valore di checksum

Len lunghezza dell’lsa

con il comando clear ospf database purge poniamo tutti gli age degli LSA a 3600 quindi
devono essere tutti aggiornati.

Un altro comando utile è show ospf route

possiamo aggiungere delle opzioni per filtrare i tipi di route

show ospf log mostra i log dei calcoli SPF (Shortest-path-first), questo comando viene
utilizzato per vedere se la rete è stabile infatti quando vengono effettuati diversi calcoli in
poco tempo significa che c’è qualche link che flappa

show ospf statistics mostra le statistiche dei pacchetti ricevuti ed inviati

Alcuni consigli per il troubleshooting

Un ultimo comando è il traceoptions per configurarlo bisogna:

Creare il file ed indicare il numero di file che verranno creati a rotazione e la dimensione

set protocols ospf traceoptions file ospf-log

set protocols ospf traceoptions file files 5 size 10k

Specificare i vari flag

i flag possono essere

database-description—All database description packets, which are used in synchronizing

the OSPF topological database

error—OSPF error packets

event—OSPF state transitions

flooding—Link-state flooding packets

graceful-restart—Graceful-restart events

hello—Hello packets, which are used to establish neighbor adjacencies and to determine
whether neighbors are reachable

ldp-synchronization—Synchronization events between OSPF and LDP

lsa-ack—Link-state acknowledgment packets, which are used in synchronizing the OSPF

topological database

lsa-analysis—Link-state analysis. Specific to the Juniper Networks implementation of OSPF,

Junos OS performs LSA analysis before running the shortest-path-first (SPF) algorithm. LSA
analysis helps to speed the calculations performed by the SPF algorithm.

lsa-request—Link-state request packets, which are used in synchronizing the OSPF

topological database

lsa-update—Link-state updates packets, which are used in synchronizing the OSPF

topological database

nsr-synchronization—Nonstop routing synchronization events

on-demand—Trace demand circuit extensions

packet-dump—Dump the contents of selected packet types

packets—All OSPF packets

restart-signaling—(OSPFv2 only) Restart-signaling graceful restart events

spf—Shortest path first (SPF) calculations

Ed opzionale si può specificare

detail—Detailed trace information

receive—Packets being received

send—Packets being transmitted

IS-IS

Come OSPF IS-IS è un protocollo Link-state, in IS-IS si utilizzano due livelli, tutti i link-state
database contenuti nel livello sono identici.

Level 2 i router formano un’adiacenza di livello 2 quando entrambi fanno parte di due aree
differenti
Level 1 due router formano un adiacenza di livello 1 quando fanno parte della stessa area.

Per un piccolo numero di router (meno di 200) puoi utilizzare un unico livello, mentre per
numeri grandi puoi configurare il backbone come Livello 2 e gli altri router in altre aree di
livello 1.

Un router di livello 1 contiene tutte le route della propria area, mentre una default per tutte
le altre, un router di livello 2 invece contiene tutte le route.

i router possono essere:

Router L1

Router L2

Router L1/L2 (che è il default per junos)

L’area di appartenenza di un router è codificata all’interno dell’indirizzo ISO chiamato

Network Entity Title (NET). IS-IS utilizza lo standard Network Service Access Point (NSAP),
ci sono 3 parti nella struttura: area, system ID, N-selector.

es. di indirizzo ISO 49.0001.1851.5722.8252.00

La prima parte indica l’area, questo campo comincia con Authority and Format Indicator
(AFI), seguito da Initial Domain Identifier, e finisce con il Domain Specific Part (DSP). Spesso
gli indirizzi cominciano con 0x49 (49 in esadecimale) che rappresenta un NSAP privato.

Il campo system ID deve essere unico nella rete, si può utilizzare il MAC-ADDRESS (ma
questo rende l’indirizzo poco leggibile) o si utilizza l’indirizzo di Loopback compresi gli zeri
nascosti es

[Link] si intende come [Link]

Alla fine abbiamo il campo N-Select (SEL) di solito il valore è 0x00 (00 in esadecimale).

Adiacenze IS-IS

Come in OSPF due router per formare un’adiacenza IS-IS utilizzano gli hello-packet, gli stati
sono:

NEW Questo è lo stato quando il proce sta cominciando (riavvio router o nuova
configurazione)

One-Way Un router si trova in questo stato quando ha inviato un hello packet (senza ancora
averne ricevuto uno)

Initializing quando un router riceve un hello packet, Questo stato indica che è la
comunicazione bidirezionale è stabilita
UP Indica che è stata stabilita la piena funzionelità IS-IS

Down indica che non c’è adiacenza. Le cause possono essere area mismatches, expiration
holdtime, authentication failures.

Reject Quando c’è un errore di autenticazione, lo stato passa da questo stato a DOWN

Dopo che due router possono scambiarsi informazioni, ogni router invia la Complete
Sequence Number (CNSP) che è simile all’indice di un libro solo che contiene tutte le
informazioni del link-state database, se ad un router manca qualche route allora invia
Partial Sequence Number PDU (PSNP) che è una richiesta delle route mancanti, l’altro
router risponde con una con un Link-State PDU (LSP) contenete le informazioni richieste,
dopo aver ricevuto le informazioni il router risponde con un PSNP (su point-to-point) o con
un CSNP (su un broadcast link).

Ogni PDU condivide lo stesso header sotto

IS-IS LAN Hello PDU, esistono 3 tipi di Hello PDU, uno per i link point-to-point e due per i
link broadcast (uno per il Level1 ed uno per il Level2), questo perchè in L1 deve limitarsi
nella propria area, L2 non ha limitazioni.

Un Broadcast hello PDU di L1 è inviato all’indirizzo [Link] (tutti i router di L1)

mentre di L2 è inviato all’indirizzo [Link] (tutti i router L2) questi indirizzi sono
utilizzati anche per gli tipi di PDU

A seguire l’header del broadcast Hello PDU

A seguire l’header del P2P Hello PDU

Complete Sequence Number PDU

The Complete Sequence Number PDU (CSNP) contiene la lista completa delle route
contenute nel link-state database (contiene solo la lista non le informazioni come ad
esempio l’indice di un libro). Dai CSNP possiamo identificare lifetime, sequence number e
checksum di tutte le informazione del link-state database del router.

Esisto CSNP di Livello 1 e di livello 2 , un CSNP di L1 è inviato all’indirizzo

[Link] (tutti i router di L1) mentre di L2 è inviato all’indirizzo
[Link]

Un router IS-IS utilizza Partial Sequence Number PDU (PSNP) per richiedere informazioni
LSP al vicino. Nei Linl p2p un PSNP è utilizzato per richiedere informazioni e come ack, nei
link broadcast viene utilizzato come ack

Ad un PSNP il router risponde con un Link-state PDU (LSP) che contiene informazioni sui
router della rete, le loro interfacce. Contiene anche la metrica ed informazioni sui vicini.

Ogni PDU contiene dei TLV, esistono diversi TLV ma per l’esame bisogna ricordare solo
TLV 1—Area Addresses

TLV 2—IS Reachability

TLV 6—IS Neighbors

TLV 8—Padding

TLV 9—LSP Entry

TLV 10—Authentication

TLV 128—IP Internal Reachability

TLV 129—Protocols Supported

TLV 130—IP External Reachability

TLV 132—IP Interface Address

TLV 137—Dynamic Hostname Mapping

Designated Intermediate System (DIS)

In un link broadcast il Designated Intermediate System aiuta a ridurre i dati nel link-state
database. In pratica il DIS rappresenta il nodo broadcast alla rete, e tutti i router del nodo
hanno adiacenza con lui. Per eleggere un DIS per prima cosa si guarda la priorità (da 0 a
127) viene eletto come DIS il router con priorità più alta. A parità di priorità viene visto il
mac-address, e viene eletto il router con mac più alto. Dopo aver eletto il DIS viene ridotto
l’hello timer, da 27 passa a 9 sec, con un hold-time a 3. Questo significa che vengono inviati
pdu ogni 3 secondi, questo per permettere ad un non DIS router di annunciare la perdita di
connessione con il DIS e riavviare la procedura di elezione del DIS.

A differenza dell’OSPF nel caso in cui venga aggiunto un router con priorità più alta o a
parità di priorità ma con un mac più alto allora quest’ultimo viene eletto DIS.

IS-IS utilizza tre metriche opzionali

delay cost che riflette il ritardo sul link

expense cost metric che riflette il costo di comunicazione sul link

error cost che riflette gli errori sul link

IS-IS valuta questi 3 costi per il QoS

Di default utilizza la wide-metric che di default è limitata a 63 a meno che non si utilizzi il
comando wide-metric-only in questo caso puoi settare la metrica fino a 2^24 (circa 16
milioni).
Configuration Command

Best practice vuole che l’indirizzo ISO viene assegnato alla loopback con il comando

[edit interfaces lo0 unit 0]

root@R1# set family iso address 49.0001.0100.0000.0001.00

[edit interfaces lo0]

root@R1# show

unit 0 {

family inet {

address [Link]/32;

family iso {

address 49.0001.0100.0000.0001.00;

Sulle altre interfacce che fanno parte dell’isis bisogna configurare il family ISO

[edit]

root@R1# set interfaces ge-0/0/0.0 family iso

root@R1# show interfaces ge-0/0/0

description "Link to R2";

mtu 9192;

unit 0 {

family inet {

address [Link]/31;

family iso;

}
[Link]@MX204-MIX> show interfaces terse

Interface Admin Link Proto Local Remote

et-0/0/0.900 up down inet [Link]/31

iso

inet6 [Link]/64

fe80::a05:e203:84fd:603f/64

mpls

multiservice

Adesso resta da configurare il protocollo su protocol isis, attivando il protocollo IS-IS di

default vengono abilitati i livelli L1 ed L2, se vogliamo possiamo disabilitare un livello, o per
tutte le interfacce

[edit protocols]

user@Riesling#

show

isis {

level 1 disable;

interface e3-0/2/0.101;

interface e3-0/2/3.100;

interface lo0.0;

o per la singola interfaccia

[edit protocols]

user@Cabernet#

show

isis {

interface fe-0/1/0.0 {

level 2 disable;
 }

interface e3-0/2/0.101;

interface lo0.0;

L’interfaccia di lo0.0 deve essere sempre inserita perchè annuncia il NET ID, l’interfaccia di
loopback anche se non specificato è sempre passiva.

Comandi per troubleshooting

user@Cabernet>

show isis adjacency

Interface System L State Hold (secs) SNPA

e3-0/2/0.101 Riesling 2 Up 23

fe-0/1/0.0 Shiraz 1 Up 7 [Link]

fe-0/1/0.0 Merlot 1 Up 24 [Link]

Interfaccia identifica l’interfaccia logica dove IS-IS ha formato l’adiacenza. Se manca bisogna
verificare se non è stata configurata sul protocollo IS-IS o non è stata inserita la family iso
sull’interfaccia

System indica il nome del router con cui è stata instaurata l’adiacenza. Se non viene risolto il
nome c’è il system ID.

L (Level) indica il livello

Stato indica lo stato dell’adiacenza, i possibili stati sono:

UP

DOWN

NEW

One-Way

Initializing

Rejected

Hold indica il tempo prima che la sessione venga cancellata (si rinnova ogni volta riceve
hello packet)
SNPA Il sub-netowrk Point of Attachment, è l’indirizzo data-link utilizzato per raggiungere il
vicino o il broadcast. Di solito il MAC del vicino è utilizzato come SNPA.

Aggiungendo detail vengono fornite informazioni aggiuntive,

user@Cabernet>

show isis adjacency detail

Riesling

Interface: e3-0/2/0.101, Level: 2, State: Up, Expires in 25 secs

Priority: 0, Up/Down transitions: 1, Last transition: [Link] ago

Circuit type: 3, Speaks: IP, IPv6

Restart capable: No

IP addresses: [Link]

Tra le informazioni vediamo la priorità per l’elezione del DIS (in questo caso 0 che indica
che non verrà mai utilizzato per l’elezione del DIS)

Con il comando clear isis adjacency si cancellano tutte le adiacenze, se ne vogliamo

cancellare solo una utilizziamo il comando clear isis adjacency nome-neighbor

Con il comando show isis interface

user@Cabernet>

show isis interface

IS-IS interface database:

Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric

e3-0/2/0.101 3 0x1 Point to Point Point to Point 10/10

fe-0/1/0.0 1 0x2 Shiraz.02 Disabled 10/10

lo0.0 0 0x1 Passive Passive 0/0

Vediamo lo stato delle interfacce

Interfaccia identifica l’interfaccia logica dove IS-IS ha formato l’adiacenza. Se manca bisogna
verificare se non è stata configurata sul protocollo IS-IS o non è stata inserita la family iso
sull’interfaccia

L (Level) indica il livello

CirID Ad ogni interfaccia IS-IS viene assegnato un circuit ID. Alla Loopback ed alle interfacce
p2p viene assegnato il valore 0x01. Ad ogni link broadcast viene assegnato il valore 0x02 e
viene incrementato di 1 ogni nuova interfaccia.

Lever 1 DR /Level 2 DR Nella loopback viene indicato passive, nelle p2p viene indicato Point
to point, mentre nelle broadcast viene indicato il nome del router che è stato eletto come
DIS

L1/L2 Metric viene indicata la metrica. Il massimo valore è 63. Ogni Router IS-IS può
calcolare un path cost di 1023

Con il comando show isis host name viene mostrata la risoluzione del system ID. Questo
comando è utile quando si pensa che 2 router hanno lo stesso router ID.

user@Cabernet>

show isis host name

IS-IS host name database:

System ID Hostname Type

1921.6800.0001 Riesling Dynamic

1921.6800.5001 Merlot Dynamic

1921.6800.8001 Shiraz Dynamic

1921.6801.6001 Cabernet Static

Con il comando show isis spf log mostra la storia dei calcoli SPF (algoritmo di Dijkstra).
Costanti calcoli SPF potrebbero indicare un flap nella rete

user@Cabernet>

show isis spf log

IS-IS level 1 SPF log:

Start time Elapsed (secs) Count Reason

Thu May 2 [Link] 0.000205 1 Periodic SPF

Thu May 2 [Link] 0.000225 1 Updated LSP Shiraz.00-00

Thu May 2 [Link] 0.000171 1 Updated LSP Shiraz.02-00

Thu May 2 [Link] 0.000177 3 Updated LSP Shiraz.02-00

IS-IS level 2 SPF log:

Start time Elapsed (secs) Count Reason

Thu May 2 [Link] 0.000166 1 Periodic SPF

Thu May 2 [Link] 0.000125 1 Updated LSP Cabernet.00-00

Thu May 2 [Link] 0.000134 1 Updated LSP Merlot.00-00

Thu May 2 [Link] 0.000127 1 Updated LSP Cabernet.00-00

Il comando show isis statics è utile per vedere quanti pacchetti sono stati trasmessi, ricevuti
ed elaborati dal router

user@Cabernet>

show isis statistics

IS-IS statistics for Cabernet:

PDU type Received Processed Drops Sent Rexmit

LSP 301 301 0 101 0

IIH 1676 96 1580 25 0

CSNP 6695 6446 0 5989 0

PSNP 57 57 0 94 0

Unknown 0 0 0 0 0

Totals 8729 6900 1580 6209 0

Total packets received: 8729 Sent: 6184

SNP queue length: 0 Drops: 0

LSP queue length: 0 Drops: 0

SPF runs: 165

Fragments rebuilt: 103

LSP regenerations: 75

Purges initiated: 5

Il comando show isis route mostra il risultato del calcolo SPF prima che le route vengono
messe nella routing table. Le stesse informazioni si possono vedere con il comando show
route protocol isis, ma questo comando è più comodo per il troubleshooting perchè mostra
ad esempio l’host name e non il next-hop
il comando show isis database con la possibilità di aggiungere detail e extensive mostra il
link-state database

A differenza dell’ospf due router potrebbero avere adiacenza IS-IS anche se non c’è una net,
in quanto IS-IS trasporta le informazioni attraverso le TLV e non attraverso IP come OSPF.

Se manca l’adiacenza bisogna effettuare questi controlli

BGP

BGP è un protocollo path-vector, ogni router conosce le network, il percorso (path) e la

direzione dove inviare il pacchetto (vector).

Per garantire un trasporto affidabile (non del traffico dati, ma del protocollo stesso) bgp
utilizza il TCP su porta 179.

Quando due peers stabiliscono una sessione TCP, i peers possono far affidamento al TCP per
i seguenti servizi:

ACKNOWLEDGMENTS Dopo aver trasmesso un segmento, un timer comincia il countdown

che si blocca solo se riceve l’ack. Se il timer arriva a 0 allora il segmento viene rinviato.

SEGMENTATION Se necessario il dato BGP viene segmentato in pezzi più piccoli

CHECKSUMS Il checksum è mantenuto sia sul TCP header che sul BGP data

DATA SEQUENCING Ad ogni segmento TCP viene assegnato un numero in modo che il
destinatario possa ordinare i segmenti anche se non li riceve in modo ordinato

FLOW CONTROL ogni peer BGP avvisa l’altro indicando il proprio buffer.

Quando due peers instaurano la sessione bgp, scambiano tutte le route (in base alle policy di
export applicate), dopo questa fase lo scambio di informazioni avviene solo se nuove route
devono essere inviate o alcune non sono più valide.

Se la sessione bgp viene stabilita da due peers (o neighbor) di AS differenti viene detta
external BGP (EBGP) di solito viene instaurata su una ptp ed è buona norma settare il TTL
ad 1.

Se invece i due peers sono dello stesso AS viene detta internal BGP (IBGP) in questo caso il
TTL è settato a 64, ed è buona norma utilizzare come indirizzo le loopback. Per garantire la
raggiungibilità delle route una best practice è utilizzare sessioni full mesh (o i route
reflector).

Due peers BGp possono essere nello stato:

IDLE è lo stato iniziale, in questo stato vengono rigettate tutte le richieste in ingresso. Dopo
che il processo BGP inizia, inizia una sessione BGP con il remote peer. Il router locale passa
allo stato Connect e resta in ascolto in attesa di una connection dal remote router.
CONNECT in questo stato, il local router è in attesa che venga completata la sessione TCP. Se
la connessione TCP va a buon fine invia un messaggio Open message al peer e passa allo
stato di OpenSent.

Se la sessione TCP fallisce, il local router resetta il timer connectRetry e passa allo stato
Connect. Se il timer connectretry raggiunge lo zero mentre il router è allo stato connect, il
timer viene resettato ed un nuovo tentativo di connessione viene effettuato. Il router resta
sullo stato connect.

ACTIVE in questo stato il router sta provando ad iniziare una connessione TCP con il peer.
Se viene stabilita allora invia un Open message e passo allo stato OpenSent.

Se la connessione fallisce, il local router inizia una nuova sessione, setta il timer
connectRetry a zero e passa allo stato Connect. Tentativi di connessione da parte di remote
peer inaspettati vengono rifiutati.

OPENSENT questo stato è raggiunto dopo che la sessione TCP è stabilita. Il router locale
invia un BGP open message ed aspetta quello del router remoto. Quando un Open message
valido è ricevuto, il router invia un keepalive al messaggio,. Il Peer negozia i parametri della
sessione e passa allo stao di openconfirme.

Se un TCP disconnect è ricevuto il router allora resetta il timer ConnectRetry e passa allo
stato di active state.

Openconfirm Quando il router riceve un valido open message passa allo stato di
openconfirm, il router locale invia un keepalice ed aspetta il keepalive dal peer.

Established questo stato è raggiunto quando il keepalive è ricevuto. Solo in questo stato i
router cominciano a scambiarsi le informazioni di routing.

In totale il BGP scambiano 4 tipi di messaggi:

Open

Update

Notification

Keepalive

L’open message è il primo pacchetto BGp inviato dopo che la connessione TCP è avvenuta.
Permette ai due peers di negoziare i parametri della sessione. Questi parametri includono
BGP version, hold time, authentication data, refresh, e supporto per le Network Layer
Reachability Information (NLRI)

L’update Message serve ad inviare e ritirare le routing information. Se necessario, ogni

messaggio contiene le vecchie informazioni che non sono più valide. Ogni update contiene
un singolo set di attributi bgp e tutte le route che utilizzano questi attributi.
Quando un peer BGP scopre un errore, invia un Notification message al remote router ed
immediatamente chiude BGP e TCP session.

Gli error code sono:

1 per un messaggio Header error

2 per un Open Message Error

3 per un Update messase error

4 per un Hold Time expired

5 per un Finite State Machine Error

6 per cessare

Il Keepalive message contiene solo l’header senza alcun dato.

Ogni router BGP stabilisce delle locazioni di memoria nel quale memorizzare le conoscenze
di routing. Queste locazioni di memoria vengono dette Routing Information Base (RIB). Un
peer BGP mantiene 3 categorie di RIB:

Adjacency-RIB-IN

Local-RIB

Adjacency-RIB-OUT

Una Adjacency-RIB-IN table è creata sul router locale per ogni BGP peer attivo. Tutte le
route (ad eccezioni di quelle che contengono AS Path loop) vengono inserite nella tabella
appropriata.

Dopo aver ricevuto un Update message, il local router applica la policy di import, che può
modificare gli attributi o scartare la rotta. Dopo il router locale esamina tutte le route nelle
Adjacency-RIB-IN per scegliere l’unica destinazione.

Questo best path scelto, viene memorizzato sulla Local-RIB table. Queste sono le route che
vengono utilizzare per il forwarding del traffico.

Per ogni peer attivo viene creata una Adjacenzy-RIB-OUT che contiene le route da
annunciare. Di default vengono copiate tutte le route della Local-RIB ma possono essere
modificate con delle policy.

Vediamo come un router juniper sceglie la rotta da inserire nella local RIB. Se fra tutte le
tabelle Adjacency-RIB-in esiste una sola rotta allora viene inserita nella tabella, altrimenti
vengono eseguiti i seguenti step finchè non si ottiene una sola destinazione (finchè non si
ottiene viene eseguito lo step successivo)
Il next-hop deve essere raggiungibile nella local routing table, altrimenti la rotta viene
scartata

Viene scelta la rotta che ha una local preference più alta

Viene scelta la rotta che ha il più corto AS-PATH

Viene scelta la rotta con l’il più piccolo ORIGIN

Viene scelta la rotta con il Multiple Exit Discriminator (MED) più basso. Questa step è
eseguito di default, solo per le route che vengono dallo stesso neighboor AS

Il router sceglie le route apprese da eBGP peer rispetto peer iBGP peer. Se restano solo
route apprese in eBgp allora si passa al punto 9.

Il router sceglie la rotta che ha il next-hop con la metrica IGP minore *

Se sono utilizzati Route Reflector, viene scelta la rotta con la più corta Cluster-List

Il router sceglie la rotta che viene dal peer che ha il più piccolo Router ID

Il router sceglie la rotta che viene dal peer che ha l’ip più piccolo

* Per ogni iBGP peers verifica le tabelle inet.0 ed inet.3 (per utilizzare gli LSP), in caso di
pareggio si preferisce utilizzare un next-hop dalla tabella inet.3.

Gli attributi BGP si suddividono in 4 categorie:

Well-done mandatory

well-done discretionary

optional transitive

optional nontransitive

I router BGP devono riconoscere tutti well-know attribute, che devono essere inclusi in
tutte le route. Discretionary possono essere inseriti o no in una determinata rotta. I router
BGP non devono capire gli attributi opzionali ma devono rinunciare se sono transitive, gli
optional nontransitive vengono scartati se non riconosciuti.

L’attributo next-hop è di tipo well-done mandatory. Una volta arrivata l’informazione, il

router locale fa un lookup del next-hop per capire la rotta verso il next-hop contenuto nella
rotta. Il risultato di questo lookup è assegnato alla rotta BGP ed inserito nella routing table e
forwarding table.

La raggiungibilità del next-hop è critica , se il next-hop non è raggiungibile allora la rotta

non sarà utilizzata. Dobbiamo far molta attenzione poichè di default è possibile cambiare
questo campo solo se la rotta è annunciata attraverso una eBGP session.
Esempio

Shiraz e Cabernet hanno una sessione eBGP attraverso gli ip [Link] e [Link] dove
shiraz annuncia le net [Link]/16 e [Link]/16, Carbenet una volta ricevuti gli
annunci per le 2 net cambia il next-hop mettendo ad esempio [Link], Cabernet ha il
next-hop raggiungibile, quindi le route sono attive.

Quando Cabernet annuncia le route a Merlot, ad esempio, utilizzando una sessione iBGP non
cambia il next-hop, ma Merlot non ha una rotta valida verso il [Link], quindi le due net
[Link] e [Link] non sono utilizzabili da Merlot. Per ovviare a questo problema di
può:

Settare il campo Next hop attribute, considerato da molti la best practice per una sessione
iBGP, questo metodo permette al router che annuncia di cambiare il valore del Next Hop
Attribute.

Utilizzare un interfaccia passiva IGP, in questo caso l’interfaccia di collegamento con il

router esterno (es. interfaccia verso shizar) è configurata passive nel protocollo IGP, in
questo modo il next-hop è raggiungibile in IGP.

L’attributo local preference è un valore numerico che può essere settato attraverso una
routing-policy o una configurazione BGP, se entrambe sono configurate prevale la routing
policy. Questo valore viene utilizzato solo nelle sessioni iBGP e non viene inviato nelle
sessioni eBGP. Più alto è alto è il valore maggiore priorità avrà la rotta nell’essere scelta.

L’attributo AS-PATH (attributo mandatorio) descrive il percorso della rotta che va

dall’origine al mio AS. Quando un router riceve un update la prima cosa che verifica è che ci
sia il proprio AS nel percorso, se il proprio AS è presente scarta l’annuncio perchè significa
che c’è un loop. Di default questo valore cambia quando un annuncio passa da un AS ad un
altro. Inizialmente quando la rotta viene originata l’as-path è vuoto, almeno finche cammina
all’interno dell’as originator. Attraverso delle policy l’as-path può essere modificato
aggiungendo dei prepend in modo da rendere questa rotta meno preferibile.

L’attributo ORIGIN (Attributo mandatorio) indica da dove è stata appresa la rotta può avere
3 valori

Se appresa localmente, attraverso un IGP il valore sarà 0 e nell’AS-PATH sarà indicato con I
(i maiscuolo)

Se appresa attraverso eGP avrà il valore 1 e sull’as-path sarà indicata con E

Se non si conosce avrà valore 2 e sull’as-path sarà indicato con ?

Multiple Exit Discriminator (MED), è un attributo optionl nontransitive, viene utilizzato

quando un AS ha una doppia sessione con un altro AS, allora invia il MED per indicare dove
ricevere il traffico. Valore più basso è preferito, di default se non viene inviato viene posto a
zero.
Per modificare il MED si utilizza il comando metric-out a livello di protocol BGP, group BGP
o neighbor BGP, o con delle policy.

L’attributo community è un attributo di tipo optional transitive, le community servono a

taggare delle route, ed utilizzare questi tag per ulteriori utilizzi (esempio identificare le
route clienti). Per applicare una community si utilizzano le policy

I comandi utiliizati sono

Propagazione delle route,

Di default un router non annuncerà mai ad un altro peer iBGP route apprese in iBGP, ma
annuncerà tutte le route apprese in eBGP. Per avere una tabella congrua è necessario che
tutti i router abbiamo una sessione iBGP full-mesh.

Un router annuncerà tutte le route apprese in eBGP ed iBGP al peer eBGP.

Esempio di configurazione

Configuriamo la policy next-hop self

Fai attenzione che nella policy next-hop di non combinare il comando next-hop con accept

Definiamo l’aggregato

Le policy di IMPORT/EXPORT possono essere applicate a livello di protocollo bgp, gruppo o

neighbor, facendo attenzione che la più specifica è applicata

Una rotta annunciata da un peer va in RIB-IN queste route vengono filtrate dalle policy e
vanno in route-table, le route in route-table vengono filtrate dalle policy e messe in RIB-out
che contiene tutte le route annunciate al peer. Come si nota solo le route attive vengono
annunciate, supponiamo ci sia una rotta BGP inattiva, perchè la stessa viene acquisita in
osfp e quindi con una metrica inferiore, allora la rotta non verrebbe annunciata, per
annunciare la rotta allora possiamo utilizzare il comando advertise-inactive

Con il comando show bgp summary

Notiamo il numero di gruppi, i peers configurati e quelli down. Inoltre per ogni peer
vediamo l’indirizzo, l’as il numero packet (in ed out) , il numero di pacchetti in coda (outQ)
che di solito è a zero, i flap l’ultimo cambio di stato (da quanto tempo è avvenuto), e se
attivo il numero di route attive / ricevute / accettate / dampened

un altro comando utile è show bgp neighbor

Un altro comando utile è show bgp group

Vediamo così il nome del gruppo, se è internal o external, il numero di peer e gli indirizzi, le
policy di export applicate, ed anche le option (che nell’esempio sopra non ci sono), tra le
option si può trovare se la sessione è multihop se c’è il remote-private, anche l’holdtime che
di default è 90

Esempio

Group Type: External Local AS: 41327

Name: eBGP-to-peering Index: 34 Flags: <>

Export: [ EXPORT-BLACKHOLE-COGENT REJECT-ALL ]

Options: <Multihop RemovePrivateAS>

Holdtime: 0 Outbound Timer: 10

Total peers: 1 Established: 1

[Link]+179

inet.0: 0/0/0/0

con il comando show route protocol bgp vediamo le route attive apprese in bgp, se una rotta
manca potrebbe esserci un problema di raggiungibilità del next-hop, o potrebbe essere
droppata da una policy.

Con il comando show route recieve-protocol bgp indirizzo-peer

vediamo tutte le route che il peer ci invia senza che le policy che il cliente ci annuncia, che
non vengono droppate dalle policy di import, per vedere quelle droppate dobbiamo
utilizzare il comando show route recieved-protocol bgp indirizzo-peer hidden

Per vedere invece le route annunciate si utilizza show route advertising-protocol bgp
indirizzo-peer

Un IP tunnel è un canale di comunicazione tra due reti, può utilizzare protocolli che
utilizzano crittografia (tipo IP-SEC) o no come GRE o IP over IP (IP-IP). Quando un paccheto
entra nel tunnel il tunnel incapsula l’intero pacchetto compreso di header e lo consegna
decapsulato al destinatario del tunnel

Il Generic Routing Encapsulation (GRE) tunnel protocol incapsula una varietà di Network
Layer Protocol all’interno di un tunnel ip. L’overhead del tunnel è 24byte.

L’overhead contiene il source address, l’entry point di ingresso, il destination e l’exit point
del tunnel. Il pacchetto GRE è incapsulato in un pacchetto IP con protocol type 47. Il
pacchetto incapsulato all’interno del GRE non viene modificato a meno del campo fiel che
viene decrementato.
Un IP over IP (IP-IP) incapsula un pacchetto ip all’interno di un altro pacchetto IP,
aggiungendo 20 byte di overhead. Anche in questo caso l’unico campo del pacchetto
incapsulato che viene modificato è il TTL che viene decrementato ma resta invariato fino
alla consegna.

Per definire un’interfaccia gre si utilizza gr-x/y/z dove x/y/z identificano su quale pic viene
creato il gre, alcuni apparati lo fanno a livello software il quel caso sarà gr-0/0/0. Stessa
cosa per il tunnnel ip-ip l'interfaccia avrà forma ip-x/y/z.

Per ogni interfaccia si possono creare diverse unit, e si può creare un solo tunnel per unit.

SIa il GRE che l’IP-IP sono stateless significa che sono sempre up, quindi non si è certi che il
remote sia raggiungibile o no, per evitare problemi si utilizzano dei meccanismi di
keepalive, come ad esempio l’oam

Oppure si può utilizzare il BFD.

Vediamo un problema legato all’mtu

Se l’user A trasmette un pacchetto più grande di 1476 all’interno del tunnel settando il bit
don’t fragment il pacchetto all’interno del tunnel viene frammentato perchè l’mtu sul link è
1500, quindi quando il destinatio riceve il pacchetto frammentato con bit DF settato scarta il
pacchetto ed invia un ICMP per far ridurre la dimensione del pacchetto inviato. Per evitare
questo problema o si aumentato MTU ad almeno 1524 oppure si utilizza il comando

clear-dont-fragment-bit

Vediamo una semplice configurazione di tunnel GRE (stessa configurazione può essere
applicata all’ip-ip”

Possiamo aggiungere altri opzioni

copy-tos-to-outer-ip-header: Questo comando abilita il tunnel GRE a copiare il Type Of

Service (TOS) dal pacchetto originale.

allow-fragmentation: Di default l’incapsulamento GRE droppa i pacchetti che superano

l’MTU settato, con questo comando invece abilitiamo la frammentazione all’interno del
tunnel.

reassemble-packets: Abilita a riassemblare i pacchetti frammentati

key:Si può assegnare una key (valore che va da 0 a 4,294,967,295) per identificare un
tunnel, NB: questo valore deve essere identico ad entrambi i capi del tunnel.

clear-dont-fragment-bit: Serve ad abilitare la frammentazione all’interno del tunnel

Per evitare problemi di frammentazione si può far in modo che il router calcoli l’mtu del
path, utilizzando il path mtu discovery, con il comando
Un comando utile per il troubleshooting è

show interface gre-0/0/0.0 detail | find “traffic statistic”

HIGH AVAILABILITY

Graceful restart (GR): Questa funzione consente l'inoltro ininterrotto dei pacchetti e la
soppressione temporanea di tutti gli aggiornamenti del protocollo di routing. GR consente a
un router di passare attraverso stati di convergenza intermedi nascosti al resto della rete.

Graceful Routing Engine switchover (GRES):Questa funzione consente a una piattaforma di

routing con RE ridondanti di continuare a inoltrare i pacchetti anche se una RE si guasta. Il
Graceful RE switchover preserva le informazioni sull'interfaccia e sul kernel e garantisce
che il traffico non venga interrotto. Il il GRES, tuttavia, non preserva il piano di controllo.

Nonstop active routing (NSR): Questa funzione utilizza la stessa infrastruttura del passaggio
regolare di RE per preservare le informazioni sull'interfaccia e sul kernel. Tuttavia, NSR
salva anche le informazioni sul protocollo di instradamento eseguendo il processo di
protocollo di instradamento (rpd) sulla RE di backup. Salvando queste informazioni
aggiuntive, NSR è autonomo e non fa affidamento su router ausiliari per assistere la
piattaforma di routing nel ripristino delle informazioni del protocollo di routing. NSR è
vantaggioso nelle reti in cui i router vicini non supportano GR. Come risultato di questa
funzionelità migliorata, NSR è un sostituto naturale di GR. NSR e GR si escludono a vicenda e
non possono essere abilitati contemporaneamente. Si noti che il GRES deve essere
configurato affinchè NSR funzioni correttamente

Bidirectional Forwarding Detection (BFD): Questa funzione è un semplice meccanismo di

hello che rileva i guasti in una rete. BFD invia pacchetti hello a un intervallo regolare
specificato. Un errore neighbor viene rilevato quando il dispositivo di routing smette di
ricevere una risposta dopo un intervallo specificato. BFD funzione con un'ampia varietà di
ambienti di rete e topologie. I timer di rilevamento guasti per BFD hanno limiti di tempo più
brevi rispetto ai meccanismi di rilevamento guasti predefiniti, fornendo un rilevamento più
rapido.

Virtual Router Redundancy Protocol (VRRP): Questa funzione consente agli host su una LAN
di utilizzare piattaforme di routing ridondanti su quella LAN senza richiedere più della
configurazione statica di un singolo percorso predefinito sugli host. Le piattaforme di
routing VRRP condividono l'indirizzo IP corrispondente al percorso predefinito configurato
sugli host. In qualsiasi momento, una delle piattaforme di routing VRRP è il master (attivo) e
le altre sono i backup. Se il master si guasta, uno dei router di backup diventa il nuovo
router master, fornendo una piattaforma di routing predefinita virtuale e consentendo di
instradare il traffico sulla LAN senza fare affidamento su un'unica piattaforma di routing

Unified In-Service Software Upgrade (ISSU): Questa funzione consente di eseguire

l'aggiornamento tra due diverse versioni del sistema operativo Junos senza interruzioni sul
piano di controllo e con interruzioni minime del traffico. Unified ISSU è supportato solo su
piattaforme Dual Routing Engine. Inoltre, devono essere abilitati il passaggio grazioso del
motore di instradamento (GRES) e l'instradamento attivo non-stop (NSR).

GRACEFUL RESTART

Supponiamo R1 deve riavviare un protocollo di routing (OSPF) allora R1 avverte i vicini, con
GR i vicini non perdono le adiacenze OSPF e continuano ad inoltrare i pacchetti.

Esistono due modalità di GR:

Restarting router mode

helper router mode (default)

Per disabilitare il GR possiamo farlo sotto routing-option per disabilitarlo a tutti i protocolli
oppure sotto il protocollo (nell’esempio fatto su BGP)

Per attivare il GR modalità Restaring lo possiamo abilitare sotto routing-option e

disabilitare per un determinato protocollo o vicino con il comando visto sopra

Per vedere se il GR attivo possiamo utilizzare il comando show bgp neighobr address se lo
vogliamo su un vicino bgp. In questo caso vedremo

Per OSPF e IS-IS dobbiamo abilitare il traceoption

BFD

BFD è supportato

Si configura sotto il protocollo o sotto la statica.

Esempio di configurazione

Non è consigliabile settare il minimum-intervall sotto i 300 ms, con questa configurazione si
suppome che il multiple value è tre (che è il default).

Cioè il link è down dopo 300 x 3 ms

BDF è molto utile nei link L3, per gli L2 si utilizza OAM

un comando per avere le informazioni sulle sessioni bfd è show bfd session , per le sessioni
BGP possiamo vederlo facendo show bgp neighboor peer-address vediamo se lo stato è up.

PS: Se lo stato BFD è down ma sul link c’è comunicazione bisogna verificare il firewall

Nel caso di apparati con doppia routing-engine per vedere lo stato si utilizza il comando
show chassis routing-engine

Per far si che entrambe le RE siano accessibili si può utilizzare questa configurazione
Viene configurato il backup-router perchè la RE di backup non ha RPD attivo quindi sfrutta
la backup-ruoter per essere raggiungibile. Quando il GRES è attivo è utile utilizzare il
commit synchronize oppure settarlo sotto system service.

Quando la RE di backup non riceve il keepalive dalla master allora capisce che la master ha
un problema e quindi diventa lei la primaria. La PFE non si riavvia ma si sgancia dalla
vecchia master e si collega alla nuova, dopo aver effettuato il collegamento la nuova RE
master confronta i dati della PFE e se obsoleti invia i messaggi di update, tutto questo
avviene senza che la PFE si blocchi.

Se è attivo il GRES la master prima di inviare gli update alla PFE li invia alla RE backup, se
non attivo li invia solo alla PFE.

Se il GRES non è attivo puoi attivare il RE failover protection

se non specificato il keepalive-time il default è 300 secondi

Se vogliamo switchare da una RE all’altra possiamo utilizzare il comando

Per attivare il GRES si utilizza il comando

una volta attivato noteremo che nella RE master comparirà master, mentre nella backup
backup.

Per visualizzare se il GRES è attivo ed il database sincronizzato si può utilizzare il comando

Questo comando si può digitare solo dalla backup

Il NONSTOP ACTIVE ROUTING (NSR) permette alla macchina con doppia RE di switchare da
una RE all’altra senza allerta i nodi vicini. In pratica entrambe le RE fanno girare il demone
RPD. NSR è il sostituto di GR e quindi entrambi non possono essere configurati nella stessa
macchina .

Per attivare il NSR bisogna attivare anche il GRES

ed inoltre bisogna attivare o utilizzare il commit synchronize.

Con il comando show task replication verifichiamo la sincronizzazione NSR.

un altro modo è attivare il flag nsr-synchronization detail sotto traceoption

NB: Per L’NSR entrambe le RE devono avere la stessa versione.

L’Unified in-service software upgrade (ISSU) permette di aggiornare senza dare alcun
disservizio.

Per l’issu bisogna che

Attivare il GRES e l’NSR verificando che entrambe le RE siano sincronizzate

Verificare che entrambe le RE abbiano la stessa versione

Effettuare il download del file

digitare il comando request system software in-service-upgrade sulla prima RE.

Con il comando show chassis in-service-upgrade verifichiamo lo stato delle FPC

Per verificare se l’issu è andato a buonfine

si utilizza il comando request system software abort in-service-upgrade

Virtual Router Redundancy Protocol (VRRP)

Questo protocollo serve a dare ridondanza al gateway di solito i 2 router VRRP sono
collegati alla rete con un semplice switch

I VRRP router comunicano tra loro attraverso pacchetti IP utilizzando l’indirizzo multicast
[Link]

Questi pacchetti hanno TTL 255 e il default interval dei VRRP advertisements è 1secondo, è
importante che i VRRP dello stesso gruppo abbiamo parametri uguali come ad esempio
stesso VRIS o parametri di autenticazione. Il virtual IP è associato ad un virtual mac address
che ha il formato 00-00-5E-00-01-VRID.

Per la scelta del master o backup si utilizza la priorità (maggiore priorità maggiore
preferenza) di default è 100.

Nel caso di fault del master il backup diventa master, se il vecchio master torna up diventa
master solo se c’è configurato l’opzione preempts.

L’elezione del master avviene per fasi:

Il master periodicamente invia periodicamente annunci a tutti i router del VRRP.

Una semplice configurazione

a questo possiamo aggiungere 2 opzioni

Un comando utile quando dobbiamo configurare diversi VRRP sul router è l’opzione vrrp-
inherit-from

Che eredità i parametri da un’altra configurazione

IPv6

In tabella alcune differenze tra IPv4 e IPv6

Alcuni benefit dell’IPv6 sono

L’header IPv6 è fisso a 40 byte

Contiene:

Version con valore 6

Traffic class 8 bit che determina il traffic priority

Flow Laber campo

 utilizzato per il QoS

Payload length indica la dimensione del payload in ottetti

next header indica il protocollo incapsulato

hop limit che è il corrispettivo TTL in IPv4

Source address

destination address

Differenze header IPv4 e IPv6

Una differenza tra IPv4 e IPv6 è che se IPv6 deve frammentare il pacchetto IPv4 utilizza gli
extension header, gli extension header sono 6

Gli IPv6 possono essere del tipo

UNICAST: identifica un solo nodo IPv6

MULTICAST: identifica un gruppo di dispositivi, il pacchetto viene consegnato a tutti

UNICAST: identifica un gruppo di dispositivi, ma il pacchetto viene consegnato ad uno solo

dispostivo del gruppo di solito il più vicino.

Un indirizzo IPv6 è formato da 8 gruppi di 16-bit esadecimali, possono essere scritti in

forma estesa o abbreviata

Come in IPv4 alcune net sono riservate

La default si può scrivere come [Link] oppure ::

Il link local address (indirizzo non ruotabile) identifica un link è formato da i primi 10 bit
1111111010 seguito da 54 0 quindi il prefisso utilizzabile è FE80::/64, gli ultimi 64 bit sono
l’interface identifier. Siccome tutti i link local address cominciano con FE80::/64 non è detto
che siano unici nella rete, quindi sono indirizzi non routabili.

ESEMPIO DI LINK LOCAL ADDRESS FE80::226:88FF:FE02:7481

Questo indirizzo viene creato in automatico quando attiviamo la family Inet6, perchè questo
indirizzo è necessario per il discovery, l’autoconfigurazione ed il routing protocol traffic.
Un indirizzo global unicast address è formato da

Format Prefix (FP):formato da 3 bit, il prefisso 001 identifica l’aggregato global unicast
address, questo è l’unico intervallo assegnato da iana.

Global Routing Prefix: i successivi 45 bits sono utilizzati per applicare il più alto di
aggregazione, tipicamente identifica un TIER1.

SID: i successivi 16 identificano un link

INTERFACE ID: Gli ultimi 64 bit sono riservati per l’interface ID, consentendo una facile
autoconfigurazione dell’host nella reta

L'interface ID viene calcolato a partire dal mac del dispositivo, essendo il mac di 48 mentre
l’interface ID di 64 viene aggiunto tra il company ID ed il manufacturer Extension ID il
valore FFFE (1111111111111110). Inoltre bisogna invertire il 7 bit del Company id. Questo
processo è detto EUI-64

Vediamo un esempio di EUI-64

1. Prendi l'indirizzo MAC e converti il primo ottetto da esadecimale a binario.

Nota : l'indirizzo MAC [Link] verrà utilizzato per i seguenti esempi.

11 :22:33:44:55:66

11 -> 00010001

2. Invertire il settimo bit. (Il settimo bit sarà 0, renderlo un 1).

000100 0 1 -> 000100 1 1

3. Convertire l'ottetto in esadecimale da binario.

00010011 = 13

4. Sostituire il primo ottetto originale con quello appena convertito.

11 :22:33:44:55:66 -> 13 :22:33:44:55:66

5. Aggiungere [Link] al centro del nuovo indirizzo MAC.

[Link] [Link] [Link]

Uno dei miglioramenti di IPv6 è la possibilità di implementare lo stateless autoconfiguration

dell’indirizzo ip. In pratica diamo la possibilità ad un host di assegnare in maniera
automatica un ip, senza configurare DHCP o altro .

Lo stateless autoconfiguration è composto da diversi elementi:

Extended unique identifier (EUI): questo valore esadecimale a 64 bit viene utilizzato per
identificare un'interfaccia. Se non si specifica un valore EUI in modo esplicito, il dispositivo
di sicurezza lo genera automaticamente dall'indirizzo MAC dell'interfaccia IPv6.(vedi
esempio precendente).

Router advertisement (RA) message: un router IPv6 invia questo messaggio

periodicamente agli host sul link o in risposta a una richiesta RS di un altro host. Le
informazioni in un RA message possono includere prefissi IPv6 del router, messaggi MTU,
percorsi specifici al router, se eseguire l'autoconfigurazione IPv6 e un periodo di tempo per
il quale un indirizzo deve rimanere valido.

Router solicitation (RS) message: gli host inviano questo messaggio per scoprire la presenza
e le proprietà dei router sul link. Quando un router IPv6 riceve una richiesta RS da un host,
risponde trasmettendo un messaggio RA. Una RA annuncia l'esistenza del router e fornisce
all'host le informazioni necessarie per eseguire le attività di configurazione automatica.

Prefix list: questa tabella contiene i prefissi IPv6. Quando le voci sono presenti nell'elenco, il
router include le voci nelle RA che il router invia agli host on-link. Ogni volta che un host
riceve una RA, l'host può utilizzare i prefissi per eseguire l'autoconfigurazione dell'indirizzo.

Il processo di neghboor discovery serve a tracciare lo stato di un vicino nel link, il protocollo
utilizza ICMP e ARP per determinare se un vicino è raggiungibile o no.

Il router capisce che il vicino è raggiungibile se riceve un NS Request o traffico IP.

Il processo di autoconfigurazione dell’indirizzo funzione così

Quando attiviamo IPv6 i due host sul link creano il link local address a partire dal mac

Ogni Host invia un RS message, utilizzando il loro link local address

L’host risponde al RS message con un RA message, questo messaggio contiene una prefix-
list

L’host utilizza questa prefix-list per l’autoconfigurazione

Se l’amministratore non vuole utilizzare l’autoconfigurazione può assegnare l’ip

staticamente oppure utilizzare il DHCP che in IPv6 si chiama statefull DHCPv6

Con il comando show interface terse vediamo l’ip uncast e il link local address

Per vedere le route IPv6 si utilizza il comando

show router table inet6

La tabella inet6 contiene anche i link local

Inizialmente il comando show ipv6 neighbors è vuoto basta far passare del traffico ip,
(esempio un ping) ed i vicini vengono popolati.
Gli indirizzi multicast IPv6 cominciano con FF

Esistono tre tipi di multicast

NS Messages

RA Messages

RS Messages

Configurazione rotta statica IPv6

Con lo show route possiamo filtrare per la table ed il protocollo esempio

La configurazione del protocollo OSPFv3 (ospf per ipv6) è simile alla configurazione OSPF,
anche il router ID utilizza un indirizzo a 32bit (ipv4) che può essere configurato sotto
ruoting-options

anche i comandi di troubleshooting sono uguali cambia solo OSPF con OSPF3

Il protocollo IS-IS invece è del tutto uguale

Il protocollo BGP è identico all’IPv4 cambiano solo gli indirizzi IP del peer ed il local-address

4 approcci comuni per trasportare traffico IPv6 su IPv4 sono:

IPv4-compatibles IPv6 address

Configure tunnels

6to4

6over4

IPv6 su tunnel IPv4

SWITCHING E BRIDGING

Bridging utilizza la segmentazione per dividere un dominio di collisione in più piccoli bridge
collision domain.

Per far ciò utilizza i seguenti meccanismi:

Learning Inizialmente il bridge non ha informazioni, per apprendere informazioni sui mac
lo switch legge tutti i frame in ingresso, se il source max è conosciuto allora lo inserisce in
tabella

Forwarding è il processo che passa il frame da un’interfaccia in ingresso ad una in uscita,

per far ciò consulta la bridge table. Se nella Tabella l'interfaccia di ingresso e di uscita di un
frame combaciano allora lo switch non inoltra il frame
Flooding Questo processo è utile per inviare i frame con MAC sconosciuto, o i broadcast
([Link]). In pratica lo switch invia il frame a tutte le interfacce tranne a quella da
dove ha ricevuto il frame

Filtering è un meccanismo che limita il traffico associato ad una vlan o ad un network

segment

Aging Per ogni mac nella Bridge table viene salvato anche il timestamp di quando viene
appresso, se questo valore è maggiore del valore impostato con il comando global-mac-
table-aging-time allora il mac non è più valido

Per vedere la bridge table, si utilizza il comando show bridge mac-table, con il comando
clear bridge mac-table eliminiamo le entri nella bridge table.

Una VLAN è una collezione di host che condivido un dominio di broadcast, una switch port
può operare in modalità:

access è associata ad una singola vlan e riceve e trasmette traffico untagged

Trunk porta utilizza per collegare 2 switch, permettono il passaggio di diverse vlan, per far
passare il traffico untagged bisogna settare la native-vlan-id

Per associare il traffico ad una vlan bisogna taggarlo il più comune è l’802.1Q

Il tag vlan (4 byte) è formato da:

Tag Protocol Identifier (TPID) 16 bit default 0x8100

Priority 3 bits

Canocical Format Indicator (CFI) 1 bit default 0

Unique VLAN Identifier (VID) 12 bits

Su di un MX per configurare una porta access bisogna configurare la vlan su bridge-domains

e l'interfaccia (NB: per una porta access devi configurare la unit 0, non puoi configurare
altre unit)

Per una porta trunk invece

Se abbiamo diverse vlan da configurare, su bridge domain invece di configurare tutte le vlan
possiamo utilizzare il comando vlan-id-list, per poi applicare le vlan sull’interfaccia come
visto prima

Con il comando show bridge domains vediamo lo stato delle vlan possiamo aggiungere
detail (specificando il nome della vlan) per avere maggiori informazioni

Per monitorare una porta trunk possiamo utilizzare il comando show interface
o show bridge domain

Con il comando show bridge statistics vediamo le statistiche dei bridge ed anche il numero
di mac appresi.

Il Protocollo MVRP (Multiple VLAN Registration Protocol) serve a ridurre l’overhead e

semplificare la gestione delle VLAN.

L’MVRP invia PDUs tra tutti gli switch della rete, per scambiarsi le VLAN ID e su quale
interfacce attive.

L’MVRP utilizza dei timer:

Join: che è l’intervallo con cui vengono trasmesse le PDU

Leave: Controlla il periodo di tempo che un'interfaccia aspetta nello stato di Leave prima di
passare allo stato unregistered

LeavALL: Controlla la frequenza con il quale l’interfaccia genera LeaveALL message

Il protocollo MVRP è disabilitato per default ed è utilizzato sulle porte trunk.

MVRP utilizza i messaggi MRP per registrare e dichiare MVRP state ed informare gli switch
della rete.

i messaggi sono:

EMPTY: L’informazione VLAN non sono dichiarate e non sono registrate

IN: L’informazione VLAN non sono dichiarate ma sono registrate

JoinEmpity: Le informazioni sono dichiarate ma non registrate

JoinIN: Le informazioni sono dichiarate e registrate

Leave: Le informazioni sulle VLAN precedentemente registrate sono cancellate

LeaveAll: Tutte le registrazioni sono cancellate. I partecipanti che vogliono partecipare al

MVRP devono registrarsi nuovamente

NEW: L'informazione VLAN è nuova e possibilmente non registrata precedentemente

L’MVRP utilizza il pruning vlan per limitare il traffico BUM ai soli dispositivi interessati, non
supporta il VLAN Spanning Tree Protocol (VSTP).

Supponiamo che vogliamo che 2 switch abbiano le stesse vlan, la prima cosa da fare e
verificare che le vlan create siano associate a delle porte access, sulle porte trunk non
dobbiamo definire alcuna vlan,

sui vari router configuriamo il protocollo mvrp inserendo solo le interfacce trunk
Per disabilitare la creazione di vlan dinamiche utilizziamo il comando no-dynamic-vlan

i timer visti primi vengono configurati per interfaccia:

I valori di default sono:

join-timer 200ms

leave-timer 800ms

leaveall-timer 1000ms

Alcuni comandi utili per il monitoraggio sono:

Un IRB (Itegrated Routind and Bridging) è un’interfaccia che viene utilizzata come gateway
dagli host nel bridge domain.

Esempio di configurazione:

Di default junos OS esegue il MAC learning, i valori di default sono

Timeout interval per i MAC entries: 300s

MAC statistics (di default disabilitato)

Numero massimo di MAC address appresi: 393215

per vedere queste statistiche show bridge mac-table extensive

Per configurare il max table size

con l’opzione packet-action drop il router droppa i frames con mac sconosciuto quando ha
la MAC table piena.

Per vedere alcune infomazioni L2 possiamo utilizzare:

Si possono impostare dei firewall filter utilizzando:

Address field

protocol type

VLAN ID

802.1p bits

Il term from non è necessario, ed esiste un discard all implicito per tutti i frame che non
matchano.

Dopo aver creato la policy bisogna applicarla all’interfaccia, o al bridge domain.

NB non puoi applicare la regola di firewall all’interno del bridge, se sul bridge è stato
utilizzato vlan-id list.

Nel campo then possiamo utilizzare:

Count : Conta il numero di volte che la regola matcha, per vederlo possiamo utilizzare il
comando show firewall

Forwarding-class Cambia la classificazione Class of Service (COS)

LOSS-PRIORITY cambia il loss priority bit del pacchetto IP

next fa passare all’altro term

next-hop-group fa saltare ad un altro gruppo

policer applica un policy di rate-limiting

port-mirror abilita l’invio di una copia del frame su di un’interfaccia per effettuare delle
analisi

Sugli MX è possibile creare delle routing-instance, due tipi di routing-instance sono:

Virtual Router un singolo chassis è visto come più router, ogni router ha una propria tabella
di routing, protocolli di routing ecc, la default instance è detta default

Virtual Switch un singolo chassis è visto come più switch, ogni switch ha una propria MAC
table, dominio di vlan, spanning tree ecc. Le dafault instance è detta default switch

Quando creiamo una routing instance

Nell’esempio precedente di tipo virtual-router, viene creata una tabella associata alla
routing-instance.

la tabella ha il nome [Link] (nell’esempio inet.0 ma potrebbe essere

anche ine6.0 ecc)

Esempio di routing-instance di tipo switch

Dopo aver creato la la routing-instance dobbiamo creare le varie porte access

o le porte trunk

o la porta IRB

NB: NON COMMITTARE PRIMA DI AVER INSERITO LE VARIE INTERFACCE ALL’INTERNO

DELLA ROUTING INSTANCE, SI FORMEREBBE UN LOOP
Per inserire le interfacce nella routing instance bisogna, inserire le interfacce (access o
trung) all’interno della routing-instance, mentre le IRB all’interno dei bridge (nell esempio
chiamati vlan_100 e vlan_200)

Con il comando bridge domain vediamo tutti i vari bridge all’interno del default switch e
quelli nel virtual-sw-1 che è stato creato con la routing-instance

Per collegare 2 virtual router si possono utilizzare le logical tunnel o anche un loop tra 2
interfacce (una appartenente ad un virtual router ed l’altra interfaccia all’altro virtual
router), per collegare 2 virtual switch invece si può utilizzare solo un loop fisico.

NB: tra 2 virtual switch lo spanning tree non funzione perchè entrambi utilizzano lo stesso
mac come parte del bridge ID

Per attivare le interfacce tunnel (GRE, IP, LT) dobbiamo modificare lo chassis, come
nell’esempio sotto

Oltre alle routing instance, possiamo creare un logical system, che a differenza delle routing
instance ha delle policy a parte, anche la parte di login, non si possono creare più di 16
logical system.

Per configurare un logical system

Le proprietà dell’interfacce tipo il mac statico l’encapsulation MTU ecc vengono configurate
nel router principale

esempio

Configurare un bridge domain nel logical system

Anche in questo caso per collegare 2 logical system possiamo utilizzare un logical tunnel o
un loop fisico

Per loggarsi nel logical system utilizziamo

Possiamo anche creare degli utenti per accedere direttamente al logical system

Il logical system l’unico protocollo di HA che supporta è il Graceful restart

Per un provider il protocollo 802.1Q è limitante quindi è stato sviluppato il protocollo

802.1ad (QinQ)

In pratica viee aggiunto un STAG per aumentare il VLAN ID space, di solito il CTAG viene
utilizzato dai clienti, STAG dal provider

STAG e CTAG hanno lo stesso formato, da protocollo cambia solo il TPID 0x88a8 per STAG, e
0x8100 per CTAG, anche se junos per default utilizza 0x8100 anche per STAG

Le operazioni che si possono effettuare sulle vlan sono

Esempio di configurazione DUAL STACK

Per abilitare il dual tag, bisogna configurare la porta in flexible vlan-tagging.

Esistono due modi per configurare un bridge in Independent Vlan Learning (IVL), che il
metodo visto finora, e Shared VLAN Learning (SVL). Nel primo metodo il MAC learning
avviene per VLAN, quindi il traffico BUM è separato per VLAN. Nel secondo invece il MAC
learning e condiviso come il traffico BUM che viene trasmesso in ogni vlan.

l grafico mostra il primo esempio di SVL e un esempio di normalizzazione VLAN (translate).

Il modo migliore per descrivere come funzione questa soluzione è discutere cosa succede a
un frame del cliente mentre attraversa il PBN:

Un frame con C-VLAN ID 112 arriva su ge-1/0/0.112 destinato a un indirizzo MAC esistente
sul lato remoto della rete.

Poichè il dominio bridge è configurato per vlan-id none, il tag C-VLAN viene eliminato (POP)
prima della ricerca nella tabella MAC.

Se l'indirizzo MAC di destinazione è sconosciuto, il frame viene floodatosu tutte le interfacce

associate al dominio bridge, comprese le sottointerfacce di ge-1/0/0 (a causa di SVL). Se il
MAC di destinazione è noto, il frame viene inoltrato fuori dall'interfaccia ge-1/0/4.0 con una
C-VLAN di 111 (normalizzazione) e una S-VLAN di 200.

All'arrivo al PEB remoto, assumendo il bridge il dominio è configurato per vlan-id none, i
tag S-VLAN e C-VLAN vengono visualizzati prima della ricerca nella tabella MAC.

Se l'indirizzo MAC di destinazione è sconosciuto, il frame viene floodato su tutte le

interfacce associate a il dominio bridge, comprese le sottointerfacce delle interfacce rivolte
ai clienti (a causa di SVL). Se l'indirizzo MAC di destinazione è noto, il frame viene inoltrato
dalla sottointerfaccia appropriata utilizzando l'incapsulamento specificato nell'interfaccia.

Un valido sostituto al QinQ è la VPLS

SPANNING TREE

Lo spanning tree è un protocollo nato per fornire dei percorsi loop-free in reti L2 ridondate.

Esistono varie versioni:

Spanning Tree Protocol (STP): La prima versione (802.1d) Ha diversi problemi, i principali
sono lenta convergenza (intorno i 50s), il secondo problema è che ogni modifica akka
topologia comporta che il MAC address viene rimosso dalla bridge table, con un eccessivo
flooding come risultato. Il terzo problema è che STP crea un singolo tree per ogni VLAN,
questo significa che i link ridondati non vengono utilizzati
Rapid Spanning Tree Protocol (RSTP) risolve due dei problemi dell’STP, cioè converge
molto più rapidamente, e limita che il cambio di topologia comporti la rimozione del MAC
dalla bridge table, RSTP continua a non utilizzare i links ridondanti

Multiple Spanning Tree Protocol (MSTP) Migliora l’RSTP creando multipli TREE per
bilanciare il traffico.

Vlan Spanning Tree Protocol (VSTP) Migliora l’RSTP, creando un tree per VLAN (max 253)
per bilanciare il traffico

Terminologia

Bridge ID: Ogni Switch che partecipa all’STP ha un ID unico che è una combinazione tra il
system MAC address ed un priority value configurabile

Root Bridge: è lo switch che ha il minore Bridge ID

Root Port: è la porta di un non root-switch più vicina (in termini di costo) al root switch

Root Path cost: è il costo del percorso che va da se stesso al root bridge, ogni non root
switch riceve delle BPDUs che contengono il root path del vicino (switch che invia la BPDU),
per calcolare il Root Path cost, basta aggiungere al root path ricevuto il costo dell’interfaccia
su cui è stato ricevuto

Port Cost: Ogni interfaccia ha un costo, che può essere anche modificato (con un valore che
va da 1 a 200.000.000).

Gli switch che condividono un segmento di rete devono determinare quale switch offre il
path più breve verso il root bridge, questo switch diventa il designated switch e la porta di
questo switch rivolta verso il segmento di rete è detta designed port. Se due switch fornisco
il path più corto verso il root bridge, allora si utilizza il bridge ID per determinare quale
switch utilizzare (il più piccolo è preferito), se invece il percorso più breve è fornito da due
interfacce dello stesso switch, si utilizza il port ID (è un’identificato unico per interfacca in
ogni switch) per determinare il percorso (anche in questo caso il più piccolo è preferito).

Per scambiare le informazioni si utilizzano le BPDU.

Vediamo come funzione l’elezione del root bridge:

quando viene configurato lo switch 2, lo switch invia le BDPU indicando se stesso come root
bridge, gli altri switch che ricevono la BPDU confrontano il loro root bridge, se il loro root
bridge ha priorità minore (o a parità di priorità il mac più piccolo) continua ad annunciare il
proprio root bridge, altrimenti annuncerà il 2 come root bridge.

Una volta eletto il ROOT Bridge, tutte le porte assumono il ruolo di designated port e sono
nello stato forwarding, tutte le root port sono nello stato di forwarding (il root bridge non
ha root ports). Le designated ports sui designated bridges sono in forwarding state. Tutte e
altre porte sono nello stato blocking.
Appena uno switch con STP abilitato si avvia, ogni porta può attraversare una serie di 5
stati:

disabled: la porta è down o in disabled

blocking (blocco): la porta non inoltra traffico

listening (ascolto): la porta riceve le BPDU ma non apprende MAC o inoltra traffico

learning (apprendimento): L’interfaccia comincia ad apprendere i MAC

forwarding (trasmissione)

Gli stati di Listening e Learning sono due stati transizionale per portare un’interfaccia da
blocking a forwarding.

Quando ogni switch determina tutti gli stati delle porte allora lo STP è fully convergegd.

Il tempo di convergenza è dato da:

Tempo di convergenza= 2x Forwarding delay + Maximum age

Lo Rapid Spanning Tree (RSTP) introduce nuove feature per migliorare la convergenza,
RSTP identifica alcuni link come point to point (P2P), quando un p2p cade, il link alternativo
passa allo stato di forwarding senza attendere alcun timer. Inoltre introduce anche la
definizione di edge port: una porta che collega un un dispositivo che non sia un bridge, ed è
sempre in forwarding.

Spanning tree introduce nuove porte

Una Alternate port è una porta che fornisce un path alternativo verso il root bridge, ma ha
un costo maggiore rispetto la root port, riceve le BPDUs ma non inoltra traffico.

Una Backup port è una porta che fornisce un backup alternativo vero un segmento di rete,
non inoltra traffico finchè la designed port è attiva.

Rispetto la STP utilizza meno stati

L’RSTP utilizza le BPDU come acknowledgment, di default invia le BPDU ogni 2 secondi e se
ne perde 3 allora ricalcola il TREE, quindi rispetto l’STP che impiega di default 50 secondi,
RSTP in 6 secondi capisce che deve ricalcolare il tree

Per configurare la priority dobbiamo configurare il Bridge-priority e l'extended system id

L’RSTP concatenerà questi due valori , vediamo cosa succede nell’header

Rispetto lo spanning tree, le interfacce del RSTP passano dallo stato di blocked allo stato di
forwarding più velocemente (non esistono i due stati intermedi listening e learning)

Le alternate port passano in forwarding subito dopo che una root port cade
Le edge port passano subito in forwarding

Le non-edge port passano allo stato di forwarding solo quando ricevono un ok da parte
dello switch collegato

Vediamo l’esempio in figura

Il link tra Switch A e Root bridge cade, allora lo switch A invia allo switch b un inferior BPDU
(una BPDU che ha un BRIDGE ID superiore), lo switch B allora cambia il ruolo della porta
verso lo switch A passando da backup a designed inviando il superior BPDU (BPDU con root
ID inferiore).

RSTP è compatibile con STP:

Se uno switch supporta solo STP, allora rifiuta le RSTP BPDU

Se uno switch che ha RSTP riceve una STP BPDU, allora converte l’interfaccia che riceve
questa STP BPDU per utilizzare questo tipo di BPDU

L’MSTP (Multiple spanning tree) come l’RSTP fornisce una veloce convergenza, ma a
differenza dell’RSTP si possono creare diversi multiple spanning-tree instance (MSTIs).
Ogni MSTI crea un tree, e l’utente può associare delle vlan ad ogni tree, in modo da
bilanciare il traffico

L’MSTP raggruppa gli switch in cluster detti Multiple spanning-tree (MST) region. Ogni
regione supporta fino a 64bit di MSTI. L’MSTP oltre a dare path ridondati riduce il numero
di BPDU. Siccome la codifica delle regione MSTP avviene dopo che il router riceve delle
RSTP BDPU, un ruoter che riceve una MSTP BPDU ma ha configurato RSTP questa BPDU la
interpreta come una RSTP BPDU.

Ogni regione è definita da un CST e su ogni regione viene eletto un root bridge.

Un MSTI message contiene

VSTP è un no standard protocollo compatibile con Per-Vlan Spanning Tree+ e Rapid Per-
Vlan Spanning tree.

Crea delle spanning-tree instance per ogni VLAN, e supporta fino a 4096 spanning tree,
ovviamente più vlan aggiungi più risorse cpu sono richieste.

VSTP utilizza la stessa terminologia dello RSTP

L’Header del VSTP è

Spanning tree protocol summary

Per configurare lo spanning tree utilizziamo

con il comando force-versione stp diciamo di forzare la versione in STP

NB: non esiste il menù STP per questo su utilizza il comando force-versione stp

Vediamo come configurare RSTP

Alcuni comandi per il trouble shooting

Configurazione del protocollo MSTP

Configurazione del VSTP

è buona norma bloccare le BPDU nelle porte edge, se la porta fa parte della configurazione
RSTP, possiamo utilizzare questa configurazione

Se non fa parte della configurazione possiamo utilizzare

Quando un’interfaccia riceve una BPDU passa allo stato di blocking e non inoltra il frames,
per riattivare l’interfaccia bisogna utilizzare il comando clear error bpdu interfaces.

Per vedere lo stato di un’interfaccia possiamo utilizzare il comando show spanning-tree

interface, e show l2-learning interface

In questo esempio se lo switch C non riceve BPDU da B, ma B continua a vedere l’interfaccia

up si formerà un loop quindi è utile configurare un loop prevent.

Per evitare che possano hackerare lo spanning tree inviando superior BDPU le interfacce
che non devono riceve superior BPDU possono essere così configurate

Se questa porta riceve una superior BPDU allora va in blocco e dopo un pò di tempo ritorna
in forwarding senza far nulla

OAM (Operation, Administration and Maintanance) sono una serie di funzioni per
monitorare lo stato di salute della rete, OAM determina

Availability: Rapporto di uptime sul tempo misurato

Frame Delay: Il tempo richiesto per trasmettere un frame da un dispositivo ad un altro

Frame Delay variation: La variazione dei test frame delay effettuati

Frame loss: il numero di frame persi

Per verificare se il link è up OAM invia dei messaggi unidirezionali, se un link va down allora
vengono generati dei messaggi di errori AIS (Alarm Indication Signal) e FDI (Forward
Defect Indicator) vediamo l’esempio

Cade il lind da B verso C (ma no da C verso B) il nodo C invia AIS e FDI al nodo D che invia
dei messaggi BDI (Backward Defect Indicator) al nodo A indicando il fault.

Un’altra features è il loopback message, esistono due tipi di loopback message:

Non-distruttive messages (tipo icmp), si abilita un dispositivo ad inviare messaggi ad un
altro

distruttive, in pratica si mette in loop l’interfaccia quindi il traffico non passa, ma serve a
testare il circuito

Il linktrace message serve a testare la bidirezionalità del circuito, il funzionemento di base è

come quello del traceroute ip

LFM serve a verificare la comunicazione unidirezionale tra due apparati su di un link

ethernet- LFM invia dei OAMPDU all’indirizzo 01-80-c2-00-00-02, attraverso il quale
comincia il processo di discovery dei dispositivi sul link. Un dispositivo può essere
configurato passive o active. Solo il dispositivo active inizia il processo di discovery e solo
lui può inviare loopback message.

L’header OAM è fatto così

il flag è utilizzato come BDIs per notificare il problema al router remoto, con

Bit 0 Link Fault (c’è un loss sul circuito )

Bit 1 Dying Gasp (Un problema esterno è stato riscontrato, es la mancanza di energia)

Bit 2 Critical Event (un evento non specificato è stato riscontrato)

Bit 3 Utilizzato durante il processo di discover

Esistono vari tipi di OAMPDU

Le Information OAMPDUs hanno diversi scopi. Vengono utilizzati durante il processo di

rilevamento per scoprire i client vicini e scambiare capacità. Sono inoltre utilizzati per
eseguire controlli di continuità tra i clienti. Quando i client non hanno informazioni da
trasmettere, scambiano Information OAMPDU vuote ad intervalli regolari e configurati. Se il
peer smette di ricevere messaggi, determina che si è verificato un errore sul collegamento
tra i due peer. Inoltre, l'informazione OAMPDU segnala eventi critici.

Gli Event Notification OAMPDUi vengono utilizzati come BDIs. In altre parole, informano il
upstream client che si sono verificati errori nel percorso di ricezione locale. Esistono
quattro diversi tipi di Event Notification OAMPDU:

Errored Frame Event

Errored Frame Period Event

Errored Frame Seconds Summary Event

Errored Symbol Period Event

Loopback control OAMPDU consente a un client LFM di indirizzare i client remoti per
impostare o disattivare un loop sulla sua interfaccia.

Variable Request and Response OAMPDU non sono attualmente supportate nel sistema
operativo Junos.

Quando un LFM client riceve un critical event significa che c’è un problema sul link, quindi
mette giù la rotta e se necessario ricalcola lo spanning-tree, tuttavia continua a monitorare
la il link. Per gli altri tipi di eventi si possono configurare delle action-profile ed applicarle
alle interfacce. In questi profili possiamo configurare un syslog, scegliere di mettere down
l’interfaccia o inviare un OAMPDU al peer remoto.

CFM opera a livelli, i livelli sono da 0 a 7 così divisi

da 5 a 7 livelli riservati per i clienti

da 3 a 4 riservati per i provider

da 0 a 2 riservati per gli operatori

Questo permette una rapida scoperta del fault.

Una Maintance Point (MP) è un’interfaccia sullo switch, ci sono tre tipi di MP:

Maintanance association End Point (MEP) sono interfacce che si trovano sull’edge, e creano
delle relazioni con un singolo MEP, in caso di E-Line EVC (Ethernet Virtual Circuit) o
multipli MEP, in caso di E-LAN EVC. MEP scambiano messaggi CC per essere sicuri che gli
altri MEP siano attivi.

Maintance association intermediate point (MIP) sono opzionali i MIP rispondo ai CFM
message di MEP di livello superiore. Ad esempio nell’immagine sotto se il customer bridge
di livello 5 fa un linktrace, allora le MIP di livello 4 risponderanno ai CFM message

Trasparente è il più semplice, inoltra solamente il traffico

Un MEP forma relazione di neighboor con altri MEP scambiando CC messages, per diventare
vicini devono avere lo stesso mantenance domain, maintenance association, livello e
direzione.

Le direzioni possono essere DOWN ed UP.

DOWN MEP: aspetta di trovare il vicino nel suo downstream

UP MEP: aspetta di trovare il vicino sul suo upstream

Vedi esempio, la relazione di neighboor deve essere instaurata tra i due customer bridge

Periodicamente una MEP invia dei CC message (Continuity check), questo periodo può
essere configurato fa 100MS, 10ms, 1s,1m,o 10m. Questi messaggi sono messaggi multicast
01-08-C2-00-00-3y dove y indica il domain level. Il remote MEP considera il link in fault se
perde 3 CCM (questo threshold può essere modificato).

Il Loopback protocol serve a verificare i fault di connettività, in pratica viene effettuata una
richiesta loopback, il ricevente inoltra il messaggio utilizzando come destination il source
del messaggio.

Il Linktrace protocol funzione come il traceroute ip, viene inviato un messaggio all’indirizzo
01-80-C2-00-00-3y dove y indica il domain level. Questo messaggio arriva ai MEP ed ai MIP,
i MEP del livello più alto scartano il messaggio, mentre quelli dello stesso livello o i MIP
rispondono.

Esistono due misurazioni di frame dealy,

one-way solo una direzione (da mittente a destinatario)

two-way andata e ritorno

Esempio di configurazione LFM

Comandi utili per il troubleshoting

Per attivare il remote loop dobbiamo aggiungere il comando remote-loopback ma

attenzione il peer deve avere configurato il comando allow-remote-loopback altrimenti da
errore(vedi esempio sotto)

Per testare il circuito loopato bisogna configurare un arp statica, vediamo il procedimento

NB: Il successo del ping apparirà come un time to live exceeded

Configurazione CFM

NB i peers devono avere stesso livello, maintenance association, maintenance domain ed

intervallo

In questo esempio abbiamo configurato il MIP che risponderà solo al livello 5 (4+1) perchè
il mep è configurato su livello 4.

Ecco un esempio di ping ethernet il primo specificando il mep ID il secondo specificando il

mac-address

esempio di traceroute ethernet

NB in questo caso visto che stiamo facendo il traceroute verso un MEP di livello 5
rispondono anche i MIP di livello 4.

Lo switch mantiene un record delle ultime misurazioni, è possibile visionare questo record
con il comando
Link Aggregation Group (LAG) 802.3ad, in pratica aggrega n link come se ne fosse uno solo,
migliorando così la banda e la sicurezza.

Per partecipare all’aggregato i link devono avere

stessa velocità e duplex

il numero massimo di link è 8 (anche se cambia da dispositivo ad dispositivo

nei MC-LAG i link possono essere anche di apparati diversi

Il traffico viene così diviso

Il traffico generato dalla RE (ad esempio il il protocol control traffic) utilizza il link più
piccolo

L’algoritmo load-balancing hash per il traffico IP, utilizza criteri Layer 2, Layer3 e layer 4,
per bilanciare, nessuna configurazione è necessaria

L’algoritmo load-balancing hash per il traffico non IP utilizza solo source e destination MAC
addresses

Per aggregare dei link si può utilizzare Link Aggregation Control Protocol (LACP), gli scambi
vengono effettuati tra gli attori (local interface) e partners (remote interface). Le interfacce
possono essere configurate in active o passive (default). LACP scambia PDUs attraverso
tutte i membri del link per vedere se sono configurati ed attivi.

Di default non ci sono interfacce aggregate configurate per configurarle bisogna modificare
la configurazione dello chassis

device-count indica il numero di interfacce aggregate configurate.

L'interfaccia aggregata (ae) rimane down finchè un interfaccia attiva viene aggiunta al LAG.

sotto aggregate puoi configurare anche il tempo ogni quanto un’interfaccia invia LACP
packets

di default le interfacce le inviano ogni secondo.

Possiamo attivare il traceoptions

L’MCLAG forma un lag tra due apparati, i due apparati utilizzano l’inter-chassis Control
protocol (ICCP) per scambiarsi informazioni.

Può essere

ACTIVE-STANDBY supportato sia su schede DPC che su schede MPC, in questo caso solo un
PE è attivo.
ACTIVE-ACTIVE supportato solo su schede MPC. Entrambi i link sono attivi, in questo caso è
necessario un Interchassis Link (ICL)

L’MC-LAG viene configurato come un semplice LAG, quindi si configurano le interfacce

E lo chassis, ed inoltre si deve configurare l’iCCP, prima configuriamo il service-id che deve
essere uguale su entrambi i PE

e poi configuriamo il protocollo ICCP

Alcuni comandi utili per il troubleshooting sono

Le interfacce sono uguali a meno chassis-id e lo status control setting (entrambi si trovano
nel menù mc-ae)

Per vedere il corretto funzionemento del LACP

Dobbiamo avere un’interfaccia collecting distributing, ed una attached.

Per configurare invece un mclag active/active

Sotto mc-ae dobbiamo aggiungere il comando mode active-active lasciando il resto come la
prima configurazione

Inoltre dobbiamo aggiungere il multi-chassis-protection inserendo la loopback dell’altro

dispositivo e l’interfaccia dove raggiungerlo.

Il comando multi-chassis-protection serve a configurare l’ICL

Oltre ad inserire il comando multi-chassis-protection, bisogna anche configurare le due

interfacce

Esempio

Nel caso Active-Active entrambi devono essere collecting distributing

Il virtual-chassis

I router possono essere master o backup mantiene la configurazione globale di entrambi i

router, la RE del router è la RE di tutto il VC. Il backup invece mantiene una copia della
configurazione tabelle di routing ecc

Il core file rappresenta il set di memoria o stack dati che in quel momento era in fault. Di
solito il file viene salvato in /var/tmp ed il nome è nome_processo.core-
tarball.core_number.tgz

Un modo per monitorare lo stato di salute degli apparati è snmp, con il comando health-
monitor

Per configurare Jflow bisogna configurare il template

e poi l’instanza

Rate indica il ratio da usare esempio 10 significa che invia 1 pacchetto ogni 10,

E poi per ogni family si

NB: il tamplate (nell’esempio sample-template) deve essere creato prima.

Nelle macchine con FPC deve essere inserito il comando

set fpc FPC_NUMBER sampling-instance INSTANCE-NAME per tutte le FCP che contengono
interfacce da monitorare.

Ed infine si può applicare una regola di firewall per selezionare il traffico da campionare

NB: ricorda sempre alla fine l’accept ed il term accept per tutto il resto del traffico (il
firewall ha il deny implicito).

Per configurare il port-mirror

e poi configurare il firewall

è necessario configurare un arp statica

MPLS aggiunge un header di 24 bit detto label, con mpls è possibile creare dei label-
switched path (LSP). Altre applicazioni MPLS sono le l2-VPN come Ethernet-VPN o Virtual
private lan service (VPLS).

Fai attenzione l’header MPLS 32bit contiene un campo label di 20 bit, quando diciamo
rimuovere o aggiungere la label mpls non indichiamo il campo label ma l’intero header.

L’Header MPLS è formato da

Label (20Bits)

Traffic class (TC 3bit) utilizzato per il class-of-service

bottom of stack bit (1bit) se settato ad 1 significa che l’header mpls è seguito dal payload, se
settato ad 0 significa che la label mpls è seguita da un’altra label

TTL

Le label da 0 a 15 sono riservate (nb da 4 a 6, da 8 a 12 e la 15 sono riservate per futuri usi)

Due label sono utilizzate alla fine di un LSP

Label 0 (Explict null) indica che si deve effettuare l’operazione di pop, ed inoltrare il traffico
utilizzando o le informazioni del payload oppure la label sotto (in caso di label
sovrapposte). Un frame MPLS può essere inviato con label 0
Label 3 (implicit Null) Viene utilizzata solo nel protocollo di signaling MPLS. Viene utilizzata
dall’egress router (l’ultimo hop in un LSP), per richiedere al router precedente di rimuovere
L’header MPLS.

Alcuni termini MPLS utili sono:

LSR è un router che partecipa al forwarding MPLS

LSP è un path unidirezionale che attraversa il network (lo puoi vedere come un tunnel)

INGRESS LSR un router che effettua l’operazione di push

TRANSIT LSR un router che effettua un operazione di swap

LIB (Label Information Base) contiene la label switch table

PHP è il penultimo router in un LSP

EGRESS LRS è l’ultimo router in un lsp

Le operazioni che si possono effettuare su una label sono

PUSH

SWAP

POP

La LIB viene memorizzata nella tabella mpls.0, questa tabella contiene almeno 4 label create
automaticamente

la 0 Explicit NULL

la 1 router alert

la 2 IPv6 explicit Null

la 13 Generica Associated Label, utilizzata per le operazioni e manutenzioni definie nella

RFC 5586

Queste 4 label hanno un default forwarding che le decapsula

Per configurare MPLS su interfaccia dobbiamo

e dopo aggiungere sotto protocollo MPLS

Per vedere le interfacce MPLS

Un LSP è definito dal nome (che deve essere univoco) e dalle label (che vanno da 1000000 a
1048575).
Un LSP statico deve essere configurato

nel router di ingress

Nel router di transit

NB: nel PHP invece che swap deve essere utilizzato il comando pop

Quando creiamo un lsp vengono modificate le tabelle mpls.0 e inet.3 non vengono modifiate
la inet.0 o la inet6.0

Si possono creare delle statiche utilizzando gli lsp con il comando

Per verificare su di un router di transito se LSP è attivo si utilizza il comando

Ed inoltre possiamo verificare la label

Applicare le label staticamente non ha senso perchè non risponderebbero in maniera

automatico in caso di fault, e poi perchè la gestione è quasi impossibile per grossi reti.
Quindi si utilizzano dei protocolli di distribuzione delle label, come:

RSVP

LDP

RSVP nasce come bandwidth reservation protocol, utilizza il network layer (protocol
number 46) e non è protocollo di routing ma di signaling. Esistono sei tipi di messaggi RSVP,
tutti e sei condividono un header comune.

Path questo messaggio è inviato dall’ingress router per richiedere che un LSP sia creato

RESV questo messaggio riserva le risorse incluse la label assegnate agli LSP

PathTear questo messaggio cancella il path e la relativa reservation dal router che riceve
questo messaggio. è originato dal sender o dal router in cui il path state è in timeout. Il verso
è dal Mittente al destinatario

ResvTear Rimuove le reservation, ma viaggia in direzione opposta al path tear

PathErr questo messaggio indica un errore nel processo di path message, viaggia nel verso
opposto del path message

ResErr Indica un errore nel processo di RESV message

Nell’immagine sopra vediamo la direzione dei messaggi

La creazione di un LSP è iniziata dall’ingress router che invia dei path message in
downstream verso l’egress LSR. Questi messaggi sono (vediamo quelli più comuni):
Session Object agisce come session identifier, e contiene gli endpoints LSP più un tunnel-id
(automaticamente assegnato)

Session_ATTRIBUTE Object Contiene le caratteristiche della sessione, incluso LSP name,

setup, tenere le priorità per il bandwidth reservation

Sender_TSpec Object banda associata all’LSP

RSVP-HOP Object Indica l'indirizzo IP dell'interfaccia sul router che invia il Path Message. Al
router successivo, l'oggetto Hop contiene l'indirizzo IP dell'hop precedente.

label_Request Object Richiesta di mappatura etichette dal router a valle.

Record_route object La lista di tutti gli indirizzi delle interfacce che il path message
attraversa

Explicit_Route Object (ERO) Elenco Strict o loos di router che i path messages RSVP devono
visitare. L'oggetto può contenere strict hops che indicano il percorso esatto da utilizzare.
Oltre allo stricts hop, l'ERO può anche contenere loose hops che indicano un hop che l'LSP
deve attraversare prima di raggiungere l'uscita. Puoi anche usare sia hops strict che loose
nello stesso ERO. NB senza specificare gli hop L’RSVP utilizza l’IGP per scegliere il percorso.

Quanto un path message arriva all’egress router, questo invia indietro verso l’ingress un
RESV message ogni transit LSR che riceve il reverse alloca la nuova label, inoltra il
messaggio al proprio upstream ed installa una nuova entry nella Label Information Base
(LIB).

Un RESV message contiene:

Session Object identifica in modo univoco l’LSP appena creato

LABEL Object esegue il processo di distribuzione delle label all’upstream

STYLE Object utilizzato per riservare la banda

Record_Route object restituisce l’LSPs path al mittente del path message

HOP object Contiene l’ip del precedente hop

L’RSVP deve essere refreshato, questo avviene attraverso l’invio dei path message e degli
RESV che di default vengono inviati ogni 30 sec. Di default Se vengono persi 3 messaggi la
sessione cade, questo valore detto keep-multiplier può essere configurato.

Altri metodi per la failure detection sono:

RSVP hello packet che è un meccanismo più veloce rispetto il refresh

RSVP tracking of IGP utilizza l’IGP per monitorare la raggiungibilità del neighboor
Il Patherr indica un errore all’upstream

Il RESVerr indica un errore al downstream

Gli RSVP teardown messages vengono utilizzati per mettere down LSP, o dall’ingress LSR o
da un transit LSR in caso di fault il PathTear è in direzione del path message

Il ResvTear è in direzione del RESV message

Un ERO è una list di hop che un LSP deve attraversare, questi hops sono identificati con
STRICT o LOOSE, non è detto che LSP segua l’IGP.

Quando un router riceve un RSVP message con un hop strict può

Verificare il constraint, in questo caso l’indirizzo indicato nello stricts hops o è l’ip
dell’interfaccia da dove riceve il messaggio o la loopback, in questo caso il costraint è
rimosso dall’ERO ed inviato

non verificare il constraint se invece il costraint non è un indirizzo della macchina il

messaggio è inviato indietro con un messaggio wrong delivery

L’RRO (Record route Object) viene così compilato ogni router che inoltra il pacchetto
aggiunge l’indirizzo dell’interfaccia da dove lo ha inviato

L’RRO viene utilizzato anche per scoprire i LOOP.

Per configurare RSVP bisogna configurare il family mpls sull’interfaccia, inserire

l’interfaccia sotto protocol MPLS ed RSVP, questa è la configurazione minima.

Per configurare un LSP (configurazione minima) sotto protocol MPLS si deve inserire il
nome dell’LSP e l’end point (di solito la loopback).

il comando no-cspf è un comando importante di default Junos OS utilizza Constrained

Shortest Path Firt (CSFP) che precalcola LSP in base all’IGP.

Durante la costruzione dell’LSP ogni router riceve una richiesta di reserve bandwidth, se ha
la banda richiesta allora farà parte dell’LSP altrimenti invierà un PathErr.

Il parametro bandwidth non è una policy o rate-limit, se si vuole limitare il traffico si può
utilizzare o l’auto-policing o applicare una policy direttamente nell’lsp

Nel primo esempio utilizziamo l'auto policing applicando l’azione drop a tutte le classi, le
opzioni disponibili sono

class all—Apply the same policer action to all the class types (ct0, ct1, ct2, and ct3).

class ctnumber—Specific class type (ct0, ct1, ct2, or ct3) to which to apply a policer action.

Policer actions—You can specify the following policer actions:

Default: no action

drop—Drop all packets.

loss-priority-high—Set the packet loss priority (PLP) to high.

loss-priority-low—Set the PLP to low.

Per ogni interfaccia possiamo anche specificare la percentuale di banda da allocare, esempio

Con il comando show rsvp interface vediamo la subscription e la banda (BW)

Per configurare un LSP con un path prima si definisce il path (con i nodi loose e strict), e poi
si applica all’LSP con il comando primary

Alcuni comandi utili

show mpls interface per verificare se mpls è attivo sulle interfacce

show rsvp interface

Su ative resv viene indicato il numero di LSP che passano sull’interfaccia, su reserverd la
banda riservata e su Highwater mark la banda massima che è stata riservata sull’interfaccia.

show mpls lsp mostra lo stato degli lsp, opzionale possiamo specificare ingress, egress o
transit

se vogliamo maggiori informazioni possiamo utilizzare il comando

show mpls lsp nome_lsp extensive

show rsvp session [transit | ingress | egress] name name_lsp extensive

Con i comandi clear rsvp session e clear mpls lsp mettono down gli lsp.

è possibile configurare l’autenticazione, che viene configurata a livello di interfaccia

Con RSVP possiamo fare l’mtu discovery attraverso RSVP-signaled

sotto protocol mpls

In pratica il router in ingresso setta il TSPEC a 9192 , ogni router invece setta lADSPEC con il
valore minore, alla fine l’egress invia all’ingress il flowspec con il valore calcolato

Con il comando show rsvp session ingress name name_lsp extensive

NB: Dall’esempio vediamo che c’è un MTU di 1500 ma ne possiamo utilizzare solo 1488
perchè tre label (12 bytes) sono utilizzati per

1 Transport label che decide quale traffico deve essere spedito

1 Service label che indica come il traffico dovrebbe essere trattato una volta raggiunto il
router di ingresso

1 Label utilizzata per il traffic protection

Certe volte è necessario configurare dei p2mp esempio nel caso vpls evpn o multicast. Per
configurare una P2MP bisogna

dove i due LSP condividono lo stesso p2mp e poi si applica

Nell’esempio precedente vediamo come si applica un P2MP ad una rotta statica (per un
multicast).

I refresh di rsvp sono molto lenti circa 157 secondi, per ottimizzare questi tempi juniper
utilizza l’IGP

Juniper consiglia di utilizzare BDF

Per visualizzare se in un path c’è BFD si utilizza il comando

Invece di creare manualmente gli LSP si può utilizzare l’auto mesh

per visualizzare tutti i tunnel creati si utilizza

Certe volte è importante mantere l’identità dell’LSP fino all’egress router per far ciò si
utilizza il comando ultimate-hop-popping che disabilità il penultimate-hop-popping e fa
l’override dell’explicte-null

per visualizzare se abbiamo configurato il comando ultimate-hop-popping si utilizza

Un esempio per mantere l’identità dell’lsp è fare delle misurazioni

Per fare le misurazioni dobbiamo configurare l’ultimate-hop-popping e l’OAM

Per visualizzare i risultati utilizziamo

Per visualizzare se sul router c’è il Graceful restart o il no-stop routing si utilizza il comando

Possiamo attivare anche il traceoptions

LDP (Label Distribution Protocol) nasce per uno scopo diverso da RSVP, nasce per scaricare
i router così che non debbano fare il lookup della full table, e non supporta traffic
engineering.

LDP introduce il FEC ( Forwarding Equivalence Class) che sono classi di pacchetti che
vengono trattati allo stesso modo.

LDP utilizza due discovery

Basic Discovery può essere stabilità tra vicini direttamente connessi, gli hello vengono
inviati all’indrizzo [Link]

Extended Discovery stabilisce rapporti di vicinanza tra router che non sono direttamente
connessi, per far ciò si utilizza l’indirizzo unicast (un esempio è L2CIRCUIT)

L’obiettivo dell’LDP è quello di crare per ogni Egress router un TREE di LSP da tutti i
possibili ingress router. Le Label vengono scambiate da Hop in Hop e per evitare loop segue
l’IGP (motivo per cui non è possibile fare TE)

Due Neighbor LDP scambiano i seguenti messaggi

dove

DISCOVERY MESSAGES sono i messaggi che annunciano e mantengono la presenza del

router nel network. Sono messaggi UDP sulla porta 646 usano il link-local address [Link]
questo limita il discovery a router vicini

SESSION MESSAGES sono i messaggi utilizzati per iniziare, mantenere e terminare la

sessione, la sessione inizia con l’avvio di una sessione TCP. Nota bene è l’indirizzo ip più alto
che è responsabile d’iniziare la sessione TCP

ADVERTISEMENT MESSAGES Crea, modifica e cancella le label per le FEC

NOTIFICATION MESSAGES Trasmettono messaggi ed errori

I notification message possono essere:

Error Notification che indicano fatal error che comportano la terminazione della sessione
LDP

Advisory Notification inviano informazioni sulla sessione LDP

Il neighbor discover è un processo simmetrico entrabi i router scambiano degli hello (UDP
646 su indirizzo [Link]) se specificato il transport address questo viene utilizzato per
decidere chi è l’attivo, se non specificato si utilizza il source address del pacchetto hello

La sessione viene avviata dall’ip più alto

Le label vengono assegnate dall’egress verso l’ingress router. La prima label che viene
installata sul router (che è il php) è la label 3 che è la implicit null

Nell’esempio in figura R1 (che è l’egress) invia la net [Link]/32 con label 3(implict null)
l’R2 che è il PHP mette in tabella inet.3 la rete [Link]/32 con nessuna label, e crea una
label (nell’esempio 252) da inviare ad R3, questa lbel viene inserita nella tabella mpls.0

R3 riceve la FEC [Link]/32 label 252 che mette in inet.3 e crea una label per la FEC in
questione (nell’esempio 917, associandola all’operazione da eseguire in questo caso swap
con 252 ed invio ad R2) questo si ripete fino all’ingress
I messaggi di maintenence sessions sono

keepalive

Shutdown

I Keepalice sono gli hello message che di default vengono inviati ogni 5 sec. e di default il
tempo di hold time è 15, questi valori possono essere asimmetrici e configurati.

La configurazione base per LDP richiede che venga inserito il family mpls sull’interfaccia e
che l’interfaccia venga inserita sia su protocol mpls che protocol ldp.

Di Default Junos annuncia in LDP solo l’indirizzo primario della loopback

è possibile inserire l’autenticazione su LDP

questa sopra è un’autenticazione MD5. juniper implementa anche un’altra autenticazione

basata su TCP detta keychain che è un’autenticazione per session

NB my-ldp-kc è il nome della key chain che creiamo così

In LDP esistono 3 tipi di policies

IMPORT POLICIES Utilizzate per scegliere le label da importare

EXPORT POLICIES utilizzate per scegliere le label da esportare

EGRESS POLICIES permette di annunciare label mapping aggiuntive. Di default l’egress

policy annuncia un singolo prefisso che è l’indirizzo primario della loopback

Dopo aver creato le policy si applicano così

LDP tunneling permette di combinare RSVP e LDP, per far ciò è necessario che i due router
abbiano due tunnell (ed da R2 a R7 e viceversa, per garantire la bidirezionalità) dentro
questi LSPs vengono inviate le label LDP (che vengono scambiate utilizzando la loopback)

Per far ciò si utilizza il comando ldp-tunneling

Con LDP funzione anche il graceful restart per vedere i valori si utilizza il comando

Due comandi per mettere down le adiacenze sono

clear ldp session e clear ldp neighbor

con show ldp interface vediamo le interfacce che utilizzano LDP ed il numero i vicini per
interfaccia

con show ldp neighbor vediamo i vicini

con show ldp session si vede lo stato delle sessioni,

utilizzando detail vediamo maggiori informazioni

con show ldp database vediamo le label inviate e ricevuto per un neighbor

Come detto prima tutte gli LSP egress sono inseriti nella inet.3. Un modo per visualizzare
tutte le LDP LSP destination è utilizzare il comando

omettendo il parametro inet.3 vediamo tutte entries LDP installate sul router

Con il comando show mpls label usage vediamo la percentuale del label space utilizzato

RSVP viene integrato anche al BGP, con la policy next-hop self cambiamo il next-hop dei
prefissi, mettendo come next-hop la loopback, se creiamo degli lsp allora nei ruoter ci
saranno due entry per raggiungere la loopback, quella IGP su inet.0 e quella LSP su inet.3

NB BGP da priorità alla tabella inet.3 rispetto la inet.0

Infatti facendo uno show route protocol bgp, vedremo

Con RSVP possiamo aggiungere un prefisso raggiungibile attraverso un LSP, questo si fa con
il comando install vediamo un esempio

Se dopo il prefisso aggiungiamo l’opzione active (es. install [Link]/24 active) questa verrà
installa anche in inet.0 come se fosse una statica ma con default preference 7

Di default junos installa gli LSP egress endpoint in inet.3 ed utilizza questi solamente per
risolvere il next-hop BGP, ma se vogliamo possiamo cambiare questo utilizzando il comando
traffic-engineering

Con BGP-IGP inseriemiamo le route e gli egress points sia sulla inet.0 mentre la inet.3 resta
vuota

Con BGP-igo-both-ribs le route vengono inserite sia in inet.0 che inet.3

MPLS-forwarding funzione come BGP-igo-both-ribs ma con questa opzione vengono create

due routte una per il forarding (indicata con il simbolo#) ed una per il routing (indicata con
il simbolo @)

Può capitare che un link non abbia banda sufficiente quindi il path non può essere creato, di
solito mpls ha dei protocolli di protezione

MPLS Fast Reroute (FRR)

Link Protection

Link-Node Protection

Sia OSPF che IS-IS possono propagare informazioni addizionali per trasportare informazioni
di traffic engineer
Per configurare il traffic-engineering bisogna indicare il parametro traffic-engineering
all’interno dei protocolli

l’obiettivo del traffic-engineer database è calcolare gli MPLS path all’interno del network,
l’IGP ha tutte le informazioni sulla topologia, l’estensione traffic-engineer aggiunge
informazioni supplementari, queste informazioni devono essere mantenute aggiornate
attraverso il flooding dei link-state update o link-state PDU quando necessario.

Con il comando show ted database id_router extensive

Vediamo quale priorità (detto colore) è stata assegnata all’LSP, ci sono 7 livelli, con questo
comando vediamo anche gli indirizzi local e remote, questi possono avere diverse
combinazioni, ogni combinazione rappresenta un tipo di link

Il CSPF è un’evoluzione dell’IGP, in pratica tiene conto di alcuni costrain (es. banda
riservata), se il link non rispetta i costrain allora viene tolto dalla topologia, i link restanti
vengono utilizzati per scegliere il percorso migliore utilizzando IGP. Se con i link restanti
non riusciamo a creare il percorso l’algoritmo restituisce un errore e LSP resta down.

In teoria ogni qualvolta un link libera o alloca della banda significa che tutti i nodi debbano
floodare nella rete questo cambiamento attraverso OSPF LSA o ISIS PDU, questo per
mantenere aggiornato il TE dell’IGP.

Questo significa però un maggiore numero di flood, quindi si è deciso di aggiorarne l’igp
sono se un LSP cambia banda per una valore pari al suo 10% (questo è il valore di default,
che può essere cambiato)

Quando RSVP riceve un messaggio di errore sul link questa informazione viene mantenuta
per 20 secondi (questo valore può essere cambiato con il comando rsvp-error-hold-time 0-
240 sotto protocol mpls) questo per evitare che cspf calcoli inutilmente il path.

Quando nel calcolo CSPF ci sono diversi path, l’algoritmo ne deve scegliere uno, di default lo
sceglie in maniera random senza tener conto della banda disponibile sul path.

Oppure si può utilizzare l’opzione least fill, ciò implica che sceglie il percorso con maggiore
banda disponibile, o most fill che tende ad utilizzare il path con minore banda disponibile
(questa è l’opzione consigliata).

Per configurare l’opzione si utilizzano le opzioni least fill o most fill sotto protocol mpls
label-switch-path nome-lsp

Esistono 32 (da 0 a 31) administrative groups detti anche colori, questi servono a taggare i
link e costringere il path ad utilizzare un determinato colore.

Con il comando show ted database extensive visualizziamo i colori, per configurarli

Nell’esempio vediamo che l’interfaccia ge-1/0/0.220 è stata taggata con 2 colori

Una volta taggate le interfacce possiamo specificare quale colore deve utilizzare (o non deve
utilizzare un LSP)

Per vedere quale colore è stato associato ad un’interfaccia si utilizza

Pert calcolare il path, CSPF deve avere l’intera visione della rete, cioè in caso di OSPF devono
tutti i router devono essere nella stessa area (stesso livello in caso di IS-IS)

Nel caso in cui i router sono in aree diverse, solo per OSPF si può utilizzare il comando

Per rendere dinamico il calcolo degli lsp si può utilizzare il PCE (Path Computation
Element),. in pratica si delega un server a fare i calcoli. Per far ciò bisogna

Configurare la CPPE

Dichiare il server

Specificare che il path è verificato dal PCE

Per configurare un LSP bidirezionale si utilizza il comando corouted-bidirectional

Con il comando show mpls lsp

vediamo se un lsp è bidirezionale

Quando il path primario va down, LSP va sul secondario, i tempi di convergenza possono
esseri modificati attraverso:

Retry-timer (default 30s) il tempo necessario a rendere un path failed

Retry-limit (default 0, che significa tentativi illimitati) è il numero di tentativi prima di

dichiare un path failed

Revert-timer è il minimo tempo che il circuito deve essere up e stabile prima di spostare il
traffico (Default 60s, se settato a 0 il traffico resterà sul secondario)

Il path secondario è opzionale e si può configurare

con il comando standby il router segnala il secondo path anche se non necessario, questo
serve a ridurre i tempo di signaling in caso di down del primario.

Nella configurazione possiamo anche specificato altro

Un path può essere configurato con il parametro

select unconditional da maggiore priorità, significa che utilizzerà questo path a meno che sia
down o degradato

select manual ha la precedenza minore.

NB: se sono configurati diversi secondary path, in caso di fault del primary il traffico
sceglierà il secondary nell’ordine di configurazione.

RSVP-signaled supporta le setup e hold priorità e preemption. La priorità va da 0 (più forte)

a 7 (meno forte). Di default vengono settate la Setup priority a 7 (weakest) la hold priority a
0 (strongest) e la prevent preemption.

La setup priority viene utilizzata per determinare quale LSP prenderà il posto di un LSP
esistente (ad esempio nel caso in cui l’attuale LSP non abbia banda a sufficienza) vengono
valutate la hold priority dell’esistente con la setup priority del nuovo.

Di default prima di associare il traffico ad un nuovo LSp il preempted LSP è messo down.
Per evitare ciò con la conseguente perdita di traffico si utilizza il soft-preemption

Per vedere se un link ha configurato il soft-preemption si utilizza il comando show rsvp

session detail

L’MPLS FAST REROUTE permette di segnalare un secondo path che verrà utilizzato nel caso
in cui il primo andasse down. Quando è attivo il router d’ingresso aggiunge un campo ai
messaggi RSVP chiedendo al downstream router di creare un detour LSP. Quando LSP
principale va down se il detour è attivo il traffico viene switchato, se non è attivo viene
inviato un messaggio ResvTear

Il detour di default non ha impostati constraint (quali banda, hop ecc) l’unico constraint
attivo è l'administrative groups (detti anche colori)

Per attivare il fast-reroute bisogna utilizzare il comando fast-reroute

inoltre possiamo aggiungere anche

con il comando show mpls lsp name name_lsp extensive vediamo le informazioni sul fast-
reroute

Il link protection ha un approccio differente, a differenza del fast reroute che offre un
backup dell’intero LSP, con il link protection prova a creare un backup per l’interfaccia
dov’è configurato il link protection

il node-link protection dente a proteggere il nodo, per configurarlo si utilizza il comando

node-link-protection

dopo aver configurato l’interfaccia su protocol RSVP bisogna speficare se il path è link-
protection o node-link-protection

con show rsvp interface nome-interfaccia extensive vediamo il tipo di protezione

L2VPN
L”VPN fornisce una netta separazione delle network clienti con quelle provider. La
configurazione avviene solo nei PE. La configurazione base prevede

Una sessione BGP con family l2vpn signaling

Una routing-instance con instance type l2vpn

L’interfaccia rivolta verso il cliente deve essere ethernet-ccc o vlan-ccc

Vediamo la configurazione di un PE

set system host-name pe1

set interfaces ge-0/0/0 description "Link from PE1 to CE1"

set interfaces ge-0/0/0 encapsulation ethernet-ccc

set interfaces ge-0/0/0 unit 0 family ccc

set interfaces lo0 unit 0 family inet address [Link]/32

set routing-instances l2vpn1 protocols l2vpn interface ge-0/0/0.0 description "CE1"

set routing-instances l2vpn1 protocols l2vpn site CE-1 interface ge-0/0/0.0 remote-site-id 2

set routing-instances l2vpn1 protocols l2vpn site CE-1 site-identifier 1

set routing-instances l2vpn1 protocols l2vpn encapsulation-type ethernet

set routing-instances l2vpn1 instance-type l2vpn

set routing-instances l2vpn1 interface ge-0/0/0.0

set routing-instances l2vpn1 route-distinguisher [Link]:12

set routing-instances l2vpn1 vrf-target target:65412:12

set routing-options autonomous-system 65412

set protocols bgp group ibgp type internal

set protocols bgp group ibgp local-address [Link]

set protocols bgp group ibgp family l2vpn signaling

set protocols bgp group ibgp neighbor [Link]

NB: L2VPN non supporta frammentazione

Bisogna configurare un univoco route-distinguisher per ogni routing-instance. Il route-

distinguisher viene associato ad una rotta, questo serve per far si che anche route uguali
vengano utilizzate su VPN differenti. Il VRF target invece è una community che viene
associata alla rotta in modo che il router sappia se importare e/o esportare quella rotta