[afnog] BGP /AS filtering

Nishal Goburdhan ndg at ieee.org
Thu Jun 27 19:18:25 UTC 2013


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_note09186a0080093f27.shtml#topic1


More information about the afnog mailing list