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

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.

Filtrado a nivel 7 con NBAR

NBAR es una tecnología que permite el reconocimiento de aplicaciones y protocolos a nivel de aplicación, sin trabajar tan solo a nivel de puerto como hace un firewall, lo que permite NBAR, es leer a nivel de cabeceras html...etc

Una funcionalidad de seguridad que se le puede dar a NBAR es descartar los paquetes de los protocolos no permitidos.

En este ejemplo vamos a descartar los paquetes de bittorrent, da igual que cambie de puerto el bittorrent, NBAR se basa en patrones de tráfico a nivel de aplicación, y descartará el tráfico.

Ejemplo:

class-map match-all TORRENTE
   match protocol bittorrent
policy-map ELIMINAR
  class TORRENTE
   drop 

int fa0/0
    service-policy output ELIMINAR

Lo malo que tienen todo este tipo de trabajos de inspección a nivel 7, es que incurre en una mayor carga de trabajo para el router. Cosa aplicable a cualquier tecnología de este tipo, por lo que se recomienda hacerlo en equipos que no están demasiado justos de CPU y memoria.

Filtrando tráfico con route maps

Quizá el filtrado de tráfico como si fuese una ACL no sea uno de los usos mas habituales para los route maps, pero es que hay que reconocer que los route maps sirven para todo.

El método consiste en crear una ACL ¿WTF? Si, utilidad real tampoco hay mucha, pero estas son las cosas raras que te toca pensar cuando te enfrentas a un examen como el CCIE. Repetimos, creas una ACL en la que estableces el tráfico que quieres descartar, y esa ACL se la pones como clausula match para el route-map, luego como clausula set del route map redireccionas el tráfico a Null0, y aquí paz y después gloria. Probablemente sea un recurso que no vas a usar en tu vida, pero bueno, cosas que pasan .

Este ejemplo es facil, todo el tráfico udp que entra o sale por la interfaz queda denegado, ya que se envía a NULL0.

ip access-list extended NO_QUIERO_UDP
    permit udp any any
 
route-map UDP_TRASH permit 10
 match ip address NO_QUIERO_UDP
 set interface Null0
interface FastEthernet 0/0
  ip policy route-map UDP_TRASH

Ojo, existe una posible pifia que he visto cometer, y es que como en los route maps que se aplican en BGP hay que añadir una sentencia permit x para que el resto de rutas se anuncien, en ocasiones cuando los route maps se usan para filtrar, o para PBR se añade esta sentencia, que no es necesaria, ni tampoco recomendada. Si añadimos una sentencia route map UDP_TRASH 20 permit,  lo que pasaría es que todo el tráfico de la interfaz fa0/0 subiría a procesadora, y en caso de los equipos grandes como un 7600/6500 no estaríamos aprovechando la funcionalidad que ofrece la tarjeta. El efecto práctico sería una subida enorme del consumo de CPU como esa tarjeta tenga bastante tráfico.