Mostrando entradas con la etiqueta eBGP. Mostrar todas las entradas
Mostrando entradas con la etiqueta eBGP. Mostrar todas las entradas

jueves, 25 de julio de 2013

BGP:Algoritmo selección ruta BGP

Uno de los pilares fundamentales para entender bgp es el algoritmo de selección de rutas o prefijos de BGP.

Para la gente acostumbrada a los IGP, BGP puede llegar a ser un poco confuso, este artículo pretende dejar claro como se decide que ruta se introduce en la tabla de rutas por BGP en un router cisco, en los routers de otros fabricantes el proceso va a ser muy similar, salvo por algunos detalles que se es exclusivo de Cisco.

BGP tan solo va a meter una ruta por defecto en la tabla de rutas para un único destino, esta ruta se elegirá comparando una serie de argumentos, que en caso de empate en el primero, se pasará al segundo, tercero, cuarto...etc hasta que se encuentre una ruta a considerar válida.

1. WEIGHT:

La ruta que tenga el mayor peso se instalará en la tabla de routing. Se trata de un atributo específico de Cisco Systems.

Se trata de un atributo que tan solo es representativo en el router, el router no le anuncia a otros routers que peso tienen las rutas, se trata de un mecanismo de control muy sencillo para elegir por donde queremos que el tráfico transite.

Una forma sencilla de configurarlo:
router bgp 200
neighbor 10.10.10.10 remote-as 100
neighbor 10.10.10.10 weight 200
También se pueden usar route-maps para fijar o matchear el weight.

2. LOCAL_PREFERENCE:

La ruta que tenga la mayor local preference se instala en la tabla de routing. Se trata de un atributo que es significativo en el sistema autónomo local, por lo que se anuncia a routers del mismo AS para influirlos, pero no se anuncia a routers de otros AS.

Por defecto el valor de la local preference es 100.

Forma de configurarlo:

router bgp 200
neighbor 10.10.10.10 remote-as 100
bgp default local-preference 200
Tambíen se pueden usar route-maps para fijar o matchear la local preference.

3. Redes originadas por medio de un network o un aggregate-address:

Estas rutas apareceran como internal en los routers, al contrario que las rutas que han sido redistribuidas de otro protocolo de routing...etc.

4. La ruta que pase por menos sistemas autónomos:

Por defecto BGP intenta pasar por el mínimo número de sistemas autónomos, para evitar bucles de routing.
Se puede configurar que a ciertas rutas se les añadan AS en el atributo AS PATH para que el resto de
routers penalicen estas rutas.

router bgp 65001
 neighbor 10.1.0.3 remote-as 65100
 neighbor 10.1.0.3 route-map prepend out
!
route-map prepend permit 10
 set as-path prepend 65001 65001 65001
5. Origen mas bajo:

Esto es simplemente que las rutas cuyo orígen es un IGP o locales, son preferidas a las aprendidas por un EGP, y estas son preferidas ante las rutas con orígen incompleto.

6. Rutas con un campo MED menor:

Por defecto los routers anuncian las rutas con el campo MED a 0, pero cuando son rutas redistribuidas de otro protocolo en BGP se añade la métrica del IGP al atributo MED en la ruta de BGP.
Por supuesto, como todo, se puede cambiar o matchear con route-maps.

Un documento muy bueno para leer con una buena dosis de café encima, que trata esto y muchas otras cosas es:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml

lunes, 3 de septiembre de 2012

BGP Communities: Filtrando por una community

En el último artículo vimos como podíamos asignar communities a prefijos de BGP, en este lo que vamos a hacer es filtrar el tráfico en base a la community que traiga asignado. Si le echas un un poco de imaginación se te ocurrirá cuantas cosas puedes hacer con route-maps y communities, de cara a redistribuciones...etc.

Configuración:

router bgp x
neighbor x.x.x.x route-map <nombre_route_map> in
route-map <nombre_route_map> deny 10
 match community <nombre_comunity_list>


route-map <nombre_route_map> permit 20 <---si no lo pones te cepillas también el resto de prefijos :-D

ip community-list standard <nombre_comunity_list> permit <community_a_filtrar>



Ejemplo:

El mismo ejemplo de la otra vez, pero en esta ocasión filtrando en R2.

R3(Anunciador):

router bgp 6
 no synchronization
 bgp log-neighbor-changes
 network 22.22.22.22 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 5
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 send-community
 neighbor 2.2.2.2 route-map COMMOUT out
 no auto-summary

interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Loopback22
 ip address 22.22.22.22 255.255.255.255

