[j-nsp] BGP import policy to accept prefixes from advertising AS only.

[Richard A Steenbergen]

On Wed, Oct 13, 2004 at 05:53:58PM -0700, Pedro Roque Marques wrote:
> 
> Just for curiosity, why do you want to do this ?
> 
> The reason i ask, is that in situations where an AS is being
> renumbered it may be very convinient for you peer as to be able to
> send an AS other than the one that is configured on the session.
> 
> By doing this you would be defeating some other peoples transition
> strategies.

I didn't know it was even possible (without using some hacked code) to 
configure the router to send an AS PATH which didn't start with your 
configured local-as, at least with Juniper gear. Even with "local-as 
private", it will still send an AS PATH starting with the configured 
local-as of that session. Not sure who else would actually support a 
transition strategy based on this, but I have only seen it used on 
route-server hacks for specific applications (such as the Equinix Direct 
transparent transit brokering system). It would be a nifty feature for 
resellers, but if such a feature did exist in non-custom code I could see 
there being more of a demand for the enforce-first-as feature to prevent 
people from doing bad things with it.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a008015ce53.html

That said, I would still love to have some of the functionality where you 
could re-use a single policy-statement throughout the configuration, to 
affect multiple sessions in different ways based upon matching from the 
specific session that the policy is being applied against. Of course the 
classic example of this is a peer-specific community structure, such as 
"6461:666" means don't export this route to AS6461 sessions. The only way 
to do this currently is to create a community named "6461:666", create a 
policy-statement AS6461, match against the community, and include it as 
part of a chain.

I do understand that doesn't directly work because of the way that adj 
ribs are grouped by similar policy, but it would certainly be a nice 
feature from an end user standpoint. Actually, I'm still trying to 
understand exactly under what circumstances it doesn't work, since I've 
heard people report success using multiple "from neighbor x.x.x.x" terms 
in an import policy which is applied to a group with multiple neighbors.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)