Re: [c-nsp] prefixes in AS-Set
Hi,
On Fri, Aug 05, 2011 at 02:53:21AM +0300, Martin T wrote:
why would one like to limit(maximum-prefix) ingress prefixes from IPX?
Because you really don't want to receive leaked full-tables from your
peers. Mistakes happen, and your customers will not like it if you
route all of the Internet through a completely overloaded peer router
that just attracted many gigs of extra traffic...
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?
If you exceed the max-prefix set, the session will go down. It's a safeguard.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
pgprIFTbsC982.pgp
Description: PGP signature
___
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/
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/
Re: [c-nsp] prefixes in AS-Set
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/
Re: [c-nsp] prefixes in AS-Set
Yes... I would probably not bother to filter every peer, but just set max prefix (if they are an IXP peer for example) or otherwise you could end up with a lot of prefix lists and I think the router can only hold so many prefix list entries. Not every peer is going to have info in the db and/or it may not be up to date etc. This approach would be suitable for where you have downstream customers and you want to filter what they can announce to you, and you want a way to automate the updating of prefix lists accepted from customers (Many transit providers do it this way) Regards, Rob -- Robert Lister On 3 Aug 2011, at 06:51, Martin T m4rtn...@gmail.com wrote: As I understand, in case ISP-A would like to peer with ISP-B, the ISP-A usually specifies it's AS-set it will announce to ISP-B? For example in case XS4ALL(xs4all.nl) would like to set up a peering with some other ISP, it will announce AS-ACCESSFORALL, which contains all XS4ALL ASN's. ISP-B should be able to find all those ASN's which are under the AS-set called AS-ACCESSFORAL by: ___ 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/
Re: [c-nsp] prefixes in AS-Set
Yeah - we used to filter based on AS-SET at one time - we quickly maxxed out the available memory (for config storage) on Cisco 7600 platforms with Sup720-3BXL's doing this. Now it's just max-prefix except our downstream customers where we specifically run filters to control what they announce to us. In a perfect world it would be all done via AS-SET but as Rob pointed out, not everyone keeps their data up to date unfortunately Paul -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rob Lister Sent: Wednesday, August 03, 2011 6:38 AM Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] prefixes in AS-Set Yes... I would probably not bother to filter every peer, but just set max prefix (if they are an IXP peer for example) or otherwise you could end up with a lot of prefix lists and I think the router can only hold so many prefix list entries. Not every peer is going to have info in the db and/or it may not be up to date etc. This approach would be suitable for where you have downstream customers and you want to filter what they can announce to you, and you want a way to automate the updating of prefix lists accepted from customers (Many transit providers do it this way) Regards, Rob -- Robert Lister On 3 Aug 2011, at 06:51, Martin T m4rtn...@gmail.com wrote: As I understand, in case ISP-A would like to peer with ISP-B, the ISP-A usually specifies it's AS-set it will announce to ISP-B? For example in case XS4ALL(xs4all.nl) would like to set up a peering with some other ISP, it will announce AS-ACCESSFORALL, which contains all XS4ALL ASN's. ISP-B should be able to find all those ASN's which are under the AS-set called AS-ACCESSFORAL by: ___ 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/
Re: [c-nsp] prefixes in AS-Set
On Wednesday, August 03, 2011 07:23:46 PM Paul Stewart wrote: Yeah - we used to filter based on AS-SET at one time - we quickly maxxed out the available memory (for config storage) on Cisco 7600 platforms with Sup720-3BXL's doing this. Now it's just max-prefix except our downstream customers where we specifically run filters to control what they announce to us. Same here, although we also throw in AS_PATH filtering just to add a little more safety. In a perfect world it would be all done via AS-SET but as Rob pointed out, not everyone keeps their data up to date unfortunately RPKI is now the way forward :-). Mark. signature.asc Description: This is a digitally signed message part. ___ 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/
[c-nsp] prefixes in AS-Set
As I understand, in case ISP-A would like to peer with ISP-B, the
ISP-A usually specifies it's AS-set it will announce to ISP-B? For
example in case XS4ALL(xs4all.nl) would like to set up a peering with
some other ISP, it will announce AS-ACCESSFORALL, which contains all
XS4ALL ASN's. ISP-B should be able to find all those ASN's which are
under the AS-set called AS-ACCESSFORAL by:
$ whois AS-ACCESSFORALL | grep member
members:AS3265
members:AS1200
members:AS5417
members:AS8283
members:AS20689
members:AS33955
$
Now if ISP-B is interested in all the prefixes which are under those
ASN's it could do whois -h whois.ripe.net -i origin ASN with every
ASN under the AS-ACCESSFORAL and manually write the addresses down or
do:
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
46.21.224.0/20
46.23.80.0/20
62.216.0.0/19
62.251.0.0/17
77.73.16.0/21
80.100.0.0/15
80.126.0.0/15
81.24.0.0/20
82.92.0.0/14
82.161.0.0/16
83.68.0.0/19
83.160.0.0/14
91.200.16.0/22
91.208.34.0/24
94.142.240.0/21
95.129.120.0/21
193.104.193.0/24
193.110.157.0/24
193.111.228.0/24
194.109.0.0/16
194.159.72.0/23
194.159.224.0/21
194.217.220.0/22
195.11.224.0/19
195.64.80.0/20
195.69.144.0/22
195.95.150.0/24
195.173.224.0/19
212.238.0.0/16
213.84.0.0/16
213.222.0.0/19
217.194.16.0/21
$
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.
Have I understood this whole concept correctly? Any additional
notes/corrections are most welcome!
It's not directly Cisco-related question, but hopefully not off-topic as well :)
regards,
martin
___
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/
