Re: Error in assignments....?
NB: this is neither an endorsement for or against generating policy
from databases.
Could somebody that has done this comment on how complicated this is to
set up? What steps were involved?
Taking this to mean filter on policy learned from databases,
following is a Tcl fragment wrapped around RAToolkit's peval that I
used to use to query the RADB and build intermediate data from which I
would then generate either Cisco prefix lists or Juniper policy
statements.
The Tcl proc psort, used to sort a list of prefixes in CIDR
notation, is left as an exercise to the reader.
proc peval {macro tag allow_incomplete description} {
set res [list $tag\tdescription\t[list $description]]
set incomplete 0
if {[catch {set tmp [exec peval $macro]} why]} {
set tmp [lindex [split $why \n] 0]
set incomplete 1
}
set plist
if {[regexp {\(\{([^\}]+)\}\)} $tmp junk tmp2]} {
set tmp3 [split $tmp2 ,]
foreach U [lsort -command psort $tmp3] {
lappend res $tag\tpermit\t[string trim $U]
}
}
if {[info exists res]} {
if {$incomplete !$allow_incomplete} {
return # [join $res \n# ]
} else {
return [join $res \n]
}
}
}
The Tcl proc named peval takes four arguments: the macro to be
evaluated, a tag that I would use later to name the final result,
whether an incomplete list of prefixes is permitted, and a
description.
That third bit, whether an incomplete list of prefixes is permitted,
turns out to be an important bit. Some bits of policy refer to other
bits of policy, and when bits referenced to not exist peval (the
RAToolkit peval, called by Tcl exec) writes them to stderr and causes
Tcl to raise an exception.
An example (I used to run AS33, and the policy for AS33 doesn't appear
to have been changed since I last updated it so I'll take the liberty
of picking on it; yes, I know DEC was bought by Compaq and Compaq
bought by HP):
% source xpeval.tcl
% peval as33 33 1 Digital Equipment Corporation prefixes
33 description {Digital Equipment Corporation prefixes}
33 permit 16.0.0.0/8
33 permit 128.45.0.0/16
33 permit 130.180.0.0/16
33 permit 198.55.32.0/21
33 permit 198.55.40.0/23
33 permit 199.33.32.0/24
33 permit 199.33.32.0/19
33 permit 199.80.128.0/17
33 permit 204.123.0.0/16
(Goodness, that's a lot of address space, isn't it?)
RAToolkit's peval uses rpsl-p.merit.edu as its source of data, and,
amusingly, returns data for the macro AS33, even though the RADB
seems to have no AS33 aut-num object. Go figure.
Anyways, there was more glue to (a) build vendor-specific
configuration language to turn that into a syntactically correct
filter for routers (the kind of glue that has to be rewritten every
time a new vendor invents a new configuration language), with care
taken not to replace a previously-defined filter with no filter should
an error be introduced into the RADB, (b) and update the router
configs nightly with the new policy.
When I ran into the problem of a list of prefixes for one peer being
generated that caused the resulting (compressed) configuration to
exceed the size of flash memory on my routers, I stopped the cron job
and switched all the peers over to maximum-prefix-style limits with
a standard bogon exclusion filter.
It took a couple days to put it together and test it (although I
didn't think to test the list too long case), and was in production
for about a year and a half. The vendors' implementation of maximum
prefix limits was not available when I started it, and was available
when the list too long case cropped up.
Re: Error in assignments....?
...exactly. So, again, I can't see a valid reason for a single route to originate from two different AS:es. Unless for transition purposes as was mentioned. - kurtis - --On Tuesday, June 11, 2002 9:58 PM +0100 Stephen J. Wilcox [EMAIL PROTECTED] wrote: I'm not familiar with all the RIR policies but RIPE is very straightforward, if you want an ASN you have to be multihomed. I cant see any logic why another RIR would be different in its approach... In my experience its far easier to get an ASN from RIPE than an IP assignment approved. For the latter you need to prove all kinds of things as to why you need it, for an ASN all you have to do is prove you have two upstream ISPs and nothing more! Steve On Tue, 11 Jun 2002, Sabri Berisha wrote: On Tue, 11 Jun 2002, Stephen J. Wilcox wrote: Ugh, this is why ASN's exist and is why ppl have been posting about inconsistent BGP announcements of late If you originate the same block from 2 ASNs then you no longer have a single administrative area and need a 3rd ASN as per the RFC. And if your regional registry refuses to assign an ASN you are cooked and you will probably end up using a solution like this. I'm not saying its good, I'm saying its bad, but unfortunately common practice.
Re: Error in assignments....?
On Tue, 11 Jun 2002, Joe Provo wrote: On Tue, Jun 11, 2002 at 03:00:41PM +0200, Kurt Erik Lindqvist wrote: [snip] Ok, my fault. I ment to say route object. However, I fail to see why (if) you would like to allow the same route to source from muliple AS:es The easy answer is that there is trash in the IRR. This is correct. When looking a little closer or talking about a well-run source DB consider the consolidation of multiple ASNs, customers getting their BGP training wheels, etc other typical origin changes. To smooth over any origin changes, it makes sense to get route objects in at least a day or two in advance; if you're doing large scale projects long-term overlaps are not at all uncommon. These are operationally valid cases where multiple route objects might exist for a single prefix (as opposed to errors such as left over cruft). If you think of the IRR as a 'flight plan' or the list of intended possibilities then it makes more sense than trying to treat it as a strict tracking of the live BGP table state. The latter would bring you nothing but woe. Agreed. For good reason you shouldn't be able to delete other networks route objects. Correspondingly it is left to each network to clean up their own registrations. This can be hard when the company in question no longer exists per se. (CRL was acquired by Applied Theory which filed for bankruptcy, whose assets were recently acquired by Fastnet.) The IRRs don't check third party sources for validation of route objects and even if they did the address registries don't map prefixes to AS numbers. This is an interesting subject to think about, however many of the solutions end up being very complicated like S-BGP if they try to address every issue. Mike. +--- H U R R I C A N E - E L E C T R I C ---+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: Error in assignments....?
On 6/12/02 6:10 PM, Mike Leber [EMAIL PROTECTED] wrote: On Tue, 11 Jun 2002, Sabri Berisha wrote: On Tue, 11 Jun 2002, Kurt Erik Lindqvist wrote: route: 209.81.0.0/19 origin:AS7091 The netblock you are referring to is not globally visible btw. Correct, ViaNet is announcing 209.81.0.0/18 now and the 209.81.0.0/19 is an example of that cruft I was talking about that people should clean up. (typing in the background as somebody sends in an update ;) Mike. Even when CRL was alive (not just a zombie) we were never able to get them to clean this up.
Error in assignments....?
Uhm, from whois.ra.net : route: 209.81.0.0/19 descr: ViaNet Communications 1235 Pear Ave, Suite 107 Mountain View, CA 94043 origin:AS7091 notify:[EMAIL PROTECTED] notify:[EMAIL PROTECTED] mnt-by:HE-NOC changed: [EMAIL PROTECTED] 19970808 source:RADB route: 209.81.0.0/19 descr: CRL Network Services Box 326 Larkspur CA 94977, USA origin:AS2041 member-of: RS-COMM_NSFNET mnt-by:MAINT-AS2041 changed: [EMAIL PROTECTED] 19990223 source:RADB ??? - kurtis -
RE: Error in assignments....?
Kurt Erik Lindqvist wrote: Uhm, from whois.ra.net : route: 209.81.0.0/19 origin:AS7091 source:RADB route: 209.81.0.0/19 origin:AS2041 source:RADB RADB are a routing registry not an address space registry. Consult ARIN, APNIC, RIPE, etc for IP space ownership details. Any RADB member can register pretty much any route/AS pair and many members don't bother to put real details when it comes to owner of the route, etc (putting the ISP instead of the customer). David. -- David Luyer Phone: +61 3 9674 7525 Network Development ManagerP A C I F I CFax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 BYTE http://www.pacific.net.au/ NASDAQ: PCNTF
Re: Error in assignments....?
A route is something different then an IP assignment/allocation. There can be multipe routes and multiple originating AS's for a netblock. The netblock you are referring to is not globally visible btw. Ok, my fault. I ment to say route object. However, I fail to see why (if) you would like to allow the same route to source from muliple AS:es Best regards, - kurtis -
Re: Error in assignments....?
On Tue, Jun 11, 2002 at 03:00:41PM +0200, Kurt Erik Lindqvist wrote: [snip] Ok, my fault. I ment to say route object. However, I fail to see why (if) you would like to allow the same route to source from muliple AS:es The easy answer is that there is trash in the IRR. When looking a little closer or talking about a well-run source DB consider the consolidation of multiple ASNs, customers getting their BGP training wheels, etc other typical origin changes. To smooth over any origin changes, it makes sense to get route objects in at least a day or two in advance; if you're doing large scale projects long-term overlaps are not at all uncommon. If you think of the IRR as a 'flight plan' or the list of intended possibilities then it makes more sense than trying to treat it as a strict tracking of the live BGP table state. The latter would bring you nothing but woe. Cheers, Joe -- Joe ProvoVoice 508.486.7471 Director, Internet Planning Design Fax508.229.2375 Network Deployment Management, RCN [EMAIL PROTECTED]
Re: Error in assignments....?
I'm not familiar with all the RIR policies but RIPE is very straightforward, if you want an ASN you have to be multihomed. I cant see any logic why another RIR would be different in its approach... In my experience its far easier to get an ASN from RIPE than an IP assignment approved. For the latter you need to prove all kinds of things as to why you need it, for an ASN all you have to do is prove you have two upstream ISPs and nothing more! Steve On Tue, 11 Jun 2002, Sabri Berisha wrote: On Tue, 11 Jun 2002, Stephen J. Wilcox wrote: Ugh, this is why ASN's exist and is why ppl have been posting about inconsistent BGP announcements of late If you originate the same block from 2 ASNs then you no longer have a single administrative area and need a 3rd ASN as per the RFC. And if your regional registry refuses to assign an ASN you are cooked and you will probably end up using a solution like this. I'm not saying its good, I'm saying its bad, but unfortunately common practice.
