[afnog] BGP /AS filtering

[Mark Tinka]

On Thursday, June 27, 2013 09:43:57 PM Riaan Vos wrote:

> 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/c
> onfiguration/guide/ irg_remove_as_xe.html#wp1093145.
> Check out the former restrictions and the enhancement
> sections.

This is quite a reasonable development of the feature set 
from Cisco.

I see that Juniper have also enhanced their own 
implementation of the feature since Junos 12.3 (look at the 
Options at the bottom of the page):

http://www.juniper.net/techpubs/en_US/junos12.3/topics/reference/configuration-
statement/remove-private-edit-protocols-bgp.html

Generally, one "can" get away with having private AS's being 
routed in their network, but not passing them on to eBGP 
neighbors even without using the 'remove-private-as' command 
provided they are aggregating all their RIR-allocated 
prefixes, because the typical use-cases for private AS's 
will allow this, i.e., multi-homing to the same ISP with a 
PI/PA prefix, multi-homing to the same ISP with the ISP's PA 
assignment, running eBGP with the ISP for availability 
reasons that don't require a public ASN, e.t.c.

But in such a case as highlighted by the OP, where a network 
could be running confederations (either to replicate route 
reflector topologies or to co-manage extended backbones 
across different operating countries/regions for the same 
company), 'remove-private-as' is the only option given the 
prefixes associated with the AS are the aggregates.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20130628/ac038298/attachment.sig>