Ok, max prefixes is very * important *!
You would not apply this to a transit peer but let's say you're peering at
an exchange point. (by peering I mean the classical definition of
exchanging sourced and customer traffic of your network with another company
but not transiting as you would with a full transit type route table) Let's
say that your friendly peer lacks some clue and or has a bad day and fat
fingers some setting that dumps their entire view in to your session. You
went from receiving a few prefixes that you wanted to having a full table
from some peer who you know nothing about internally and who can really
screw your traffic engineering and performance. I had this happen several
times with networks I won't name but with max prefixes set it simply dropped
the session and allowed me to not lose the consistency of the over all
network. Typically, you'd do something like first evaluate the number of
prefixes you will receive with the peer. This is typically information you
exchange with the prospect ahead of time and likewise you provide your
number of prefixes to them. Then I set the max prefixes at some factor (say
2 or 3) times the value so the peer has reasonable room to grow with out
needing manual intervention. Let's say you're receiving 200 prefixes, you
could easily set the max pref length to say 600 - 1000 and probably not have
to touch that setting for months if not years in some cases. You may run in
to an instance where a peer outgrows your max prefix setting naturally
through the course of a growing business / network but you will see this
coming and work out a new value.
In terms of what's installed, yes, I believe it's in order so if you
have max pref set to 1000 the 1001st prefix in theory should dump the
session or at least this is how it worked the last time I was in an
environment with exchange peering routers. Using tools like this and good
use of community tags, route-maps and prefix-lists along with peering groups
you aught to be able to simplify the entry in your config for each peer to 3
lines or so making it very easy. You also limit your risk of announcing the
wrong routes. Also remember that my comments are IOS specific but the
concepts are general enough that they should apply to your specific
situation.
Hope that helps and I understood your question correctly.
Thank you
Scott
-----Original Message-----
From: Martin T
Sent: Thursday, August 04, 2011 7:53 PM
To: Brandon Ewing
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] prefixes in AS-Set
Rob,
why would one like to limit(maximum-prefix) ingress prefixes from IPX?
Doesn't more prefixes mean more choice in terms of routes?
In addition, for example in case of this "peval AS-ACCESSFORALL | sed
's/({//;s/})//;s/, /\n/g' | aggregate -q" example, there are 32
different aggregated prefixes. Now if set maximum-prefix limit value
to 20, which prefixes are accepted? First 20 which are seen by the
router?
Paul, Mark,
in case you set up a prefix filter for an IXP peer, you do the process
I described in the first e-mail and then manually check which
aggregated prefixes you would like to accept and which ones you filter
out using the prefix filter?
Brandon,
thanks for this tool!
regards,
martin
2011/8/3 Brandon Ewing <nicot...@warningg.com>:
On Wed, Aug 03, 2011 at 08:51:03AM +0300, Martin T wrote:
peval AS-ACCESSFORALL | sed 's/({//;s/})//;s/, /\n/g' | aggregate -q
This last command would give:
$ peval AS-ACCESSFORALL | sed 's/({//;s/})//;s/, /\n/g' | aggregate -q
$
Level3 has a nice tool as a result of their automated prefix list
generation
that is available for use:
whois -h filtergen.level3.net "RIPE::AS-ACCESSFORALL"
So you can avoid all the sed. :) Check out whois -h filtergen.level3.net
help for more options -- you can have it output fully formed Cisc-style
prefix-lists as well.
So in case XS4ALL announces it's AS-set AS-ACCESSFORALL(it seems to be
the only AS-set for company XS4ALL) to ISP-B, the latter would receive
all those prefixes above over the established BGP session.
Another nice feature is you can have AS-SETs in AS-SETs.
--
Brandon Ewing
(nicot...@warningg.com)
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
