Las confederation es una extensión de BGP, explicada en el RFC 3065 (http://www.ietf.org/rfc/rfc3065.txt) lo cual nos permite dividir un sistema autónomo en múltiples subsistemas autónomos para que nuestro sistema IBGP sea más escalable.
Una cosa que tiene que quedar clara es que las confederations no están intencionadas para suprimir a los route-reflectors si no para complementarse entre si.
Utilizaremos como ejemplo el AS200 compuesto por 3 routers el cual vamos a dividir en 2 subsistemas autónomos.
Una cosa que tiene que quedar clara es que las confederations no están intencionadas para suprimir a los route-reflectors si no para complementarse entre si.
Utilizaremos como ejemplo el AS200 compuesto por 3 routers el cual vamos a dividir en 2 subsistemas autónomos.
Nos centraremos en configurar sistema a sistema, cada subsistema funciona como si usara iBGP entre sus routers y eBGP con los que hace la confederación.
Para los routers que están en una confederación el bgp se configura diréctamente en el sistema confederado, es decir, veamos desde el punto de vista de R4 y R1, R4 tiene que establecer una relación eBGP con R1 sin tener que saber que éste está confederado, para el tiene que ser transparente como se organice el otro proveedor internamente. La configuración de R4 sería la siguiente
R4#sh run | s bgpPara los routers que están en una confederación el bgp se configura diréctamente en el sistema confederado, es decir, veamos desde el punto de vista de R4 y R1, R4 tiene que establecer una relación eBGP con R1 sin tener que saber que éste está confederado, para el tiene que ser transparente como se organice el otro proveedor internamente. La configuración de R4 sería la siguiente
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.14 remote-as 200
no auto-summary
y R1 tiene que configurar R4 como una relación eBGP y R2 como iBGP, al tener una relación eBGP tiene que esconder el SUB-AS que estamos usando, para eso se utilizará el comando «bgp confederation identifier»
R1#sh run | s bgp
router bgp 65000
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 200
neighbor 10.0.0.2 remote-as 65000
neighbor 10.0.0.13 remote-as 100
no auto-summary
router bgp 65000
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 200
neighbor 10.0.0.2 remote-as 65000
neighbor 10.0.0.13 remote-as 100
no auto-summary
Para la conexión entre R2 y R3 cuya relación es como si fuera un eBGP tendremos que decirle a cada router que el vecino está en un sistema confederado con el comando «bgp confederation peers AS#» y también realizar la relación entre R2 y R1
R2#sh run | s bgp
router bgp 65000
no synchronization
bgp log-neighbor-changes
bgp confederation peers 65100
neighbor 10.0.0.1 remote-as 65000
neighbor 10.0.0.6 remote-as 65100
no auto-summary
router bgp 65000
no synchronization
bgp log-neighbor-changes
bgp confederation peers 65100
neighbor 10.0.0.1 remote-as 65000
neighbor 10.0.0.6 remote-as 65100
no auto-summary
R3#sh run | s bgp
router bgp 65100
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 200
bgp confederation peers 65000
neighbor 10.0.0.5 remote-as 65000
neighbor 10.0.0.10 remote-as 300
no auto-summary
R5#sh run | s bgp
router bgp 300
no synchronization
bgp log-neighbor-changes
neighbor 10.0.0.9 remote-as 200
no auto-summary
Ésto hace que cuando vayamos a usar sistemas confederados sepamos bien que números de sistemas usar ya que no se puede hacer modificación de un AS a un sistema confederado en caliente, el proceso bgp va a caer, hay que prestar mucha atención en el diseño inicial del bgp.
Adjunto la práctica hecha con gns3.
Excelente!, justo lo que necesitaba, una explicación al grano sin tanto preámbulo :D
ResponderEliminarGracias!!!!!!
Eliminar