Il 14 gennaio 2010 01.18, Stefano Sasso <[email protected]> ha scritto:
> Il 13 gennaio 2010 17.24, Davide Brini <[email protected]> ha scritto:
>> Pero' e' possibile creare delle policy che "artificialmente", se mi passi il
>> termine, aggiungono piu' volte l'AS number. Il motivo per cui cio' viene 
>> fatto
>> e' perche' cosi' l'AS_PATH e' piu' lungo (e quindi per BGP e' meno 
>> preferibile
>> rispetto ad altre route in cui e' piu' corto). Generalmente si fa cio' per
>> tentare di influenzare le route scelte da chi invia traffico verso il tuo AS
>> (anche se ci sono modi piu' puliti di farlo, che dovrebbero essere usati se
>> possibile).
>
> si, ciò è chiaro, non ho dubbi su questo.
> la mia domanda è un po' diversa (scusate se non mi sono spiegato bene).
>
> quello che voglio fare è questo: ipotizzando che As300 sia un mio
> transit provider, io voglio ricevere le rotte originate da questo AS
> (e per fare questo uso _300$); voglio inoltre ricevere, tramite l'as
> 300 le rotte originate dai suoi peer. ora, io non posso sapere a
> priori se i peer (o clienti) di as 300 usino as prepending, ma voglio
> accettare in ogni caso le loro rotte (transitanti comunque per l'as
> 300). E non posso a priori sapere quale sia il loro as number (quindi
> non posso usare direttamente  _XXXX$)
> la regex scritta mi sembrava la più efficace... o sbaglio?
>
> ciao,
> stefano
>

Ciao Stefano,
ora è chiarissimo. La tua regex  _300_([0-9]+)(_\1)*$ nell'as-path acl
permette rotte originate da un peer diretto dell'AS300 per le quali
quest'ultimo è di transito, anche in caso di prepending.
Ad esempio, se L'AS 'AAAA' è un qualsiasi peer diretto dell'AS300, la
tua regex permetterà i seguenti as-path:

300_AAAA
300_AAAA_AAAA
300_AAAA_AAAA_AAAA_ ...  e così via...

Ma anche:

XXXX_300_AAAA_ ...
YYYY_XXXX_300_AAAA_ ...
... _ZZZZ_YYYY_XXXX_300_AAAA_ ...
dove, XXXX, YYYY, ZZZZ sono gli AS che separano il tuo AS dall'AS300.

CIao,
Matteo
_______________________________________________
http://www.areanetworking.it
http://www.areanetworking.it/blog
[email protected]
http://ml.areanetworking.it/mailman/listinfo/cug

Reply via email to