Junos VRF percorsi statici multi-next-hop a parità di costo non bilanciati


8

Sto bilanciando il carico del traffico su collegamenti doppi, della stessa dimensione, aggregando allo stesso VRF sul router PE (Juniper MX5 JunOS 11.4). Il traffico proveniente dalla CE (Cisco) si sta bilanciando bene, ma ho bisogno di fare il contrario.

Non sto NATing all'interno della rete multi-sito, l'unico NATing avviene sul firewall perimetrale a Internet.

Ho configurato il VRF come segue sul router Juniper PE:

# show routing-instances {client}
instance-type vrf;
.
.
vrf-export {client}-load-balance;
.
.
routing-options {
    static {
        .
        .
        route 10.0.0.0/24 next-hop [ 196.33.144.11 196.33.144.3 ];
        .
        .
    }
}
forwarding-options {
    load-balance {
        indexed-next-hop;
        per-flow {
            hash-seed;
        }
    }
}

e nella configurazione principale questo:

# show policy-options policy-statement {client}-load-balance
then {
     load-balance per-packet;
}

e

# show forwarding-options hash-key
family inet {
    layer-3;
    layer-4;
}

Il router sceglie ancora solo l'hop 196.33.144.3 per instradare il traffico della sottorete (10.0.0.0/24) e non eseguire il bilanciamento su entrambi i collegamenti.

Ecco alcuni controlli:

# run show route forwarding-table table {client}
Routing table: {client}.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            user     0 8:5b:e:84:4c:b0    ucst   561     3 ge-1/1/2.3017
default            perm     0                    rjct   961     1
0.0.0.0/32         perm     0                    dscd   959     1
10.0.0.0/24        user     0 196.33.144.3       ucst   589     5 ge-1/1/5.2100
10.0.0.55/32       user     0                    ucst   645     6 gr-1/1/10.1
10.0.0.210/32      user     0                    ucst   645     6 gr-1/1/10.1
10.0.6.0/24        user     0                    ucst   921     3 gr-1/1/10.16
.
.

e

# run show route 10.0.0.0 table {client}.inet.0

{client}.inet.0: 19 destinations, 20 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/24        *[Static/5] 3d 07:43:36
                    > to 196.33.144.3 via ge-1/1/5.2100
                      to 196.33.144.11 via gr-1/1/10.1

e

# run show route table {client}.inet.0 detail

{client}.inet.0: 19 destinations, 20 routes (19 active, 0 holddown, 0 hidden)
.
.
10.0.0.0/24 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Router, Next hop index: 1048574
                Address: 0xb6b407c
                Next-hop reference count: 3
                Next hop: 196.33.144.3 via ge-1/1/5.2100, selected
                Next hop: 196.33.144.11 via gr-1/1/10.1
                State: <Active Int Ext>
                Age: 3d 7:46:23
                Task: RT
                Announcement bits (2): 0-RT 2-KRT
                AS path: I
                AS path: Recorded

10.0.0.55/32 (1 entry, 1 announced)
        *Static Preference: 5
.
.

Ci sono guide che spiegano questo usando l'istanza predefinita inet.0 del router, ma non riesco a trovare esempi di ciò all'interno di un VRF.

Sto provando il comando vrf-export come alternativa a "forwading-table export load-balance-policy-name" perché il VRF non ha l'opzione di tabella di inoltro.

Qualche idea su cosa posso provare?


Entrambi gli hop successivi sono raggiungibili dall'MX?
Jordan Head,

Sì. Posso eseguire correttamente il ping di entrambi gli IP utilizzando: # esegui ping istanza di routing IP {client}
Shawn Gradwell,

Va bene, lasciami fare questo, ho un sospetto.
Jordan Head,

2
"Sto provando il comando vrf-export come alternativa a forwading-table export load-balance-policy-name" È strano, senza modificare la tabella di inoltro, ECMP non funzionerà. Non intendo offenderti, ma sei sicuro che stai cercando di metterlo al editlivello corretto ? Dovrebbe essere set routing-options forwarding-table export {client}-load-balance.
Ryan Foley,

Oh, ho letto male una parte di esso. Ryan ha perfettamente ragione, è necessario applicare la politica di bilanciamento del carico alla gerarchia da lui menzionata. L'esportazione VRF non è per il bilanciamento del carico, ma per cose come target / distinguitori di rotta.
Jordan Head,

Risposte:


5

Sembra che stai applicando la politica di bilanciamento del carico a routing-instance. Deve essere applicato al forwarding-tableper poter eseguire l'ECMP sul piano di inoltro.

routing-options {
     forwarding-table {
          export load-balancing-policy;
     }
}

Per confermare che funziona, dovresti vedere qualcosa di simile a questo. Nota la voce aggiuntiva nella tabella di inoltro per la voce 10.0.0.0/24.

# run show route forwarding-table table {client}
Routing table: {client}.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            user     0 8:5b:e:84:4c:b0    ucst   561     3 ge-1/1/2.3017
default            perm     0                    rjct   961     1
0.0.0.0/32         perm     0                    dscd   959     1
10.0.0.0/24        user     0 196.33.144.3       ucst   589     5 ge-1/1/5.2100 *
10.0.0.0/24        user     0 196.33.144.11      ucst   645     6 gr-1/1/10.1   *
10.0.0.55/32       user     0                    ucst   645     6 gr-1/1/10.1
10.0.0.210/32      user     0                    ucst   645     6 gr-1/1/10.1
10.0.6.0/24        user     0                    ucst   921     3 gr-1/1/10.16
.
.

1
Questo ha funzionato! Ho anche aggiunto i due IP dell'hop successivo a questo criterio specifico per bloccarlo solo su quella route. Grandi cose grazie!
Shawn Gradwell,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.