[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