Mostrando entradas con la etiqueta route maps. Mostrar todas las entradas
Mostrando entradas con la etiqueta route maps. Mostrar todas las entradas

jueves, 23 de marzo de 2017

BGP: Filtrar por tamaño de la red en BGP, he ahí el dilema

Introducción
 El equipo de I+D del área técnica y WARP redactaron en conjunto el presente artículo basado en algunos incidentes gestionados por el centro de respuestas de LACNIC.
 En el mundo de BGP existen decenas de maneras para filtrar prefijos. El objetivo del presente post mostrar una serie de recomendaciones para tener una red más estable, no perder conectividad con ciertos destino y reducir el número de quejas en nuestro NOC.
Situación identificada
  Muchos ISPs no pueden recibir la full routing table de BGP (para el dia de hoy consta de ~610.000 prefijos IPv4) en sus enrutadores.
  Lo anterior puede deberse a diversas razones:
  • El enrutador no posee suficiente RAM para aprender todos los prefijos (además recordar que es posible que el router tenga varias sesiones BGP)
  • Por ahorro de CPU
  • Porque el upstream provider a su vez no entrega toda la tabla de enrutamiento
  • Por simplicidad y sencillez
 Entendiendo la situación e independientemente de la razón que sea, el enrutador no aprende toda la tabla de enrutamiento.
Problema
  No aprender toda la tabla de enrutamiento puede traer algunos inconvenientes parciales pero que al final trae problemas de conectividad, quejas de los usuarios, inconvenientes de acceso a ciertos sitios, entre otros.
¿Por qué?
  Imaginemos la siguiente situación:
  1. Tengo un router (propiedad de EXAMPLE) en Internet que solo aprende la tabla parcial de enrutamiento
  2. El router propiedad de EXAMPLE quedó configurado solo para aprender redes “más grandes” que /21. Es decir, aprende redes /20, /19, /18, etc.  (evidentemente estamos hablando de IPv4)
  3. Debido a la configuración establecida en el punto “b”, el router no aprenderá prefijos de tamaño /21, /22, /23 ni /24
  4. Mientras tanto en otra parte del mundo, le acaban de secuestrar su red /21 a la empresa ACME (planteamos el caso como un secuestro pero podría ser una mala configuración)
  5. ACME decide realizar anuncios más específicos de su red original /21, es decir, anuncia 8 redes /24
  6. Por causa de los filtros configurados por EXAMPLE, nunca verá dichos anuncios /24 de ACME
  7. EXAMPLE seguirá aprendiendo la red /21 del secuestrador de la red. Lo que puede ocasionar que el tráfico hacia ACME puede ser potencialmente secuestrado (repito, se entiende que esta situación es potencial, no necesariamente el tráfico irá hacia el atacante)
Diagrama:
  El siguiente diagrama representa la hipótesis planteada en el punto anterior de manera gráfica para facilitar su comprensión.
Articulo BPG.png
Recomendación
 Realizaremos la siguiente recomendación en base a algunas experiencias vividas, teniendo en cuenta que solo aplican al caso de cuando no se pueda aprender/recibir la tabla completa de BGP:
  1. No filtrar permitiendo redes menos específicas. Es conveniente aprender redes más chicas, es decir: /24, /23, /22.
  2. Filtrar por AS_PATH de profundidad.
  3. Crear los ROAs respectivos a los prefijos (RPKI).
Algunos ejemplos (Cisco like)
1)  Solo queremos aprender redes entre /22 y /24 (hay otras maneras de hacer esto):
router bgp 65002
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.1 route-map FILTRO-IN in
!
ip prefix-list REDESCHICAS seq 5 permit 0.0.0.0/0 ge 22 le 24
!
route-map FILTRO-IN permit 10
match ip address prefix-list REDESCHICAS
!
2) Solo queremos aprender dos AS de profundidad (hay otras maneras de hacer esto):
router bgp 65001
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 route-map ASFILTER-IN in
!
ip as-path access-list 5 permit ^[0-9]+_$
ip as-path access-list 5 permit ^[0-9]+ [0-9]+_$
!
route-map ASFILTER-IN permit 10
match as-path 5
!
Mas información

Autores
- Dario Gomez
- Alejandro Acosta (@ITandNetworking)
en No hay comentarios:
Etiquetas: , , , , , , ,

lunes, 10 de febrero de 2014

Configurando Quagga para manipular prefijos (Local Preference) utilizando RPKI

Objetivo:
   En el siguiente mini laboratorio configuraremos Quagga para manipular prefijos BGP y asignar Local Preference segun el estado RPKI (valid, invalid, Not Found).
 
