Subnetting de rango IP público

Éste era el esquema de red de nuestro CPD:

Se pueden ver un par de firewalls SRX-240 en cluster. Había dos redes públicas, resultado de hacer subnetting sobre 62.97.89.0/27: 62.97.89.0/28 (reth1, desde donde llega Internet) y 62.97.89.16/28 (reth2). También podemos observar una red privada 172.27.0.0/19 (reth0).

El mes pasado cambiamos de proveedor de Internet en el CPD. El rango de IPs públicas también cambió (Assigned PA, Provider-aggregatable), aunque seguíamos teniendo la misma cantidad: 32 (/27). Descargué el fichero de configuración del firewall, e hice 32 sustituciones:

De esta manera, la antigua 62.97.89.0/28 era ahora la 212.81.192.224/28, y la antigua 62.97.89.16/28 la nueva 212.81.192.240/28.

Sin embargo, al aplicar la nueva configuración, no había Internet para 212.81.192.240/28. Sin embargo, funcionaba correctamente en 212.81.192.224/28 y la interna 172.27.0.0/19. ¿Qué ocurría?

Días después, mi compañero estaba hablando con el servicio de soporte de nuestro nuevo proveedor de internet. Mientras, yo hacía un tanto de lo mismo con el antiguo. Estábamos tratando de ver si el problema era la configuración del ISP. Pregunté a la chica que me atendía sí veía algo en especial en el router que nos daba salida a internet. Algo relacionado con el subnetting del rango IP público. Me dijo que nada.

Después me puse junto con mi compañero, que seguía hablando con el soporte del nuevo ISP. Momentos después, el técnico hizo «algo» y empezamos a ver usuarios en nuestro FTP, que estaba en 212.81.192.240/28. Eso quería decir que, por fin, todo funcionaba correctamente. Justo en ese momento llamó la chica con la que había estado hablando. Me dijo que, efectivamente, había una configuración especial: la subred 62.97.89.0/28 era directamente accesible, y además había una ruta a 62.97.89.2 para alcanzar 62.97.89.16/28. Nos mandaron la configuración, que se puede ver más abajo. En ese momento, entendí que el proveedor nuevo había hecho precisamente eso, sólo que con las IPs nuevas:

interface Loopback99
 description ConfigVersion:1.25 by APT
 no ip address
 shutdown
!
interface FastEthernet0
 description IfType[Customer] Customer[METEOPLAY S.L.] SID[130601152] IfStatus[UnMonitored] Coments[]
 no ip address
 duplex full
 speed 100
 no cdp enable
!
interface FastEthernet1
 description IfType[Customer] Customer[METEOPLAY S.L.] SID[130601152] IfStatus[UnMonitored] Coments[]
 no ip address
 duplex full
 speed 100
 no cdp enable
!
interface FastEthernet2
 description IfType[Customer] Customer[METEOPLAY S.L.] SID[130601152] IfStatus[UnMonitored] Coments[]
 no ip address
 duplex full
 speed 100
 no cdp enable
!
interface FastEthernet3
 description IfType[Customer] Customer[METEOPLAY S.L.] SID[130601152] IfStatus[UnMonitored] Coments[]
 no ip address
 duplex full
 speed 100
 no cdp enable
!
interface FastEthernet4
 description IfType[Access] L3BEnd[sar5.BCN] L1Circuit[BCN/BCN/IA-153795] Rate[10M]
 bandwidth 10240
 ip address 212.0.116.66 255.255.255.252
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 duplex full
 speed 100
 no cdp enable
 arp timeout 300
 service-policy output main
!
interface Vlan1
 description IfType[Customer] Customer[METEOPLAY S.L.] SID[130601152] IfStatus[UnMonitored] Coments[]
 ip address 62.97.89.1 255.255.255.240
 no ip redirects
 no ip proxy-arp
 load-interval 60
 arp timeout 300
 hold-queue 75 out
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip route 0.0.0.0 0.0.0.0 212.0.116.65
ip route 62.97.89.16 255.255.255.240 62.97.89.2
ip tacacs source-interface FastEthernet4
!

Estuve leyendo una pregunta en serverfault que trataba sobre lo que hemos estado hablando en esta entrada: si podemos hacer subnetting de un rango IP público directamente accesible de manera transparente a nuestro ISP. Miremos la respuesta aceptada:

If you’re not using NAT, i.e. if you want to actually do routing and put real servers on those IP address, then you can’t subnet your network in a way that is transparent to your provider; they will need to modify their router configuration and their routing tables to account for your new network setup, possibly giving you two gateway addresses and/or two routers (or by setting up a new route if you put one subnet «behind» the other and your firewall in the middle).

Howewer, if you keep using NAT and simply give half of the addresses to a firewall and half of them to another, then their external IPs will appear to your ISP as still belonging to a single subnet, and everything will keep working fine.

Básicamente da tres soluciones:

1. División por parte del ISP del rango IP público otorgado en dos subredes. Nos darían dos puertas de enlace. Me imagino que cada una estaría configurada en una interfaz física distinta, o bien, como dice el autor de la respuesta, preconfiguradas en dos routers distintos.
2. Configuración por parte del ISP de una red directamente accesible, normalmente suya, en la que estaría el firewall, más ruta hacia éste para acceder la nuestra. Éste es nuestro caso, sólo que la red directamente accesible la primera subred del rango público otorgado. Ahí había también había ordenadores. Estaban puestos en la zona «untrust» del juniper.
3. NAT (1 a 1, one to one): esta opción es transparente al ISP, aunque no sería un subnetting IP público verdadero. De hecho, ni siquiera sería subnetting. Simplemente se daría una mitad de las IPs a un router (o interfaz) y la otra mitad al otro.

El error

Siempre había pensado que si una subred estaba numéricamente contenida en otra, sólo haría falta una única ruta hacia la más grande, la contenedora. Siguiendo con nuestro caso, como 212.81.192.240/28 está numéricamente contenida en 212.81.192.224/27, sólo haría falta una ruta para ésta última. De esta manera, creía que podía hacer subnetting de un rango IP público de manera transparente al ISP. Esto funciona si la red contenedora está enrutada a nuestro Juniper (normalmente a través de otra red del ISP, no nuestra) y éste tiene conectividad directa con nuestras subredes. Sin embargo, aquí hay una subred con conectividad directa entre el ISP y el Juniper, y otra que sólo conoce el Juniper, pero no el ISP. Por tanto, necesitamos informar al ISP y que añada una ruta.

Leyendo en la web, encontré este comentario que parecía darme la razón:

Hi Nick,

It will work fine.  The SP is providing a /24 and send everything to your /24.  From there, you take the /24 and break it down to multiple smaller subnet.  The /24 is an aggregate route for smaller subnets.  If for example the ISP would have given you a /22, you could divide that to multiple /24 (4). but all the ISP cares for is the /22. (aggregate route).

HTH

El concepto que menciona al final, ruta agregada (aggregate route, route aggregation) es precisamente el mecanismo que he comentado al inicio de esta sección. También se conoce como supernetting, prefix aggregation, o route summarization. Tiene que ver con Classless Inter-Domain Routing (CIDR).