summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorDonald Sharp <sharpd@cumulusnetworks.com>2015-05-20 02:40:34 +0200
committerDonald Sharp <sharpd@cumulusnetworks.com>2015-05-20 02:40:34 +0200
commit73ac816057d972d9d13236fbe1a740167ad26f37 (patch)
treef899eafbd96f26dcb537a8519bd9b35f79b549af /doc
parentPatch to produce output of BGP commands in csv format. Useful for easier scri... (diff)
downloadfrr-73ac816057d972d9d13236fbe1a740167ad26f37.tar.xz
frr-73ac816057d972d9d13236fbe1a740167ad26f37.zip
bgpd: bgpd-table-map.patch
COMMAND: table-map <route-map-name> DESCRIPTION: This feature is used to apply a route-map on route updates from BGP to Zebra. All the applicable match operations are allowed, such as match on prefix, next-hop, communities, etc. Set operations for this attach-point are limited to metric and next-hop only. Any operation of this feature does not affect BGPs internal RIB. Supported for ipv4 and ipv6 address families. It works on multi-paths as well, however, metric setting is based on the best-path only. IMPLEMENTATION NOTES: The route-map application at this point is not supposed to modify any of BGP route's attributes (anything in bgp_info for that matter). To achieve that, creating a copy of the bgp_attr was inevitable. Implementation tries to keep the memory footprint low, code comments do point out the rationale behind a few choices made. bgp_zebra_announce() was already a big routine, adding this feature would extend it further. Patch has created a few smaller routines/macros whereever possible to keep the size of the routine in check without compromising on the readability of the code/flow inside this routine. For updating a partially filtered route (with its nexthops), BGP to Zebra replacement semantic of the next-hops serves the purpose well. However, with this patch there could be some redundant withdraws each time BGP announces a route thats (all the nexthops) gets denied by the route-map application. Handling of this case could be optimized by keeping state with the prefix and the nexthops in BGP. The patch doesn't optimizing that case, as even with the redundant withdraws the total number of updates to zebra are still be capped by the total number of routes in the table. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Diffstat (limited to 'doc')
-rw-r--r--doc/bgpd.texi11
1 files changed, 11 insertions, 0 deletions
diff --git a/doc/bgpd.texi b/doc/bgpd.texi
index 10fe13ca2..5dd4ed616 100644
--- a/doc/bgpd.texi
+++ b/doc/bgpd.texi
@@ -247,6 +247,17 @@ and generates updates to its peers.
Default max-delay is 0, i.e. the feature is off by default.
@end deffn
+@deffn {BGP} {table-map @var{route-map-name}} {}
+This feature is used to apply a route-map on route updates from BGP to Zebra.
+All the applicable match operations are allowed, such as match on prefix,
+next-hop, communities, etc. Set operations for this attach-point are limited
+to metric and next-hop only. Any operation of this feature does not affect
+BGPs internal RIB.
+
+Supported for ipv4 and ipv6 address families. It works on multi-paths as well,
+however, metric setting is based on the best-path only.
+@end deffn
+
@node BGP Peer
@section BGP Peer