PDF de programación - Implementando BGP

Implementando BGP

José A. Domínguez

<[email protected]>

University of Oregon

Programa

 Uso de atributos de BGP
 Implementando IBGP
 Implementando EBGP
 Enfasis en Estabilidad, Escalabilidad

y Ejemplos de Configuraciones

Repaso de BGP

Por qué utilizarlo?

3

Resultado Deseado?

 Implementación de políticas de

enrutamiento que sean:
 Escalable
 Estable
 Simple (o eso esperamos!)

Más Detalles...

 Necesitas escalar su IGP
 Eres un cliente con dos conexiones a ISPs
 Necesitas transitar todas las rutas en

Internet

 Necesitas implementar una politica de

enrutamiento, o expandir las políticas de QoS

Actualizaciones de BGP

Retiros
Retiros

Atributos
Atributos

Prefijos
Prefijos

(NLRI - Network-Layer
(NLRI - Network-Layer

Reachability Information)
Reachability Information)

Atributos de BGP Utilizados
para Definir la Política de
Enrutamiento

1: ORIGIN
1: ORIGIN
2: AS-PATH
2: AS-PATH
3: NEXT-HOP
3: NEXT-HOP
4: MED
4: MED
5: LOCAL_PREF
5: LOCAL_PREF
6: ATOMIC_AGGREGATE
6: ATOMIC_AGGREGATE

 7: AGGREGATOR
 7: AGGREGATOR
 8: COMMUNITY
 8: COMMUNITY
 9: ORIGINATOR_ID
 9: ORIGINATOR_ID
 10: CLUSTER_LIST
 10: CLUSTER_LIST
 14: MP_REACH_NLRI
 14: MP_REACH_NLRI
 15: MP_UNREACH_NLRI
 15: MP_UNREACH_NLRI

BGP Externo (eBGP)

•Entre router en AS diferentes
•Usualmente con conexióm directa
•Con next-hop apuntando a si mismo

131.108.0.0

 Router B

AS 109

.1

A

router bgp 110
neighbor 131.108.10.1 remote-as 109

131.108.10.0
131.108.10.0

 Router A

router bgp 109
neighbor 131.108.10.2 remote-as 110

150.10.0.0

.2

B

AS 110

BGP Interno
• Vecinos en el mismo AS
• No se modifica el Next-hop
• No necesariamente con
conexión directa
• No anuncia otras rutas
aprendidas por iBGP

 Router B:

A

B

router bgp 109
neighbor 131.108.30.2 remote-as 109

 Router A:

router bgp 109
neighbor 131.108.20.1 remote-as 109

Atributos de BGP: NEXT_HOP

EBGP—next-hop set to self

150.10.1.1 150.10.1.2

AS 200
150.10.0.0/16

DDD

AS 300

FF

EE

150.1.1.1

CC

192.0.0.0/24 150.1.1.3

150.1.1.2

BB

AS 301

3rd Party EBGP

150.1.1.3

150.10.0.0/16 150.10.1.1
192.0.0.0/24 150.10.1.1

IBGP next-hop unmodified

AA
AS 201
192.0.0.0/24

Modificando los defaults:

Solo para EBGP NLRI:
neighbor x.x.x.x next-hop-self

Modificando con route-map:
set ip next-hop { A.B.C.D | peeraddress}

Problema: Detección de Loop,
Políticas
Solución: AS-PATH

 Secuencia de ASs

Lista de AS por los que la
ruta ha pasado

 Conjunto de AS (AS Set)
Sumariza la secuencia de
ASs
El order de la secuencia
se pierde

 Prefijo con route-map:

set as-path

1883

193.0.32/24

AA

1880

193.0.34/24

D

EEE

1881

193.0.33/24

BB

1882

193.0.35/24

CC

A: 193.0.33/24 1880 1881
A: 193.0.33/24 1880 1881
B: 193.0.34/24 1880
B: 193.0.34/24 1880
C: 193.0.32/24 1880 1883
C: 193.0.32/24 1880 1883
E: 193.0.32/22 1880 {1881, 1882,1883}
E: 193.0.32/22 1880 {1881, 1882,1883}

