.png)
Tengo una aplicación que ejecuta un socket IP sin formato, el destino de este socket se rige por las rutas instaladas mediante el comando 'ip route add'. Estas rutas pueden cambiar durante la vida útil de un socket (por ejemplo, debido a cambios en el siguiente salto).
Simplificado, digamos que tengo 2 interfaces eth0y eth1. También tengo una ruta predeterminada a través de eth0.
El punto final del socket sin formato es, por ejemplo 10.10.10.10, eth1 tiene dirección 100.0.0.1. Hago lo siguiente durante la vida útil del socket sin formato:
ip -f inet route delete 10.10.10.10
ip -f inet route add 100.0.0.2 dev eth1
ip -f inet route add 10.10.10.10/32 via 100.0.0.2 dev eth1
Ahora lo que veo es que después de esta operación el tráfico va correctamente eth1durante unos segundos, luego sale mal (vía eth0) durante un rato (menos de medio segundo) y luego vuelve a ser correcto (hasta donde puedo ver de forma permanente). ).
Entonces mi pregunta principal es: ¿Alguien puede dar una explicación de lo que podría salir mal aquí? Intenté agregar ip route flush cachedespués de la secuencia mencionada antes pero no funcionó. Actualmente estoy desconcertado por qué el tráfico a veces disminuye. Creo que es un problema de sincronización en los comandos de enrutamiento o algún otro desencadenante que deshabilita la ruta por una fracción de segundo, pero me estoy quedando sin opciones.
Intenté usar la SO_BINDTODEVICEopción en mi socket sin formato, pero lamentablemente esto no ayudó mucho, la principal diferencia es que cuando el tráfico sale mal, no se envía.en absoluto, porque pasaría por la interfaz incorrecta. Sin embargo, lo que esperaba era que esto estableciera errno en algo como E_CANNOTROUTE (esto no existe) para poder detectarlo y volver a intentar enviar el paquete. Actualmente no hace esto, pero ¿hay alguna manera de detectar tal falla? Tengo control (casi) total sobre el sistema y la aplicación que ejecuta el socket.
Una solución que sé que funcionaría sería no usar sockets sin formato L3 sino AF_PACKETsockets (y también hacer ARP/ND yo mismo), pero prefiero no entrar en eso todavía.
Actualizar
He mejorado el comportamiento en mi sistema al cambiar este comportamiento de cambio de ruta. Cuando tengo que actualizar el siguiente salto, miro la ruta ya instalada y tomo medidas en función de eso:
- Si no está allí, simplemente instalo la nueva ruta y me salto la eliminación.
- Si la ruta exacta ya está presente (mismo nh, mismo desarrollador), ahora no hago nada.
- Si hay otro nh presente para esta ruta, ahora hago una eliminación más específica solo para este nh seguido de un complemento.
Si bien esto estabilizó la mayoría de mis problemas, a veces todavía veo que sucede lo mismo (aunque con mucha menos frecuencia) cuando ocurre una eliminación y adición real (último caso en el nuevo mecanismo). Además, esto todavía no explica qué sale mal (simplemente lo evita), así que dejaré esta pregunta abierta por ahora ya que tengo mucha curiosidad por saber qué sale mal aquí.
Para su información: tengo el problema con centos, por lo que puedo ver, al pasar de centos4 a centos6, 32 bits.
Respuesta1
Si entendí correctamente, los paquetes siempre deberían salir eth1, y su problema es que cuando actualiza a un nuevo nexthop en eth1, sus paquetes a veces salen eth0. Eso sería porque eliminar+agregar no es una operación atómica.
Intente agregar primero y luego eliminar. La eliminación tiene que ser específica (creo que con el dispositivo y nexthop) para que no elimine también la nueva ruta que acaba de agregar.
Respuesta2
¿Existe una ruta predeterminada (u otra ruta que cubra 10.10.10.10/32) a través de eth0? Si elimina primero y luego agrega, es posible que tenga una condición de carrera en la que se produce la eliminación, los paquetes salen por la ruta predeterminada durante el tiempo entre la eliminación y la adición, luego se produce la adición y los paquetes comienzan a ir a donde usted espera.
Definitivamente me suena como una especie de condición de carrera, probablemente debido a la naturaleza no atómica de las dos operaciones de enrutamiento que mencionaste (como lo establece la Ley 29).