Introducing the J2SW BGP Community Builder

I am excited to announce the second in my Network Tools applications: the J2SW BGP Community Builder. I designed this to help with different BGP communities and configuring them on your routers. In a nutshell, you select the provider and the routing action you want. The builder returns the community value, explains what the provider should do with it, and generates a scoped configuration fragment.

What the Builder Does

The builder currently includes 56 customer-sendable actions. It covers the RFC well-known communities along with policies published by AWS Direct Connect and NTT DATA. Hurricane Electric and Cogent Communications are also included.

The available actions depend on the selected network. AWS Direct Connect communities can control route preference. Cogent includes local-preference controls and several export policies, while NTT supports actions such as selective prepending.

Each action includes an explanation. The result also identifies the provider and the area of the routing policy affected by the community. A source link opens the documentation used when the policy was added to the builder.

Selecting a Community

Start by selecting the network or policy set. The routing-action list will change to show the communities supported by that provider. Choose the result you want instead of searching through a table of numeric values. The target ASN is not your own ASN. It identifies the peer affected by the provider policy. The field only appears when the selected community requires it.

Enter the exact IPv4 or IPv6 prefix that should receive the community. The generated policy matches that prefix before adding the selected value. This prevents a copied route-map or routing filter from tagging every route exported to the provider.

You will also enter the provider’s BGP peer address. The address identifies the session where the policy will be used, but the builder does not automatically attach a new export policy. Replacing an existing outbound policy could remove prefix filters or other community rules already applied to that neighbor. We don’t want that.

The output keeps neighbor attachment commands commented where the platform supports them. You must merge the generated fragment into the router’s existing export policy.

Generated Router Configurations

Version 1.0 generates policy fragments for MikroTik RouterOS 7 and Cisco IOS-XE. It also supports Juniper Junos and FRRouting. The output format changes when you select a different platform.

For MikroTik, the builder creates a RouterOS 7 routing-filter rule that matches the entered destination prefix. The rule appends the community instead of replacing communities already attached to the route. It then identifies the peer whose export chain needs the rule.

Cisco IOS-XE output creates an IPv4 or IPv6 prefix list based on the address entered. A route-map matches that list and adds the community with the additive option. The neighbor commands remain commented so an existing outbound route-map is not replaced by accident.

Junos output creates a named community and a policy term that matches the prefix exactly. The policy adds the community before accepting the route. A comment identifies the BGP group where the term must be merged.

FRRouting uses a prefix list and route-map structure similar to Cisco. It matches only the entered route and adds the community without removing existing values. The output includes commented neighbor lines for the selected peer.

Using the Generated Policy

Copying the community value is useful when the router already has an export policy. You can add that value to an existing term without using the full generated fragment. The explanation beside the value provides a quick check of the requested provider action.

The configuration copy button requires a valid prefix and peer address. Communities that use a selected ASN also require a value between 1 and 65535 because the current format uses a standard 16-bit community field. Invalid inputs stop the builder from producing a router fragment.

The generated configuration is a starting point for the existing BGP policy. Review the prefix match and confirm the neighbor address before applying it. Check the advertised route afterward to make sure the community left your router.

Verify the Provider Policy

Some providers must enable blackholing or another policy on the customer session before accepting the value. A route server or transit provider may also strip communities that are not allowed by its policy. Provider documentation can change. Compare the generated value with the current routing guide before applying it to production. A looking glass or received-route check can confirm whether the provider applied the requested advertisement policy.

Open the J2SW BGP Community Builder.

j2networks family of sites
https://j2sw.com
https://startawisp.info
https://indycolo.net
#packetsdownrange #routethelight