Over the last couple of weeks, a group of people using the RIS (data) decided
to hold a phone conference in order to discuss future development plans for
the RIS as well as other things, that were hard to discuss by email. Below
you can find the minutes of this meeting. We agreed to post the minutes of
this meeting here, so everybody can see what we discussed. If you have
comments on our discussion, feel free to post them to this list.
We agreed to hold another phone conference in a couple of weeks. This will be
an open forum. If you want to participate in future phone conferences, please
send mail to ris(a)ripe.net and we'll provide you with technical details.
Comments, suggestions and ideas by email to ris-users(a)ripe.net are also
welcome.
Regards,
James
--
James Aldridge, Network Engineer, New Projects Group, RIPE NCC
Tel: +31 20 535 4444 Fax: +31 20 535 4445
Singel 258 P.O. Box 10096
1016 AB Amsterdam 1001 AB Amsterdam
The Netherlands The Netherlands
----------
Notes on the RIS conference call 18:00 CET, 16 October 2003
Participants:
RIPE NCC:
Henk Uijterwaal, James Aldridge, Matthew Williams,
Arife Vural, Lorenzo Colitti, Rene Wilhelm;
Agilent:
Alex Tudor, Lance Tatman, Jerry McCollom, Hong-Wei Kong;
Technical University Munich:
Olaf Maennel
Dan Ardelean (Purdue) and Z. Morley Mao (Berkeley) provided input but were
unable to participate in the conference call.
Scribe: James Aldridge
Agenda:
1. RIPE NCC "ip2asn" service
2. Zebra/Quagga and libbgpdump
3. Beacons
4. CVS server
5. BGP decoder
6. Keepalive issues
7. Future merge with zebra
1. ip2asn
Rene Wilhelm gave an update on the current status:
- nearing completion
- raw data read from 8-hourly RIS RIB dumps
- structure built in memory
- "whois" server returns a (partial) RPSL "route" object for
compatibility with existing RIR-based tools.
Is this sufficient?
OK as a first try, but want more... summarise traceroute as AS hops,
etc.
This would be for the traceroute application to perform; ip2asn just
provides a BGP-based mapping between IP address and origin AS(es).
Is there a demand for a standalone IP to ASN server returning
additional information (incorporating database of IXP address ranges,
etc)?
Rene will provide sample output from the current ip2asn server.
2. zebra, libbgpdump
Lorenzo Colitti presented an update on changes to libbgpdump and zebra
(/quagga).
- bug fixes
- dealing with data corruption
- segmentation faults
- infinite loops
- IPv6 support
- direct gzip support (using zlib)
Importance of multi-platform support was emphasised (make it easy to
build on more systems than just FreeBSD, Linux, etc.; use "sh
./configure", etc)
Need a test plan for future changes:
- test data (known input)
- regression testing on output produced
Need to document library's behaviour for specific cases of bad input
data.
Needs to report back statistics from processing input file (in Hong
Wei's version?)
Summary of libbgpdump-1.3.1
- backward compatible for input data
- baseline release for further integration
Aim towards a replacement for "route_btoa".
3. beacons
James Aldridge summarised recent changes to the RIS BGP beacons
following input from the research community
- timestamps and sequence numbers on announcements by overloading the
AGGREGATOR attribute (similar to the PSG beacons)
- anchor prefix (195.80.239.0/24) advertised by each RRC with
per-RRC AGGREGATOR values.
Proposal to monitor RIS beacon announcements and withdrawals using an
additional bgpd with multi-hop EBGP peerings with each RRC was greeted
with interest. James will implement this and make the beacon
reference updates alongside other RIS raw data.
- Proposals from Z. Morley Mao:
"(1) Would it be possible to put a host behind a few beacon prefixes,
so that application layer traffic measurements can be conducted to
study how data plane is affected by routing changes? If bandwidth is
a concern, one can rate-limit the incoming pipe of those hosts."
Technically, it wouldn't be too difficult to add a dummy
interface with appropriate IP addresses on each RRC. However,
the current agreement with peers and RRC hosts is that there
will never be any (non-BGP) traffic to the RRCs.
"(2) Could you instrument failover scenarios for multihomed beacons,
i.e., announce withdrawal to all but one of the upstream provider to
study how long it takes to switch over to backup provider?"
RIS team will investigate this.
4. cvs server
Henk Uijterwaal summarised the current status of the RIPE NCC
providing a public CVS server for NCC-developed software.
- Other groups within the RIPE NCC also want this
- Being set up
- Requirements and specs done
- Now in the hands of RIPE NCC Ops group.
- Waiting for security sign-off
- Probably two to three weeks.
In the meantime we can exchange tarballs and patches.
5. BGP Decoder
Covered in 2 above.
6. Keepalive issues
Problems with missing keepalive messages from Zebra had previously
been seen only under Linux and it had been thought that FreeBSD was
immune to these problems. However, recent tests show that FreeBSD
also exhibits the same problems.
Removing "unnecessary" routines from Zebra bgpd solves the problem but
at the loss of required functionality.
Is this problem caused by an overloaded system or a more structural
problem in Zebra even on faster or more lightly loaded systems? This
needs to be investigated.
Can we come up with system requirements for reliable operation for BGP
collection for different setup sizes? (e.g. XXX Mhz processor, YYY
Mbytes RAM, etc. for NNN full BGP feeds)
7. Future merge of Zebra/Quagga work
Getting patches incorporated into quagga seems much easier than was
the case with Zebra.
Document results of tests and submit to quagga-dev.
Need to dump outgoing updates. Currently bgpd only dumps received
updates and we miss outgoing error responses, etc.
