[lacnog] Cisco route-maps and route-policy

Rogerio Mariano rogermariano.cala en yahoo.com
Dom Abr 24 22:59:12 BRT 2016


Hola Tomas, 
Voy a escribir en Inglés para poder explicar mejor ya que mi español y muy limitado …Les pido un montón de excusas por las


I have a CiscoVIRL at home and I said to her RPL and would really be a good way to run the policy, I might just change the attach point policy for the Peers, but it would be a very different way than you did. If you have a lot of material on RPL (Videos, files) Paul Finch that Cisco TME. 


However follow the XR RPL Inheritance rules:

 <>
In XR/QNX software, BGP neighbors or groups inherit configuration from other configuration groups. 

 <>
For (AFI) address family-independent configurations: 

 <>
• <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>Neighbors can inherit from session groups and neighbor groups. 

 <>
• <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>Neighbor groups can inherit from session groups and other neighbor groups. 

 <>
• <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>Session groups can inherit from other session groups. 

 <>
• <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>If a neighbor uses a session group and a neighbor group, the configurations in the session group are preferred over the global address family configurations in the neighbor group. 

 <>
For address family-dependent configurations: 

 <>
• <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>Address family groups can inherit from other address family groups. 

 <>
• <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>Neighbor groups can inherit from address family groups and other neighbor groups. 

 <>
• <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>Neighbors can inherit from address family groups and neighbor groups.


Configuration group inheritance rules are numbered in order of precedence as follows: 

 <>
1.  <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>If the item is configured directly on the neighbor, that value is used. In the example that follows, the advertisement interval is configured both on the neighbor group and neighbor configuration and the advertisement interval being used is from the neighbor configuration: 

 <>
RP/0/RSP0/CPU0:router(config)# router bgp 140
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor-group AS_1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# advertisement-interval 15
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor 10.1.1.1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# remote-as 1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# use neighbor-group AS_1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# advertisement-interval 20
 <>
 <>
The following output from the show bgp neighbors command shows that the advertisement interval used is 20 seconds: 

 <>
RP/0/RSP0/CPU0:router# show bgp neighbors 10.1.1.1
 <>
 <>
BGP neighbor is 10.1.1.1, remote AS 1, local AS 140, external link
 <>
 Remote router ID 0.0.0.0
 <>
  BGP state = Idle
 <>
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
 <>
  Received 0 messages, 0 notifications, 0 in queue
 <>
  Sent 0 messages, 0 notifications, 0 in queue
 <>
  Minimum time between advertisement runs is 20 seconds
 <>
 <>
 For Address Family: IPv4 Unicast
 <>
  BGP neighbor version 0
 <>
  Update group: 0.1
 <>
  eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
 <>
  Route refresh request: received 0, sent 0
 <>
  0 accepted prefixes
 <>
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
 <>
  Threshold for warning message 75%
 <>
 <>
  Connections established 0; dropped 0
 <>
  Last reset 00:00:14, due to BGP neighbor initialized
 <>
  External BGP neighbor not directly connected.
 <>
 <>
2.  <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>Otherwise, if the neighbor uses a session group or address family group, the configuration value is obtained from the session group or address family group. If the address family group or session group has a parent and an item is configured on the parent, the parent configuration is used. If the item is not configured on the parent but is configured on the parent of the parent, the configuration of the parent of the parent is used, and so on. In the example that follows, the advertisement interval is configured on a neighbor group and a session group and the advertisement interval value being used is from the session group: 

 <>
RP/0/RSP0/CPU0:router(config)# router bgp 140
 <>
RP/0/RSP0/CPU0:router(config-bgp)# session-group AS_2
 <>
RP/0/RSP0/CPU0:router(config-bgp-sngrp)# advertisement-interval 15
 <>
RP/0/RSP0/CPU0:router(config-bgp-sngrp)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor-group AS_1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# advertisement-interval 20
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor 192.168.0.1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# remote-as 1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# use session-group AS_2
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# use neighbor-group AS_1
 <>
 <>
The following output from the show bgp neighbors command shows that the advertisement interval used is 15 seconds: 

 <>
RP/0/RSP0/CPU0:router# show bgp neighbors 192.168.0.1
 <>
 <>
