Otras configuraciones de MC-LAG
Configuración de puente activo-activo y VRRP a través de IRB en agregación de vínculos multichasis en enrutadores serie MX
En las siguientes secciones se describe la configuración de 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 de Interchassis
- Configuración de varios chasis
- Configuración del ID de servicio
- Configuración de la supervisión IGMP 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 bajo la jerarquía [editar 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 de modo activo-activo solo es válida si la encapsulación es un ethernet-bridge o un extended-vlan-bridge.
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 la ICL sube, el enrutador configurado como espera muestra las interfaces Ethernet agregadas multichasis compartidas con el par.
Usar la protección de varios chasis en el nivel de interfaz física es una forma de reducir la configuración a nivel de interfaz lógica.
Si hay interfaces lógicas n+1 en ae0, desde ae0.0 hasta ae0.n, hay interfaces lógicas n+1 en ge-0/0/0 también, 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 de Ethernet agregadas multichasis que pertenecen a distintos grupos de redundancia.
Configuración del vínculo de protección de vínculos de Interchassis
El vínculo de protección de vínculos de interchassis (ICL-PL) proporciona redundancia cuando se produce una falla de vínculo (por ejemplo, una falla de troncalización MC-LAG) en uno de los vínculos activos. ICL-PL es una interfaz Ethernet agregada. Solo puede configurar una ICL-PL entre los dos pares, aunque puede configurar varios MC-LAG entre ellos.
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
Una jerarquía de nivel superior se utiliza para especificar una configuración relacionada con variaschassis, 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 la interfaz de protección multichasis para todas las interfaces Ethernet agregadas multichassis que también forman parte del par. Esto se puede invalidar 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 de toda la red para un servicio en el conjunto de enrutadores de PE que proporcionan el servicio. Puede configurar los IDs de servicio bajo el nivel de las jerarquías que se muestran en los ejemplos siguientes:
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 de nivel de puente es necesario para vincular dominios de puente relacionados entre pares y debe configurarse con el mismo valor. Los valores de service-id comparten el espacio de nombre en todas las instancias de puente y enrutamiento, y entre pares. Por lo tanto, no se permiten valores duplicados para los identificadores de servicio en estas entidades.
El ID de servicio en el nivel de dominio de puente es obligatorio para dominios de puente de VLAN de tipo no único. 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 recogió 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 contiene un dominio de puente que contiene una interfaz Ethernet agregada multichasis, debe configurar un id numberde servicio de opciones de conmutador a nivel global, independientemente de si los dominios de puente contenidos tienen ID de servicio específicos configurados.
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 en N1 y 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 se debe configurar cuando se configura la interfaz Ethernet agregada multichassis y una interfaz lógica Ethernet agregada multichassis forma parte de un dominio de puente. Este requisito se aplica.
Un dominio de puente único no puede corresponder con dos IDs 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 multichasis y asignarlas a un ID de grupo de redundancia independiente, que no es compatible. Un servicio debe asignarse uno a uno con el grupo de redundancia que proporciona el servicio. Este requisito se aplica.
Figura 2: Dominio de puente con interfaces lógicas de dos interfaces
Ethernet agregadas multichassis
Para mostrar la configuración de Ethernet agregada multichassis, utilice el comando mostrar interfaces mc-ae . Para obtener más información, consulte el Explorador de CLI.
Configuración de la supervisión IGMP 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 de 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 se deben configurar en lamulticast-snooping-optionsinstrucción para ese dominio de puente.
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 de Ethernet agregada multichasis en enrutadores MX240, MX480, enrutadores MX960 y conmutadores serie QFX.
La
service-idinstrucción es obligatoria para dominios de puente de tipo VLAN no únicos (ninguno, todos o vlan-id-tags:dual).La instrucción es opcional para dominios de puente con una VID definida.
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, y entre pares. Por lo tanto, no se permiten valores duplicadosservice-iden estas entidades.Un cambio de service-id de puente se considera catastrófico y el dominio del puente se cambia.
Este procedimiento le permite habilitar o deshabilitar la función de replicación.
Para configurar la supervisión IGMP en modo activo-activo-activo de MC-LAG:
Configuración manual y automática de conmutación de vínculos para interfaces MC-LAG en enrutadores serie MX
En una topología de agregación de vínculos multichasis (MC-LAG) con modo de espera activa, una conmutación de vínculo solo se produce si el nodo activo se cae. 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 una conmutación 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 error en PE1, PE2 se convierte en el nodo activo. Sin embargo, tan pronto como PE1 esté disponible de nuevo, se activa una conmutación automática de vínculo y el control se vuelve a conmutar a PE1 aunque PE2 esté activo.
Puede configurar la conmutación de vínculo en dos modos: revertivo y no siempre. 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 modo no siempre, el usuario debe activar manualmente la conmutación del vínculo. También puede configurar un tiempo de reversión que activa una conmutación automática o manual cuando caduca el temporizador especificado.
Si dos dispositivos MC-LAG configurados en una configuración de espera activa mediante el protocolo de control de intertrasetraje (ICCP) y el modo de conmutación no virtual está configurado en las interfaces Ethernet agregadas de los MC-LAG y cuando ambas interfaces mc-ae están vinculadas con una configuración de conmutación local de circuito de capa 2, recomendamos que realice la conmutación ingresando el
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[edit interfaces aeX aggregated-ether-options mc-ae]nivel de jerarquía).En el modo de conmutación no continua, cuando una interfaz MC-LAG pasa al estado de espera debido a una falla de vínculo miembro de 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 encuentre una falla y vuelva al estado activo.
Si realiza una conmutación en ambas interfaces Ethernet agregadas en el MC-LAG, debido a la configuración de conmutación local de circuito de capa 2, una conmutación en una interfaz Ethernet agregada activa una conmutación en la otra interfaz Ethernet agregada. En este caso, ambas interfaces Ethernet agregadas se mueven al estado de espera y, luego, vuelven al estado activo. Por lo tanto, no debe realizar conmutación en ambas interfaces Ethernet agregadas en un MC-LAG al mismo tiempo.
No se admiten la configuración de circuitos de capa 2 y las funcionalidades de VPLS si configura una interfaz MC-LAG para que esté en modo de conmutación revertiva. Solo puede configurar la capacidad de conmutación revertiva o no activa si dos dispositivos MC-LAG están configurados en una configuración de 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. Puede realizar una conmutación introduciendo el comando delrequest 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 conmutación de vínculo en una interfaz MC-LAG:
Puede usar el show interfaces mc-ae revertive-info comando para ver la información de configuración de conmutación.
Forzar enlaces o interfaces de MC-LAG con capacidad LACP limitada para estar activo
En una red MC-LAG, un vínculo de cliente MC-LAG sin configuración del Protocolo de control de acceso a vínculos (LACP) permanece inactiva y los conmutadores MC-LAG no pueden acceder a este.
Para garantizar 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 mediante la force-up instrucción en el nivel jerárquico adecuado del dispositivo:
[edit interfaces interface-name aggregated-ether-options lacp][edit interfaces interface-name ether-options 802.3ad lacp]
Puede configurar la función de fuerza de conexión en los conmutadores MC-LAG en modo activo o en modo de espera. Sin embargo, para evitar el tráfico duplicado y las caídas de paquetes, configure la función de fuerza ascendente solo 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 fuerza activa 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 dará preferencia al que tiene 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 fuerza de conexión en 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 la LACP aparece parcialmente en la red MC-LAG( es decir, se presenta en uno de los conmutadores MC-LAG y no aparece en otros conmutadores MC-LAG), la función de fuerza de conexión está deshabilitada.
Aumento de entradas de protocolo ARP y de descubrimiento de red para topologías mejoradas de MC-LAG y VXLAN de capa 3
- Descripción de la necesidad de un aumento en las entradas arp y del protocolo de descubrimiento de red (NDP)
- Aumento de entradas de protocolo ARP y de descubrimiento de red para MC-LAG mejorado mediante el uso de transporte IPv4
- Aumento de entradas de protocolo ARP y de descubrimiento de red para MC-LAG mejorado mediante el uso de transporte IPv6
- Aumento de ARP para puerta de enlace EVPN-VXLAN para borde-leaf en puente enrutado de borde (ERB) o spine en puente enrutado central (CRB) para tráfico de inquilino IPv4
- Aumento de entradas de protocolo ARP y de descubrimiento de red para puerta de enlace EVPN-VXLAN para borde leaf en puente enrutado de borde (ERB) o spine en puente enrutado central (CRB) para tráfico de inquilino IPv6
Descripción de la necesidad de un aumento en las entradas arp y del protocolo de descubrimiento de red (NDP)
El número de entradas ARP y NDP ha aumentado a 256 000 para mejorar los escenarios de MC-LAG y VXLAN de capa 3 mejorados.
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 mejorada de MC-LAG con una gran cantidad 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 caso, el aumento de las entradas ARP y NDP se necesita en el nivel spine.
Dispositivos Leaf que funcionan como puertas de enlace de capa 2 y capa 3.
En este caso, los dispositivos spine de tránsito solo proporcionan el enrutamiento de capa 3 y el mayor número de entradas ARP y NDP necesarias solo en el nivel leaf.
Aumento de entradas de protocolo ARP y de descubrimiento de red para MC-LAG mejorado mediante el uso de transporte IPv4
Para aumentar la cantidad de entradas ARP y NDP mediante el transporte IPv4, siga estos pasos. Recomendamos que utilice los valores proporcionados en este procedimiento para un rendimiento óptimo:
Aumento de entradas de protocolo ARP y de descubrimiento de red para MC-LAG mejorado mediante el uso de transporte IPv6
Para aumentar la cantidad de entradas arp y protocolo de descubrimiento de red mediante el transporte IPv6. Recomendamos que utilice los valores proporcionados en este procedimiento para un rendimiento óptimo:
Aumento de ARP para puerta de enlace EVPN-VXLAN para borde-leaf en puente enrutado de borde (ERB) o spine en puente enrutado central (CRB) para tráfico de inquilino IPv4
Para aumentar la cantidad de entradas ARP mediante el tráfico de inquilino de IPv4, siga estos pasos. Recomendamos que utilice los valores proporcionados en este procedimiento para un rendimiento óptimo:
Aumento de entradas de protocolo ARP y de descubrimiento de red para puerta de enlace EVPN-VXLAN para borde leaf en puente enrutado de borde (ERB) o spine en puente enrutado central (CRB) para tráfico de inquilino IPv6
Para aumentar la cantidad de entradas de protocolo ARP y de descubrimiento de red mediante el tráfico de inquilinos IPv4 e IPv6, siga estos pasos. Recomendamos que utilice los valores proporcionados en este procedimiento para 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 de la serie EX y enrutadores de la serie MX) a otro, realice las siguientes tareas:
- Configurar dispositivos para la sincronización de configuración
- Crear un grupo de configuración global
- Crear un grupo de configuración local
- Crear un grupo de configuración remota
- Cree 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 configuración
Configure los nombres de host o direcciones IP para los dispositivos que sincronizarán sus configuraciones, así como los nombres de usuario y los detalles de autenticación para los usuarios que administran la sincronización de configuración. Además, habilite una conexión NETCONF para que los dispositivos puedan sincronizar sus configuraciones. Secure Copy Protocol (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, C y D, debe configurar los detalles del conmutador B, C y D en el conmutador A.
Para especificar los detalles de configuración:
Crear un grupo de configuración global
Cree un grupo de configuración global 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 remota
Cree un grupo de configuración remota para dispositivos remotos.
Para crear un grupo de configuración remota:
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;
}
}
}
}
Cree grupos de aplicación para las configuraciones locales, remotas y globales
Cree grupos de aplicación para que los cambios en la configuración se hereden por grupos de configuración locales, remotos y globales. Enumerar los grupos de configuración en orden de herencia, donde los datos de configuración del primer grupo de configuración tienen prioridad sobre los datos en los grupos de configuración subsiguientes.
Cuando se aplican los grupos de configuración y se emite el commit peers-synchronize comando, los cambios se confirman en los dispositivos locales y remotos. Si hay un error en cualquiera de los dispositivos, se emite un mensaje de error y se termina 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 cuando se realiza la sincronización de configuración.
Puede habilitar la peers-synchronize instrucción en el dispositivo local (o de solicitud) para copiar y cargar su configuración en el dispositivo remoto (o en respuesta) de forma predeterminada. Como alternativa, puede emitir el commit peers-synchronize comando.
Configure el
commitcomando en el local (o en la solicitud) 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 que solicita).[edit] user@switch# commit peers-synchronize
Solución de problemas de conexiones de dispositivos remotos
Problema
Descripción
Cuando se ejecuta 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
Compruebe 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 en el directorio /root/.ssh/known_hosts:1 e intente conectarse al conmutador B de nuevo.
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 fue correcta.
Cierre la sesión del conmutador B.
root@Switch B# exit
logout Connection to Switch B closed.Verifique que NETCONF a través de 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 NETCONF a través de SSH se realizó correctamente.
Si el mensaje de error muestra que NETCONF a través de SSH no se realizó correctamente, habilite NETCONF a través de SSH mediante la emisión del
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 han creado grupos de configuración.root@Switch A# show | compare
Ejecute 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.