On 23.01.2012 22:00, Ondrej Zajicek wrote:
On Mon, Jan 23, 2012 at 08:14:28PM +0400, Alexander V. Chernikov wrote:
On 23.01.2012 20:01, Maciej Wierzbicki wrote:
Hello.
Case study: * importing full BGP table from various uplinks * some routes received by BGP are being exported via OSPF to core1, using filters: (source = RTS_BGP&& bgp_path ~ [= * ASNXYZ * =])
Question: how to aggregate routes (whenever possible) before exporting them via OSPF to core?
It is not possible currently.
I'm working on BGP route aggregation and I plan to get more or less working code at the end of this week.
Do you plan to integrate it to the BGP protocol? I don't think it is This is separate protocol, of course. a good idea. It would be easy to make generic route aggregation - My first idea was to implement generic aggregation protocol. However, do we really need it generic? Currently we have bunch of link-state protocols (ISIS / OSPF) which are pure singletons, and, even if not we probably don't want to make summary routes between instances. RIP[ng] is RIP(c). There are also some multicast protocols but is is far-far away. Not sure if we should permit route aggregation from different protocol types.
'virtual' protocol similar to static, which generates aggregate routes based on its config and received routes
Yes. I personally see this as following: protocol abgp agg1 { aggregate address 1.2.3.0/24; aggregate address 1.2.4.0/24 save attributes (or other keywords); # Aggregate as much attributes as possible ( see RFC 4271 9.2.2.2. ) # http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094826... aggregate address 2.3.4.5.0/24 summary only; aggregate address 3.4.5.0/24 mandatory list { 3.4.5.1/32, 3.4.5.8/29}; import filter somefilter; # Change summary route attributes } protocol bgp bgp1 { .. aggregator agg1; } Rte's matching 'summary only' instances have to be modified (no-export community have to be added to community attribute) by aggregator before passing them to rte_update Mandatory list is a list of routes which have to exist before summary route is announced. [BGP] protocols using aggregator will call rte_update_agg() instead of usual rte_update() Aggregator stores its summary and mandatory routes in modified f_trie. ( I think, there is no need to import/implement another tree if we can modify current implementation: e.g. use regular pools (flag passed to f_new_trie, along with node_size) and add trie_remove_prefix ) Possibly we have to implement some kind of lazy protocol name resolving. I mean, add all "aggregator $proto_name" entries to linked-list with file/line data and do symbol lookup after configuration parsing is finished calling modified cf_error() if lookup fails. Btw, I've got small patch from my previous approach, it moves default protocol preference to struct protocol and assigns it in proto_config_new instead of assigning it in every protocol manually. Maybe it is a good candidate for the next commit? :) -- Alexander V. Chernikov Yandex NOC