summaryrefslogtreecommitdiffstats
path: root/bgpd/bgp_lcommunity.h
diff options
context:
space:
mode:
authorPascal Mathis <mail@pascalmathis.com>2018-05-13 02:29:40 +0200
committerPascal Mathis <mail@pascalmathis.com>2018-05-13 19:37:51 +0200
commit8d9b8ed99de997a4ade10b98aac4ea43add2f9c8 (patch)
tree109db36e85e78c402790f37d15de6096fd2877c4 /bgpd/bgp_lcommunity.h
parentMerge pull request #2217 from donaldsharp/pim_threads (diff)
downloadfrr-8d9b8ed99de997a4ade10b98aac4ea43add2f9c8.tar.xz
frr-8d9b8ed99de997a4ade10b98aac4ea43add2f9c8.zip
bgpd: Improve JSON support for large communities
The current implementation of building JSON output is greatly different for large communities compared to standard communities. This is mainly noticeable by the missing 'list' attribute, which usually offers an array of all communities present on a BGP route. This commit adds the missing functionality of properly returning a 'list' attribute in JSON output and also tries a similar approach like the standard communities are using to implement this feature. Additionally, the 'format' specifier has been completely removed from large communities string/JSON rendering, as the official RFC8092 specifies that there is only one canonical representation: > The canonical representation of BGP Large Communities is three > separate unsigned integers in decimal notation in the following > order: Global Administrator, Local Data 1, Local Data 2. Numbers > MUST NOT contain leading zeros; a zero value MUST be represented with > a single zero. Each number is separated from the next by a single > colon. For example: 64496:4294967295:2, 64496:0:0. As the 'format' specifier has not been used/checked and only one canonical representation exists per today, there was no reason to keep the 'format' parameter in the function signature. Last but not least, the struct attribute 'community_entry.config' is no longer being used for large communities and instead 'lcommunity_str' is being called to maintain a similar approach to standard communities. As a side effect, this also fixed a memory leak inside 'community_entry_free' which did not free the allocated memory for the 'config' attribute when dealing with a large community. Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
Diffstat (limited to 'bgpd/bgp_lcommunity.h')
-rw-r--r--bgpd/bgp_lcommunity.h11
1 files changed, 5 insertions, 6 deletions
diff --git a/bgpd/bgp_lcommunity.h b/bgpd/bgp_lcommunity.h
index 78841accf..c88a01639 100644
--- a/bgpd/bgp_lcommunity.h
+++ b/bgpd/bgp_lcommunity.h
@@ -21,10 +21,7 @@
#ifndef _QUAGGA_BGP_LCOMMUNITY_H
#define _QUAGGA_BGP_LCOMMUNITY_H
-/* Extended communities attribute string format. */
-#define LCOMMUNITY_FORMAT_ROUTE_MAP 0
-#define LCOMMUNITY_FORMAT_COMMUNITY_LIST 1
-#define LCOMMUNITY_FORMAT_DISPLAY 2
+#include "lib/json.h"
/* Large Communities value is twelve octets long. */
#define LCOMMUNITY_SIZE 12
@@ -40,6 +37,9 @@ struct lcommunity {
/* Large Communities value. */
uint8_t *val;
+ /* Large Communities as a json object */
+ json_object *json;
+
/* Human readable format string. */
char *str;
};
@@ -65,10 +65,9 @@ extern void lcommunity_unintern(struct lcommunity **);
extern unsigned int lcommunity_hash_make(void *);
extern struct hash *lcommunity_hash(void);
extern struct lcommunity *lcommunity_str2com(const char *);
-extern char *lcommunity_lcom2str(struct lcommunity *, int);
extern int lcommunity_match(const struct lcommunity *,
const struct lcommunity *);
-extern char *lcommunity_str(struct lcommunity *);
+extern char *lcommunity_str(struct lcommunity *, bool make_json);
extern int lcommunity_include(struct lcommunity *lcom, uint8_t *ptr);
extern void lcommunity_del_val(struct lcommunity *lcom, uint8_t *ptr);
#endif /* _QUAGGA_BGP_LCOMMUNITY_H */