[GTER] Balanceamento quando utilizando route-map

[Carlos Eduardo Terra]

Julio Arruda escreveu:
> Carlos Eduardo Terra wrote:
>>> E' impossivel identificar se a decisao de roteamento no seu lado foi 
>>> feito via longest match "convencional", ou PBR, ou pelo roteador jogando 
>>> dados,, etc..
>>>   
>> Eu tambem achava.
>>> Se voce esta enviando trafego para um upstream que nao espera ver aquele 
>>> endereco origem vindo de voce, nao e' por que voce roteou PBR que ele 
>>> esta dropando, e sim por que ele esta 'saneando' o trafego, usando RPF 
>>> ou algo similar para se proteger de receber trafego de onde nao deveria 
>>> estar vindo.
>>>
>>>   
>> Sendo que eu estou jogando para o provedor X apenas os dados originados 
>> pelos IPs me fornecidos pelo provedor X, e jogando para o provedor Y 
>> apenas os dados originados pelos IPs fornecidos pelo provedor Y.
>>
>> Para testar esse 'possível' problema eu testei também com um ip do 
>> provedor Y saindo pelo provedor X. O pacote saiu pela rede X e voltou 
>> pelo provedor Y. Mas isso é gambiarra das grandes.
> 
> E mal sinal, de que o provedor X nao segue BCP38. shame on him..
> 
> um pacote IP certamente nao tem diferenca se roteado via tabela de 
> roteamento, PBR, next-hop forward filter, o termo que o fabricante usar, 
> NAO altera o pacote de maneira diferente de forwarding normal.
> Existem os l4-7 switches que fazem umas coisas meio 'nao naturais' e etc 
> (exemplo, por default nao substituir o MAC ao 'SLB-ezar' o pacote e 
> coisas nao obvias), mas isto com certeza nao e' o seu caso.
> 
> 
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

Será que é alguma particularidade de um circuito ATM?
O Provedor X entrega meu link por um circuito ATM e me passou pela
cabeça nesse momento se este problema seria devido a alguma
particularidade do protocolo.

Alguém sabe se existe algum parametro especial?

Grato.
-- 
Carlos Eduardo Terra