ARGOMENTO:

Salve a tutti,
dopo aver visto la lezione registrata sul FR stavo iniziando a studiare il capitolo in questione e mi sono venuti alcuni dubbi riguardo all'INV-ARP. Quello che non riesco a capire è perchè il mapping automatico fatto grazie all'invArp funziona solo per reti frame relay full-mesh in cui ci ciascun spoke ha connettività diretta con ciascun altro, mentre per reti hub-spoke il mapping automatico non funziona. Forse perchè i spoke non avendo DLCI diretti verso gli altri spokes non sanno come risolvere l'indirizzo IP? o meglio gli spokes conoscono solo il DLCI dell'hub e non degli altri?
vi posto ciò che c'è scritto sul curriculum:

"Another example is on a hub-and-spoke Frame Relay network. Use static address mapping on the spoke routers to provide spoke-to-spoke reachability. Because the spoke routers do not have direct connectivity with each other, dynamic Inverse ARP would not work between them. Dynamic Inverse ARP relies on the presence of a direct point-to-point connection between two ends. In this case, dynamic Inverse ARP only works between hub and spoke, and the spokes require static mapping to provide reachability to each other."

Grazie

Daniele

Ciao Daniele,
l'inverse ARP funziona (quando il mapping automatico non è disabilitato) per tutti i circuiti previsti/esistenti, a prescindere dal tipo di topologia (full-mesh, partial o hub-and-spoke).

Quando hai di fronte una topologia hub-and-spoke quindi, tutti gli spoke possono risolvere il layer 3 dell'hub e l'hub può risolvere il layer 3 di tutti gli spoke. Questo perchè, quando si utilizza il DLCI previsto per un circuito, a layer 2 si ha una destinazione ben precisa: se da uno spoke mi viene detto di poter utilizzare facciamo conto il DLCI X, questo gioco forza mi porterà verso l'hub, e non vi è possibilità alcuna che possa raggiungere direttamente uno spoke (questo per l'accordo con il service provider). Funzionando l'inverse ARP andando a chiedere "chi c'è dietro un determinato DLCI/PVC", la richiesta proveniente da uno spoke non troverà mai risposta diretta da parte di un altro spoke. Se vi fosse invece un altro circuito acquistato/configurato tra due spoke, allora l'INARP funzionerebbe anche tra loro.

Il mapping statico che si può utilizzare per ottenere una raggiungibilità spoke-to-spoke, comunque a layer 2 continua a puntare verso l'hub: spoke1 invierebbe dunque un frame che a layer 2 sarebbe sempre indirizzato all'hub (PVC-X spoke1-to-hub), ma che poi a layer 3 punta verso una destinazione differente (come tipicamente accade in realtà per il 99% del traffico). Attraverso la sua routing table, e la conoscenza del DLCI relativo, l'hub incapsula nuovamente utilizzando il DLCI previsto al raggimento dello spoke2 (PVC-Y hub-to-spoke2). La grande differenza sta nell'utilizzo di due PVC (DLCI) differenti (posto ovviamente il valore locale del DLCI) che necessariamente passano per l'hub, richiedendo un nuovo incapsulamento a layer 2, contrariamente a quanto avverrebbe se esistesse un PVC dedicato tra spoke1 e spoke2.

Grazie Jody,
mi mancava questa cosa che l'hub potesse reinoltrare il frame verso un nuovo PVC, ora diciamo che mi è più chiaro.
Invece ti volevo chiedere un'altra cosa che sul capitolo riguardante il Frame-Relay è buttata un pò li senza essere approfondita. Quando parla dei problemi relativi ai protocolli di routing implementati con il FR, mentre spiega dettagliatamente il problema relativo allo SPLIT HORIZON per protocolli di routing distance vector non lo fa o forse non l'ho capito per quanto riguarda i problemi di routing per i protocolli link-state tipo OSPF dove dice che:

" However, reachability issues can arise with the DR/BDR. OSPF over NBMA networks works in non-broadcast network mode, by default, and neighbors are not automatically discovered. Neighbors can be statically configured. However, ensure that the hub router becomes a DR, as shown in Figure 4. Recall that a NBMA network behaves like Ethernet, and on Ethernet, a DR is needed to exchange routing information between all routers on a segment. Therefore, only the hub router can act as a DR, because it is the only router that has PVCs with all other routers."

L'elezione del DR/BDR si ha su reti Multiaccess ovvero su reti che hanno sul medesimo segmento di rete più router, sia FR che ETH sono multiaccess solo che FR è NB e ETH è BR.
Sul Frame RELAY vorrei capire perchè:
1 - non si possono scoprire i neighbor
2- perchè ci sono problemi di elezioni del DR/BDR, questo forse è legato al fatto che non essendo una rete Broadcast i frame non raggiungono tutti i nodi della rete e quindi l'elezione non può avvenire.

Se ci sono post sul forum riguardo a queste cose va benissimo..

Buona giornata

Ciao Daniele,
ti stai addentrando in una landa decisamente interessante

Le interazioni tra Frame Relay ed OSPF vengono affrontate in CCNP e CCIE, dove le problematiche consistono nel poter utilizzare il multicast o meno per adiacenze e update, e/o nel voler o meno eleggere un DR/BDR per il segmento. Il curriculum come al solito "getta l'esca", in modo da stimolare eventuali approfondimenti in materia. La questione è molto complessa e non la si può riassumere in due parole. Se vuoi approfondire la cosa, ti consiglio le seguenti risorse ufficiali:

Cisco - Initial Configurations for OSPF over Non-Broadcast Links
Cisco - Initial Configurations for OSPF over Frame Relay Subinterfaces
Cisco - Problems with Running OSPF in NBMA and Broadcast Mode over Frame Relay
Cisco - OSPF Design Guide - Adjacencies
IETF - Guidelines for Running OSPF over Frame Relay Networks

Buona lettura!