[j-nsp] Policy Statement Question
Michael Loftis
mloftis at wgops.com
Sat Jan 28 20:28:19 EST 2006
--On January 28, 2006 7:58:56 PM +0000 Guy Davies <aguydavies at gmail.com>
wrote:
<...>
> You could do something like applying a lower localpref to prefixes
> learned from your T1 upstream with a path longer than (as an example)
> four AS hops. That would then mean that anything four ASes or more
> away would be preferred via your T2 upstream (since localpref is
> evaluated before AS path length). If your T2 also takes service from
> your T1, you may wish to make paths via your T2 then your T1 even less
> desirable so that you don't end up going via the T2 then the T1 to a
> destination.
This is actually the exact method I use with as-path-groups, and then i
don't explicitly set it, i add or subtract some, this helps me create more
complicated rules.
>
> You could do this with something like...
>
> policy-options {
> long-paths "<T1-AS>( .*){3,}";
> longer-paths "<T2-AS>+ <T1-AS>( .*)+";
> policy-statement long-paths {
> term from-T1 {
> from {
> protocol bgp;
> as-path long-paths;
> }
> then {
> set localpref 80;
> }
> }
> term T1-via-T2 {
> from {
> protocol bgp;
> as-path longer-paths;
> }
> then {
> set localpref 50;
> }
> }
> }
> }
>
> There really aren't that many options with BGP for making the balance
> more equal. You could try enabling BGP multipath but I don't think
> this will help in your environment.
>
> In order to apply this to use both of your upstreams, I think you'd
> need to put both of them into a single group. Then have something
> like the following
>
> protocols {
> bgp {
> group transit {
> multipath {
> multiple-as;
> }
> peer <t1-address> {
> peer-as <t1-as>;
> import long-paths;
> }
> peer <t2-address> {
> peer-as <t2-as>;
> import long-paths;
> }
> }
> }
>
> I haven't checked the syntax of this stuff so it may have some flaws
> but it gives you the general idea.
>
> Rgds,
>
> Guy
>
> On 28/01/06, Jeff Neuffer <jneufferjr at gmail.com> wrote:
>> We do "AS_PATH prepending" by matching our prefix's with a "from{}" and
>> "then{}". I haven't tried it any other way. So I would export this in
>> the eBGP session to the peer I wanted to influence.
>>
>>
>> protocols {
>> bgp {
>> group provider1 {
>> type external;
>> multihop {
>> ttl 2;
>> }
>> export bgp-prefix-stuff;
>> neighbor xxx.xxx.xxx.xxx {
>> peer-as 1111;
>> }
>> }
>> }
>> }
>>
>> policy-options {
>>
>> ...omit...
>>
>> policy-statement bgp-prefix-stuff {
>>
>> ...omit...
>>
>> term bgp-prefix-stuff {
>> from {
>> protocol bgp;
>> policy our_prefixes;
>> }
>> then accept;
>> }
>> then reject;
>> }
>>
>> policy-statement our_prefixes {
>> term our_prefixes {
>> from {
>> route-filter xxx.xxx.xxx.0/19 exact;
>> inactive: route-filter xxx.xxx.xxx.0/20 exact;
>> }
>> then accept;
>> }
>>
>> ...omit...
>>
>> term our_prefixes_prepend {
>> from {
>> route-filter xxx.xxx.xxx.0/20 exact;
>> }
>> then {
>> as-path-prepend "9999 9999 9999";
>> accept;
>> }
>> }
>> then reject;
>> }
>> }
>>
>> +---------- N O R T H - S T A T E - C O M M U N I C A T I O N S
>> ----------+
>> | Jeff Neuffer Jr Internet Connections Voice 336 821
>> | 4656 | Data Services Technician W A N Solutions Fax 336
>> | 886 2243 | Email Hosting jneuffer at nstel.com |
>> | PGP Key ID: 0xDD5D3FB8 Web Hosting
>> | http://www.northstate.net |
>> +-----------------------------------------------------------------------
>> --+
>>
>>
>>
>> Chris Davies wrote:
>> > I have two current issues which might have one solution. Our initial
>> > testing shows that the Juniper reduced average latency about 10ms, so,
>> > even though our Cisco wasn't showing any real signs of cpu usage, it
>> > appears (and feels like) the Juniper has made an improvement in
>> > performance which was a small surprise.
>> >
>> > The issue I'm working with now is that we buy transit from two
>> > providers, a Tier 1 (Cogent) and a Tier 2 (Internap) if you wanted to
>> > use 'old' terms. The problem I am running into is that since Internap
>> > is technically a Tier 2 (they buy transit from Tier 1 providers), only
>> > 25k of the 175k routes have shorter ASPaths to the destination.
>> >
>> > Since Internap is only adding 1 router hop and 1 AS Hop, I should ASPad
>> > on Cogent's side. That would perhaps level the playing field for
>> > inbound traffic.
>> >
>> > If I understand this right, can someone do a sanity check? (The
>> > IOS2junos convertor really made things a mess for me, so, I tried to
>> > figure out what it needed and stripped out the rest of it)
>> >
>> > policy-statement aspad_Cogent {
>> > term aspad_Cogent {
>> > then as-path-prepend 11110;
>> > }
>> > }
>> >
>> > Do I need a from condition if I want to unconditionally aspad?
>> >
>> > If I understand it, I do not want an accept here since I want the next
>> > policy statement to also be executed.
>> >
>> > Now, on my A-Peer with Cogent (they use multihop), I would set
>> >
>> > export [ aspad_Cogent bgp_distributes ]
>> >
>> > At that point, I need to
>> >
>> > clear bgp neighbor (a-peer's ip) soft
>> >
>> > to send the config.
>> >
>> > AS Padding on my exports should result in inbound traffic perhaps
>> > choosing a better path since the ASPath's across Cogent and Internap
>> > would be a little more balanced. When I add another provider alongside
>> > these two, if it is another Tier 1 provider, I would probably need to
>> > pad their incoming as well.
>> >
>> > If someone could give this a quick sanity check, I'd appreciate it. 12
>> > years of IOS -> Junos has been a bit of a challenge. :)
>> >
>> > Thanks.
>> > _______________________________________________
>> > juniper-nsp mailing list juniper-nsp at puck.nether.net
>> > http://puck.nether.net/mailman/listinfo/juniper-nsp
>> >
>> >
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
More information about the juniper-nsp
mailing list