)]}' { "log": [ { "commit": "60cc95921ae663de325ca3e76e8c05d8224986ab", "tree": "7d78102aa9650da4bba1355b2a6601135d687b37", "parents": [ "4feb0d02c029e2e4f229f6283f579b8673b0ac11" ], "author": { "name": "Pradosh Mohapatra", "email": "pmohapat@cumulusnetworks.com", "time": "Mon Nov 09 20:21:41 2015 -0500" }, "committer": { "name": "Paul Jakma", "email": "paul.jakma@hpe.com", "time": "Tue Sep 13 10:36:44 2016 +0100" }, "message": "bgpd, doc, lib, zebra: nexthop-tracking in zebra\n\n0. Introduction\n\nThis is the design specification for next hop tracking feature in\nQuagga.\n\n1. Background\n\nRecursive routes are of the form:\n\n p/m --\u003e n\n [Ex: 1.1.0.0/16 --\u003e 2.2.2.2]\n\nwhere \u0027n\u0027 itself is resolved through another route as follows:\n\n p2/m --\u003e h, interface\n [Ex: 2.2.2.0/24 --\u003e 3.3.3.3, eth0]\n\nUsually, BGP routes are recursive in nature and BGP nexthops get\nresolved through an IGP route. IGP usually adds its routes pointing to\nan interface (these are called non-recursive routes).\n\nWhen BGP receives a recursive route from a peer, it needs to validate\nthe nexthop. The path is marked valid or invalid based on the\nreachability status of the nexthop. Nexthop validation is also\nimportant for BGP decision process as the metric to reach the nexthop\nis a parameter to best path selection process.\n\nAs it goes with routing, this is a dynamic process. Route to the\nnexthop can change. The nexthop can become unreachable or\nreachable. In the current BGP implementation, the nexthop validation\nis done periodically in the scanner run. The default scanner run\ninterval is one minute. Every minute, the scanner task walks the\nentire BGP table. It checks the validity of each nexthop with Zebra\n(the routing table manager) through a request and response message\nexchange between BGP and Zebra process. BGP process is blocked for\nthat duration. The mechanism has two major drawbacks:\n\n(1) The scanner task runs to completion. That can potentially starve\n the other tasks for long periods of time, based on the BGP table\n size and number of nexthops.\n\n(2) Convergence around routing changes that affect the nexthops can be\n long (around a minute with the default intervals). The interval\n can be shortened to achieve faster reaction time, but it makes the\n first problem worse, with the scanner task consuming most of the\n CPU resources.\n\n\"Next hop tracking\" feature makes this process event-driven. It\neliminates periodic nexthop validation and introduces an asynchronous\ncommunication path between BGP and Zebra for route change notifications\nthat can then be acted upon.\n\n2. Goal\n\nStating the obvious, the main goal is to remove the two limitations we\ndiscussed in the previous section. The goals, in a constructive tone,\nare the following:\n\n- fairness: the scanner run should not consume an unjustly high amount\n of CPU time. This should give an overall good performance and\n response time to other events (route changes, session events,\n IO/user interface).\n\n- convergence: BGP must react to nexthop changes instantly and provide\n sub-second convergence. This may involve diverting the routes from\n one nexthop to another.\n\n3. Overview of the changes\n\nThe changes are in both BGP and Zebra modules. The short summary is\nthe following:\n\n- Zebra implements a registration mechanism by which clients can\n register for next hop notification. Consequently, it maintains a\n separate table, per (VRF, AF) pair, of next hops and interested\n client-list per next hop.\n\n- When the main routing table changes in Zebra, it evaluates the next\n hop table: for each next hop, it checks if the route table\n modifications have changed its state. If so, it notifies the\n interested clients.\n\n- BGP is one such client. It registers the next hops corresponding to\n all of its received routes/paths. It also threads the paths against\n each nexthop structure.\n\n- When BGP receives a next hop notification from Zebra, it walks the\n corresponding path list. It makes them valid or invalid depending\n on the next hop notification. It then re-computes best path for the\n corresponding destination. This may result in re-announcing those\n destinations to peers.\n\n4. Design\n\n4.1. Modules\n\nThe core design introduces an \"nht\" (next hop tracking) module in BGP\nand \"rnh\" (recursive nexthop) module in Zebra. The \"nht\" module\nprovides the following APIs:\n\nbgp_find_or_add_nexthop() : find or add a nexthop in BGP nexthop table\nbgp_find_nexthop() : find a nexthop in BGP nexthop table\nbgp_parse_nexthop_update() : parse a nexthop update message coming\n from zebra\n\nThe \"rnh\" module provides the following APIs:\n\nzebra_add_rnh() : add a recursive nexthop\nzebra_delete_rnh() : delete a recursive nexthop\nzebra_lookup_rnh() : lookup a recursive nexthop\n\nzebra_add_rnh_client() : register a client for nexthop notifications\n against a recursive nexthop\n\nzebra_remove_rnh_client(): remove the client registration for a\n recursive nexthop\n\nzebra_evaluate_rnh_table(): (re)evaluate the recursive nexthop table\n (most probably because the main routing\n table has changed).\n\nzebra_cleanup_rnh_client(): Cleanup a client from the \"rnh\" module\n data structures (most probably because the\n client is going away).\n\n4.2. Control flow\n\nThe next hop registration control flow is the following:\n\n\u003c\u003d\u003d\u003d\u003d BGP Process \u003d\u003d\u003d\u003d\u003e|\u003c\u003d\u003d\u003d\u003d Zebra Process \u003d\u003d\u003d\u003d\u003e\n |\nreceive module nht module | zserv module rnh module\n----------------------------------------------------------------------\n | | |\nbgp_update_ | | |\n main() | bgp_find_or_add_ | |\n | nexthop() | |\n | | |\n | | zserv_nexthop_ |\n | | register() |\n | | | zebra_add_rnh()\n | | |\n\nThe next hop notification control flow is the following:\n\n\u003c\u003d\u003d\u003d\u003d Zebra Process \u003d\u003d\u003d\u003d\u003e|\u003c\u003d\u003d\u003d\u003d BGP Process \u003d\u003d\u003d\u003d\u003e\n |\nrib module rnh module | zebra module nht module\n----------------------------------------------------------------------\n | | |\nmeta_queue_ | | |\n process() | zebra_evaluate_ | |\n | rnh_table() | |\n | | |\n | | bgp_read_nexthop_ |\n | | update() |\n | | | bgp_parse_\n | | | nexthop_update()\n | | |\n\n4.3. zclient message format\n\nZEBRA_NEXTHOP_REGISTER and ZEBRA_NEXTHOP_UNREGISTER messages are\nencoded in the following way:\n\n/*\n * 0 1 2 3\n * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * | AF | prefix len |\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * . Nexthop prefix .\n * . .\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * . .\n * . .\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * | AF | prefix len |\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * . Nexthop prefix .\n * . .\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n */\n\nZEBRA_NEXTHOP_UPDATE message is encoded as follows:\n\n/*\n * 0 1 2 3\n * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * | AF | prefix len |\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * . Nexthop prefix getting resolved .\n * . .\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * | metric |\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * | #nexthops |\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * | nexthop type |\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * . resolving Nexthop details .\n * . .\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * . .\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * | nexthop type |\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n * . resolving Nexthop details .\n * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n */\n\n4.4. BGP data structure\n\nLegend:\n\n/\\ struct bgp_node: a BGP destination/route/prefix\n\\/\n\n[ ] struct bgp_info: a BGP path (e.g. route received from a peer)\n\n _\n(_) struct bgp_nexthop_cache: a BGP nexthop\n\n /\\ NULL\n \\/--+ ^\n | :\n +--[ ]--[ ]--[ ]--\u003e NULL\n /\\ :\n \\/--+ :\n | :\n +--[ ]--[ ]--\u003e NULL\n :\n _ :\n (_).............\n\n4.5. Zebra data structure\n\nrnh table:\n\n O\n / \\\n O O\n / \\\n O O\n\n struct rnh\n {\n u_char flags;\n struct rib *state;\n struct list *client_list;\n struct route_node *node;\n };\n\n5. User interface changes\n\nquagga# show ip nht\n3.3.3.3\n resolved via kernel\n via 11.0.0.6, swp1\n Client list: bgp(fd 12)\n11.0.0.10\n resolved via connected\n is directly connected, swp2\n Client list: bgp(fd 12)\n11.0.0.18\n resolved via connected\n is directly connected, swp4\n Client list: bgp(fd 12)\n11.11.11.11\n resolved via kernel\n via 10.0.1.2, eth0\n Client list: bgp(fd 12)\n\nquagga# show ip bgp nexthop\nCurrent BGP nexthop cache:\n 3.3.3.3 valid [IGP metric 0], #paths 3\n Last update: Wed Oct 16 04:43:49 2013\n\n 11.0.0.10 valid [IGP metric 1], #paths 1\n Last update: Wed Oct 16 04:43:51 2013\n\n 11.0.0.18 valid [IGP metric 1], #paths 2\n Last update: Wed Oct 16 04:43:47 2013\n\n 11.11.11.11 valid [IGP metric 0], #paths 1\n Last update: Wed Oct 16 04:43:47 2013\n\nquagga# show ipv6 nht\nquagga# show ip bgp nexthop detail\n\nquagga# debug bgp nht\nquagga# debug zebra nht\n\n6. Sample test cases\n\n r2----r3\n / \\ /\n r1----r4\n\n- Verify that a change in IGP cost triggers NHT\n + shutdown the r1-r4 and r2-r4 links\n + no shut the r1-r4 and r2-r4 links and wait for OSPF to come back\n up\n + We should be back to the original nexthop via r4 now\n- Verify that a NH becoming unreachable triggers NHT\n + Shutdown all links to r4\n- Verify that a NH becoming reachable triggers NHT\n + no shut all links to r4\n\n7. Future work\n\n- route-policy for next hop validation (e.g. ignore default route)\n- damping for rapid next hop changes\n- prioritized handling of nexthop changes ((un)reachability vs. metric\n changes)\n- handling recursion loop, e.g.\n 11.11.11.11/32 -\u003e 12.12.12.12\n 12.12.12.12/32 -\u003e 11.11.11.11\n 11.0.0.0/8 -\u003e \u003cinterface\u003e\n- better statistics\nAddresses upstream comments.\n\n\"show ip bgp nexthop detail\" couldn\u0027t display multiple NHs due to a bug.\nFix that.\n\nFix reference counts for the nexthop cache entries\n\nSigned-off-by: Pradosh Mohapatra \u003cpmohapat@cumulusnetworks.com\u003e\nSigned-off-by: Daniel Walton \u003cdwalton@cumulusnetworks.com\u003e\nSigned-off-by: Dinesh Dutt \u003cddutt@cumulusnetworks.com\u003e\nSigned-off-by: Donald Sharp \u003csharpd@cumulusnetworks.com\u003e\nSigned-off-by: Vivek Venkatraman \u003cvivek@cumulusnetworks.com\u003e\n\nFix reference counts for the nexthop cache entries.\n\nSigned-off-by: Vivek Venkatraman \u003cvivek@cumulusnetworks.com\u003e\n\nEdited-by: Paul Jakma \u003cpaul.jakma@hpe.com\u003e\n- Fix nexthop_ipv6_add defs in rib.h not having been modified with rib_ prefix.\n- Remove rib_lookup_and_pushup, appears not to be used except for\n !HAVE_NETLINK \u0026\u0026 HAVE_STRUCT_IFALIASREQ case of ioctl.c::if_set_prefix,\n so it\u0027s not being used at all on platform with most testing of RIB.\n" }, { "commit": "82dd707988b7481e203cab058c92f0b3041dd558", "tree": "01923f2a1a5b0ca381e9eb7b093f467ca4cc942b", "parents": [ "13c378d96a57017f5995b2e0df46cfc31123f0e8" ], "author": { "name": "Lou Berger", "email": "lberger@labn.net", "time": "Tue Jan 12 13:41:57 2016 -0500" }, "committer": { "name": "Paul Jakma", "email": "paul.jakma@hpe.com", "time": "Fri Feb 26 14:11:43 2016 +0000" }, "message": "bgpd: improve cleanup in bgp_delete()\n\nSigned-off-by: Lou Berger \u003clberger@labn.net\u003e\n" }, { "commit": "3e841d3b49bdb475ce793eee5d82e5137dff57d3", "tree": "6d3d9a0dde3bcd83631b2abd7764e13d7485b9ae", "parents": [ "2daf7f3a8d69213f35b16a04dbe300957481a811" ], "author": { "name": "Lou Berger", "email": "lberger@labn.net", "time": "Tue Jan 12 13:41:51 2016 -0500" }, "committer": { "name": "Paul Jakma", "email": "paul.jakma@hpe.com", "time": "Fri Feb 26 14:11:42 2016 +0000" }, "message": "bgpd: add nexthop length to AF macro\n\nSigned-off-by: Lou Berger \u003clberger@labn.net\u003e\nSigned-off-by: David Lamparter \u003cequinox@opensourcerouting.org\u003e\n" }, { "commit": "10f9bf3f2021f874e574e4ebae9413bee982ed2b", "tree": "5102a98c91d7d60380c07c08d0aaa32aa19cdbdf", "parents": [ "f669f7d25f0f491d5e487897227ff434aef20406" ], "author": { "name": "Jorge Boncompte [DTI2]", "email": "jorge@dti2.net", "time": "Mon May 07 16:52:52 2012 +0000" }, "committer": { "name": "David Lamparter", "email": "equinox@opensourcerouting.org", "time": "Tue May 22 20:25:07 2012 +0200" }, "message": "bgpd: optimize bgp_nexthop_self()\n\n This function scores 2nd, profiling a full internet table load. It\u0027s called\nfor every prefix received.\n Instead of looping in the interface lists comparing addresses use a hash\nto mantain them.\n\n* bgpd.c: Init the own address hash.\n* bgp_nexthop.c: Introduce methods to maintain an own address hash.\n (bgp_connected_add) add addresses to the hash.\n (bgp_connected_delete) delete addresses from the hash.\n (bgp_nexthop_self) lookup addresses in the hash. Removed the unused afi_t\n parameter.\n* bgp_route.c: (bgp_update_main) Micro-optimization, rearranged condition to\n not lookup the hash for bogus nexthops (0.0.0.0 or a class D/E address)\n\nSigned-off-by: Jorge Boncompte [DTI2] \u003cjorge@dti2.net\u003e\nSigned-off-by: David Lamparter \u003cequinox@opensourcerouting.org\u003e\n" }, { "commit": "8e80bdf20f493a71bcf74262ed3aa3a2437f4df6", "tree": "b1ebddbda4b8f12a28c3ce6299ebe931105a25b6", "parents": [ "23be94ea00fadace0007b6ffa6c9107124249e91" ], "author": { "name": "Denis Ovsienko", "email": "infrastation@yandex.ru", "time": "Fri Aug 05 18:52:52 2011 +0400" }, "committer": { "name": "Paul Jakma", "email": "paul@quagga.net", "time": "Sun Jan 08 11:30:55 2012 +0000" }, "message": "bgpd: touch nexthop handling code\n\nbgp_nexthop_lookup_ipv6(): declare variables where they are actually\nused, drop no-op initialization (the field is already 0)\nbgp_nexthop_lookup(): ditto\nbgp_nexthop_check_ebgp(): rename to bgp_nexthop_onlink()\nbgp_nexthop_cache_changed(): rename to bgp_nexthop_cache_different()\n" }, { "commit": "228da42898c4f7bd72d9c1ee4135108e8d40d860", "tree": "a780ed018bfeb97c174958f188c770c74a48bad9", "parents": [ "54a15182e05ca757db3bb90a4135e9f8fd3c84f2" ], "author": { "name": "Chris Caputo", "email": "ccaputo@alt.net", "time": "Sat Jul 18 05:44:03 2009 +0000" }, "committer": { "name": "Paul Jakma", "email": "paul@quagga.net", "time": "Sun Jul 19 18:28:08 2009 +0100" }, "message": "[bgpd] Stability fixes including bugs 397, 492\n\nI\u0027ve spent the last several weeks working on stability fixes to bgpd.\nThese patches fix all of the numerous crashes, assertion failures, memory\nleaks and memory stomping I could find. Valgrind was used extensively.\n\nAdded new function bgp_exit() to help catch problems. If \"debug bgp\" is\nconfigured and bgpd exits with status of 0, statistics on remaining\nlib/memory.c allocations are printed to stderr. It is my hope that other\ndevelopers will use this to stay on top of memory issues.\n\nExample questionable exit:\n\n bgpd: memstats: Current memory utilization in module LIB:\n bgpd: memstats: Link List : 6\n bgpd: memstats: Link Node : 5\n bgpd: memstats: Hash : 8\n bgpd: memstats: Hash Bucket : 2\n bgpd: memstats: Hash Index : 8\n bgpd: memstats: Work queue : 3\n bgpd: memstats: Work queue item : 2\n bgpd: memstats: Work queue name string : 3\n bgpd: memstats: Current memory utilization in module BGP:\n bgpd: memstats: BGP instance : 1\n bgpd: memstats: BGP peer : 1\n bgpd: memstats: BGP peer hostname : 1\n bgpd: memstats: BGP attribute : 1\n bgpd: memstats: BGP extra attributes : 1\n bgpd: memstats: BGP aspath : 1\n bgpd: memstats: BGP aspath str : 1\n bgpd: memstats: BGP table : 24\n bgpd: memstats: BGP node : 1\n bgpd: memstats: BGP route : 1\n bgpd: memstats: BGP synchronise : 8\n bgpd: memstats: BGP Process queue : 1\n bgpd: memstats: BGP node clear queue : 1\n bgpd: memstats: NOTE: If configuration exists, utilization may be expected.\n\nExample clean exit:\n\n bgpd: memstats: No remaining tracked memory utilization.\n\nThis patch fixes bug #397: \"Invalid free in bgp_announce_check()\".\n\nThis patch fixes bug #492: \"SIGBUS in bgpd/bgp_route.c:\nbgp_clear_route_node()\".\n\nMy apologies for not separating out these changes into individual patches.\nThe complexity of doing so boggled what is left of my brain. I hope this\nis all still useful to the community.\n\nThis code has been production tested, in non-route-server-client mode, on\na linux 32-bit box and a 64-bit box.\n\nRelease/reset functions, used by bgp_exit(), added to:\n\n bgpd/bgp_attr.c,h\n bgpd/bgp_community.c,h\n bgpd/bgp_dump.c,h\n bgpd/bgp_ecommunity.c,h\n bgpd/bgp_filter.c,h\n bgpd/bgp_nexthop.c,h\n bgpd/bgp_route.c,h\n lib/routemap.c,h\n\nFile by file analysis:\n\n* bgpd/bgp_aspath.c: Prevent re-use of ashash after it is released.\n\n* bgpd/bgp_attr.c: #if removed uncalled cluster_dup().\n\n* bgpd/bgp_clist.c,h: Allow community_list_terminate() to be called from\n bgp_exit().\n\n* bgpd/bgp_filter.c: Fix aslist-\u003ename use without allocation check, and\n also fix memory leak.\n\n* bgpd/bgp_main.c: Created bgp_exit() exit routine. This function frees\n allocations made as part of bgpd initialization and, to some extent,\n configuration. If \"debug bgp\" is configured, memory stats are printed\n as described above.\n\n* bgpd/bgp_nexthop.c: zclient_new() already allocates stream for\n ibuf/obuf, so bgp_scan_init() shouldn\u0027t do it too. Also, made it so\n zlookup is global so bgp_exit() can use it.\n\n* bgpd/bgp_packet.c: bgp_capability_msg_parse() call to bgp_clear_route()\n adjusted to use new BGP_CLEAR_ROUTE_NORMAL flag.\n\n* bgpd/bgp_route.h: Correct reference counter \"lock\" to be signed.\n bgp_clear_route() now accepts a bgp_clear_route_type of either\n BGP_CLEAR_ROUTE_NORMAL or BGP_CLEAR_ROUTE_MY_RSCLIENT.\n\n* bgpd/bgp_route.c:\n - bgp_process_rsclient(): attr was being zero\u0027ed and then\n bgp_attr_extra_free() was being called with it, even though it was\n never filled with valid data.\n\n - bgp_process_rsclient(): Make sure rsclient-\u003egroup is not NULL before\n use.\n\n - bgp_processq_del(): Add call to bgp_table_unlock().\n\n - bgp_process(): Add call to bgp_table_lock().\n\n - bgp_update_rsclient(): memset clearing of new_attr not needed since\n declarationw with \"\u003d { 0 }\" does it. memset was already commented\n out.\n\n - bgp_update_rsclient(): Fix screwed up misleading indentation.\n\n - bgp_withdraw_rsclient(): Fix screwed up misleading indentation.\n\n - bgp_clear_route_node(): Support BGP_CLEAR_ROUTE_MY_RSCLIENT.\n\n - bgp_clear_node_queue_del(): Add call to bgp_table_unlock() and also\n free struct bgp_clear_node_queue used for work item.\n\n - bgp_clear_node_complete(): Do peer_unlock() after BGP_EVENT_ADD() in\n case peer is released by peer_unlock() call.\n\n - bgp_clear_route_table(): Support BGP_CLEAR_ROUTE_MY_RSCLIENT. Use\n struct bgp_clear_node_queue to supply data to worker. Add call to\n bgp_table_lock().\n\n - bgp_clear_route(): Add support for BGP_CLEAR_ROUTE_NORMAL or\n BGP_CLEAR_ROUTE_MY_RSCLIENT.\n\n - bgp_clear_route_all(): Use BGP_CLEAR_ROUTE_NORMAL.\n\n Bug 397 fixes:\n\n - bgp_default_originate()\n - bgp_announce_table()\n\n* bgpd/bgp_table.h:\n - struct bgp_table: Added reference count. Changed type of owner to be\n \"struct peer *\" rather than \"void *\".\n\n - struct bgp_node: Correct reference counter \"lock\" to be signed.\n\n* bgpd/bgp_table.c:\n - Added bgp_table reference counting.\n\n - bgp_table_free(): Fixed cleanup code. Call peer_unlock() on owner if\n set.\n\n - bgp_unlock_node(): Added assertion.\n\n - bgp_node_get(): Added call to bgp_lock_node() to code path that it was\n missing from.\n\n* bgpd/bgp_vty.c:\n - peer_rsclient_set_vty(): Call peer_lock() as part of peer assignment\n to owner. Handle failure gracefully.\n\n - peer_rsclient_unset_vty(): Add call to bgp_clear_route() with\n BGP_CLEAR_ROUTE_MY_RSCLIENT purpose.\n\n* bgpd/bgp_zebra.c: Made it so zclient is global so bgp_exit() can use it.\n\n* bgpd/bgpd.c:\n - peer_lock(): Allow to be called when status is \"Deleted\".\n\n - peer_deactivate(): Supply BGP_CLEAR_ROUTE_NORMAL purpose to\n bgp_clear_route() call.\n\n - peer_delete(): Common variable listnode pn. Fix bug in which rsclient\n was only dealt with if not part of a peer group. Call\n bgp_clear_route() for rsclient, if appropriate, and do so with\n BGP_CLEAR_ROUTE_MY_RSCLIENT purpose.\n\n - peer_group_get(): Use XSTRDUP() instead of strdup() for conf-\u003ehost.\n\n - peer_group_bind(): Call bgp_clear_route() for rsclient, and do so with\n BGP_CLEAR_ROUTE_MY_RSCLIENT purpose.\n\n - bgp_create(): Use XSTRDUP() instead of strdup() for peer_self-\u003ehost.\n\n - bgp_delete(): Delete peers before groups, rather than after. And then\n rather than deleting rsclients, verify that there are none at this\n point.\n\n - bgp_unlock(): Add assertion.\n\n - bgp_free(): Call bgp_table_finish() rather than doing XFREE() itself.\n\n* lib/command.c,h: Compiler warning fixes. Add cmd_terminate(). Fixed\n massive leak in install_element() in which cmd_make_descvec() was being\n called more than once for the same cmd-\u003estrvec/string/doc.\n\n* lib/log.c: Make closezlog() check fp before calling fclose().\n\n* lib/memory.c: Catch when alloc count goes negative by using signed\n counts. Correct #endif comment. Add log_memstats_stderr().\n\n* lib/memory.h: Add log_memstats_stderr().\n\n* lib/thread.c: thread-\u003efuncname was being accessed in thread_call() after\n it had been freed. Rearranged things so that thread_call() frees\n funcname. Also made it so thread_master_free() cleans up cpu_record.\n\n* lib/vty.c,h: Use global command_cr. Add vty_terminate().\n\n* lib/zclient.c,h: Re-enable zclient_free().\n" }, { "commit": "5304cb52f47a646554241b3bc1d1dab9ccaea73d", "tree": "7de840321cf650b83aeb992d6bbcb57a93dd855a", "parents": [ "cec0c4fb1beb024e54d134a419893e2ad4389254" ], "author": { "name": "Paul Jakma", "email": "paul.jakma@sun.com", "time": "Thu Mar 30 14:01:14 2006 +0000" }, "committer": { "name": "Paul Jakma", "email": "paul.jakma@sun.com", "time": "Thu Mar 30 14:01:14 2006 +0000" }, "message": "[bgpd] Include header dependency in bgp_nexthop.h\n\n2006-03-19 Paul Jakma \u003cpaul.jakma@sun.com\u003e\n\n\t* bgp_nexthop.h: Include if.h as a dependent header, for struct\n\t connected.\n" }, { "commit": "94f2b3923e9663d0355a829f22e4e31cf68ee7b8", "tree": "59c0291a76b1c97fbb089abb479307f19cdfd4c1", "parents": [ "7cad40007b9714dba65065916ea68577f9d3d6dd" ], "author": { "name": "paul", "email": "paul", "time": "Tue Jun 28 12:44:16 2005 +0000" }, "committer": { "name": "paul", "email": "paul", "time": "Tue Jun 28 12:44:16 2005 +0000" }, "message": "2005-06-28 Paul Jakma \u003cpaul.jakma@sun.com\u003e\n\n\t* (global) The great bgpd extern and static\u0027ification.\n\t* bgp_routemap.c: remove unused ROUTE_MATCH_ASPATH_OLD code\n\t (route_set_metric_compile) fix u_int32_t to ULONG_MAX comparison\n\t warnings.\n\t* bgp_route.h: (bgp_process, bgp_withdraw, bgp_update) export these\n\t used by various files which had their own private declarations,\n\t in the case of mplsvpn - incorrect.\n" }, { "commit": "00d252cb5ff21ecc537ab40385316b41622a95e2", "tree": "c0132f4be53d8ae251ecb1dd8c39816f8734d08f", "parents": [ "269d74fdc39a612da8f627bf97628c68d25a16ab" ], "author": { "name": "paul", "email": "paul", "time": "Mon May 23 14:19:54 2005 +0000" }, "committer": { "name": "paul", "email": "paul", "time": "Mon May 23 14:19:54 2005 +0000" }, "message": "2005-05-23 Paul Jakma \u003cpaul@dishone.st\u003e\n\n\t* bgp_fsm.h: Add extern qualifier to exported functions\n\t* bgp_nexthop.c: add static to nexthop specific globals\n\t* *.h: Add guard defines\n" }, { "commit": "718e3744195351130f4ce7dbe0613f4b3e23df93", "tree": "bac2ad39971cd43f31241ef123bd4e470f695ac9", "parents": [], "author": { "name": "paul", "email": "paul", "time": "Fri Dec 13 20:15:29 2002 +0000" }, "committer": { "name": "paul", "email": "paul", "time": "Fri Dec 13 20:15:29 2002 +0000" }, "message": "Initial revision\n" } ] }