Introduction
This page describes the acknowledgement messages sent from the RIPE
Database after an update is processed. It presents a typical route update
and explains the reply.
Sample update
Assume the following e-mail was sent to the database:
From: dbtest@ripe.net
Subject: Route update
To: auto-dbm@ripe.net
Please update these routes:
password: mb-child
password: ml-parent
route: 20.13.0.0/16
descr: Route
origin: AS200
mnt-by: CHILD-MB-MNT
changed: dbtest@ripe.net 20020101
source: DB-TEST
route: 20.0.0.0/8
descr: parent route object
origin: AS100
mnt-by: PARENT-MB-MNT
changed: dbtest@ripe.net 20020101
source: DB-TEST
Regards
LIR Admin
|
After the e-mail is received, it will be processed. A reply will be
sent to thesending address, <dbtest@ripe.net> in
this case.
Reply details
The complete reply can be seen here.
Mail headers
The mail header will look like this:
From: RIPE Database Management <ripe-dbm@ripe.net>
To: dbtest@ripe.net
Subject: FAILED: Route update
|
The most important part is the "FAILED:" text added to the subject
line in the reply. A failed update is an update that has one or more
objects with errors. An update where there were no failures has "SUCCEEDED:"
added to the subject line.
Also notice that the e-mail is from <ripe-dbm@ripe.net> not
<auto-dbm@ripe.net>. This is to ensure that a user who is confused
by the e-mail from the database receives a human if they reply to it.
Update mail headers
The next part of the message includes some of the headers of the update:
> From: dbtest@ripe.net
> Subject: Route update
> Date: Wed, 23 Apr 2003 12:01:07 +0200
> Reply-To: dbtest@ripe.net
> Message-ID: <20030423100107.GA26859@somebox.ripe.net>
|
The headers are quoted with the '>' symbol,used in the same way
as many e-mail clients. These headers are included to help users identify
the reply, and is also useful when RIPE DBM receives questions about
specific updates. The message-id is especially helpful, because it uniquely
identifies the update. If you send an e-mail to RIPE DBM please include
this information.
Summary of update
Following the headers, a summary of the update can be seen:
SUMMARY OF UPDATE:
Number of objects found: 2
Number of objects processed successfully: 1
Create: 1
Modify: 0
Delete: 0
No Operation: 0
Number of objects processed with errors: 1
Create: 0
Modify: 1
Delete: 0
Syntax Errors: 0
|
The total number of objects in the message is reported. This is futher
broken down to successes and failures, and then by type within each
of the following categories:
- "Create" refers to attempts to create new objects.
- "Modify" refers to attempts to change existing objects.
- "Delete" refers to attempts to delete existing objects.
- "No Operation" refers to objects that do not have any changes.
- "Syntax Errors" refers to objects that could not be parsed, therefore
it was not possible to determine what type of operation was intended.
Message-level detailed
reply
Next begins a detailed report. In many cases it will not be necessary
to look any further, e.g. if all updates are successful.
DETAILED EXPLANATION:
***Warning: Invalid keyword(s) found: Route, update
***Warning: All keywords were ignored
|
The above warnings are regarding the subject line, "Route update" of
the update e-mail. Certain words have special meaning, as defined in
section 3.3.3 of the RIPE
Database Reference Manual. Any other words in the subject are reported
here.
Failure details
Next a detailed report about each object with errors is given. This
section begins with the following text:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following object(s) were found to have ERRORS:
|
All objects with errors are reported as a group. Failures are reported
first.
Object-level information
Details about each object are then reported. This section starts with
three dashes followed by the type of update that was attempted, the
primary key of the object, and any object-level information about the
update:
---
Modify FAILED: [route] 20.0.0.0/8AS100
***Error: Authorisation failed
***Info: Syntax check passed
|
Object details
The original object sent to the database then follows:
route: 20.0.0.0/8
descr: parent route object
origin: AS100
mnt-by: PARENT-MB-MNT
changed: dbtest@ripe.net 20020101
source: DB-TEST
|
This is helpful to give the full context of the update.Errors associated
with a specific attribute are reported here, immediately following the
attribute.
Authorisation information
For all objects that require authorisation from a maintainer, the authorisation
checks are reported as follows:
***Info: Authorisation for [route] 20.0.0.0/8AS100
using mnt-by:
not authenticated by: PARENT-MB-MNT
|
Each object that is used to authorise the update is listed, along with
the attributes checked. Since this is a modify, the object itself is
used and the maintainers in any "mnt-by:" attributes must authorise
the update. In this example, the PARENT-MB-MNT maintainer was not properly
authenticated.
Other information may also be reported here, e.g. if disallowed "status:"
attributes are used.
Success details
After all of the failed updates have been reported, a section for the
successful updates follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following object(s) were processed SUCCESSFULLY:
|
As with failures, all objects without errors are reported as a group.
Object-level information
Details about each object are then reported. This section starts with
three dashes followed by the type of update that was attempted, the
primary key of the object, and any object-level information about the
update:
---
Create SUCCEEDED: [route] 20.13.0.0/16AS200
|
For successful operations, the complete original object is not returned.
Authorisation information
For all objects that required authorisation from a maintainer, the
authorisation checks are reported as follows:
***Info: Authorisation for parent [route] 20.0.0.0/8AS100
using mnt-lower:
authenticated by: PARENT-ML-MNT
***Info: Authorisation for origin [aut-num] AS200
using mnt-by:
authenticated by: CHILD-MB-MNT
***Info: Authorisation for [route] 20.13.0.0/16AS200
using mnt-by:
authenticated by: CHILD-MB-MNT
|
This was a route creation, therefore the parent address space and the
originating route were both required for authorisation.The key of the
objects used and the attributes checked are reported, as well as any
maintainers that were authenticated in this update.Finally, the authorisation
for the new object itself is reported.
Non-object text
If there was any text in the message that did not look like an object,
it is reported at the end. This typically includes greetings and signatures:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following paragraph(s) do not look like objects
and were NOT PROCESSED:
Please update these routes:
Regards
LIR Admin
|
RIPE DBM signature
Finally, the RIPE DBM mailbox information is added explaining where
to send any questions or suggestions:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For assistance or clarification please contact:
RIPE Database Administration <ripe-dbm@ripe.net>
|
Back to the
RIPE Database dbupdate page
| 
you are here: home -> RIPE Database
