Dopo aver effettuato la configurazione IP di base ed aver attivato OSPF, in questo post tratteremo la prima parte relativa all'MPLS: la configurazione dei TE tunnels, sotto forma di interfacce traffic-eng, e dei relativi tunnel path. Al lavoro! 👷‍♂️

Interfacce TE

Per il nostro progetto abbiamo bisogno di 4 interfacce traffic-eng (2 per ogni endpoint), configurate secondo questa logica:

  • West -> East via North
  • West -> East via South
  • East -> West via North
  • East -> West via South
Importante: Ricordiamoci che il TE tunnel serve a stabilire un LSP ed è unidirezionale. Dovremo quindi crearli uno per uno come entità a se stanti.

Procediamo quindi con la configurazione, partendo dai tunnel-path:

# West
/mpls traffic-eng tunnel-path
add hops=192.0.2.2:strict,192.0.2.10:strict name=East_via_North record-route=yes use-cspf=no
add hops=192.0.2.6:strict,192.0.2.14:strict name=East_via_South record-route=yes use-cspf=no

# East
/mpls traffic-eng tunnel-path
add hops=192.0.2.9:strict,192.0.2.1:strict name=West_via_North record-route=yes use-cspf=no
add hops=192.0.2.13:strict,192.0.2.5:strict name=West_via_South record-route=yes use-cspf=no

Abbiamo quindi creato su ogni router i due tunnel-path, uno per North e l'altro per South. Sono stati dichiarati gli hop come strict, disabilitato CSPF (che non ci serve, e per il quale sarebbe comunque necessario attivarne il relativo supporto anche in OSPF) ed abilitato invece il record-route, funzionalità che ci consente di vedere da quali router "passa" il tunnel - un po' come traceroute -  che può essere molto utile in fase di debug.

Riguardo la scelta di dichiarare gli hop strict: questo vuol dire che il percorso dovrà essere esattamente quello indicato, e non potranno esserci altri hop intermedi. Si tratta di un dettaglio implementativo, da valutarsi caso per caso.

Configuriamo adesso le  interfacce TE:

# West
/interface traffic-eng
add disabled=no from-address=192.0.2.248 name=East_via_North primary-path=East_via_North secondary-paths=East_via_South to-address=192.0.2.250
add disabled=no from-address=192.0.2.249 name=East_via_South primary-path=East_via_South secondary-paths=East_via_North to-address=192.0.2.251

# East
/interface traffic-eng
add disabled=no from-address=192.0.2.250 name=West_via_North primary-path=West_via_North secondary-paths=West_via_South to-address=192.0.2.248
add disabled=no from-address=192.0.2.251 name=West_via_South primary-path=West_via_South secondary-paths=West_via_North to-address=192.0.2.249
Nota: abbiamo configurato anche i secondary-path - incrociati rispetto ai primary -  che verranno utilizzati in caso di fault del principale. Se non fosse stato configurato un secondary path, in caso di fault del primario l'interfaccia diventerebbe indisponibile.

È consigliabile a questo punto verificare che tutto stia funzionando correttamente.

[admin@East] > /int traffic-eng monitor [find] once
               tunnel-id: 3                             4
      primary-path-state: established                   established
            primary-path: West_via_North                West_via_South
    secondary-path-state: not-necessary                 not-necessary
             active-path: West_via_North                West_via_South
            active-lspid: 1                             1
            active-label: 20                            17
          explicit-route: S:192.0.2.9/32,S:192.0.2.1/32 S:192.0.2.13/32,S:192.0.2.5/32
          recorded-route: 192.0.2.2[20],192.0.2.1[0]    192.0.2.6[17],192.0.2.5[0]
      reserved-bandwidth: 0bps                          0bps
      
[admin@West] > /int traffic-eng monitor [find] once
               tunnel-id: 2                              3
      primary-path-state: established                    established
            primary-path: East_via_North                 East_via_South
    secondary-path-state: not-necessary                  not-necessary
             active-path: East_via_North                 East_via_South
            active-lspid: 1                              1
            active-label: 17                             16
          explicit-route: S:192.0.2.2/32,S:192.0.2.10/32 S:192.0.2.6/32,S:192.0.2.14/32
          recorded-route: 192.0.2.9[17],192.0.2.10[0]    192.0.2.13[16],192.0.2.14[0]
      reserved-bandwidth: 0bps                           0bps

Vediamo che le interfacce TE sono correttamente funzionanti, il campo recorded-route ci testimonia che i due tunnel fanno percorsi differenti. Verifiche più puntuali possono essere fatte utilizzando questo comando:

[admin@West] > mpls traffic-eng path-state print detail
Flags: L - locally-originated, E - egress, F - forwarding, P - sending-path, R - sending-resv
 0 LFP  src=192.0.2.248:1 dst=192.0.2.250:2 bandwidth=0bps label=none out-label=17 out-interface=ether1 out-next-hop=192.0.2.2
        path-out-explicit-route="S:192.0.2.2/32,S:192.0.2.10/32" path-out-record-route="192.0.2.1"

 1 LFP  src=192.0.2.249:1 dst=192.0.2.251:3 bandwidth=0bps label=none out-label=16 out-interface=ether2 out-next-hop=192.0.2.6
        path-out-explicit-route="S:192.0.2.6/32,S:192.0.2.14/32" path-out-record-route="192.0.2.5"

 2  EF R src=192.0.2.250:1 dst=192.0.2.248:3 bandwidth=0bps resv-bandwidth=0bps label=expl-null in-interface=ether1 in-previous-hop=192.0.2.2
        path-in-record-route="192.0.2.2[20],192.0.2.10" resv-out-record-route="192.0.2.1[0]"

 3  EF R src=192.0.2.251:1 dst=192.0.2.249:4 bandwidth=0bps resv-bandwidth=0bps label=expl-null in-interface=ether2 in-previous-hop=192.0.2.6
        path-in-record-route="192.0.2.6[17],192.0.2.14" resv-out-record-route="192.0.2.5[0]"

Attraverso il quale possiamo verificare non solo il record-route come mostrato dall'interfaccia TE, ma anche le interfacce e relative etichette.

Nel prossimo post termineremo la configurazione, abilitando BGP e configurando - infine - BGPVPLS. Alla prossima puntata !