[j-nsp] Policy Statement Question
Guy Davies
aguydavies at gmail.com
Sat Jan 28 14:58:56 EST 2006
Hi Chris,
AS path prepending is normally used to make a particular upstream less
attractive to the rest of the Internet as a path *to* you rather than
making it less attractive to you as a path to the rest of the
Internet. If you are trying to influence inbound traffic then this is
one (relatively crude) mechanism for achieving that aim. In your
setup, BGP doesn't provide much in the way of alternatives for
influencing inbound traffic (MED is only useful if you have multiple
paths to the same upstream, and even then it's only useful if your
upstreams don't ignore it).
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.
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
>
More information about the juniper-nsp
mailing list