Add support to track bgp communities #1068

New Issue

adam · 2025-12-29T16:28:29+01:00

adam commented

2025-12-29 16:28:29 +01:00

Originally created by @ryanmerolle on GitHub (Jul 1, 2017).

Though netbox does not support tracking dynamic routing peering or route advertisements, it would be very useful to track communities in the IPAM section.

For those who do not use communities in BGP, see this NANOG presentation for a summary.

The beauty of tracking communities in IPAM is that it allows you to track the your intended routing policy if you leverage communities for such.

I suggest the feature track 32-bit integers which allow for colons within the community field. Next each community could track a name/description along with a note field. Like prefixes, communities could be grouped by parent and child communities. So for example all communities beginning with the same number and then separated by a colon could be grouped under one parent community if that signified some logic. For example all communities beginning 701: could be group by what ever the common function is. Optionally, communities could also be associated to prefixes and vrfs.

Originally created by @ryanmerolle on GitHub (Jul 1, 2017). Though netbox does not support tracking dynamic routing peering or route advertisements, it would be very useful to track communities in the IPAM section. For those who do not use communities in BGP, see [this NANOG presentation ](https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf) for a summary. The beauty of tracking communities in IPAM is that it allows you to track the your intended routing policy if you leverage communities for such. I suggest the feature track 32-bit integers which allow for colons within the community field. Next each community could track a name/description along with a note field. Like prefixes, communities could be grouped by parent and child communities. So for example all communities beginning with the same number and then separated by a colon could be grouped under one parent community if that signified some logic. For example all communities beginning 701: could be group by what ever the common function is. Optionally, communities could also be associated to prefixes and vrfs.

adam closed this issue

2025-12-29 16:28:29 +01:00

adam commented

2025-12-29 16:28:29 +01:00

@ryanmerolle commented on GitHub (Jul 1, 2017):

This issue/feature relates to, but is not dependent on #127. I also seemed to have found a somewhat duplicate feature in #1060 that @jeremystretch closed, but instead of just closing this myself, I'll leave it open at the off chance I described a narrower scope.

Frankly, like ASNs, prefixes, and VRFs, it would just be used to document the intended state of the network for all, and not delve into some of the areas we are trying to keep out of scope of netbox.

@ryanmerolle commented on GitHub (Jul 1, 2017): This issue/feature relates to, but is not dependent on #127. I also seemed to have found a somewhat duplicate feature in #1060 that @jeremystretch closed, but instead of just closing this myself, I'll leave it open at the off chance I described a narrower scope. Frankly, like ASNs, prefixes, and VRFs, it would just be used to document the intended state of the network for all, and not delve into some of the areas we are trying to keep out of scope of netbox.

adam commented

2025-12-29 16:28:30 +01:00

@jeremystretch commented on GitHub (Jul 5, 2017):

This is one of those things that falls pretty squarely into the realm of policy management. Yes, it'd be nice to add to NetBox, but doing so opens the door for things like firewall policies, prefix lists, QoS classifications, etc. We already have a huge backlog of feature requests for things more pertinent to NetBox's core functions, so I'm going to have to maintain my stance of eschewing policy-centric features until we have a more complete product.

@jeremystretch commented on GitHub (Jul 5, 2017): This is one of those things that falls pretty squarely into the realm of policy management. Yes, it'd be nice to add to NetBox, but doing so opens the door for things like firewall policies, prefix lists, QoS classifications, etc. We already have a huge backlog of feature requests for things more pertinent to NetBox's core functions, so I'm going to have to maintain my stance of eschewing policy-centric features until we have a more complete product.

adam referenced this issue

2025-12-29 16:32:22 +01:00

Add Chinese translations #1476

adam referenced this issue

2025-12-29 16:32:42 +01:00

Support more languages #1527

adam referenced this issue

2025-12-29 18:32:15 +01:00

Add chinese translation #3950

Sign in to join this conversation.