Algoritmo de selección de la mejor ruta
- Weight (Atributo propietario de Cisco, Default 32768 para rutas originadas localmente, más alto,mejor).
- Local Preference (Default 100, más alto, mejor).
- Preferir Rutas Locales (originadas con network o redistribute sobre las agregadas con aggregate-address).
- AS-PATH (Más corto, mejor).
- Origen IGP sobre origen EGP sobre origen Incomplete (IGP es cuando se publican con comando network, Incomplete por redistribución).
- MED Elegir el camino con menor Multi Exit Discriminator (Default 0, como toda métrica, menor es mejor).
- Preferir eBGP sobre iBGP
- Preferir menor métrica del IGP al nexthop BGP
- Ruta más vieja Si las rutas son externas, elegir la que se recibió primero (la más estable).
- Menor router-id de BGP
- Menor IP de neighbor
¿Por qué no aparecen las rutas en la tabla?
- Las rutas están marcadas como no sincronizadas en la salida del comando show ip bgp longer-prefixes.
Si la
sincronización está habilitada, debe existir un prefijo exacto en la tabla de
rutas para que un path iBGP sea considerado válido. Dicha
sincronización está habilitada por defecto en Cisco IOS®. Si la ruta es aprendida desde un neighbor OSPF, el OSPF router ID debe ser el mismo
que el router-id de BGP del neighbor iBGP. Se puede desactivar con el comando:
sincronización está habilitada por defecto en Cisco IOS®. Si la ruta es aprendida desde un neighbor OSPF, el OSPF router ID debe ser el mismo
que el router-id de BGP del neighbor iBGP. Se puede desactivar con el comando:
no synchronization
Synchronization está deshabilitado por default en los
release 12.2(8)T de Cisco IOS y posteriores.
- Las rutas tienen un NEXT_HOP inaccesible.
Recordar que
es deseable tener una ruta estática como /32 hacia el NEXT_HOP que
publica el neighbor.
- Rutas son publicadas por un neighbor eBGP en donde el AS local figura en el AS-PATH. (Prevención de loops).
- Si está habilitado bgp enforce-first-as y el UPDATE no contiene el AS del neighbor como el primer AS en la AS_SEQUENCE.
- El neighbor utiliza iBGP y no va a enviarme las rutas que aprenda por iBGP desde otro neighbor. Ver iBGP reflectors.
Configuración básica de un neighbor
Es deseable que los vecinos tengan estas configuraciones
mínimas:
!El AS del lado remoto debe estar definido.
neighbor 1.2.3.4 remote-as 65530
!No negociar version hace que el peer levante más rápido.
neighbor 1.2.3.4 version 4
!Dar una amplia descripción del peering, que sea lo más completa posible.
neighbor 1.2.3.4 description #Empresa# - #Sitio# - #TelefonoDelSoporte# - #NroDeEnlace# - #PersonaResponsable#
!Hacer el peering contra un aloopback siempre que sea posible.
neighbor 1.2.3.4 update-source Loopback0
!Habilitar multihop para sesiones eBGP si es que usamos una loopback.
neighbor 1.2.3.4 ebgp-multihop 10
!Autenticar el peering.
neighbor 1.2.3.4 password 53kr3TMuyD1f1C1L
!Guardar una copia de los updates recibidos por si queremos actualizar los filtros sin bajar el peer.
neighbor 1.2.3.4 soft-reconfiguration inbound
!Limitar la cantidad de prefijos aceptados por el peer. Avisar cuando llegue al 90%.
neighbor 1.2.3.4 maximum-prefix 100 90
!Activar el neighbor en el AFI si es que tenemos configurado no bgp default ipv4-unicast
neighbor 1.2.3.4 activate
Cosas que deberíamos tener en cuenta:
- Habilitar Non StopForwarding.
- No deben llegar nuestros prefijos por eBGP, ni aunque sean más específicos.
- Hay más de 300.000 rutas en la tabla mundial, tratá de publicar prefijos grandes (/24 como máximo).
- No publicar bogons ni IP’s privadas (rfc1918).
- Las AS-PATH Access List son tus amigas, usalas.
- Las communities son amigas de las AS-PATH ACL, por ende también son tus amigas, usalas.
- Está bueno modificar la distancia administrativa de eBGP para que sea peor que tu IGP.
- Es preferible usar un ADVERTISE-MAP antes que inundar el mundo con AS-PATH prepends.
- Siempre usar bgp dampening.
- El resto del mundo va a usar dampening sobre vos!!!.
- Aplicar communities a la entrada para identificar rutas de cada proveedor.
- Un route-map con description vale más que mil comandos show.
- No redistribuir nunca BGP en IGP.
- No redistribuir nunca IGP en BGP.
- Si inevitablemente se redistribuye IGP en BGP, hacer un route-map con filtrado adecuado y set origin igp.
- Siempre usar límites de largo de AS-PATH.
¿En qué orden se aplican los filtros en IOS?
El orden de preferencia varía de acuerdo a los atributos que
son aplicados para updates entrantes o salientes.
Para updates entrantes:
- route-map
- filter-list
- prefix-list, distribute-list
Para updates salientes:
- prefix-list, distribute-list
- filter-list
- route-map
Los
prefix-list y distribute-list son mutualmente excluyentes, y solo un comando (neighbor
prefix-list o neighbor distribute-list) puede ser aplicado en cada
dirección entrante o saliente para un neighbor en particular.
Obviamente, en lo posible usar route-map dado que es
una herramienta más poderosa.
Acerca de los prefix-list:
Un ACL
normal no puede chequear la máscara de una red. Solamente puede chequear bits
para asegurar una coincidencia, nada más.
Un prefix-list tiene la ventaja sobre un ACL, puede chequear ambas cosas: bits y máscara de red; Ambos deben coincidir paraque la red sea permitida o denegada.
Si existe únicamente un / despues de la red (no hay le o ge) entonces se chequea la máscara de red y el número que sigue a la /.
Un prefix-list tiene la ventaja sobre un ACL, puede chequear ambas cosas: bits y máscara de red; Ambos deben coincidir paraque la red sea permitida o denegada.
Si existe únicamente un / despues de la red (no hay le o ge) entonces se chequea la máscara de red y el número que sigue a la /.
ip prefix-list test permit 192.168.1.0/24
Entonces en este caso se van a chequear los 24 bits de
izquierda a derecha (no importan los últimos 8) Y también se va a chequear que
la máscara de red sea de 24 bits. Ambas cosas deben ser ciertas para que se
permita la red.
Ahora bien, podemos ser permisivos en cuanto a la máscara de red:
Ahora bien, podemos ser permisivos en cuanto a la máscara de red:
ip prefix-list test permit 192.168.1.0/24 ge 25
Si usamos el le o ge (o ambos) después de la
/, entonces vamos a chequear los 24 bits de la red de izquierda a derecha. Si
eso coincide entonces matcheamos la máscara de red, que en este caso puede ser mayor
o igual que 25 bits.
Mientras los primeros 24 bits de la red coincidan bit a bit,
la máscara puede ser /25, /26, /27, /28,/29, /30, /31, o /32.
En el ejemplo:
ip prefix-list test permit 192.168.1.0/24 le 28
Si los primeros 24 bits coinciden bit a bit, la máscara debe
ser menor o igual a 28, pero a partir del /24 definido.
Mientras los primeros 24 bits de la red coincidan bit a bit,
la máscara puede ser /24, /25, /26, /27 o /28.
ip prefix-list test permit 192.168.1.0/24 ge 25 le 28
Obviamente nos da que deben coincidir los primeros 24 bits
de la red 192.168.1.0 con una máscara de /25, /26, /27 o /28.
No hay comentarios:
Publicar un comentario