[lacnog] Cisco route-maps and route-policy
Rogerio Mariano
rogermariano.cala en yahoo.com
Sab Abr 23 00:48:15 BRT 2016
Hola Tomas,
El route-map en el IOS XR se llama RPL (Route Policy Language) y se puede hacer de dos maneras, una por la XR CLI o la otra por Shell el QNX usando python o rest
En el caso del peer-group que será una sola política, lo que hará que una diferencia es que se puede aplicar esta política por el protocolo concatena su jerarquía de interfaz (por ejemplo, crea un RPL en un peer-group y luego aplicar esta política en la interfaz declarada vecina que dentro de la instancia de OSPF o IS-IS) o en la interfaz física individual. El XR es complejo de entender para aquellos acostumbrados a utilizar estos sistemas monolíticos, pero que ya se utiliza un JunOS o algún sistema BSD no tendrá dificultades para entender su semántica y estructura.
Hice un ejemplo que debe ayudarle, sigue a continuación ...
Sigue un artículo del Xander Thuijs es el gerente de la IOS XR BU y ASR9K en Cisco
https://supportforums.cisco.com/document/88676/asr9000xr-understanding-and-using-rpl-route-policy-language <https://supportforums.cisco.com/document/88676/asr9000xr-understanding-and-using-rpl-route-policy-language>
<<<<< Exemplo Tomas 1 >>>>>>>>>>>>>
ip prefix-list PERMITESUMARIO seq 5 permit 10.0.0.0/8
ip prefix-list PERMITESUMARIO seq 10 permit 172.16.0.0/12
ip prefix-list PERMITESUMARIO seq 15 permit 164.85.0.0/16
ip prefix-list PERMITESUMARIO seq 20 permit 192.168.0.0/16
ip prefix-list PERMITESUMARIO seq 25 deny 10.0.0.0/8 le 32
ip prefix-list PERMITESUMARIO seq 30 deny 172.16.0.0/12 le 32
ip prefix-list PERMITESUMARIO seq 35 deny 164.85.0.0/16 le 32
ip prefix-list PERMITESUMARIO seq 40 deny 192.168.0.0/16 le 32
ip prefix-list PERMITESUMARIO seq 45 permit 0.0.0.0/0 le 32
!
route-map SoO_9999 permit 10
set local-preference 100
set extcommunity soo 33333:9999
!
router bgp 1234
address-family ipv4 vrf tomas
no synchronization
neighbor CE_tomas_M3_M4 peer-group
neighbor CE_tomas_M3_M4 timers 10 30
neighbor CE_tomas_M3_M4 as-override
neighbor CE_tomas_M3_M4 remote-as 33333
neighbor CE_tomas_M3_M4 soft-reconfiguration inbound
neighbor CE_tomas_M3_M4 default-originate
neighbor CE_tomas_M3_M4 prefix-list PERMITESUMARIO out
neighbor 1.1.1.2 description peering CE-1
neighbor 1.1.1.2 peer-group CE_tomas_M3_M4
neighbor 1.1.1.2 route-map SoO_9999 in
neighbor 1.1.1.2 activate
aggregate-address 10.0.0.0 255.0.0.0
aggregate-address 172.16.0.0 255.240.0.0
aggregate-address 164.85.0.0 255.255.0.0
aggregate-address 192.168.0.0 255.255.0.0
exit-address-family
######################################################
vrf tomas
address-family ipv4 unicast
import route-target
1234:100
!
export route-target
1234:100
!
!
!
!
prefix-set PRFX-DENY-SUMARIO
10.0.0.0/8 le 32,
172.16.0.0/12 le 32,
164.85.0.0/16 le 32,
192.168.0.0/16 le 32
end-set
!
prefix-set PRFX-PERMIT-SUMARIO
10.0.0.0/8,
172.16.0.0/12,
164.85.0.0/16,
192.168.0.0/16
end-set
!
route-policy POL--BGP-M4--OUT
if destination in PRFX-PERMIT-SUMARIO then
done
elseif destination in PRFX-DENY-SUMARIO then
drop
else
done
endif
end-policy
!
route-policy POL--BGP-M4-SOO--IN($soo)
set local-preference 100
set extcommunity soo (33333:$soo)
done
end-policy
!
router bgp 1234
address-family ipv4 unicast
!
address-family vpnv4 unicast
!
neighbor-group CE_tomas_M4
remote-as 33333
timers 10 30
address-family ipv4 unicast
route-policy POL--BGP-M4--OUT out
as-override
default-originate
soft-reconfiguration inbound
!
!
vrf tomas
rd 1234:1
address-family ipv4 unicast
aggregate-address 10.0.0.0/8
aggregate-address 164.85.0.0/16
aggregate-address 172.16.0.0/12
aggregate-address 192.168.0.0/16
!
neighbor 1.1.1.2
use neighbor-group CE_tomas_M4
description peering CE-1
address-family ipv4 unicast
route-policy POL--BGP-M4-SOO--IN(9999) in
!
!
!
!
Saludos,
Rogerio Mariano
> Em 22 de abr de 2016, à(s) 15:39, Tomas Lynch <tomas.lynch en gmail.com> escreveu:
>
> Excelente Javier, es un AND, es verdad. Muchas gracias.
>
>
> Ahora mi siguiente pregunta es sobre XR. En el caso de que el neighbor pertenezca a un peer group donde ambos tienen un route-policy, el policy del neighbor es el único que se aplica. SI quisiera aplicar ambos policies puedo usar el comando " apply $peer-group-policy" dentro del policy del neighbor. Existe alguna manera más fácil de hacer esto?
>
> Gracias,
>
> Tomas
>
> 2016-04-22 14:13 GMT-04:00 Javier Rodriguez <rodriguezsotelo en gmail.com <mailto:rodriguezsotelo en gmail.com>>:
> Tomas,
>
> En ese caso si por ejemplo un anuncio se acepta por el prefix-list del neighbor y el route-map del grupo lo descarta, queda rechazado. En otro caso, si el prefix-list del neighbor descarta y el route-map del grupo acepta, queda descartado. En conclusión hace un AND entre las dos políticas.
> Hugo en "BGP Design and Implementation" de Cisco difiere de información que hay en internet, antepone el filter-list al route-map. De todos modos en el escenario de Tomas no existe filter-list por lo tanto no hay cambios.
> Inbound: filter-list -> Route-Map -> Distribute List/Prefix List
> Si mal no recuerdo de practicas en laboratorio este ultimo orden es el acertado.
>
> Saludos,
>
> Javier I. Rodríguez Sotelo
>
>
> El 22 de abril de 2016, 14:55, Nicolas Antoniello <nantoniello en gmail.com <mailto:nantoniello en gmail.com>> escribió:
> Fe de erratas: debi decir "hereda".
> :)
>
>
> El Friday, April 22, 2016, Tomas Lynch <tomas.lynch en gmail.com <mailto:tomas.lynch en gmail.com>> escribió:
> 2016-04-22 13:32 GMT-04:00 Nicolas Antoniello <nantoniello en gmail.com <>>:
> Hola Tomas,
>
> Mi experiencia si mal no recuerdo es que el peer ereda del peer-group y si hay solapamiento gana el peer... Pero supongo que es OS depndiente eso (asumo que hablas de Cisco).
>
>
> Si definitivamente IOS.
>
>
> Saludos,
> Nico
>
>
> El Friday, April 22, 2016, Tomas Lynch <tomas.lynch en gmail.com <>> escribió:
> Gracias Hugo pero qué pasa cuando el peer group tiene un route map y el peer tiene un prefix list. Se mantiene la misma precedencia?
>
> On Apr 22, 2016 12:43 PM, "Zamora López Hugo" <HZAMORA en reduno.com.mx <>> wrote:
> Tomas,
>
>
>
> For inbound updates, the order of precedence is route-map, filter-list, prefix-list, distribute-list
>
>
>
> For outbound updates, the order of precedence is prefix-list, distribute-list, filter-list, route-map
>
>
>
> Saludos.
>
>
>
> Hugo Zamora
>
>
>
> De: LACNOG [mailto:lacnog-bounces en lacnic.net <>] En nombre de Tomas Lynch
> Enviado el: Viernes, 22 de Abril de 2016 11:07 a.m.
> Para: Latin America and Caribbean Region Network Operators Group
> Asunto: [lacnog] Cisco route-maps and route-policy
>
>
>
> Estimados,
>
> Heredé, por decirlo de alguna manera, una red que tiene varios peers de BGP.
>
> Todos están agrupados en distintos peer groups y estos peer-groups tienen sus políticas de entrada y salida. Algunos neighbors tienen una prefix list en particular. Sigue un ejemplo:
>
> neighbor eBGP-Group route-map OUTPUT out
> neighbor eBGP-Group route-map INPUT in
> !
>
> neighbor 1.1.1.1 peer-group eBGP-Group
>
> neighbor 1.1.1.1 prefix-list CUALQUIERA in
>
> Mi pregunta es si el neighbor 1.1.1.1 primero analiza la prefix-list y luego el route-map INPUT o si lo hace al revés por la precendencia del route-map en los inbound policies o si simplemente no toma en cuenta el route-map.
>
> Muchas gracias,
>
> Tomas Lynch
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net <>
> https://mail.lacnic.net/mailman/listinfo/lacnog <https://mail.lacnic.net/mailman/listinfo/lacnog>
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog <https://mail.lacnic.net/mailman/options/lacnog>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net <>
> https://mail.lacnic.net/mailman/listinfo/lacnog <https://mail.lacnic.net/mailman/listinfo/lacnog>
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog <https://mail.lacnic.net/mailman/options/lacnog>
>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
> https://mail.lacnic.net/mailman/listinfo/lacnog <https://mail.lacnic.net/mailman/listinfo/lacnog>
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog <https://mail.lacnic.net/mailman/options/lacnog>
>
>
>
>
> --
> Atte.
>
> Javier I. Rodríguez Sotelo
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
> https://mail.lacnic.net/mailman/listinfo/lacnog <https://mail.lacnic.net/mailman/listinfo/lacnog>
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog <https://mail.lacnic.net/mailman/options/lacnog>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20160423/d9aa34e1/attachment.html>
Más información sobre la lista de distribución LACNOG