BGP neighbor is 192.168.0.1, remote AS 1, local AS 140, external link
 <>
 Remote router ID 0.0.0.0
 <>
  BGP state = Idle
 <>
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
 <>
  Received 0 messages, 0 notifications, 0 in queue
 <>
  Sent 0 messages, 0 notifications, 0 in queue
 <>
  Minimum time between advertisement runs is 15 seconds
 <>
 <>
 For Address Family: IPv4 Unicast
 <>
  BGP neighbor version 0
 <>
  Update group: 0.1
 <>
  eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
 <>
  Route refresh request: received 0, sent 0
 <>
  0 accepted prefixes
 <>
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
 <>
  Threshold for warning message 75%
 <>
 <>
  Connections established 0; dropped 0
 <>
  Last reset 00:03:23, due to BGP neighbor initialized
 <>
  External BGP neighbor not directly connected.
 <>
 <>
3.  <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>Otherwise, if the neighbor uses a neighbor group and does not use a session group or address family group, the configuration value can be obtained from the neighbor group either directly or through inheritance. In the example that follows, the advertisement interval from the neighbor group is used because it is not configured directly on the neighbor and no session group is used: 

 <>
RP/0/RSP0/CPU0:router(config)# router bgp 150
 <>
RP/0/RSP0/CPU0:router(config-bgp)# session-group AS_2
 <>
RP/0/RSP0/CPU0:router(config-bgp-sngrp)# advertisement-interval 20
 <>
RP/0/RSP0/CPU0:router(config-bgp-sngrp)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor-group AS_1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# advertisement-interval 15
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor 192.168.1.1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# remote-as 1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# use neighbor-group AS_1
 <>
 <>
The following output from the show bgp neighbors command shows that the advertisement interval used is 15 seconds: 

 <>
RP/0/RSP0/CPU0:router# show bgp neighbors 192.168.1.1
 <>
 <>
BGP neighbor is 192.168.2.2, remote AS 1, local AS 140, external link
 <>
 Remote router ID 0.0.0.0
 <>
  BGP state = Idle
 <>
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
 <>
  Received 0 messages, 0 notifications, 0 in queue
 <>
  Sent 0 messages, 0 notifications, 0 in queue
 <>
  Minimum time between advertisement runs is 15 seconds
 <>
 <>
 For Address Family: IPv4 Unicast
 <>
  BGP neighbor version 0
 <>
  Update group: 0.1
 <>
  eBGP neighbor with no outbound policy; defaults to 'drop'
 <>
  Route refresh request: received 0, sent 0
 <>
  Inbound path policy configured
 <>
  Policy for incoming advertisements is POLICY_1
 <>
  0 accepted prefixes
 <>
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
 <>
  Threshold for warning message 75%
 <>
 <>
  Connections established 0; dropped 0
 <>
  Last reset 00:01:14, due to BGP neighbor initialized
 <>
  External BGP neighbor not directly connected.
 <>
 <>
To illustrate the same rule, the following example shows how to set the advertisement interval to 15 (from the session group) and 25 (from the neighbor group). The advertisement interval set in the session group overrides the one set in the neighbor group. The inbound policy is set to POLICY_1 from the neighbor group. 

 <>
RP/0/RSP0/CPU0:router(config)# router bgp 140
 <>
RP/0/RSP0/CPU0:router(config-bgp)# session-group ADV
 <>
RP/0/RSP0/CPU0:router(config-bgp-sngrp)# advertisement-interval 15
 <>
RP/0/RSP0/CPU0:router(config-bgp-sngrp)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor-group ADV_2
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# advertisement-interval 25
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# address-family ipv4 unicast
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp-af)# route-policy POLICY_1 in
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp-af)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor 192.168.2.2
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# remote-as 1
 <>
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# use session-group ADV
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# use neighbor-group TIMER
 <>
 <>
The following output from the show bgp neighbors command shows that the advertisement interval used is 15 seconds: 

 <>
RP/0/RSP0/CPU0:router# show bgp neighbors 192.168.2.2
 <>
 <>
BGP neighbor is 192.168.2.2, remote AS 1, local AS 140, external link
 <>
 Remote router ID 0.0.0.0
 <>
  BGP state = Idle
 <>
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
 <>
  Received 0 messages, 0 notifications, 0 in queue
 <>
  Sent 0 messages, 0 notifications, 0 in queue
 <>
  Minimum time between advertisement runs is 15 seconds
 <>
 <>
 For Address Family: IPv4 Unicast
 <>
  BGP neighbor version 0
 <>
  Update group: 0.1
 <>
  eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
 <>
  Route refresh request: received 0, sent 0
 <>
  0 accepted prefixes
 <>
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
 <>
  Threshold for warning message 75%
 <>
 <>
  Connections established 0; dropped 0
 <>
  Last reset 00:02:03, due to BGP neighbor initialized
 <>
  External BGP neighbor not directly connected.
 <>
 <>