Problema: Indicar mejor camino a AS
Solución: MED

690

200

1755

1880

1883

209

 Informa sobre la preferencia de punto de entrada
 Se compara si los caminos son del mismo AS

A no ser que se us “bgp always-compare-med”

 Es un atributo no-transitivo
set metric
 route-map:
set metric-type internal

Problema: Sobrepasando As-
path/MED?
Solución: LOCAL PREFERENCE

690

680

1755

1880

660

 Atributo es local al AS — mandatorio para las

actualizaciones de iBGP

 route-map: set local-preference

Problema: Sobrepasando Local
Preference
Solución: WEIGHT

690

666

1755

1880

660

 Local al router en que es configurado
 route-map: set weight
 El mayor peso (weight) gana sobre todos los caminos

válidos

Problema: Escalando Políticas de
Enrutamiento
Solución: COMMUNITY

Communities:
Communities:

1:100—customer routes
1:100—customer routes

1:80—peer routes
1:80—peer routes

Match Community
1:100 1:80

Set Community

1:80

CORE

Peer A

Match Community

1:100

Match Community
1:100

Set Community

1:100

Cliente A

Cliente B

Todas las rutas

Rutas de Clientes

Atributo de BGP: COMMUNITY
 Agrupa los destinos para ayudar a

escalar la aplicación de políticas

 Comunidades Típicas:

 Destinos aprendidos de los clientes
 Destinos aprendidos de los peers
 Destinos en la VPN
 Destinos que reciben tratamiento

preferencial en la cola

Atributos de BGP:
COMMUNITY

 Activación por neighbor/peer-group:

 neighbor {peer-address | peer-group-name}

send-community

 Transferidos a través de ASs
 Formato común es una cadena de 4

bytes: <AS>:[0-65536]

Atributos de BGP:
COMMUNITY (Cont.)

 Cada destino puede ser miembro de varias

comunidades

 Route-map: set community
<1-4294967295> número de comunidad
aa:nn
additive
local-AS
no-advertise No enviar a ningún peer (well-known community)
no-export No exportar fuera del AS/Conf. (well-known community)
none

número de comunidad en formato aa:nn
Añade a una comunidad existente
No enviar a los peers EBGP (well-known community)

No atributo de comunidad

Atributo de menor uso:
ORIGIN

 IGP—creado con comando network en la

configuración de BGP

 EGP—Redistribuido de EGP
 Incomplete—Redistribute IGP en la

configuración de BGP

 NOTA: siempre usar route-map para

modificar: set origin igp

Comando set en un route-map

Añade una cadena de AS para el atributo

set BGP community list (for deletion)

 as-path
AS-PATH
 comm-list
 community Atributo de Comunidad
 dampening Configura parámetros para dampening
 local-preference Atributo de preferencia local de BGP
 metric
enrutamiento
 origin
 weight
 ip next-hop { A.B.C.D | peer-address }

Codigo de origen BGP
Peso BGP para la tabla de enrutamiento

Valor Metric para el protocolo de

Atributos de BGP

