Policy Description
This document describes two aspects of BGP network control that can be used to form policy decisions throughout the JT Network.
Please note that this policy may not yet be in effect across the whole of AS8681.
It has a number of purposes:
- To allow JT networks and its’ customers to use communities in order to control how prefixes are handled within the network when announcing to external parties.
- To provide a coherent and conformant policy on BGP prefix management within the network.
- To allow JT to increase the efficiency of its’ use of external links.
It is divided into the following sections:
- Description of communities
- The use of communities in the JT network (both for classification and for control)
Communities
The notation used to represent community values splits the 32-bit attribute into two 16-bit decimal numbers seperated by a single colon `:’. Conventionally, the left-hand value is an AS number and the other is site defined.
There are some predefined community values that are common to all AS’s. Refer to RFC1997 and RFC1998 for more details on Communities.
Use of communities in the JT Network
There are two uses for communities in the JT network: classification of prefixes and control of prefixes.
Only JT itself classifies prefixes as they enter the network at its’ borders. Customers and peers should not do so (and such communities will be filtered at the JT border). These attributes can be used by multihomed downstreams to weight traffic in order to distribute it according to local administrative policies. Prefixes are classified according to geographic entry point, class of prefix (Transit, Public Peering, Private Peering) and which entity of each class (Specific Transit provider, Public Peering point etc).
Prefix control allows the path-extension or filtering entirely of customer prefixes where they are announced at the borders of Jersey Telecoms’ network. Only class of network (Transit, Public Peering, Private Peering) and/or class entity (Specific Transit provider, specific Public Peering point etc) can be targeted.
As a matter of policy, the AS number used for all community strings is AS8681. This allows for consistency across the network.
There are five classes of communities, identified by the number of digits in the right-hand side:
| 1 digit | prefix classification by distribution range |
|---|---|
| 2 digits | local preference control and blackholing |
| 3 digits | prefix classification by peer or IXP from which it was received |
| 4 digits | outgoing announcement control |
| 5 digits | prefix classification by location at which it was received |
In addition to the communities listed below, the well-known communities (local-AS, no-advertise and no-export) are recognised and can be used (in fact, they’re handled automatically by the routers).
One-digit communities
These communities are set by JT upon entry on the network. They indicate the type of prefix and how it should be distributed. The following communities are used:
| 8681:1 | AS8681 Internal Routes | These are locally originated internal-only routes which aren’t announced to any peers. |
|---|---|---|
| 8681:2 | AS8681 Supernets | These are Jersey Telecom’s own supernet routes. Unless specifically supressed by other means, this prefix will be announced everywhere, including upstreams and peers. This is announced to transit, peering and customers. |
| 8681:3 | Customer Originated Routes | These are Jersey Telecom’s BGP customer routes. Unless specifically supressed by other means, this prefix will be announced everywhere, including upstreams and peers. This is announced to transit, peering and customers. |
| 8681:4 | Peer Originated Routes | This is a prefix received from a private or public IXP peer. This is announced to customers. |
| 8681:5 | Transit Originated Routes | Originated Network This is a prefix recieved from a transit provider. This is announced to customers. |
| 8681:8 | DDoS Mitigated Prefixes | Prefixes with this community are forwarded to the mitigation platform. |
| 8681:9 | Blackholed Prefixes | Prefixes with this community are installed in the forwarding table with a “discard” next hop, i.e. packets with the appropriate destination are discarded instead of forwarded. |
Two-digit communities
Customers can set two-digit communities to control which local preference prefixes receive. A two digit community may also be used to enable network-wide blackholing of the announced prefix.
Community Pref
---------------------------------------------------------
50 Last Resort Transit
75 Transit
100 Peering
8681:10 110 Depreferred DSL Routes
8681:13 130 Depreferred Customer Routes / Default for DSL Routes
8681:15 150 Default for Customer Routes
8681:17 170 Preferred Customer Route
200 Default for JT-originated Routes
8681:99 Blackhole - All traffic to this prefix will be
blackholed at JT's border
Three-digit communities
Prefixes coming from peers and transit will be tagged with three-digit community values, e.g. a prefix received at DECIX will be tagged with 8681:641. Only the most specific community is added, e.g. a route from DECIX will not have 8681:640 set. Additionally prefixes from peers will be tagged with a 4xx community based on speed of the interconnection.
Community Entry point ---------------------------------------------------------- 8681:10x Internal Routes 8681:101 Redistributed Connected Routes 8681:102 Redistributed Static Routes 8681:103 Private-AS BGP Routes 8681:11x Internal DSL Routes 8681:111 Redistributed ADSL Connected Routes 8681:112 Redistributed ADSL Static Routes 8681:113 Private-AS BGP ADSL Routes 8681:4xx Special Markings 8681:410 From a Low capacity IXP (10Mbps) 8681:411 From a Medium capacity IXP (100Mbps) 8681:411 From a High capacity IXP (1Gbps) 8681:5xx External Transit *** 8681:520 Level(3) *** 8681:530 Level(3) Paris *** 8681:540 AboveNet *** 8681:550 Cogent *** 8681:560 SURE PEERING *** 8681:570 COGENT PARIS *** 8681:591 Hurricane Electric (IPv6) *** 8681:592 Tele2 (IPv6) *** 8681:6xx From an IXP / NAP *** 8681:61x From UK IXPs *** 8681:611 From LINX *** 8681:612 From LoNAP 8681:62x From FR IXPs 8681:621 From PaNAP 8681:622 From FreeIX 8681:623 From SFIX 8681:63x From NL IXPs 8681:631 From AMS-IX 8681:632 From NL-IX 8681:64x From DE IXPs 8681:641 From DE-CIX 8681:7xx From a Private Peer 8681:71x From a UK private peering 8681:800 Tunneled IPv6 Routes *** 8681:801 Tunneled IPv6 Peer *** 8681:802 Tunneled IPv6 Customer *** 8681:999 Invalid communities recieved
Four-digit communities
Customers can set four-digit communities to control where prefixes are announced. The three-digit communities are used as a base for this and prefixed by 1, 2, 3 or 9 to control prepending of the customer’s prefix on announcement to peers or transits on the specified location.
| 8681:1xxx | Prepend announcement with “8681” on its AS-path |
|---|---|
| 8681:2xxx | Prepend announcement with “8681 8681” |
| 8681:3xxx | Prepend announcement with “8681 8681 8681” |
| 8681:8xxx | Do not prepend (such as when prepend is default) |
| 8681:9xxx | Filter announcement, i.e. don’t announce |
For example, setting the community 8681:9611 will have the effect that the network on which it is set will not be announced to LINX, whereas setting 8681:9400 will have the effect that the network on which it is set will not be announced to any low-speed IXP or private peer.
These communities may not be implemented in the whole network. When used, it should be verified that the specific community is honored. Otherwise you can request that it is implemented.
For a wider range, the “x” in the list of entry points can be replaced by “0”. So for example “8681:2610” will result in a prepend of length two on all IXPs in the UK, and “8681:2500” has the effect of prepending 8681 to all transits.
Five-digit communities
Every prefix has a five-digit community set which tells on which location it was received. This community has the following format:
8681:1<cc><loc>
where <cc> usually is the country code with possible additions or modification, and <loc> is a number for each of the POPs/locations in the country.
Community Entry point --------------------------------------- 8681:1xxxx Channel Islands 8681:101xx Jersey 8681:10101 Central Exchange 8681:10102 Trinity Gardens 8681:10103 North Exchange 8681:10104 South Exchange 8681:10105 East Exchange 8681:10106 West Exchange 8681:10107 Five Oaks/TEC 8681:10108 TEC Colo 8681:10109 East Colo 8681:10110 Central Colo 8681:10111 No.1 The Forum 8681:10112 No.2 The Forum 8681:10113 Channel House 8681:10114 Queen Street Shop 8681:10115 Rue des Pres 8681:10116 Hue Court SDR 8681:10117 Jardin du Soleil SDR 8681:10118 Waterfront SDR 8681:10119 Snow Hill SDR 8681:10120 Fort Regent SDR 8681:10121 Sandybrook SDR 8681:10122 Hodge Nurseries SDR 8681:10123 La Chasse SDR 8681:10124 Trinity SDR 8681:10125 St. Martin.s SDR 8681:10126 Mont Mado Store 8681:10127 Victoria Tower 8681:102xx Guernsey 8681:10201 St Georges (POP1) 8681:10202 Broadcasting House (POP2) 8681:10203 ITEX Braye Road 8681:10204 ITEX Gibauderie 8681:10205 First Tower Lane 8681:10206 St Georges Hall 8681:10207 Pitronnerie 8681:10208 St Martins 8681:10209 Castel 8681:10210 Alderney 8681:2xxxx Europe 8681:231xx NL 8681:13100 NL Originated Supernets 8681:233xx FR 8681:23300 FR Originated Supernets 8681:23301 FT Aubervilliers 8681:244xx UK 8681:24400 UK Originated Supernets 8681:24401 Telehouse North 8681:24402 Telehouse East 8681:24403 Telecity Powergate 8681:24404 Telecity Harbour Exchange 8681:249xx DE 8681:24900 DE Originated Supernets 8681:30000 North America 8681:301xx USA 8681:30100 USA Originated Supernets 8681:4xxxx Asia 8681:485xx HK 8681:48501 Hong Kong Originated Supernets 8681:999xx International 8681:99900 Unspecified Originated Supernets
Filtering Communities
JT will filter all 8681:* communities received via any external BGP peering, apart from 8681:xxxx and 8681:xx from customers, which can be used to control announcements. Any route containing improper communities will have all communities stripped and will be tagged with the special alert community of 8681:6666.
All other communities are accepted and passed unchanged and ignored.