TOPOLOGÍA
- Configurar las sesiones IBGP y EBGP
- Usar las loopback para las sesiones IBGP
- Propagar la red 172.24.0.0/22 a ambos ISPs
- Debe haber conectividad entre los dos PCs
------------------------------------------------------------------------------------------------
CONFIGURACIÓN BÁSICA
root@JNCIS-BGP1> show configuration | display set
set system host-name JNCIS-BGP1
set interfaces em0 unit 0 family inet address 172.24.1.1/30
set interfaces em1 unit 0 family inet address 172.30.1.1/30
set interfaces lo0 unit 0 family inet address 192.168.100.1/32
root@JNCIS-BGP2> show configuration | display set
set system host-name JNCIS-BGP2
set interfaces em0 unit 0 family inet address 172.24.1.2/30
set interfaces em1 unit 0 family inet address 172.31.1.1/30
set interfaces lo0 unit 0 family inet address 192.168.100.2/32
root@BGP-ISP-A> show configuration | display set
set system host-name BGP-ISP-A
set interfaces em0 unit 0 family inet address 172.30.1.2/30
set interfaces em1 unit 0 family inet address 10.10.10.1/24
root@BGP-ISP-B> show configuration | display set
set system host-name BGP-ISP-B
set interfaces em0 unit 0 family inet address 172.31.1.2/30
set interfaces em1 unit 0 family inet address 10.20.20.1/24
--------------------------------------------------------------------------------------------------------
1. Configuración de EBGPs e IBGPs
root@BGP-ISP-A> show configuration | display set
set routing-options autonomous-system 65501
set protocols bgp group EBGP-65503 type external
set protocols bgp group EBGP-65503 peer-as 65503
set protocols bgp group EBGP-65503 neighbor 172.30.1.1
root@BGP-ISP-B> show configuration | display set
set routing-options autonomous-system 65502
set protocols bgp group EBGP-65503 type external
set protocols bgp group EBGP-65503 peer-as 65503
set protocols bgp group EBGP-65503 neighbor 172.31.1.1
root@JNCIS-BGP1> show configuration | display set
set routing-options router-id 192.168.100.1
set routing-options autonomous-system 65503
set protocols bgp group EBGP-65501 type external
set protocols bgp group EBGP-65501 peer-as 65501
set protocols bgp group EBGP-65501 neighbor 172.30.1.2
set protocols bgp group IBGP-65503 type internal
set protocols bgp group IBGP-65503 local-address 192.168.100.1
set protocols bgp group IBGP-65503 neighbor 192.168.100.2
3.Creamos el agregado y lo exportamos hacia los ISPs
root@JNCIS-BGP1> show configuration | display set
set routing-options aggregate route 172.24.0.0/22
set policy-options policy-statement PROPAGAR-AGREGADO term IP-AGR from protocol aggregate
set policy-options policy-statement PROPAGAR-AGREGADO term IP-AGR from route-filter 172.24.0.0/22 exact
set policy-options policy-statement PROPAGAR-AGREGADO term IP-AGR then accept
set protocols bgp group EBGP-65501 export PROPAGAR-AGREGADO
Comprobamos en los ISPs que nos llega la 172.24.0.0/22
set routing-options router-id 192.168.100.1
set routing-options autonomous-system 65503
set protocols bgp group EBGP-65501 type external
set protocols bgp group EBGP-65501 peer-as 65501
set protocols bgp group EBGP-65501 neighbor 172.30.1.2
set protocols bgp group IBGP-65503 type internal
set protocols bgp group IBGP-65503 local-address 192.168.100.1
set protocols bgp group IBGP-65503 neighbor 192.168.100.2
root@JNCIS-BGP2> show configuration | display set
set routing-options router-id 192.168.100.2
set routing-options autonomous-system 65503
set protocols bgp group EBGP-65502 type external
set protocols bgp group EBGP-65502 peer-as 65502
set protocols bgp group EBGP-65502 neighbor 172.31.1.2
set protocols bgp group IBGP-65503 type internal
set protocols bgp group IBGP-65503 local-address 192.168.100.2
set protocols bgp group IBGP-65503 neighbor 192.168.100.1
Comprobamos las vecindades
Los IBGP no se han formado, los EBGP sí. |
Como hemos configurado que los IBGPs formen la sesión a través de las loopback, tenemos que decirles a ambos la manera de llegar a la loopback del vecino. Si hacemos un ping a las loopback vemos que no llegamos. Para solucionarlo, configuramos tanto en JNCIS-BGP1 como en JNCIS-BGP2:
root@JNCIS-BGP1# set routing-options static route 192.168.100.2 next-hop 172.24.1.2
root@JNCIS-BGP2# set routing-options static route 192.168.100.1 next-hop 172.24.1.1
En la realidad un ISP tendrá un protocolo IGP para propagar su routing interno. En los últimos tiempos es IS-IS el protocolo más usado, especialmente en redes MPLS.
Ahora miramos la vecindad y se ha formado. Sed pacientes, BGP es lento.
Juniper recomienda usar siempre el atributo next-hop para las vecindades IBGP. Son interfaces que siempre están "UP". Así hacemos que todas las rutas recibidas en JNCIS-BGP1 desde el equipo JNCIS-BGP2, cambian el next-hop y se establezca en la 192.168.100.1 que es la loopback 0.0 del equipo JNCIS-BGP-1.
Para configurarlo, debemos crear una política y luego aplicarla en BGP:
set policy-options policy-statement IBGP-NEXT-HOP term next-hop then next-hop self
set protocols bgp group IBGP-65503 export IBGP-NEXT-HOP
3.Creamos el agregado y lo exportamos hacia los ISPs
root@JNCIS-BGP1> show configuration | display set
set routing-options aggregate route 172.24.0.0/22
set policy-options policy-statement PROPAGAR-AGREGADO term IP-AGR from protocol aggregate
set policy-options policy-statement PROPAGAR-AGREGADO term IP-AGR from route-filter 172.24.0.0/22 exact
set policy-options policy-statement PROPAGAR-AGREGADO term IP-AGR then accept
set protocols bgp group EBGP-65501 export PROPAGAR-AGREGADO
Comprobamos en los ISPs que nos llega la 172.24.0.0/22
COMANDOS PARA VERIFICAR BGP
- show bgp summary
- show bgp neighbor
- show bgp group
- show route protocol bgp
- show route receive-protocol bgp 172.30.1.2
- show route advertising-protocol bgp 172.30.1.2
NOTA: las rutas hidden (ocultas) puede deberse a que hay aplicado un filtro, a que tienen un next-hop invalido (no alcanzable) o a un descarte.
APLICACIÓN DE POLÍTICAS
Cuando creamos una política tenemos varios sitio donde aplicarla. Podemos aplicarla a nivel de protocolo, a nivel de grupo (es como lo hemos hecho en en ejemplo de arriba) y también se puede aplicar al nivel de neighbor.
Hay que tener en cuenta que Junos aplicará la política más específica, es decir, si tenemos aplicadas políticas a varios niveles, al final aplicara la del nivel más bajo o específico.
Si se configuran las 3, al final se aplicaría la del neighbor |
DIFERENCIA ENTRE IMPORT Y EXPORT
Las políticas de IMPORT son las que habilitan que se instalen las rutas recibidas por los diferentes vecinos BGP en la tabla de rutas general. Estas políticas se ejecutan antes de que se instalen en la tabla de rutas general y por lo tanto tenemos un control de las rutas. Hay que tener en cuenta que esto afecta a la selección de rutas, pues solo las que están activas y en la tabla de rutas general son evaluadas en el proceso de selección de BGP.
Las políticas de EXPORT son las que habilitan que se instalen las rutas desde la tabla de rutas general a las tabla de forwarding o los protocolo dinámicos de enrutamiento. Solo las que estén activas en la tabla de rutas general serán elegidas para exportarse. Las rutas inactivas no se exportan.
Por ejemplo, si tenemos una ruta OSPF (con un preference de 10) y una ruta BGP (con un preference de 170) para llegar al mismo destino, Junos elegirá el protocolo OSPF para exportar a la forwarding table (tabla de envío). De esta manera, la ruta BGP quedaría en estado "inactivo". Por lo tanto, a la ruta OSPF podríamos aplicarle una política de EXPORT, pero no con la de BGP, pues está "inactiva".
Este comportamiento lo podemos cambiar y hacer que BGP exporte las rutas inactivas configurando en la políticas el envío de estas:
policy-options {
policy-statement name{
from state
(active|inactive);
}
}
|
from state inactive
O también podemos usar el comando "advertise-inactive" a diferentes niveles en la configuración:
[edit protocols bgp]
[edit protocols bgp group group-name]
[edit protocols bgp group group-name neighbor address]
También debajo de "logical-system" y "routing-instances".
Cuando aplicamos políticas de EXPORT, las rutas y los atributos cambian cuando se exportan, por lo tanto, esas mismas rutas que permanecen en la tabla de rutas local no son modificadas.
Cuando usemos el comando show route receive-protocols BGP X.X.X.X vemos las rutas que nos manda el vecino y a las que todavía no se les ha aplicado una política de IMPORT. Vemos las rutas con los atributos que nos envían los vecino. Con este comando tampoco vemos las rutas que han sido rechazadas por la política de IMPORT, pero si le añadimos la palabra hidden, podremos verlas, es decir, las que han sido rechazadas por la políticas de IMPORT (aquí si ha siado ya aplicada la política de IMPORT). Para ver la diferencia cuando se aplican las políticas, podemos compararlo con las rutas que nos muestra la tabla de rutas general (show route). Ahí veremos cuáles se han instalado.
4. Configuramos BGP-ISP-A y B para que exporten sus LANs.
root@BGP-ISP-A> show configuration | display set
set protocols bgp group EBGP-65503 export EXPORT-LAN
set policy-options policy-statement EXPORT-LAN term 10 from interface em1.0
set policy-options policy-statement EXPORT-LAN term 10 then accept
root@BGP-ISP-B> show configuration | display set
set protocols bgp group EBGP-65503 export EXPORT-LAN
set policy-options policy-statement EXPORT-LAN term 10 from protocol direct
set policy-options policy-statement EXPORT-LAN term 10 then accept
Dos maneras diferentes de decirle en la política que red queremos exporta.
Ahora comprobamos las rutas enviadas y recibidas.
Con el comando show route advertising-protocol bgp vemos las rutas que el equipo a enviado, a las que se les ha ya aplicado la política de EXPORT. Podemos verlas instaladas en la tabla de envíos:
show route forwarding-table |
aun que lo publicaste algún tiempo, el ejercicio esta muy bueno y me ha sido de ayuda. gracias
ResponderEliminarMe alegra muchísimo Nestor. ¡Un saludo!
ResponderEliminar