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

[Marko Zec]

On Tuesday 14 September 2010 18:39:17 Simon van der Linden wrote:
> Hi,
>
> 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.

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.

Hope this helps,

Marko