Escenario:
- R1 publica un prefijo con un AS que no le corresponde (segun ROA)
- R2 publica el mismo prefijo que R1 pero desde un AS que si es valido
- R2 publica un prefijo sin ROA.
- En este escenario el validador y el router Quagga estan en el mismo equipo

Diagrama del laboratorio:




 Requisitos:
- Quagga con soporte para RPKI
- RPKI Validator de RIPE NCC
- Un prefijo que sepamos que se tiene ROA valido. En nuestro caso utilizamos el prefijo 200.85.64.0 que sabiamos que tiene un ROA que indica que debe ser publicado por el AS 7908
- Ejecutar el validador de RIPE NCC antes de ejecutar Quagga


Configuraciones de todos los equipos

Conf-Quagga-RPKI-Mini-LAB.txt

hostname RPKI-RTR
password test
!
router bgp 65000
 bgp router-id 10.0.0.10
 bgp bestpath prefix-validate allow-invalid
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 route-map rpki in
 neighbor 10.0.0.2 remote-as 7908
 neighbor 10.0.0.2 route-map rpki in
 neighbor 10.0.0.3 remote-as 65003
 neighbor 10.0.0.3 route-map rpki in
!
route-map rpki permit 10
 match rpki invalid
 set local-preference 10
!
route-map rpki permit 20
 match rpki valid
 set local-preference 30
!
route-map rpki permit 30
 match rpki notfound
 set local-preference 20
!        
line vty
!
enable-rpki
  rpki polling_period 1000
  rpki timeout -1216757171
!
  rpki group 1
    rpki cache 127.0.0.1 8282
!

R1.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
enable password test
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.1 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 password test
 login
!
end

R2.cfg

!
!
!
!
hostname R2
!
no ip domain lookup
no ip icmp rate-limit unreachable
ip tcp synwait 5
!
!
interface Ethernet0
 ip address 10.0.0.2 255.255.255.0
 half-duplex
!
!
router bgp 7908
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
!
line con 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
line aux 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
!
!
end

R3.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.3 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65003
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 192.168.0.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
end



Salida final en Quagga:
(Notese los flags N, I, V) (Notese los local preference)

RPKI-RTR# sh ip bgp
BGP table version is 0, local router ID is 10.0.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
N*> 192.168.0.0      10.0.0.3                 0     20      0 65003 i
I*  200.85.64.0      10.0.0.1                 0     10      0 65001 i
V*>                  10.0.0.2                 0     30      0 7908 i

Total number of prefixes 2



en No hay comentarios:
Etiquetas: , , , , , , ,

viernes, 22 de febrero de 2013

Publicar prefijos IPv4 sobre una sesión eBGP IPv6

Situación:
  Deseo publicar redes/prefijos IPv4 sobre una sesión eBGP en IPv6

Historia:
  A pesar de no ser común este caso pueden ocurrir en algunas situaciones.

Solución:
  Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6/IPv4). Por ello es posible intercambiar información IPv4 dentro de una sesión eBGP IPv6.

Configuración:
  En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R2 lo aprenda R1).


R1:
!
interface Ethernet0
 ip address 22.22.22.21 255.255.255.252
  ipv6 address 2001:DB8::1/64
!        
router bgp 1
 bgp log-neighbor-changes
 neighbor 2001:DB8::2 remote-as 2
 neighbor 2001:DB8::2 ebgp-multihop 3
 !       
 address-family ipv4
 neighbor 2001:DB8::2 activate
 neighbor 2001:DB8::2 route-map IPv4 in
 no auto-summary
 no synchronization
 exit-address-family

!      
route-map IPv4 permit 5
 set ip next-hop 22.22.22.22
! 
R2:
!
 interface Ethernet0
 ip address 22.22.22.22 255.255.255.252
 half-duplex
 ipv6 address 2001:DB8::2/64
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 2001:DB8::1 remote-as 1
 neighbor 2001:DB8::1 ebgp-multihop 3
 !       
 address-family ipv4
 neighbor 2001:DB8::1 activate
 no auto-summary
 no synchronization
 network 2.2.2.0 mask 255.255.255.0
 exit-address-family
!        

 








"El truco":
  * La sesión eBGP debe ser obligatoriamente multihop, sino, R1 no aprenderá la ruta. Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!). 
  * En R1 quien aprende la ruta debe tener un route-map aplicado cuando aprende las mismas (in) forzando el next-hop con la dirección IPv4 de R2

Mas información:
- http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-mptcl-bgp.html#GUID-06407EF3-4FAD-4519-A2A9-6CC6037288C0
- Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco




Espero sea útil!
en No hay comentarios:
Etiquetas: , , , , , , ,

domingo, 17 de febrero de 2013

Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco

