Mailing List Archive

On Monday 6 January 2003, at 18 h 53,
Paul Jakma <paulj@alphyra.ie> wrote:

> What, if anything, do people use to automate/verify BGP peering?

maximum-prefixes :-)

> dont have such a complex BGP setup that i need it, but if i did it
> seems that RPSL (see RFC2622 and RFC2650 - as used by RIPE and other
> routing db's) provides quite a rich language to specify peering
> arrangments

It has no IPv6 support, unfortunately.

> and one that ought to be easy to integrate into
> (semi-)?automated config/verification systems. (some tools exist
> already - eg see rtconfig)

The problem is not the tools, it is the database. It is not sufficiently
maintained, probably because many operators do it by hand and update the IRR
when they think of it (I've heard that ARIN and APNIC databases are much
worse.)

In one experiment I made, a third of the routes we learn over peerings are not
in the IRR. If I configure filters, I lose one third of my (gratis) peerings.
A good business for the transit providers.

On Mon, 6 Jan 2003, Stephane Bortzmeyer wrote:

> > What, if anything, do people use to automate/verify BGP peering?
>
> maximum-prefixes :-)

:)

> It has no IPv6 support, unfortunately.

perhaps not in the original RFCs, but there must be later drafts that
implement IPv6 objects, RIPE's db has IPv6 support.

> The problem is not the tools, it is the database. It is not
> sufficiently maintained, probably because many operators do it by
> hand and update the IRR when they think of it (I've heard that ARIN
> and APNIC databases are much worse.)

The public databases are not well maintained, no.

But one can run a private DB.

> In one experiment I made, a third of the routes we learn over
> peerings are not in the IRR. If I configure filters, I lose one
> third of my (gratis) peerings. A good business for the transit
> providers.

ah well.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
The goal of science is to build better mousetraps. The goal of nature
is to build better mice.

On Mon, Jan 06, 2003 at 06:53:16PM +0000, Paul Jakma wrote:
>
> why is this? do people use other tools? otherwise, what precisely is
> it that prevents use of tools that are out there?
>

As I don't care (not really, but that's another story) what is in the
routing db, retrieving as-set and pfx information is very easy if you use
extended whois and I had to do own config scripts anyway, I decided to
build an own set of scripts. Some are once-per-peer like setup and deletion.
Others are of cron type like adjusting as path filters and prefix lists.
Latter are executed once per day and loaded automagically to the routers.

Why I don't use RIPE tools? Couldn't make them compile thru. IMHO policy
checks should be done by the RIR as that is what we pay them for as well.
I second Stephane that quality of DB data is very low. People simply forget
to start garbage collection now and then. Thereby is it really simple to
have an up-to-date routing db. Erase all routes and then dump your bgp
config to the DB.


Arnold

On Mon, 6 Jan 2003, Paul Jakma wrote:

> perhaps not in the original RFCs, but there must be later drafts that
> implement IPv6 objects, RIPE's db has IPv6 support.

ah.. but only for delegating inet6num's. not it appears for BGP
peering.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
History teaches us that men and nations behave wisely once they have
exhausted all other alternatives.
-- Abba Eban

On Mon, Jan 06, 2003 at 10:42:55PM +0000, Paul Jakma wrote:
> The public databases are not well maintained, no.
>
> But one can run a private DB.
>

If you put rubbish in, you also only get rubbish out. Hence private DB is
not really a solution.

Better is to agree with your peer that both parties maintain there objects
properly. In a public DB.

Maybe lifetime of an object might also be an approach to have up-to-date
data.



Arnold

On Monday 6 January 2003, at 22 h 42,
Paul Jakma <paulj@alphyra.ie> wrote:

> > It has no IPv6 support, unfortunately.
>
> perhaps not in the original RFCs, but there must be later drafts that
> implement IPv6 objects,

Yes, several incompatible drafts (for instance, some create a new class of
'route6' objects while some reuse the 'route' class).

> RIPE's db has IPv6 support.

No, in RIPE-NCC, there is no support for IPv6 routes (there is a support for
IPv6 networks, the 'inet6num' object but you cannot register your routes like
you do with RPSL in the 'route' and 'aut-num' objects).

On Monday 6 January 2003, at 23 h 58,
Arnold Nipper <arnold@nipper.de> wrote:

> Better is to agree with your peer that both parties maintain there objects
> properly. In a public DB.

Yes, several peers force you to do so. If they are larger than you (and then
you have no bargaining power), it is convincing :-)

On Monday 6 January 2003, at 23 h 53,
Arnold Nipper <arnold@nipper.de> wrote:

> I second Stephane that quality of DB data is very low. People simply forget
> to start garbage collection now and then. Thereby is it really simple to
> have an up-to-date routing db. Erase all routes and then dump your bgp
> config to the DB.

Another approach, that we use at Gitoyen, is to produce the aut-num object
automatically from the same database that holds your peering agreements. That
way, you can have an automatically up-to-date aut-num, an automatically
up-to-date list of peers on the Web site, etc.

A small ISP has few objects to maintain and therefore has no problem keeping
them up-to-date, even by hand.

A large ISP uses a database, anyway, either a toolchain built internally or a
packaged software like RoboBijal or Northern Star and therefore has no problem
keeping the objects up-to-date (it is easy to automate the updates to the
RIPE-NCC database, may be with EPP <URL:http://www.ietf.org/html.charters/provr
eg-charter.html>, it will be even simpler and synchronous).

So, I do not see why some ISP still pretend they have no time to maintain the
IRR, but the fact is many do not keep it up-to-date.

Tip of the day: a zsh (should work with all Bourne-like shells) function to
sign and send an update to the RIPE-NCC database. Next version will add the
changed: line automatically :-)

ripe-sign-and-send() {
if [ "$1" = "" ]; then
echo "Usage: $0 file"
return
fi
if [ ! -e $1 ]; then
echo "$1 does not exist"
return
fi
gpg --clearsign --armor --output - --default-key gitoyen $1 | \
command mutt -s MODIFY \
-e 'set from=bortzmeyer@gitoyen.net; my_hdr X-NCC-Regid: fr.gitoyen' \
auto-dbm@ripe.net
}