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.
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 /.
ip prefix-list test permit 192.168.1.0/24Entonces 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:
ip prefix-list test permit 192.168.1.0/24 ge 25Si 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 28Si 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 28Obviamente 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.
0 comentarios:
Publicar un comentario