[Xorp-users] BGP packing not performed while dumping route table

[Simon van der Linden]

On mer, 2010-09-15 at 17:50 +0200, Marko Zec wrote:
> On Tuesday 14 September 2010 18:39:17 Simon van der Linden wrote:
> > I noticed that when a BGP peering comes up, the route table is dumped to
> > the new peer, but no packing is performed, that is, two prefixes with
> > the same set of attributes are sent in two separate UPDATEs instead of
> > only one.
> >
> > >From what I read in bgp/route_table_ribout.cc, packing is possible. Does
> > anyone has a possible explanation about this behavior? Otherwise, I'll
> > dig into it someday.
> 
> As far as I can recall it, when a BGP peering comes up, a dedicated stage 
> called dumptable is injected at the beginning of the outbound path of the new 
> peering pipeline.  The sole purpose of this stage is to scan through all the 
> existing winning routes and push them one by one further down the pipeline, 
> where each prefix might or might not get axed, or have its path attributes 
> modified, by a filtering / policy stage, before it would eventually reach the 
> ribout stage, which then packs it into a BGP update message.

Right. From what I have understood so far, it seems the dumptable calls
add_route downstream for each route, which gets immediately pushed to
the peer_handler, instead of being queued, and later pushed, so as to
make packing possible in the ribout.

> The fundamental problem is that dumptables scan over the entire IPv4 / IPv6 
> address space when emitting updates downstream, instead of using path 
> attributes as the first-level iteration key.  That said, even if a sequence 
> of prefixes with identical path attributes would make it to the ribout stage, 
> that would happen out of pure luck, i.e. with real-world BGP feeds that would 
> be a rather unlikely event.  So extending bgp/route_table_ribout.cc to 
> coalesce multiple prefixes with identical path attributes into a single BGP 
> update message is unlikely to make a significant impact, without first 
> rearchitecting the way in which dumptables emit prefixes, which might be a 
> much more difficult problem to solve.

I'd like to measure the impact of packing in various situations (notably
for routing table transfers when a peering comes up) on some chosen set
of routes. In some data I retrieved from routeviews, there are a bit
less than 4 prefixes with the same set of attributes, on average.

Thanks,

Simon