Mailing List Archive

pr@isprime.com (Phil Rosenthal) writes:

> Hello.
>
> As this topic has been raised in the autonomous-system thread, We are
> planning on implementing community-based prepends for bgp customers,
> which given the featureset available today, I think requires different
> export policies for every peer.

Wouldn't a common export policy do the trick ?

community prepend-my-1 10458:1;
community prepend-my-2 10458:2;
community prepend-customer-1 10458:3;
community prepend-customer-2 10458:4;

policy-statement common-export {
term a {
from community prepend-my-1;
then as-path-prepend "10458";
}
term b {
from community prepend-my-2;
then as-path-prepend "10458 10458";
}
term c {
from community prepend-customer-1;
then as-path-expand last-as;
}

term d {
from community prepend-customer-2;
then as-path-expand last-as count 2;
}
[...]
}

Or do you have different requirements ?

Pedro.

I want to have the capability to have my customers be able to prepend
to peers individually.
Like,
65001:(peeras) = prepend once to (peeras)
65002:(peeras) = prepend twice to (peeras)
65003:(peeras) = prepend three times to (peeras)


On Dec 12, 2003, at 5:49 PM, Pedro Roque Marques wrote:

> pr@isprime.com (Phil Rosenthal) writes:
>
>> Hello.
>>
>> As this topic has been raised in the autonomous-system thread, We are
>> planning on implementing community-based prepends for bgp customers,
>> which given the featureset available today, I think requires different
>> export policies for every peer.
>
> Wouldn't a common export policy do the trick ?
>
> community prepend-my-1 10458:1;
> community prepend-my-2 10458:2;
> community prepend-customer-1 10458:3;
> community prepend-customer-2 10458:4;
>
> policy-statement common-export {
> term a {
> from community prepend-my-1;
> then as-path-prepend "10458";
> }
> term b {
> from community prepend-my-2;
> then as-path-prepend "10458 10458";
> }
> term c {
> from community prepend-customer-1;
> then as-path-expand last-as;
> }
>
> term d {
> from community prepend-customer-2;
> then as-path-expand last-as count 2;
> }
> [...]
> }
>
> Or do you have different requirements ?
>
> Pedro.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
--Phil Rosenthal
ISPrime, Inc.

On Fri, Dec 12, 2003 at 05:14:19PM -0500, Phil Rosenthal wrote:
> I have my peer groups organized by similar physical/logical
> characteristics (customers, public peers, private peers, transit, etc),
> but even as it is now, many of them have their own import/export
> policies to filter customers,

Yeah, and usually it's only one policy in the import chain which
differentiates customers.

<dream>
$ fgrep chains vendor/juniper/JunOS-featurerequests
- per-neighbor import/export chains additive to the peer-group chains
(or a placeholder "$PARENT_CHAIN" in per-protocol/group/neighbor chains)
</dream>


Regards,
Daniel

On Fri, Dec 12, 2003 at 06:05:25PM -0500, Phil Rosenthal wrote:
> I want to have the capability to have my customers be able to prepend
> to peers individually.
> Like,
> 65001:(peeras) = prepend once to (peeras)
> 65002:(peeras) = prepend twice to (peeras)
> 65003:(peeras) = prepend three times to (peeras)

This is actually a very common policy that providers implement, or at
least want to implement very badly. Unfortunately, the only way to do it
right now is to use a policy-statement per peer ASN.

I've been pondering this one for years now, trying to think of a better
way to do it. The goal here is to introduce specific information about the
session the policy is currently being evaluated against into the policy,
and then allow the policy to make a decision based on it.

Introducing the above information into the policy seems straight forward
enough. You could do something like this (note I'm going to reverse your
ordering a bit, trying to keep the first 16 bits of the word
representative of the ASN in question for consistancy's sake, and god
have mercy on my soul for using the format I am going to use :P):

some-new-command prependable-ASNs members [ "2914" "6461" "3549" ];
community prepend-once members ".*:65001";
community prepend-twice members ".*:65002";
community prepend-thrice members ".*:65003";

policy-statement common-export {
term prepend-once {
from {
community prepend-once;
some-new-compare-command $SESSION['peer-as'] prependable-ASNs;
}
then as-path-prepend "10458";
}
...
}

But if you really want to have fun, you need to take this one step
further. Allow the operator to configure their own values AND keys for
session specific interface information they want brought into the
policies.

Say for example:

...
neighbor 1.2.3.4 {
peer-as 1234;
some-new-command "peer-as" "1234";
some-new-command "shortname" "roque";
}

...

prefix-list roque-prefixes {
10.0.0.0/24 orlonger;
10.2.0.0/23;
}

policy-statement common-import {
term prefix-filter
from {
prefix-list "${SESSION['shortname']}-prefixes";
}
then accept;
}
then reject;
...
}

firewall {
filter common-input-filter {
term customer-filter {
from {
source-prefix-list "${SESSION['shortname']}-prefixes";
}
then accept;
}
/* Why the heck don't firewalls allow this like policy-statements do? */
then discard;
}
}

THEN you have a common firewall filter, a common policy, and the only
thing you need to do is stick to a consistant standard for naming them.
Useful? I sure as hell think so!

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