[afnog] BGP /AS filtering

[Riaan Vos]

So after my last correction on the public ASN in the path which will cause
the private ASNes to not be removed, I thought about this more and then
vaguely remembered seeing/reading something about an enhancement to this
rule. Googled a bit and come across this document:
http://www.cisco.com/en/US/docs/ios/ios_xe/iproute_bgp/configuration/guide/
irg_remove_as_xe.html#wp1093145. Check out the former restrictions and the
enhancement sections.

So there is a possibility on below private ASNs to be cleaned given the
code they are running (and of course the vendor :)) and then also the way
things are plugged in.

--
Riaan





On 2013/06/27 9:18 PM, "Nishal Goburdhan" <ndg at ieee.org> wrote:

>
>On 25 Jun 2013, at 3:07 PM, "Saul Stein" <saul at enetworks.co.za> wrote:
>
>> Dear friendly BGP boffs!
>>  
>> Please can someone explain:
>>  
>> We get the following route:
>> 41.90.0.0/16     10474  37100    33771   65535   64555   64555   33771
>>  
>> My question is why are we seeing 2 private ASes (65535  64555   64555)
>>behind 33771 (safaricom)
>>  
>> My understanding was that Safaricom should be hiding itŠ. So we should
>>only see
>> 41.90.0.0/16     10474  37100    33771
>
>"remove-private-as" fails if there is a valid as in the path.   [1]
>from the same URL, see:
>The following conditions apply:
>€ You can only use this solution with external BGP (eBGP) peers.
>€ If the update has only private AS numbers in the AS_PATH, BGP removes
>these numbers.
>€ If the AS_PATH includes both private and public AS numbers, BGP doesn't
>remove the private AS numbers. This situation is considered a
>configuration error.	
>€ If the AS_PATH contains the AS number of the eBGP neighbor, BGP does
>not remove the private AS number.
>€ If the AS_PATH contains confederations, BGP removes the private AS
>numbers only if they come after the confederation portion of the AS_PATH.
>
>in this case, 33771 is _valid_ so if 65535 (yes, i realise this is a
>private ASN) tried to strip 64555 (yes, it can be done), it would fail
>because of the first (ie. rightmost) 33771.
>
>more than likely someone has separate ASNs for their *cough, choke
>sputter* mpls network, and then one for their regular IP network, and
>they're peering between some sort of internet-vrf to another for IP
>services.
>
>that's just an uninformed guess though.
>
>that's not the worst thing about that as-path though  :-(
>
>--n.
>
>[1] 
>http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f
>27.shtml#topic1
>_______________________________________________
>afnog mailing list
>http://afnog.org/mailman/listinfo/afnog