Pérdida de conexión entre nodos en una red privada

Tengo 3 nodos ejecutándose en una red privada.

Después de hacer esta pregunta , agregué manualmente node1como peer to node2y node3, por lo que mi red se ve así:

                 _______                    
     ---------> | node2 |
    /           |_______|
   v
 _______
| node1 |
|_______|
   ^
    \            _______
     ---------> | node3 |
                |_______|

Dejé los nodos ejecutándose anoche, pero alrededor de las 10 p. m. (BRST), node2y node3dejé de escuchar node1( admin.peersestaba vacío), mientras node1todavía estaba conectado a ambos ( admin.peerscontenía 2 elementos), pero no obtuve ninguna interacción.

¿Es posible que esto sea un problema con el protocolo Ethereum o sería otra cosa?

Editar:

Estoy ejecutando los nodos en la misma máquina física, pero en diferentes máquinas virtuales. Esas máquinas virtuales se han Ubuntu 12.04instalado.

Las máquinas virtuales se ejecutan en un CentOS con VMWare vCenter.

¿Los relojes de sus diferentes nodos están todos sincronizados con la hora de la red?
Sí lo son. De hecho, están en la misma máquina física, aunque están en diferentes máquinas virtuales.
¿Qué sistema de máquina virtual está utilizando y cuál es el sistema operativo host?
@JackWinters He editado la pregunta...

Respuestas (1)

Resumen

Hubiera esperado que los parámetros de los nodos de arranque permitieran que el nodo 2 y el nodo 3 encontraran el nodo 1, el nodo 2 y el nodo 3 y luego que todos los nodos mantuvieran sus conexiones entre pares.

Por Henrique Barcelosel problema de , parece que esta configuración no es estable en una red privada que ejecuta los nodos en una máquina virtual.

La alternativa de usar static-nodes.jsonno parece proporcionar una conexión estable.

La siguiente configuración a probar es usar trusted-nodes.jsony especificar el --maxpeersparámetro

A continuación se muestran los pasos que estamos tomando para resolver el problema.


Un problema interesante.

  1. En cuanto a la probabilidad, diría que es muy poco probable que este sea un problema con el protocolo Ethereum, ya que es lo suficientemente robusto para Internet.

  2. Ha declarado que su hora está sincronizada con la hora de la red. Este parece ser un problema que se encuentra regularmente y es por eso que hice la pregunta anterior.

  3. Veamos su configuración.

  4. Pregunta. ¿Está ejecutando otros nodos de la red principal de Ethereum dentro de su red privada? La razón por la que pregunto esto es que puede haber un conflicto con el puerto de red 30303, en referencia al primer enlace de su pregunta.

  5. Desde el primer enlace de su pregunta, está iniciando sus instancias de geth en los diferentes nodos con el siguiente comando:

    geth --verbosity 4 --autodag --nat any --genesis /opt/blockchain/genesis.json
 --datadir /opt/blockchain/data --networkid 4828 --port 30303 --rpc
 --rpcaddr 10.48.247.25 --rpcport 8545 --rpcapi db,eth,net,web3,admin
 --rpccorsdomain '*' --fast --mine --ipcdisable

    El nodo 1 se ha configurado como su nodo de arranque. Los nodos 2 y 3 tienen el archivo /opt/blockchain/data/static-nodes.json con la siguiente información:

    ["enode://{node1publickey}@{node1ip}:30303"]

  6. La información en /opt/blockchain/data/static-nodes.json en 5. anterior coincide con la información de inicio en la instancia de node1 geth que se muestra usando el comando admin.nodeInfo en la instancia de node1 geth.

    ...
enode: "enode://{node1publickey}@{node1ip}:30303",
...

    ¿Es esto correcto?

  7. Mirando sus parámetros de inicio de geth ahora:
    a. Podría intentar eliminar el --nat anyparámetro
    b. Su --networkides único de la red principal "1"
    c. No --port 30303debería ser un problema a menos que esté ejecutando otros nodos Ethereum de red principal dentro de su red, y aun así no debería ser un problema, ya que estará en una IP diferente
    d. Su --rpcaddrdebe ser la dirección IP de cada máquina. El nodo 1 debe tener la dirección IP del nodo 1. El nodo 2 debe tener la dirección IP del nodo 2 y el nodo 3 debe tener la dirección IP del nodo 3.
    mi. Su --rpcport, --rpcapiy --rpccorsdomainno debería afectar la conectividad de su red.
    F. No deberías necesitar el--fastEl parámetro ya que su cadena de bloques debe ser pequeño de todos modos, ya que es una cadena de bloques de testnet interna.
    gramo. Sus parámetros --miney --ipcdisableno deberían afectar su conectividad.
  8. Lo que intentaría a continuación es eliminar el --bootnodeparámetro y probar el /opt/blockchain/data/static-nodes.jsonmétodo en 5. arriba en los nodos 2 y 3. Ejecute esto por un tiempo y esperemos que no tenga interrupciones de conectividad. Podemos tachar esto de la lista si aún tiene interrupciones de conectividad.