Situación:
  Deseo publicar redes/prefijos IPv6 sobre una sesión eBGP en IPv4

Historia:
  A pesar de no ser común este caso pueden ocurrir en algunas situaciones. En esta oportunidad, tengo un router Cisco con soporte IPv6 (routing) pero su configuración BGP no permite definir neighbors IPv6

Error:
  Mensaje que quizás estas recibiendo y el mismo te trajo a esta página  :)

*Mar  1 02:05:00.663: BGP: 1.1.1.1 Advertised Nexthop ::FFFF:1.1.1.1: Non-local or Nexthop and peer Not on same interface
*Mar  1 02:05:00.663: BGP(1): 1.1.1.1 rcv UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, originator 0.0.0.0, path 1, community , extended community
*Mar  1 02:05:00.667: BGP(1): 1.1.1.1 rcv UPDATE about 2001:db8::/32 -- DENIED due to:
*Mar  1 02:05:00.667: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar  1 02:05:00.771: BGP(0): 1.1.1.1 computing updates, afi 0, neighbor version 0, table version 25, starting at 0.0.0.0

Solución:
  Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6). Por ello es posible intercambiar información IPv6 dentro de una sesión eBGP IPv4.

Configuración:
  En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R1 lo aprenda R2).


R1:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::1/64
 ipv6 enable
!
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 1.1.1.2 remote-as 2
 neighbor 1.1.1.2 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.2 activate
 network 2001:db8::/32
 no synchronization
 redistribute static
 exit-address-family
!
ipv6 route 2001:db8::/32 Null0


R2:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::2/64
 ipv6 enable
!
router bgp 2
 no synchronization
 bgp router-id 1.1.1.2
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.1 activate
 neighbor 1.1.1.1 route-map IPv6-NextHop in
 exit-address-family
!
route-map IPv6-NextHop permit 10
 set ipv6 next-hop 2001:db8::1
!

"El truco":
  * La sesión eBGP debe ser obligatoriamente multihop, sino, R2 no aprenderá la ruta (el mismo error que se ve arriba). Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!). 
  * En R2 quien aprende la ruta debe haber un route-map aplicado cuando aprende las rutas (in) forzando el next-hop con la dirección IPv6 de R1

Después de aplicar ebgp-multihop (todo funciona):

*Mar  1 02:01:42.539: BGP(1): 1.1.1.1 rcvd UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, path 1
*Mar  1 02:01:42.539: BGP(1): 1.1.1.1 rcvd 2800:26::/32
*Mar  1 02:01:42.543: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar  1 02:01:42.543: BGP(1): Revise route installing 2001:db8::/32 -> 2001:db8::1 (::) to main IPv6 table

Mas información:
- https://supportforums.cisco.com/docs/DOC-21110
- http://ieoc.com/forums/p/15154/130174.aspx
- http://ieoc.com/forums/p/15154/130174.aspx


Espero sea útil!
en No hay comentarios:
Etiquetas: , , , , , ,

viernes, 12 de junio de 2009

Policy Based Routing, HSRP y redundancia. Cisco

Necesidad
Contar con dos routers y una dirección IP en Standby (HSRP), donde ciertas redes origen enrutarlas por el Carrier A y otras redes por el Carrier B, sin embargo en caso de fallar algún proveedor funcione la redundancia.
En el caso descrito anteriormente no se puede utilizar un protocolo de enrutamiento dinámico porque se desea enrutar por dirección fuente. Por otro lado, si pueden existir otros modos de realizar esta tarea.

Escenario

2 Router Cisco 1841
2 Enlaces WAN
HSRP
Redes a enviar por el Carrier 1:
10.1.0.0 0.0.255.255
192.168.30.0 0.0.0.255
Redes a enviar por el Carrier 2:
10.144.192.0 0.0.15.255

Diagrama





Procedimiento

Lo primero que haremos es configurar la parte de HSRP. Para ello utilizaremos la siguiente configuración:

En RTR-1
interface FastEthernet0/0
description TO-LAN
ip address 10.1.1.207 255.255.0.0
standby 1 ip 10.1.1.206
standby 1 timers 1 5
standby 1 priority 110
standby 1 preempt
standby 1 authentication CISCO
standby 1 track 1 decrement 20

En RTR-2
interface FastEthernet0/0
description TO-LAN
ip address 10.1.1.204 255.255.0.0
standby 1 ip 10.1.1.206
standby 1 timers 1 5
standby 1 preempt
standby 1 authentication CISCO

Con la configuración anterior tendremos en RTR-1 el IP 10.1.1.207 y en RTR-2 el IP 10.1.1.204. El IP virtual es el 10.1.1.206

2) Indicarle a cada router como alcanzar la WAN del router contrario e indicarles las listas de acceso:

