You are here: Home > Manage IPs and ASNs > RIPE Database > dbupdate > Reading dbupdate acknowledgments

Reading dbupdate acknowledgments

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 _at_ ripe _dot_ net 
Subject: Route update
To: auto-dbm _at_ ripe _dot_ 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 _at_ ripe _dot_ net 20020101
source:     DB-TEST

route:      20.0.0.0/8
descr:      parent route object
origin:     AS100
mnt-by:     PARENT-MB-MNT
changed:    dbtest _at_ ripe _dot_ 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 _at_ ripe _dot_ 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 _at_ ripe _dot_ net>
To: dbtest _at_ ripe _dot_ 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 _at_ ripe _dot_ net> not <auto-dbm _at_ ripe _dot_ 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 _at_ ripe _dot_ net       
>  Subject:    Route update    
>  Date:       Wed, 23 Apr 2003 12:01:07 +0200      
>  Reply-To:   dbtest _at_ ripe _dot_ net   
>  Message-ID: <20030423100107.GA26859 _at_ somebox.ripe _dot_ 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 _at_ ripe _dot_ 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 _at_ ripe _dot_ net>

Back to the RIPE Database dbupdate page