75k1#sh ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/24, version 139267814
Paths: (1 available, best #1)
Not advertised to any peer
as

! AS-PATH

AS

ID

65000 64000 {100 200}, (aggregated by 64000 16.0.0.2)

! NEXT-HOP IGP METRIC

PEER-IP PEER-ID
10.0.10.4 (metric 10) from 10.0.0.1 (10.0.0.2)
Origin IGP, metric 100, localpref 230, valid, aggregated
internal (or external or local),
atomic-aggregate, best
Community: 64000:3 100:0 200:10
Originator: 10.0.0.1, Cluster list: 16.0.0.4, 16.0.0.14

Algoritmo Básico Para Decidir
Considera solo las rutas sincronizadas sin referencia
circular y un next-hop válido, entonces prefiere:

Mayor WEIGHT
Mayor LOCAL PREFERENCE
ORIGINADA LOCALMENTE (eg network/aggregate)
Más Corto AS-PATH
Menor ORIGIN (IGP < EGP < incomplete)
Menor MED
EBGP

Menor IGP METRIC al next-hop

IBGP

Sincronización

690

A

1880

B

209

• Router A no anunciará los prefijos de AS209 hasta
que haya convergencia en el IGP.
• Asegurarse de que los next-hops del iBGP pueden
ser vistos via IGP, entonces:

router bgp 1880
no synchronization

Consideraciones Generales

 Sincronización: no requerida si se tiene

una maya iBGP completa

 => No dejar que BGP tenga prioridad

sobre IGP

 auto-summary: no. En su lugar usar

comandos de agregación:

router bgp 100
no synchronization
no auto-summary
distance 200 200 200

Hasta Ahora …

 Aplicar las políticas en base al AS
 Agrupar las rutas usando comunidades
 Seleccionar los puntos de entrada y salida

para grandes grúpos de políticas usando
MEDs y preferencia local

Pueden tús políticas escalar?

Implementando iBGP

Route Reflectors, Peer Groups

26

Guías para un iBGP Estable

 Establecer la conexión usando direcciones de

loopback
 neighbor { ip address | peer-group}



update-source loopback0

 Independiente de fallos de la interfase física
 Balanceamiento de la carga es realizado por el

IGP

Guía Para Escalar iBGP

 Usar peer-group y route-reflector
 Solo llevar next-hop en el IGP
 Solo llevar todas las rutas en BGP si es

necesario

 No redistribuir BGP en el IGP

Usando Peer-Groups

iBGP Peer Group

eBGP

Peer Group
con todas
las rutas

Peer Group
“Default”

Peer Group

Rutas de
Clientes

Qué es un peer-group?

 Todos los miembros del peer-group
tienen una política de salida común
 Actualizaciones generadas solo una

vez para el peer-group

 Simplifica la configuración
 Miembros pueden tener diferentes

políticas de entrada

Por qué usar Route-
Reflectors?

Para evitar una maya con
N(n-1)/2 sesiones

13 Routers =>
78 Sesiones

iBGP!

n=1000 => casi
medio millón de
sesiones iBGP!

Usando Route-Reflectors

Backbone
Backbone

RRRR

Regla para evtar un
circulo de RR:
Topología de RR
debe reflejar la
topología física

RRCRRC

RRRR

Grupo A
Grupo A

RRRR
Grupo C
Grupo C

RRRR

RRC

RR

Grupo B

RRC

RRC

RRRR
Grupo D
Grupo D

Qué es un Route-Reflector?

 El Reflector recibe información de

clientes y no clientes

 Si el mejor camino es de un cliente,

reflejarlo a clientes y no clientes

 Si el mejor camino es de no-cliente,

reflejarlo a los clientes

Desplegando Route-Reflectors

 Divida el backbone en varios grupos
 Cada grupo contiene al menos 1 RR

(multiples para redundancia), y multiples
clientes

 Los RRs crean una maya completa de iBGP
 Utilizar solo un IGP—next-hop que no es

modificado por el RR

Route-Reflector Jerárquico

RR

Router id
140.10.1.1

141.153.30.1

A

 Ejemplo:

B

RouterB>sh ip bgp 198.10.0.0
BGP routing table entry for 198.10.10.0/24
3
141.153.14.2 from 141.153.30.1 (140.10.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best

C

Router id
141.153.17.2

RRC Router id

141.153.17.1
RR

RRC
D

141.153.14.2

Originator: 141.153.17.2
Cluster list: 144.10.1.1, 141.153.17.1

AS3

198.10.0.0

Atributos de BGP:
ORIGINATOR_ID

 ORIGINATOR_ID

 Router ID del vecino iBGP qye refleja rutas

del cliente RR a no clientes

 Sobrepasado por: bgp cl