En la versión actual de Quagga en Linux, descubrí que hay una regla que puede suprimir la publicidad de algún tipo de información de rutas a los enrutadores vecinos a través de RIPv2.
Si el enrutador r1 se conecta a otro enrutador r2 a través de una interfaz 'nic0' y r1 tiene otra interfaz 'nic1', conéctese a otra red 'net1'. Entonces r1 espera anunciar la ruta a 'net1' a su vecino r2. La red, digamos net0, es la red que conecta r1 y r2, que es, digamos, 10.3.1.32/27, y la red 'net1' es, digamos, 10.3.1.0/24.
En este caso, la entrada de ruta 10.3.1.0/24 (a través de nic1) no se enviará a r2 porque el programa RIPv2 en Quagga suprimió internamente la entrada y la descartó.
Revisé el código fuente de RIPv2 de Quagga y descubrí que se debe a una regla: 10.3.1.0/24 tiene un prefijo de red que está contenido en el prefijo de red 10.3.1.32/27, en otras palabras, los 24 bits más a la izquierda. de 10.3.1.0 es una subcadena de los 27 bits más a la izquierda de 10.3.1.32.
Pero no entiendo por qué existe esa regla. ¿Está definido por el estándar RIPv2 o simplemente una peculiaridad de Quagga? Según tengo entendido, la superposición entre net0 y net1 es válida y no debería ser un problema debido a la 'Regla de coincidencia de prefijo de red más larga' en el enrutamiento, y para el enrutador r2, realmente necesita saber que existe una red net1 más grande (comparando a net0) se puede acceder a través de r1. Si Quagga suprimió esta información de ruta, r2 no lo sabrá y no se podrá acceder a los hosts en net1 desde net0 desde el lado de r2.
¿Hay alguien que sepa eso?
gracias, woody
Respuesta1
Si la red 10.3.1.0/24 está conectada directamente al R1, eso podría representar un problema. En este caso, R1 tiene direcciones IP superpuestas en ambas interfaces. No soy un experto en Linux, pero sé que esto no es compatible con los enrutadores Cisco (y estoy bastante seguro de que tampoco es compatible con ningún otro enrutador/firewall).
Si la red no está conectada directamente al R1, entonces debe haber un tercer enrutador en la red, llamémoslo R0. R0 está conectado directamente a la red 10.3.1.0/24 y se conecta a R1 a través de alguna otra red, por ejemplo, 172.16.0.0/24. En ese caso, la configuración debería funcionar bien. Probé esto en enrutadores Cisco.
10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
R 10.3.1.0/24 [120/1] via 172.16.0.101, 00:00:13, Ethernet0/1 (nic1)
C 10.3.1.32/27 is directly connected, Ethernet0/0 (nic0)
Quizás Quagga, aunque no se queja de ello, tampoco pueda manejar estos rangos de IP superpuestos en ambas interfaces.