Junos VRF de igual costo, rutas estáticas de varios saltos posteriores sin equilibrio


8

Estoy equilibrando la carga del tráfico en enlaces duales del mismo tamaño que se agregan al mismo VRF en el enrutador PE (Juniper MX5 JunOS 11.4). El tráfico del CE (Cisco) se está equilibrando bien, pero necesito hacer lo contrario correctamente.

No estoy haciendo NAT dentro de la red de sitios múltiples, el único NAT ocurre en el firewall perimetral a Internet.

He configurado el VRF de la siguiente manera en el enrutador 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;
        }
    }
}

y en la configuración principal esto:

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

y

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

El enrutador todavía elige solo el salto 196.33.144.3 para enrutar el tráfico de la subred (10.0.0.0/24) hacia y sin equilibrar ambos enlaces.

Aquí hay algunos controles:

# 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
.
.

y

# 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

y

# 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
.
.

Hay guías que explican esto utilizando la instancia predeterminada de inet.0 del enrutador, pero no puedo encontrar ejemplos de esto dentro de un VRF.

Estoy probando el comando vrf-export como una alternativa para "forwading-table export load-balance-policy-name" porque el VRF no tiene la opción de tabla de reenvío.

¿Alguna idea de lo que puedo probar?


¿Se puede acceder a los dos saltos siguientes desde el MX?
Jordan Head

Si. Puedo hacer ping a ambas IP con éxito usando: # run ping IP routing-instance {client}
Shawn Gradwell

Bien, déjame analizar esto. Tengo una corazonada.
Jordan Head

2
"Estoy probando el comando vrf-export como alternativa para forwading-table export load-balance-policy-name" Eso es extraño, sin modificar su tabla de reenvío, ECMP no funcionará. No quiero ofenderte, pero ¿estás seguro de que estás tratando de ponerlo por debajo del editnivel correcto ? Debería ser set routing-options forwarding-table export {client}-load-balance.
Ryan Foley

Oh, leí totalmente una parte de ella. Ryan tiene toda la razón, debe aplicar la política de equilibrio de carga a la jerarquía que mencionó. VRF-export no es para equilibrar la carga, es para cosas como objetivos de ruta / distintivos.
Jordan Head

Respuestas:


5

Parece que está aplicando la política de equilibrio de carga a routing-instance. Debe aplicarse al forwarding-tablepara que pueda realizar ECMP en el plano de reenvío.

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

Para confirmar que está funcionando, debería ver algo similar a esto. Tenga en cuenta la entrada adicional en la tabla de reenvío para la entrada 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
Esto funcionó! También agregué las dos direcciones IP de siguiente salto a esta política específica para bloquearla solo en esa ruta. Grandes cosas gracias!
Shawn Gradwell
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.