[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