interface Loopback33
 ip address 33.33.33.33 255.255.255.255

interface FastEthernet0/0
!
interface FastEthernet0/1
 no switchport
 ip address 192.168.2.3 255.255.255.0
ip route 1.1.1.1 255.255.255.255 192.168.2.2
ip route 2.2.2.2 255.255.255.255 192.168.2.2

route-map COMMOUT permit 10
 match ip address 23
 set community 3 33 333
!
route-map COMMOUT permit 20
 set community 2 22 222
access-list 23 permit 33.33.33.33

R2(El que filtra):

router bgp 5
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 5
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 6
 neighbor 3.3.3.3 ebgp-multihop 2
 neighbor 3.3.3.3 route-map PRUEBA in
neighbor 3.3.3.3 update-source Loopback0
 no auto-summary
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 no switchport
 ip address 192.168.1.2 255.255.255.0
!
interface FastEthernet0/1
 no switchport
 ip address 192.168.2.2 255.255.255.0

ip route 1.1.1.1 255.255.255.255 192.168.1.1
ip route 3.3.3.3 255.255.255.255 192.168.2.3

ip community-list standard SIN_333 permit 333
!
!
route-map PRUEBA deny 10
 match community SIN_333
!
route-map PRUEBA permit 20


R1:


router bgp 5
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 5
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 no switchport
 ip address 192.168.1.1 255.255.255.0

Verificación:

R2#show ip bgp 22.22.22.22
BGP routing table entry for 22.22.22.22/32, version 8
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  6
    3.3.3.3 from 3.3.3.3 (22.22.22.22)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 2 22 222
R2#show ip bgp 33.33.33.33
% Network not in table
R2#

miércoles, 29 de agosto de 2012

BGP Communities: Anunciando prefijos con communities

Este es el primer artículo específico de BGP que tiene este blog pero vamos a empezar con un poquito de nivel, se va a tratar el tema de las communities en BGP.

Una community es un mecanismo muy parecido a un TAG, que se le pone a un prefijo de BGP. Las communities se utilizan sobre todo a nivel ISP, y hay communities conocidas que indican si la ruta debe de ser interna, si es exportable...etc.

Cada operador suele tener un documento de communities, al que el resto de ISP deberá acogerse para hacer traffic engineering, pero eso esa es otra historia. En esta vamos a hacer pruebas con comunidades de prueba.

Configuración:

En el lado que añadimos la community, en el otro con hablar BGP con el que agrega la community nos vale.

router bgp x
neighbor x.x.x.x send-community <----necesario ya que por defecto no se envían
 neighbor 2.2.2.2 route-map <nombre_route_map> out
 


route-map <nombre_route_map>permit 10
 set community <communities_separadas_espacios>
Ejemplo:



R3(Anunciador):

router bgp 6
 no synchronization
 bgp log-neighbor-changes
 network 22.22.22.22 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 5
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 send-community
 neighbor 2.2.2.2 route-map COMMOUT out
 no auto-summary

interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Loopback22
 ip address 22.22.22.22 255.255.255.255
!
interface FastEthernet0/0
!
interface FastEthernet0/1
 no switchport
 ip address 192.168.2.3 255.255.255.0

ip route 1.1.1.1 255.255.255.255 192.168.2.2
ip route 2.2.2.2 255.255.255.255 192.168.2.2

route-map COMMOUT permit 10
 set community 3 33 333


R2:

router bgp 5
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 5
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 6
 neighbor 3.3.3.3 ebgp-multihop 2
 neighbor 3.3.3.3 update-source Loopback0
 no auto-summary

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 no switchport
 ip address 192.168.1.2 255.255.255.0
!
interface FastEthernet0/1
 no switchport
 ip address 192.168.2.2 255.255.255.0

ip route 1.1.1.1 255.255.255.255 192.168.1.1
ip route 3.3.3.3 255.255.255.255 192.168.2.3


R1:


router bgp 5
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 5
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 no switchport
 ip address 192.168.1.1 255.255.255.0


Verificación:

R2#show ip bgp 22.22.22.22
BGP routing table entry for 22.22.22.22/32, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  6
    3.3.3.3 from 3.3.3.3 (22.22.22.22)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 3 33 333


R1#show ip bgp 22.22.22.22
BGP routing table entry for 22.22.22.22/32, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  6
    3.3.3.3 from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best


Si os habéis fijado bien podéis observar que R1 no tiene la community en la ruta, es simplemente porque R2 no anuncia communities a R1 :).


Otro día veremos mas BGP que alguno ya me lo ha reclamado.