En RTR-1
ip route 10.0.0.1 255.255.255.255 10.1.1.204
access-list 120 REMARK Por el carrier 1
access-list 120 permit ip 10.1.0.0 0.0.255.255 any
access-list 120 permit ip 192.168.30.0 0.0.0.255 any

access-list 121 REMARK Por el carrier 2
access-list 121 permit ip 10.144.192.0 0.0.15.255 any

En RTR-2
ip route 172.16.100.225 255.255.255.255 10.1.1.207
access-list 120 REMARK Por el carrier 1
access-list 120 permit ip 10.1.0.0 0.0.255.255 any
access-list 120 permit ip 192.168.30.0 0.0.0.255 any

access-list 121 REMARK Por el carrier 2
access-list 121 permit ip 10.144.192.0 0.0.15.255 any

3) Es necesario habilitar SLA (Service Level Agreement) y tracks en los routers para mantener el monitoreo vía ping de los enlaces WAN en cada router. Esto es necesario para que a través de PBR los route-maps puedan tomar la decisión de por donde enrutar los paquetes.

En RTR-1

ip sla monitor 2
type echo protocol ipIcmpEcho 172.16.100.225
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 2 life forever start-time now

ip sla monitor 3
type echo protocol ipIcmpEcho 10.0.0.1
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 3 life forever start-time now

track 2 rtr 2 reachability
track 3 rtr 3 reachability

En RTR-2

ip sla monitor 2
type echo protocol ipIcmpEcho 10.0.0.1
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 2 life forever start-time now

ip sla monitor 3
type echo protocol ipIcmpEcho 172.16.100.225
timeout 1000
threshold 50
frequency 3
ip sla monitor schedule 3 life forever start-time now

track 2 rtr 2 reachability
track 3 rtr 3 reachability

En el ejemplo anterior, en ambos routers se estan monitoreando los IPs WAN vía ping con un timeout de 1000 ms, un umbral de 50 ms cada 3 segundos.

4) Configurar los route-maps en cada router

RTR-1

route-map CARRIER permit 5
match ip address 120
set ip next-hop verify-availability 172.16.100.225 10 track 2
set ip next-hop verify-availability 10.0.0.1 20 track 3

route-map CARRIER permit 10
match ip address 121
set ip next-hop verify-availability 10.1.1.207 10 track 3
set ip next-hop verify-availability 172.16.100.225 20 track 2

RTR-2

route-map CARRIER permit 5
match ip address 121
set ip next-hop verify-availability 10.0.0.1 10 track 2
set ip next-hop verify-availability 10.1.1.207 20 track 3

route-map CARRIER permit 10
match ip address 120
set ip next-hop verify-availability 10.1.1.207 10 track 3
set ip next-hop verify-availability 10.0.0.1 20 track 2


5) Finalmente es necesario aplicar el comando ip policy route-map en la interfaz f0/0 en cada router

#conf termin
(config)#inter f0/0
(config-if)#ip policy route-map CARRIER

Explicación
Ahora bien, vamos a intentar correr esto en frio:
1) El host 10.1.0.100 envia un paquete a la red 192.168.1.0
2) El paquete lo recibe RTR-2 por la interfaz F0/0
3) La politica es aplicada según el route-map CARRIER
4) En RTR-1, el route-map CARRIER identifica la red origen 10.1.0.100 y coloca como next-hop el IP 10.1.0.207
5) Lo recibe la interfaz f0/0 de RTR-1 quien nuevamente aplica la politica CARRIER y sabe que debe enviar el paquete por la interfaz F0/1 con next-hop 172.16.100.225

Ahora bien, vamos a intentar correr esto en frio con el enlace f0/1 caido en RTR-1:

1) El host 10.1.0.100 envia un paquete a la red 192.168.1.0
2) El paquete lo recibe RTR-2 por la interfaz F0/0
3) La politica es aplicada según el route-map CARRIER. El route-map sabe que no puede ser alcanzado el IP 172.16.100.225 gracias a los comandos SLA previamente configurados (el router cada 3 segundos verifica si puede hacerle ping a este IP).
4) El route-map CARRIER identifica la red origen 10.1.0.100 y coloca como next-hop el IP 10.0.0.1

Verificacion
1) Traceroute desde las redes pertinentes
2) #show track 2
3) #show track 3
en 21 comentarios:
Etiquetas: , , ,
Suscribirse a: Entradas (Atom)

Una propuesta inesperada dentro de IETF – Ethernet sobre HTTPS

En el presente post quiero hablar mayormente sobre un documento con poco tiempo en IETF llamado “Ethernet sobre HTTPS”. Debo confesar que su...