[lacnog] Cisco route-maps and route-policy
Tomas Lynch
tomas.lynch en gmail.com
Dom Abr 24 17:15:45 BRT 2016
Rogerio,
Muchas gracias por el ejemplo. Lo que yo estoy buscando es qué pasa si el
grupo tiene una política in y el peer también. ¿Tengo alguna forma aparte
del "apply" en heredar la política del grupo? Esto es como lo resolví:
neighbor-group eBGP-peers
route-policy eBGP-peers in ! input group policy
remove-private-as
!
neighbor 1.1.1.1
use group eBGP-peers
!
neighbor 2.2.2.2
use group eBGP-peers
route-policy neigh_2 in !input peer policy
!
route-policy eBGP-peers
if some_condition then
drop
else
pass
endif
end-set
!
route-policy neigh_2 in
apply eBGP-peers
if other_condition then
drop
else
pass
endif
end-set
Con este ejemplo, peer 1.1.1.1 hereda la política eBGP-peers y el
remote-private-as sin problemas. Peer 2.2.2.2, hereda sin problemas el
comando remove-private-as pero la política eBGP-peers no ya que tiene la
política neigh_2 aplicada. Para solucionar esto hago un "apply eBGP-peers"
dentro de la policy neigh_2. Esto funciona sin problemas y es simple pero
quisiera saber si no hay algo más simple para indicar que herede la
política del grupo.
Gracias,
Tomás Lynch
2016-04-22 23:48 GMT-04:00 Rogerio Mariano <rogermariano.cala en yahoo.com>:
> 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
>
>
>
>
> <<<<< 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>:
>
>> 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>
>> escribió:
>>
>>> Fe de erratas: debi decir "hereda".
>>> :)
>>>
>>>
>>> El Friday, April 22, 2016, Tomas Lynch <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
>>>>>>> Cancelar suscripcion: 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
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>
>>>
>>
>>
>> --
>> Atte.
>>
>> Javier I. Rodríguez Sotelo
>>
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: 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
>
>
>
> _______________________________________________
> 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/20160424/bb7dde8f/attachment.html>
Más información sobre la lista de distribución LACNOG