Otras configuraciones de MC-LAG
Configuración de puentes activo-activo y VRRP a través de IRB en la agregación de vínculos multichasis en enrutadores de la serie MX
En las secciones siguientes se describe la configuración del puente activo-activo y VRRP a través de IRB en una agregación de vínculos multichasis (MC-LAG):
- Configuración de MC-LAG
- Configuración del vínculo de protección de vínculos entre chasis
- Configuración de varios chasis
- Configuración del ID de servicio
- Configuración de IGMP Snooping para MC-LAG activo-activo
Configuración de MC-LAG
Un MC-LAG se compone de grupos de agregación de vínculos lógicos (LAG) y se configura en la jerarquía [edit interfaces aeX], de la siguiente manera:
[edit]
interfaces {
ae0 {
encapsulation ethernet-bridge;
multi-chassis-protection {
peer 10.10.10.10 {
interface ge-0/0/0;
}
}
aggregated-ether-options {
mc-ae {
mode active-active; # see note below
}
}
}
}
La instrucción mode active-active solo es válida si la encapsulación es un puente Ethernet o un puente VLAN extendido.
Utilice la instrucción mode para especificar si un MC-LAG está activo-en espera o activo-activo. Si la conexión ICCP está activa y aparece ICL, el enrutador configurado como en espera abre las interfaces Ethernet agregadas multichasis compartidas con el par.
El uso de la protección multichasis en el nivel de interfaz física es una forma de reducir la configuración en el nivel de interfaz lógica.
Si hay n+1 interfaces lógicas en ae0, desde ae0.0 hasta ae0.n, también hay n+1 interfaces lógicas en ge-0/0/0, desde ge-0/0/0.0 hasta ge-0/0/0.n, cada interfaz lógica ge-0/0/0 es un vínculo de protección para la interfaz lógica ae0.
Un dominio de puente no puede tener interfaces lógicas Ethernet agregadas de varios chasis que pertenezcan a diferentes grupos de redundancia.
Configuración del vínculo de protección de vínculos entre chasis
El vínculo de protección de vínculos entre chasis (ICL-PL) proporciona redundancia cuando se produce un fallo de vínculo (por ejemplo, un fallo de troncalización MC-LAG) en uno de los vínculos activos. La ICL-PL es una interfaz Ethernet agregada. Sólo puede configurar una ICL-PL entre los dos pares, aunque puede configurar varios MC-LAG entre ellos.
La ICL-PL asume que la interfaz ge-0/0/0.0 se utiliza para proteger la interfaz ae0.0 de MC-LAG-1:
[edit]
interfaces {
ae0 {
....
unit 0 {
multi-chassis-protection {
peer 10.10.10.10 {
interface ge-0/0/0.0;
}
....
}
...
}
}
}
La interfaz de protección puede ser una interfaz de tipo Ethernet como ge o xe, o una interfaz Ethernet agregada (ae).
Configuración de varios chasis
Se utiliza una jerarquía de nivel superior para especificar una configuración relacionada con varios chasis, como se indica a continuación:
[edit]
multi-chassis {
multi-chassis-protection {
peer 10.10.10.10 {
interface ge-0/0/0;
}
}
}
En este ejemplo se especifica la interfaz ge-0/0/0 como interfaz de protección multichasis para todas las interfaces Ethernet agregadas multichasis que también forman parte del par. Esto se puede anular especificando la protección en el nivel de interfaz física y el nivel de interfaz lógica.
Configuración del ID de servicio
Debe configurar la misma configuración única para toda la red para un servicio del conjunto de enrutadores PE que proporcionan el servicio. Puede configurar los ID de servicio en el nivel de las jerarquías que se muestra en los siguientes ejemplos:
Configuración global (sistema lógico predeterminado)
switch-options {
service-id 10;
}
bridge-domains {
bd0 {
service-id 2;
}
}
routing-instances {
r1 {
switch-options {
service-id 10;
}
bridge-domains {
bd0 {
service-id 2;
}
}
}
}
Sistemas lógicos
ls1 {
switch-options {
service-id 10;
}
routing-instances {
r1 {
switch-options {
service-id 10;
}
}
}
}
No se admite el uso de un nombre de servicio por dominio de puente.
El ID de servicio a nivel de puente es necesario para vincular dominios de puente relacionados entre pares y debe configurarse con el mismo valor. Los valores de identificador de servicio comparten el espacio de nombres en todas las instancias de puente y enrutamiento, así como entre los elementos pares. Por lo tanto, no se permiten valores duplicados para ID de servicio en estas entidades.
El ID de servicio en el nivel de dominio de puente es obligatorio para los dominios de puente de VLAN no únicos. El ID de servicio es opcional para dominios de puente con un identificador de VLAN (VID) definido. Si no se define ningún ID de servicio en este último caso, se recoge de la configuración del ID de servicio para esa instancia de enrutamiento.
Cuando se configura esta instancia de enrutamiento predeterminada (o cualquier otra instancia de enrutamiento) que contenga un dominio de puente que contenga una interfaz Ethernet agregada de varios chasis, debe configurar un identificador numberde servicio de opciones de conmutación a nivel global, independientemente de si los dominios de puente contenidos tienen configurados identificadores de servicio específicos.
En la ilustración de ejemplo que se muestra en la figura 1, las instancias de enrutamiento de red N1 y N2, ambas para el mismo ID de servicio, se configuran con el mismo ID de servicio tanto en N1 como en N2. No se admite el uso de una cadena de nombre en lugar de un número.
de servicio
Se aplican las siguientes restricciones de configuración:
El ID de servicio debe configurarse cuando se configura la interfaz Ethernet agregada de varios chasis y una interfaz lógica de Ethernet agregada de varios chasis forma parte de un dominio de puente. Este requisito se cumple.
Un único dominio de puente no puede corresponder a dos identificadores de grupo de redundancia.
En la figura 2, es posible configurar un dominio de puente que consta de interfaces lógicas de dos interfaces Ethernet agregadas de varios chasis y asignarlas a un ID de grupo de redundancia independiente, lo cual no es compatible. Un servicio debe asignarse uno a uno con el grupo de redundancia que proporciona el servicio. Este requisito se cumple.
Figura 2: Dominio de puente con interfaces lógicas desde dos interfaces Ethernet agregadas de múltiples chasis
Para mostrar la configuración de Ethernet agregada multichasis, utilice el comando mostrar interfaces mc-ae . Para obtener más información, consulte el Explorador de CLI.
Configuración de IGMP Snooping para MC-LAG activo-activo
Para que la solución de multidifusión funcione, se debe configurar lo siguiente:
El vínculo de protección multichasis debe configurarse como una interfaz orientada al enrutador.
[edit bridge-domain bd-name] protocols { igmp-snooping { interface ge-0/0/0.0 { multicast-router-interface; } } }En este ejemplo, ge-0/0/0.0 es una interfaz ICL.
Las
multichassis-lag-replicate-stateopciones de instrucción deben configurarse bajo la instrucción para ese dominio demulticast-snooping-optionspuente.
El espionaje con MC-LAG activo-activo solo se admite en modo no proxy.
Configuración de la supervisión IGMP en el modo activo-activo de MC-LAG
Puede utilizar la opción de service-id la bridge-domain instrucción para especificar la configuración Ethernet agregada de varios chasis en enrutadores MX240, enrutadores MX480, enrutadores MX960 y conmutadores de la serie QFX.
La
service-idinstrucción es obligatoria para los dominios de puente de tipo VLAN no únicos (none, all o vlan-id-tags:dual).La instrucción es opcional para dominios puente con un VID definido.
El nivel
service-idde puente es necesario para vincular dominios de puente relacionados entre pares y debe configurarse con el mismo valor.Los
service-idvalores comparten el espacio de nombres en todas las instancias de puente y enrutamiento, así como entre los pares. Por lo tanto, no se permiten valores duplicadosservice-iden estas entidades.Un cambio de identificador de servicio de puente se considera catastrófico y se cambia el dominio del puente.
Este procedimiento le permite habilitar o deshabilitar la característica de replicación.
Para configurar la supervisión IGMP en el modo activo-activo de MC-LAG:
Configuración del cambio de vínculo manual y automático para interfaces MC-LAG en enrutadores de la serie MX
En una topología de agregación de vínculos multichasis (MC-LAG) con modo de espera activa, un cambio de vínculo solo ocurre si el nodo activo deja de funcionar. Puede anular este comportamiento predeterminado configurando una interfaz MC-LAG en modo de espera activa para revertir automáticamente a un nodo preferido. Con esta configuración, puede activar un cambio de vínculo a un nodo preferido incluso cuando el nodo activo esté disponible. Por ejemplo, considere dos nodos, PE1 y PE2. PE1 está configurado en modo activo, lo que lo convierte en un nodo preferido y PE2 está configurado en modo de espera activa. En caso de cualquier fallo en PE1, PE2 se convierte en el nodo activo. Sin embargo, tan pronto como PE1 vuelve a estar disponible, se activa un cambio automático de vínculo y el control vuelve a PE1 aunque PE2 esté activo.
Puede configurar el cambio de vínculo en dos modos: revertivo y no revertivo. En el modo revertivo, el cambio de vínculo se activa automáticamente mediante el comando del request interface mc-ae switchover modo operativo. En el modo no revertivo, el usuario debe activar manualmente el cambio de vínculo. También puede configurar un tiempo de reversión que active un cambio automático o manual cuando caduque el temporizador especificado.
Si dos dispositivos MC-LAG configurados en una configuración de espera activa mediante el protocolo de control entre chasis (ICCP) y el modo de cubierta de conmutación no revertiva están configurados en las interfaces Ethernet agregadas de ambos MC-LAG y cuando ambas interfaces mc-ae están vinculadas entre sí con una configuración de conmutación local de circuito de capa 2, le recomendamos que realice el cambio introduciendo el botón
request interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id)comando de modo operativo en solo una de las interfaces Ethernet agregadas de un dispositivo MC-LAG. Este comando solo se puede emitir en dispositivos MC-LAG configurados como nodos activos (mediante lastatus-control activeinstrucción en el nivel de[edit interfaces aeX aggregated-ether-options mc-ae]jerarquía).En el modo de conmutación no revertiva, cuando una interfaz MC-LAG pasa al estado de espera debido a un error de vínculo miembro MC-LAG y otra interfaz MC-LAG se mueve al estado activo, el MC-LAG en estado de espera permanece en ese estado hasta que el MC-LAG en estado activo encuentra un error y vuelve al estado activo.
Si realiza un cambio en ambas interfaces Ethernet agregadas en el MC-LAG, debido a la configuración de conmutación local del circuito de capa 2, un cambio en una interfaz Ethernet agregada desencadena un cambio en la otra interfaz Ethernet agregada. En tal escenario, ambas interfaces Ethernet agregadas se mueven al estado de espera y luego vuelven al estado activo. Por lo tanto, no debe realizar la conmutación en ambas interfaces Ethernet agregadas en un MC-LAG al mismo tiempo.
La configuración del circuito de capa 2 y las funcionalidades VPLS no son compatibles si se configura una interfaz MC-LAG para que esté en modo de conmutación revertiva. Puede configurar la capacidad de conmutación revertiva o no revertiva únicamente si dos dispositivos MC-LAG están configurados en una configuración en espera activa (un dispositivo establecido como nodo activo mediante la
status-control standbyinstrucción y el otro dispositivo establecido como nodo en espera mediante lastatus-control activeinstrucción en el[edit interfaces aeX aggregated-ether-options mc-ae]nivel de jerarquía). Para realizar un cambio, introduzca el comando derequest interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id)modo operativo solo en dispositivos MC-LAG configurados como nodos activos.
Para configurar el mecanismo de cambio de vínculo en una interfaz MC-LAG:
Puede utilizar el show interfaces mc-ae revertive-info comando para ver la información de configuración del conmutador.
Forzar la activación de vínculos o interfaces MC-LAG con capacidad LACP limitada
En una red MC-LAG, un vínculo de cliente MC-LAG sin configuración de Protocolo de control de acceso de vínculos (LACP) permanece inactivo y los conmutadores MC-LAG no pueden acceder a él.
Para asegurarse de que el dispositivo cliente con capacidad LACP limitada esté activo y accesible en la red MC-LAG, configure uno de los vínculos o interfaces Ethernet agregados en un conmutador MC-LAG para que esté activo utilizando la force-up instrucción en el nivel de jerarquía adecuado en su dispositivo:
[edit interfaces interface-name aggregated-ether-options lacp]
Puede configurar la función de forzamiento en los conmutadores MC-LAG en modo activo o en modo de espera. Sin embargo, para evitar el tráfico duplicado y la caída de paquetes, la función de forzar solo se configura en un vínculo Ethernet agregado de los conmutadores MC-LAG. Si hay varios vínculos Ethernet agregados en los conmutadores MC-LAG con la función de forzar configurada, el dispositivo selecciona el vínculo según el ID de puerto LACP y la prioridad del puerto. Se da preferencia al puerto con la prioridad más baja. En el caso de dos puertos con la misma prioridad, se da preferencia al que tenga el ID de puerto más bajo.
La force-up opción no se admite en conmutadores QFX10002.
En el conmutador QFX5100, puede configurar la función de forzar el protocolo de control de agregación de vínculos (LACP) en los conmutadores MC-LAG a partir de Junos OS versión 14.1X53-D10.
Si LACP aparece parcialmente en la red MC-LAG (es decir, aparece en uno de los conmutadores MC-LAG y no aparece en otros conmutadores MC-LAG), la función de forzar se desactiva.
Aumento de las entradas de ARP y protocolo de descubrimiento de red para topologías mejoradas de MC-LAG y VXLAN de capa 3
- Comprender la necesidad de un aumento en las entradas de ARP y Protocolo de descubrimiento de red (NDP)
- Aumento de las entradas de ARP y protocolo de descubrimiento de red para MC-LAG mejorado mediante transporte IPv4
- Aumento de las entradas de ARP y protocolo de descubrimiento de red para MC-LAG mejorado mediante el transporte IPv6
- Aumento del ARP para la puerta de enlace EVPN-VXLAN para hoja de borde en puente enrutado de borde (ERB) o spine en puente enrutado centralmente (CRB) para tráfico de inquilinos IPv4
- Aumento de las entradas de ARP y protocolo de descubrimiento de red para puerta de enlace EVPN-VXLAN para hoja de borde en puente enrutado de borde (ERB) o spine en puente enrutado centralmente (CRB) para tráfico de inquilinos IPv6
Comprender la necesidad de un aumento en las entradas de ARP y Protocolo de descubrimiento de red (NDP)
El número de entradas ARP y NDP ha aumentado a 256 000 para mejorar los escenarios mejorados de MC-LAG y VXLAN de capa 3.
Estos son algunos escenarios mejorados de MC-LAG y VXLAN de capa 3 en los que se necesita un aumento en las entradas ARP y NDP:
Topología MC-LAG mejorada con un gran número de interfaces MC-AE que contienen un gran número de miembros por chasis.
Topología spine-leaf no contraída, en la que los dispositivos leaf funcionan como puertas de enlace de capa 2 y manejan el tráfico dentro de la VXLAN, y los dispositivos spine funcionan como puertas de enlace de capa 3 y manejan el tráfico entre las VXLAN mediante interfaces IRB.
En este escenario, el aumento de las entradas ARP y NDP es necesario a nivel de columna vertebral.
Dispositivos leaf que funcionan como puertas de enlace de capa 2 y capa 3.
En este escenario, los dispositivos de columna vertebral de tránsito solo proporcionan el funcionamiento del enrutamiento de capa 3, y el mayor número de entradas ARP y NDP solo se necesita a nivel de hoja.
Aumento de las entradas de ARP y protocolo de descubrimiento de red para MC-LAG mejorado mediante transporte IPv4
Para aumentar el número de entradas ARP y NDP mediante el transporte IPv4, siga estos pasos. Se recomienda utilizar los valores proporcionados en este procedimiento para obtener un rendimiento óptimo:
Aumento de las entradas de ARP y protocolo de descubrimiento de red para MC-LAG mejorado mediante el transporte IPv6
Para aumentar el número de entradas ARP y Protocolo de detección de red mediante el transporte IPv6. Se recomienda utilizar los valores proporcionados en este procedimiento para obtener un rendimiento óptimo:
Aumento del ARP para la puerta de enlace EVPN-VXLAN para hoja de borde en puente enrutado de borde (ERB) o spine en puente enrutado centralmente (CRB) para tráfico de inquilinos IPv4
Para aumentar el número de entradas ARP mediante tráfico de inquilino IPv4, siga estos pasos. Se recomienda utilizar los valores proporcionados en este procedimiento para obtener un rendimiento óptimo:
Aumento de las entradas de ARP y protocolo de descubrimiento de red para puerta de enlace EVPN-VXLAN para hoja de borde en puente enrutado de borde (ERB) o spine en puente enrutado centralmente (CRB) para tráfico de inquilinos IPv6
Para aumentar el número de entradas ARP y Protocolo de detección de red mediante tráfico de inquilinos IPv4 e IPv6, siga estos pasos. Se recomienda utilizar los valores proporcionados en este procedimiento para obtener un rendimiento óptimo:
Sincronización y confirmación de configuraciones
Para propagar, sincronizar y confirmar cambios de configuración de un dispositivo (Junos Fusion Provider Edge, Junos Fusion Enterprise, conmutadores serie EX y enrutadores serie MX) a otro, realice las siguientes tareas:
- Configurar dispositivos para la sincronización de la configuración
- Crear un grupo de configuración global
- Crear un grupo de configuración local
- Crear un grupo de configuración remoto
- Crear grupos de aplicación para las configuraciones locales, remotas y globales
- Sincronización y confirmación de configuraciones
- Solución de problemas de conexiones de dispositivos remotos
Configurar dispositivos para la sincronización de la configuración
Configure los nombres de host o las direcciones IP de los dispositivos que sincronizarán sus configuraciones, así como los nombres de usuario y los detalles de autenticación de los usuarios que administran la sincronización de la configuración. Además, habilite una conexión NETCONF para que los dispositivos puedan sincronizar sus configuraciones. El Protocolo de copia segura (SCP) copia las configuraciones de forma segura entre los dispositivos.
Por ejemplo, si tiene un dispositivo local denominado conmutador A y desea sincronizar una configuración con dispositivos remotos denominados conmutador B, conmutador C y conmutador D, debe configurar los detalles del conmutador B, el conmutador C y el conmutador D del conmutador A.
Para especificar los detalles de configuración:
Crear un grupo de configuración global
Cree un grupo de configuración global de los dispositivos locales y remotos.
Para crear un grupo de configuración global:
El resultado de la configuración es el siguiente:
groups {
global {
when {
peers [ Switch A Switch B Switch C Switch D ];
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.1.1.1/8;
}
}
}
ge-0/0/1 {
ether-options {
802.3ad ae0;
}
}
ge-0/0/2 {
ether-options {
802.3ad ae1;
}
}
ae0 {
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members v1;
}
}
}
}
ae1 {
aggregated-ether-options {
lacp {
active;
system-id 00:01:02:03:04:05;
admin-key 3;
}
mc-ae {
mc-ae-id 1;
redundancy-group 1;
mode active-active;
}
}
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members v1;
}
}
}
}
}
switch-options {
service-id 1;
}
vlans {
v1 {
vlan-id 100;
l3-interface irb.100;
}
}
}
}
Crear un grupo de configuración local
Cree un grupo de configuración local para el dispositivo local.
Para crear un grupo de configuración local:
El resultado de la configuración es el siguiente:
groups {
local {
when {
peers Switch A;
}
interfaces {
ae1 {
aggregated-ether-options {
mc-ae {
chassis-id 0;
status-control active;
events {
iccp-peer-down {
prefer-status-control-active;
}
}
}
}
}
irb {
unit 100 {
family inet {
address 10.10.10.3/8 {
arp 10.10.10.2 l2-interface ae0.0 mac 00:00:5E:00:53:00;
}
}
}
}
}
multi-chassis {
multi-chassis-protection 10.1.1.1 {
interface ae0;
}
}
}
}
Crear un grupo de configuración remoto
Cree un grupo de configuración remoto para dispositivos remotos.
Para crear un grupo de configuración remoto:
El resultado de la configuración es el siguiente:
groups {
remote {
when {
peers Switch B Switch C Switch D
}
interfaces {
ae1 {
aggregated-ether-options {
mc-ae {
chassis-id 1;
status-control standby;
events {
iccp-peer-down {
prefer-status-control-active;
}
}
}
}
}
irb {
unit 100 {
family inet {
address 10.10.10.3/8 {
arp 10.10.10.2 l2-interface ae0.0 mac 00:00:5E:00:53:00;
}
}
}
}
}
multi-chassis {
multi-chassis-protection 10.1.1.1 {
interface ae0;
}
}
}
}
Crear grupos de aplicación para las configuraciones locales, remotas y globales
Cree grupos de aplicación para que los cambios en la configuración sean heredados por grupos de configuración locales, remotos y globales. Enumere los grupos de configuración por orden de herencia, donde los datos de configuración del primer grupo de configuración tienen prioridad sobre los datos de los grupos de configuración siguientes.
Al aplicar los grupos de configuración y emitir el commit peers-synchronize comando, los cambios se confirman tanto en los dispositivos locales como en los remotos. Si hay un error en alguno de los dispositivos, se emite un mensaje de error y se finaliza la confirmación.
Para aplicar los grupos de configuración:
[edit] user@switch# set apply-groups [<name of global configuration group> <name of local configuration group> <name of remote configuration group>]
Por ejemplo:
[edit] user@switch# set apply-groups [ global local remote ]
El resultado de la configuración es el siguiente:
apply-groups [ global local remote ];Sincronización y confirmación de configuraciones
El commit at <"string"> comando no se admite al realizar la sincronización de la configuración.
Puede habilitar la peers-synchronize instrucción en el dispositivo local (o solicitante) para copiar y cargar su configuración en el dispositivo remoto (o que responde) de forma predeterminada. También puede emitir el commit peers-synchronize comando.
Configure el
commitcomando en el local (o solicitando) para realizar automáticamente unapeers-synchronizeacción entre dispositivos.[edit] user@switch# set system commit peers-synchronize
El resultado de la configuración es el siguiente:
system { commit { peers-synchronize; } }Emita el
commit peers-synchronizecomando en el dispositivo local (o solicitante).[edit] user@switch# commit peers-synchronize
Solución de problemas de conexiones de dispositivos remotos
Problema
Descripción
Al ejecutar el commit comando, el sistema emite el siguiente mensaje de error:
root@Switch A# commit
error: netconf: could not read hello error: did not receive hello packet from server error: Setting up sessions for peer: 'Switch B' failed warning: Cannot connect to remote peers, ignoring it
El mensaje de error muestra que hay un problema de conexión NETCONF entre el dispositivo local y el dispositivo remoto.
Resolución
Resolución
Verifique que la conexión SSH al dispositivo remoto (conmutador B) esté funcionando.
root@Switch A# ssh root@Switch B
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is 21:e8:5a:58:bb:29:8b:96:a4:eb:cc:8a:32:95:53:c0. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /root/.ssh/known_hosts:1 ECDSA host key for Switch A has changed and you have requested strict checking. Host key verification failed.El mensaje de error muestra que la conexión SSH no funciona.
Elimine la entrada de clave del directorio /root/.ssh/known_hosts:1 e intente conectarse de nuevo al conmutador B.
root@Switch A# ssh root@Switch B
The authenticity of host 'Switch B (10.92.76.235)' can't be established. ECDSA key fingerprint is 21:e8:5a:58:bb:29:8b:96:a4:eb:cc:8a:32:95:53:c0. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'Switch A,10.92.76.235' (ECDSA) to the list of known hosts. Password: Last login: Wed Apr 13 15:29:58 2016 from 192.168.61.129 - JUNOS 15.1I20160412_0929_dc-builder Kernel 64-bit FLEX JNPR-10.1-20160217.114153_fbsd-builder_stable_10 At least one package installed on this device has limited support. Run 'file show /etc/notices/unsupported.txt' for details.La conexión al conmutador B se realizó correctamente.
Cierre sesión en el conmutador B.
root@Switch B# exit
logout Connection to Switch B closed.Compruebe que NETCONF sobre SSH está funcionando.
root@Switch A# ssh root@Switch B -s netconf
logout Connection to st-72q-01 closed.Password:<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>El mensaje de registro muestra que la NETCONF sobre SSH se realizó correctamente.
Si el mensaje de error mostró que NETCONF sobre SSH no se realizó correctamente, habilite NETCONF sobre SSH emitiendo el
set system services netconf sshcomando.Cree grupos de configuración para sincronizar si aún no lo ha hecho.
Puede ejecutar el
show | comparecomando para ver si se ha creado algún grupo de configuración.root@Switch A# show | compare
Emita el
commitcomando.root@Switch A# commit
[edit chassis] configuration check succeeds commit complete {master:0}[edit]El mensaje de registro muestra que la confirmación se realizó correctamente.