Añadido a continuación el 04/12/2016:

  1. Henrique Barcelosha estado usando el static-nodes.jsonmétodo para que los pares se encuentren, pero las conexiones entre pares se interrumpieron. He sugerido intentarlo trusted-nodes.json, ya que estos especifican nodos de pares confiables para conectarse y no estarían bloqueados por los --maxpeerslímites de conexión.
  2. Lo que encontré en mis pruebas es que la static-nodes.jsonopción no se conectaría a menos que agregue un --maxpeersparámetro distinto de cero, aunque --maxpeersestá destinado a 25 por defecto.
Aproximadamente 4. No, solo estoy ejecutando los nodos en la red privada.
Aproximadamente 5. node1es el nodo de arranque, estoy pasando su enodo a través --bootnodesde node2y node3, pero no haystatic-nodes.json
Sobre 7.a. --natel valor predeterminado es "cualquiera" de acuerdo con los documentos
He agregado un static-nodes.jsonarchivo en node2y node3, con una matriz que contiene el enodo de node1. Dejaré los nodos funcionando durante la noche y mañana comentaré los resultados aquí (estoy en GMT-0300)
Esperamos escuchar acerca de sus resultados.
Aparentemente el problema de conectividad fue solucionado. Sin embargo, no sé exactamente qué me ha resuelto.
Probablemente, static-nodes.jsonayudó, pero no puedo estar seguro.
Ejecútelo durante unos días más y compruebe si las conexiones son sólidas. Luego, puede volver al método anterior de usar los nodos de arranque y, si hay desconexiones, confirme que el método de los nodos de arranque no se adapta a su entorno.
Sí, estaba planeando hacer algo así. Gracias por tu ayuda con este problema @BokkyPooBah
¡Oh, no! Los nodos volvieron a divergir durante el fin de semana :/
Cuando tus nodos divergen, ¿nunca se vuelven a unir? He estado haciendo algunas pruebas adicionales y descubrí que necesitaba configurar el parámetro --maxpeers para que funcione la conexión entre pares. Examinaré un poco más y me pondré en contacto con usted. También he estado configurando --verbosidad un poco más alto que el predeterminado 3 para rastrear mi problema de conexión entre pares.
No creo que se reincorporaran en ningún momento porque estaban a 1000 cuadras uno del otro. Actualmente estoy ejecutando con verbosidad = 4, he visto algunos mensajes como "el par se ha vuelto inestable", pero no sé exactamente qué significa esto.
Estoy revisando los registros, la última importación de bloques se realizó el 9 de abril a las 10:37:19 GMT-0300 (el sábado pasado), lo que significa que los nodos no se han comunicado entre sí durante casi 2 días.
Y también he estado buscando probar el trust-nodes.json ya que ignora el límite de maxpeers. Consulte ethereum.stackexchange.com/questions/2478/… . Es posible que desee probar esta configuración a continuación.
Esto es extraño porque --maxpeersel valor predeterminado es 25 y solo tengo 3 nodos en ejecución:/
Descubrí que cuando estaba usando --dev --networkid xxxx --nodiscover con static-nodes.json no podía hacer que los pares se conectaran con mensajes de rechazo de nodo (que se muestran cuando la verbosidad está configurada en 4 o 5), hasta Configuré manualmente --maxpeers en un número distinto de cero.
No estoy usando --dev, ¿debería estarlo?
Su --networkid y --genesis harán que su instancia de red sea única. --help muestra que --dev activa el Developer mode: pre-configured private network with several debugging flags.
He notado registros más detallados en el --devmodo. Los nodos se han comportado bien durante la noche, sin divergir hasta ahora.
Acabo de terminar de escribir los resultados de mi prueba en ethereum.stackexchange.com/questions/2851/… . Hay algunos bits allí en la configuración admin.verbosity(6)para rastrear los intentos de conexión P2P.
@HenriqueBarcelos ¿Alguna vez resolviste esto? Tengo el mismo problema y estos pasos no lo han solucionado.
¿Dónde colocas trusted-nodes.json? ¿Tienes que reiniciar geth para que use la lista de enodos?
Pérdida de conexión entre nodos en una red privada
RespuestasAquíPolítica de privacidad1y, 1v