diff options
author | Donald Sharp <sharpd@cumulusnetworks.com> | 2015-05-20 02:40:34 +0200 |
---|---|---|
committer | Donald Sharp <sharpd@cumulusnetworks.com> | 2015-05-20 02:40:34 +0200 |
commit | 73ac816057d972d9d13236fbe1a740167ad26f37 (patch) | |
tree | f899eafbd96f26dcb537a8519bd9b35f79b549af /doc | |
parent | Patch to produce output of BGP commands in csv format. Useful for easier scri... (diff) | |
download | frr-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.texi | 11 |
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 |