[lacnog] Cisco route-maps and route-policy

[Javier Rodriguez]

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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20160422/e4da2df0/attachment.html>