diff options
| author | Pascal Mathis <mail@pascalmathis.com> | 2018-05-13 02:29:40 +0200 |
|---|---|---|
| committer | Pascal Mathis <mail@pascalmathis.com> | 2018-05-13 19:37:51 +0200 |
| commit | 8d9b8ed99de997a4ade10b98aac4ea43add2f9c8 (patch) | |
| tree | 109db36e85e78c402790f37d15de6096fd2877c4 /bgpd/bgp_clist.c | |
| parent | Merge pull request #2217 from donaldsharp/pim_threads (diff) | |
| download | frr-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_clist.c')
| -rw-r--r-- | bgpd/bgp_clist.c | 11 |
1 files changed, 3 insertions, 8 deletions
diff --git a/bgpd/bgp_clist.c b/bgpd/bgp_clist.c index d1bc7f6e5..7cf147754 100644 --- a/bgpd/bgp_clist.c +++ b/bgpd/bgp_clist.c @@ -512,7 +512,7 @@ static int lcommunity_regexp_match(struct lcommunity *com, regex_t *reg) if (com == NULL || com->size == 0) str = ""; else - str = lcommunity_str(com); + str = lcommunity_str(com, false); /* Regular expression match. */ if (regexec(reg, str, 0, NULL, 0) == 0) @@ -986,13 +986,8 @@ int lcommunity_list_set(struct community_list_handler *ch, const char *name, entry->any = (str ? 0 : 1); entry->u.lcom = lcom; entry->reg = regex; - if (lcom) - entry->config = lcommunity_lcom2str( - lcom, LCOMMUNITY_FORMAT_COMMUNITY_LIST); - else if (regex) - entry->config = XSTRDUP(MTYPE_COMMUNITY_LIST_CONFIG, str); - else - entry->config = NULL; + entry->config = + (regex ? XSTRDUP(MTYPE_COMMUNITY_LIST_CONFIG, str) : NULL); /* Do not put duplicated community entry. */ if (community_list_dup_check(list, entry)) |