4.  <http://www.cisco.com/c/dam/en/us/td/i/templates/blank.gif>Otherwise, the default value is used. In the example that follows, neighbor 10.0.101.5 has the minimum time between advertisement runs set to 30 seconds (default) because the neighbor is not configured to use the neighbor configuration or the neighbor group configuration: 

 <>
RP/0/RSP0/CPU0:router(config)# router bgp 140
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor-group AS_1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# remote-as 1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor-group adv_15
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# remote-as 10
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# advertisement-interval 15
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbrgrp)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor 10.0.101.5
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# use neighbor-group AS_1
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# exit
 <>
RP/0/RSP0/CPU0:router(config-bgp)# neighbor 10.0.101.10
 <>
RP/0/RSP0/CPU0:router(config-bgp-nbr)# use neighbor-group adv_15
 <>
 <>
The following output from the show bgp neighbors command shows that the advertisement interval used is 30 seconds: 

 <>
RP/0/RSP0/CPU0:router# show bgp neighbors 10.0.101.5
 <>
 <>
BGP neighbor is 10.0.101.5, remote AS 1, local AS 140, external link
 <>
 Remote router ID 0.0.0.0
 <>
  BGP state = Idle
 <>
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
 <>
  Received 0 messages, 0 notifications, 0 in queue
 <>
  Sent 0 messages, 0 notifications, 0 in queue
 <>
  Minimum time between advertisement runs is 30 seconds
 <>
 <>
 For Address Family: IPv4 Unicast
 <>
  BGP neighbor version 0
 <>
  Update group: 0.2
 <>
  eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
 <>
  Route refresh request: received 0, sent 0
 <>
  0 accepted prefixes
 <>
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
 <>
  Threshold for warning message 75%
 <>
Connections established 0; dropped 0
 <>
  Last reset 00:00:25, due to BGP neighbor initialized
 <>
  External BGP neighbor not directly connected.
 <>
 <>
The inheritance rules used when groups are inheriting configuration from other groups are the same as the rules given for neighbors inheriting from groups.



Saludos,

Rogerio Mariano

> Em 24 de abr de 2016, à(s) 17:15, Tomas Lynch <tomas.lynch en gmail.com> escreveu:
> 
> 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 <mailto: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 <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 <http://10.0.0.0/8>
> ip prefix-list PERMITESUMARIO seq 10 permit 172.16.0.0/12 <http://172.16.0.0/12>
> ip prefix-list PERMITESUMARIO seq 15 permit 164.85.0.0/16 <http://164.85.0.0/16>
> ip prefix-list PERMITESUMARIO seq 20 permit 192.168.0.0/16 <http://192.168.0.0/16>
> ip prefix-list PERMITESUMARIO seq 25 deny 10.0.0.0/8 <http://10.0.0.0/8> le 32
> ip prefix-list PERMITESUMARIO seq 30 deny 172.16.0.0/12 <http://172.16.0.0/12> le 32
> ip prefix-list PERMITESUMARIO seq 35 deny 164.85.0.0/16 <http://164.85.0.0/16> le 32
> ip prefix-list PERMITESUMARIO seq 40 deny 192.168.0.0/16 <http://192.168.0.0/16> le 32
> ip prefix-list PERMITESUMARIO seq 45 permit 0.0.0.0/0 <http://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 <http://10.0.0.0/8> le 32,
>   172.16.0.0/12 <http://172.16.0.0/12> le 32,
>   164.85.0.0/16 <http://164.85.0.0/16> le 32,
>   192.168.0.0/16 <http://192.168.0.0/16> le 32
> end-set
> !
> prefix-set PRFX-PERMIT-SUMARIO
>   10.0.0.0/8 <http://10.0.0.0/8>,
>   172.16.0.0/12 <http://172.16.0.0/12>,
>   164.85.0.0/16 <http://164.85.0.0/16>,
>   192.168.0.0/16 <http://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 <http://10.0.0.0/8>
>    aggregate-address 164.85.0.0/16 <http://164.85.0.0/16>
>    aggregate-address 172.16.0.0/12 <http://172.16.0.0/12>
>    aggregate-address 192.168.0.0/16 <http://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 <mailto: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 <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 <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/20160424/87815638/attachment.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: blank.gif
Type: image/gif
Size: 43 bytes
Desc: no disponible
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20160424/87815638/attachment.gif>


Más información sobre la lista de distribución LACNOG