You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
26 |
Working Group: |
Routing |
Status: |
Final |
Revision Number: |
2 |
Please mail comments/suggestions on:
The draft agenda circulated in the previous week was agreed. A copy is displayed at the end of this summary. There were no additions or changes to the minutes of the RIPE 25 Routing WG session. A short overview of open actions was given.
Last year improvements to authorisation during the interaction with the database were discussed. One of the elements is hierarchical authorisation and the first implementations of it were done for inetnum objects and domains. Up to now there is no hierarchical authorization scheme for route objects. Following the same reasoning as for inetnum objects - to protect the objects against unauthorized changes - there definitely is a need to apply hierarchical authorisation also to route objects; route objects in the RIPE database are already used by some ISPs to build configuration elements for their routers. Obviously, this calls for stronger protection.
The route objects do not stand alone. They do have relationships to other objects in the database
In a second presentation David Kessens introduced the aoe (autnum object editor). With this new tool autnum objects can be automatically generated for registries. Data of neighbors and for the policies can be taken from existing databases, from real life BGP dumps, or entered manually including heuristics. It has a user friendly interface including a GUI (based on X.11 Tcl/Tk), an "on-line" help, and it makes updates to IRRs easy. The functionality of aoe was explained by various examples and it turns out that aoe can make work with autnum objects much easier. In the future, RPSL will also be supported (up to now aoe generates RIPE-181++ syntax), cooperation with other tools will be implemented, and more and better heuristic methods will be included. The aoe shares the same requirements with the RAToolSet (which it is part of) being
During the RIPE meeting a test installation of the RA ToolSet was accessible to the participants.
The presentation was very interesting and caused a lot of discussion. Topics from the presentation and the discussion are comprised below: As it turns out there are peaks of close to 10 million BGP announcements and withdrawals in a given day with more than 100 BGP updates per second. Major providers are not major causes of instability while individual ISPs and end-sites can have a disproportionate effect on routing stability. It is interesting that BGP traffic is a function of weekday/weekend and even of the time of the day. A correlation to the amount of traffic is speculative, however there might be an indication of some correlation to maintenance work. Up to now there has been no analysis whether long holidays show in the statistics as well.
For real big instability incidents (abnormal events) Merit people called the originators of the instability to find out the reason. From a relatively low number of 36 incidents it turned out that
A graph showing the number of BGP announcements (normalized to the number of routes) seemed to indicate that the instability grows because a linear regression of the data showed an increase. However, in the discussion it was noted that there was a very large variance in the samples taken and a linear regression may not be justified and therefore misleading. Moreover, the growth in complexity of the Internet may introduce another effect: more routes are seen because of an increasing number of peerings. Therefore, a mere normalisation of the number of BGP announcements to the number of routes may not be sufficient. In the end (because the increase was not very steep), there might be no indication for a growing instability at all.
A more elaborated analysis of the BGP announcements shows that most of the BGP updates are redundant or unnecessary with a large percentage of duplicates. 99% of the BGP traffic is withdrawals. One reason for this might be that withdrawals are always sent to all peers and accepted there regardless of outgoing or incoming filters. It is suspected that this behaviour is actually wanted because especially if a new filter is set up, previously valid routes should be withdrawn anyway.
Another interesting analysis showed the frequency of BGP updates for the same prefix and origin. There were pronounced peaks at 30sec intervals. A close relation to IGP updates is suspected. However, in the discussion it was also mentioned that with Cisco routers the default keepalive on lines is 10sec and the line protocols go down after three missed keepalives which is 30sec. If immediate BGP update is configured (which is the default) then the corresponding routes are immediately withdrawn. Obviously, there are other sources for this specific frequency and a more detailed analysis should be performed.
It was a bit disappointing to have no statistics on the instability depending on the prefix length. With all the data collected an analysis like this should be possible.
Recommendations to improve routing stability were
Route Flap Dampening BOF, RIPE 26, 22.1.97, 14:00
Chairman: |
Christian Panigl (CP) |
Scribe: |
Joachim Schmitz (JS) |
Attendees: |
approx 30 |
In the Routing WG session Christian Panigl asked whether people are interested to participate in a BOF on route flap dampening. The BOF session was held after the plenary session of the RIPE meeting on Wednesday.
CP experienced quite severe reachability problems of customer networks because route flap dampening became active at various AS borders following scheduled maintenance actions on a core router. If the default dampening parameters were used everywhere, it wouldn't have hurt that much, because dampening would have lasted for ~20-30 minutes only for all prefixes.
Some backbone ISPs, however, have started to implement "progressive route flap dampening" typically using different parameters. The common effect is that longer prefixes are dampened more aggressively than shorter prefixes.
In the observed case all /24 customer networks were cut off from parts of the Internet for more than 2 hours and were no longer able to reach for instance the root nameservers. By the way, many, even top- and second-level nameservers are sitting in /24 (192/TWD) prefixes themselves and could easily be "victims" of such a progressive dampening policy ! This also applies to PI address space and multi-homed site prefixes.
CP wasn't branding route flap dampening itself, but the aggressiveness of some of the implemented "progressive" parameters and was questioning the real usefulness of progressive dampening at all.
Following CP's introduction a vivid discussion on route flap dampening came off:
The group was forming into two major camps with regard to how dampening should be done:
The default values for dampening parameters as they are found in Cisco routers are based upon some experiments approx one year ago. These experiments lead to recommendations by the IETF last year.
Nevertheless, some ISPs have moved away from the default values and are using their own parameters. Because of the urgent need of coordination of these values CP will try to collect related recommendations and the outcome of similar discussions. This is an activity of the RIPE Routing WG, therefore everybody who is aware of related efforts (IETF, NANOG, ...) should come back to the Routing WG list with hints and pointers !
- Routing Working Group Meeting -
Agenda for RIPE-26, Jan 1997, Amsterdam
Chris Fletcher, Joachim Schmitz, Christian Panigl
21/5/97