Cisco & Meraki specialists. Across the UK.
+44 203 196 6566 · option 1sales@proxar.co.uk

Connect. Secure. Manage.

BGP Communities and Policy

Develop a documented Cisco BGP community strategy so provider requests, route handling and traffic policy remain consistent and understandable.

Cisco Partner since 2009 Projects & ongoing support

Illustrative Cisco and Meraki equipment in organised data-centre racks
Your network. Properly considered.Design · Implementation · Support
1,000+

Devices supported
across the UK

20+

Client locations
supported

Nearly 8 Tbps

Traffic handled
at peak time

3 min

Average
response time

Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.

BGP communities and policy provide a structured way to label routes and apply agreed routing decisions. They can help a Cisco network express customer groups, provider preferences, export restrictions or operational actions without maintaining separate rules for every individual prefix. MCI Network Services helps organisations build a community scheme that is understandable, controlled at trust boundaries and supported by the providers expected to act on it.

01

Cisco-focused engineering

Design around the platform, traffic and failure behaviour you actually operate.

02

Change with evidence

Use pre-checks, acceptance criteria and a documented route back.

03

Operational handover

Keep the configuration, diagrams and responsibilities understandable after delivery.

Give each community a documented meaning

A community value is useful only when its meaning is agreed. We start with the routing outcomes the business requires and identify where labels will be assigned, read and removed. The register records the value, purpose, authorised source and expected action. A number found in a configuration is not evidence that a provider still recognises it.

We distinguish internal classifications from values exchanged with external networks. An internal label might identify a site or service class; an upstream provider may use a different scheme to influence propagation or preference. The policy needs an explicit translation where those schemes meet. Reusing one convenient number for unrelated purposes makes later troubleshooting unnecessarily difficult.

Illustrative Cisco and Meraki industrial network equipment in a plant environment
01Network engineering for operational and industrial environments.
Cisco PartnerCisco Partner
Cisco MerakiCisco Meraki
ISO 9001Quality management
ISO 27001Information security
Cyber EssentialsCyber Essentials
Cyber Essentials PlusCyber Essentials Plus

MCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information

Choose the appropriate community type

Standard, extended and large communities have different formats and uses. We check which types the Cisco platforms, address families and remote peers support. A requirement involving four-byte autonomous-system identifiers, for example, deserves more thought than assuming a legacy numbering convention will remain convenient indefinitely.

This is an implementation decision rather than a reason to complicate every network. A small, well-documented standard-community scheme may meet the requirement. A more extensive environment may benefit from a structured large-community namespace. The design should explain why the selected format fits the estate and how new values will be allocated without collisions.

Illustrative Cisco and Meraki data-centre network infrastructure
02Network infrastructure designed around the workloads it carries.

A useful starting point

Not sure where to start?

Bring the requirement. We will help you define the engineering work.

Talk to a specialist

Treat received labels as untrusted input

An external neighbour should not be able to trigger privileged internal policy merely by attaching a familiar community. We review which values are accepted, stripped or replaced at each boundary. Classification that affects sensitive routing decisions should come from an authorised source or be assigned locally after the route has passed the relevant checks.

We also examine route-map ordering and whether an action adds to existing communities or replaces them. An apparently small configuration change can erase a label that another part of the network relies on. The policy review follows the route across several devices to establish the combined effect, rather than inspecting one command in isolation.

Illustrative Cisco and Meraki network rack in a modern office
03The office network: switching, uplinks and structured cabling.

Coordinate provider actions carefully

Provider communities may influence regional advertisement, local preference, prepending or other documented behaviour. The available actions differ by service and provider. We obtain the applicable technical specification and confirm any conditions before using a value in production. A community from another customer’s design is not a safe substitute.

Discard or remotely triggered blackhole actions require particular care. Where legitimately included in the service, we restrict who can request them, which prefixes they may affect and how the action is reversed. The aim is a controlled incident-response capability, not a label that can accidentally remove reachability to a large part of the business.

Illustrative enterprise Cisco network rack in a modern office environment
04Enterprise switching and routing, built to be operated.

Verify propagation end to end

A configured community may never reach the device expected to act on it. We check the relevant advertisement settings, policy stages and address families. The acceptance test follows a representative route from its origin to the receiving peer and confirms both the label and the resulting decision.

We include negative tests where feasible. An unauthorised community should not create a privileged outcome, and a route without the required label should follow the defined default policy. These tests are especially useful when a new scheme replaces many individual prefix rules. The migration should demonstrate that the intended protection remains in place.

Illustrative Cisco and Meraki fibre network rack with structured cabling
05Fibre, switching and the physical path behind the service.

Introduce changes without losing the old meaning

Community migrations often need a period in which old and new labels coexist. We define how that transition works, where translation occurs and when the previous values can be removed. The change plan identifies affected peers and the supported method for refreshing route information.

A rollback must restore the previous policy interpretation as well as the configuration text. We therefore record the baseline attributes and selected paths before implementation. After the change, traffic observations help confirm that the route-policy result matches the customer objective. A syntactically valid route map is only one part of acceptance.

Illustrative Cisco and Meraki equipment in organised data-centre racks
06Data-centre connectivity with clear physical and logical boundaries.

Keep the policy useful to operations

The final handover includes the community register, trust-boundary rules and examples of expected route attributes. Engineers should be able to identify why a route was treated differently without searching old email threads. We recommend reviewing unused values and provider dependencies when circuits or routing ownership change.

This work complements BGP route filtering and traffic engineering. MCI’s Cisco network services can cover a new policy scheme, an audit of existing communities or a targeted correction. The starting point is the routing behaviour you need, with every label tied to an accountable decision.

Illustrative Cisco and Meraki industrial network equipment in a plant environment
07Network engineering for operational and industrial environments.

Talk to a specialist

What does your network need next?

Tell us what you are planning, changing or trying to improve. We will help define a practical next step and the engineering scope.

+44 203 196 6566

Choose option 1

sales@proxar.co.uk

UK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.

Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.

Tell us what you need.

A short outline is enough. Please do not include passwords or sensitive network details.

Thank you. Your enquiry has been submitted.

We’ll use these details to respond to your enquiry. Please leave out passwords and sensitive network information. Read our privacy notice.